From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5B6C63B29D for ; Tue, 18 Apr 2023 09:30:45 -0400 (EDT) Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-38e12d973bfso291787b6e.0 for ; Tue, 18 Apr 2023 06:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681824644; x=1684416644; h=content-transfer-encoding:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O+PJ9mz3o5dE3nmStFQ4JlrM+c+8jPyY+Is8VSPyvJE=; b=DzyJ1lvVeRnuAG3HJkkQoqSxSOdg9S5nYs9jiPp+dha8HkrGBGByHReahtAN93+LZ/ R9y+0wSCTRb+CdFAR7zshFPP6NTMDkN9VTqRaKoRFHBYqoHAyn8f7n38INs9jPM8/Tq4 q8LIGylzTzXcPsjKohct0Ei0CYxZZ5+eL8+n0ptaelYFBPuif7zz5mE/5FMNhw1KBsrT IFRm8SQdwNACwAdW+W4UpMbM7xJ097tlcKugSc0vHl8lC73z7aVDZJtHTb9Zi2K1nWei OUVfEPbPfjfPuQDasr//nC98SqrsnIlJWAQwlc8ynR5UfUad+IzfLn3QDN8pmTUQni9Z hCGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681824644; x=1684416644; h=content-transfer-encoding:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O+PJ9mz3o5dE3nmStFQ4JlrM+c+8jPyY+Is8VSPyvJE=; b=KKWGyEhDm1pdL7y1U98cSO4vApHuuxDcHxdwCCI8z3+z9xW3/KtyOwrwpBI26nFIWb xQhBlvsA62aRSLwh19mo7/KPeIL1Yod54EG+EcGKCRxpaMsExH7fqcJeLqA8xB4VA4in E9c00Wx5HBZmpUQPM3KS7P1ISADhV84IQwJB31pewprcfQJ5YZ1hvphiFhoEDukX0fZ9 v0pfE/O9h7hpr/3Tyomn7216tiVY+SdePYSQXzogrIwP3suIaHoEIx/9hx2kFCvlnUFA AzqCY9BHnIXh3CoEVxWOpHu9FsWCXxVxWkpXTwpipZjV6ghSZXce1sy9IzKMvGlceBwP PwHQ== X-Gm-Message-State: AAQBX9c2nAbVetdgTq+Mde0zPMRgc3cAP9YD2CZlkpEkER7HczReZKR2 MmkeWpM20D1RclQZc7BqyOJYKQK1igH/jK97vw75+bM2fWo2eg== X-Google-Smtp-Source: AKy350YOM8I9a64JNYdgAZwo7jvZAVwTNcyoSgHCB/XSJziX9d8+VstybjVZaOSo9aIf074t074nqCMzNdfjj+pYjrU= X-Received: by 2002:aca:f284:0:b0:386:be95:91e9 with SMTP id q126-20020acaf284000000b00386be9591e9mr661803oih.1.1681824644199; Tue, 18 Apr 2023 06:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6358:10a:b0:118:4a30:b981 with HTTP; Tue, 18 Apr 2023 06:30:43 -0700 (PDT) In-Reply-To: References: <202304171438.33HEcqi7056122@gndrsh.dnsmgr.net> From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Tue, 18 Apr 2023 15:30:43 +0200 Message-ID: To: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] fiber IXPs in space X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2023 13:30:45 -0000 Hi Sebastian, AFAIK, you can disable PEPs at satellite terminals web page for management, just like any other setting such as UPnP or the Wi-Fi network. Some satellite terminals do not have PEPs embedded, they are an extra HW accessory you can even remove (like this: https://www.xiplink.com) Or you can use a VPN (IPSec, Wireguard, OpenVPN...), or QUIC, instead of TC= P. If the DNS address is anycast, it is an address of a SpaceX DNS server on their gateways, and the user can configure this DNS or any other (that would not be captured and answered back by the satellite), is there really any practical difference between doing it overtly or just answering back captured DNS packets detected to that anycast addresses? Regards, David 2023-04-18 10:34 GMT+02:00, Sebastian Moeller : > Hi David, > > >> On Apr 18, 2023, at 09:46, David Fern=C3=A1ndez via Starlink >> wrote: >> >> PEPs have been mentioned as an example of so called stealth optimization= . >> >> Another example, I think it is IGMP snooping: >> https://en.wikipedia.org/wiki/IGMP_snooping > > I think this is different from "PEPs" (I really dislike the marketing > naming... IGMP snooping arguably deals to deal with the fact that IGMP ha= s a > different idea of unicast/multicast scoping than is optimal for switched = L2 > network domains... it is also as far as I can tell opt-in in that one nee= ds > to activate it in once's L2.5 devices first. I am not sure whether norrma= l > geo-stationary internet users can opt-out of the TCP shenanigans played b= y > PEPs? > >> So, well, maybe this so called DNS stealth optimization is not so bad, >> if it really is easy to implement and it brings benefits (RTT by >> half), but pros and cons should be carefully evaluated. > > I heartily disagree, stealth DNS "optimization" is not something an ISP > should be caught doing behind their users backs. I remember when my forme= r > ISPs insisted upon capturing DNS queries to non-existent domains to an > advertisement page of their own, I was neither impressed nor happy (even > though they did offer an opt-out). > Now, if a hypothetical starlink offer would do that DNS snooping only for > DNS queries directed against starlink's own DNS server IP addresses that > would be palatable from a who handles the query perspective (starlink in > both cases), but from a layering violation perspective this still seems > rather vile. If the want to offer DNS forwarders in space, they should > simply do so overtly and not high-jack packets directed to a different > server. > > At least that is my subjective take on this issue. > Regards > Sebastian > >> >> Regards, >> >> David >> >> 2023-04-17 21:00 GMT+02:00, David Lang : >>> On Mon, 17 Apr 2023, Rodney W. Grimes wrote: >>> >>>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote: >>>>> >>>>>> The idea would be that the satellite inspects IP packets and when it >>>>>> detects a DNS query, instead of forwarding the packet to ground >>>>>> station, it just answers back to the sender of the query. >>>>> >>>>> This would be a bad way to implement it. You don't want to override >>>>> queries to >>>>> other DNS servers, but it would be very easy to create an anycast >>>>> address >>>>> that >>>>> is served by the satellites. >>>> >>>> Yes, and the later is what I proposed, the idea of intercepting >>>> someone ELSE'S anycast address and processing it would be >>>> wrong in many ways, in effect a Man In the Middle attack >>>> as stated else where. >>> >>> I was assuming that it would be done in coordination with the existing >>> user, >>> not >>> as a stealth optimization. I should have made that clear. >>> >>> David Lang >>> >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink > >