[Starlink] fiber IXPs in space

[David Fernández]

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 TCP.

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 <moeller0 at gmx.de>:
> Hi David,
>
>
>> On Apr 18, 2023, at 09:46, David Fernández via Starlink
>> <starlink at lists.bufferbloat.net> 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 has 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 needs
> to activate it in once's L2.5 devices first. I am not sure whether norrmal
> geo-stationary internet users can opt-out of the TCP shenanigans played by
> 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 former
> 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 <david at lang.hm>:
>>> 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>