From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.21.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E22753B2A4 for ; Sun, 16 Apr 2023 21:57:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681696643; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=z2YcK4Xvticj3jaO7aH5VFTWe9eNorAPvo8jK7lSeXA=; b=sehSePzSqvRLrgBJIQE7+06GxqyljH3NtBzBRo/SJpDF0podGwg7Ph5zifv0IiFEEPYhwk 9l6X650ty5UjiESndusX1zzMHxGGzrFA6SYuwcK1xIZ9UAWmhpwfkDFqchH8r/bfRMmxHJ NHZGnHJYx1kU4ncdK1UG9804XAcA1qo= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2237.outbound.protection.outlook.com [104.47.71.237]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-13-aLTGQOHJMqmBrhQ1rDvMzA-1; Mon, 17 Apr 2023 11:57:22 +1000 X-MC-Unique: aLTGQOHJMqmBrhQ1rDvMzA-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by ME2PR01MB6114.ausprd01.prod.outlook.com (2603:10c6:220:e9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Mon, 17 Apr 2023 01:57:18 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::8ab6:3d14:f4e:6fa2]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::8ab6:3d14:f4e:6fa2%7]) with mapi id 15.20.6298.045; Mon, 17 Apr 2023 01:57:18 +0000 Message-ID: <48d715c9-2ce7-deb1-6ca0-4fb80ed723ca@auckland.ac.nz> Date: Mon, 17 Apr 2023 13:57:16 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: starlink@lists.bufferbloat.net References: <1681691279.13362849@apps.rackspace.com> From: Ulrich Speidel In-Reply-To: <1681691279.13362849@apps.rackspace.com> X-ClientProxiedBy: SYBPR01CA0094.ausprd01.prod.outlook.com (2603:10c6:10:3::34) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|ME2PR01MB6114:EE_ X-MS-Office365-Filtering-Correlation-Id: 067d3392-77e9-4fa9-a6ca-08db3ee71343 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: 02RXDp5PsVfr65BF9udfMcZWjYIF2Z/MjcyY7+8weqCn1/V0DlPbYoYtuDg3113W/U7AAhXiKb6dzEO4sqjGHvSCINrcdTw3ggBt7SzKTku9UnWDL/5+nGKIfaPr0OjxskRVogt0Z1tJ6hzOUpXo2KGCJpSyMsIVzNTmVIMnNuEy1U2vjZ+ju7nOQqeFy0w84y+saspBB2bI4hYFLLVpWkyMxaNEf5HON54whTngWw4w5uDdXRG0ilHVb40u0SUrPRQSGAGrLOkhN0XzIDjYBPZISYKstbhnGYc/QfHFGm9b4i+dXub4A6Ylp/wIS+yNXkqGHcoqa99OOgLS+EI0GxoQjnKilIlWqHAeR5MsvWLWO5SgUVdVgZHcVfcjafmqYf/M2yDNjlg7L/l9uPzMbqS3SEtAYyKTXSVndQs23fxR2S6KcHNrC4FiAN68GiaPCokBQXHxFh27Y9fzwor6RPGKEF6xgZTtqytL5wnRuoXm7sLcYUkU7YqJriQOBq+89dyXq02THRWgfGyGhLb8LmmLpdsm7BiBSqxJUIyPlbcimX9EbzhIl90yAS+9z3M804NBk+p7c/4zMpydKw6yk7BS+kDa4/JONfyj9pvJnKTbs+9311vHAa1MmQZAMJCSUQJ5D9GIaZ2vdKVldCxAVA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(136003)(39860400002)(396003)(366004)(346002)(376002)(451199021)(38100700002)(8676002)(8936002)(5660300002)(166002)(2906002)(36756003)(86362001)(31696002)(478600001)(33964004)(6486002)(31686004)(186003)(966005)(2616005)(6512007)(6506007)(53546011)(66476007)(66946007)(66574015)(786003)(316002)(41300700001)(83380400001)(6916009)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WWkrQTZJT2hmSGZXY2hxbnRVY0pZVllCbkZrMXNyTHpRdTlld3pTeFA0VnlP?= =?utf-8?B?aWJhY09uQmNZRVEwV05mYkpQVnJzTEZiTklUMk1QZFBQelJ4Z013YUxlZHFY?= =?utf-8?B?Y3VhempJZi9USHBUVnEwQ1ZGdnZNNXZmNXVMcGJoM3QvaUlkcFF1VnNtUlM0?= =?utf-8?B?QllrQk9MQjVNWGxKQWxGSnJCcHoxVG5ybkFQWVY1MUE1ODZoY2NNTDQ1cEEv?= =?utf-8?B?ZFhzVVUvZ3ZDTmNMRUZNNXNHZG56QzFxWUpaTHg4ekZ6NFF4NWdWcEZUejRW?= =?utf-8?B?U1NaN0lpc2xqakw5bWlwRDBzclNXRFdqYzhSWC9YRUc0OW1pazhKbG0xWm1W?= =?utf-8?B?T0dpZmMyREgzeGxwZGFrcUJGN1QrbU1xL29wRzJzc2hib1U5SlQzblhvWnBp?= =?utf-8?B?dlAvQzQ3ZEtMZEZ2dlozbUFHMDZIcGFzVmJXN2I2RCtGbFNYc1VFME1KaVFW?= =?utf-8?B?Wm0xUnJtcFduTHgwWGlWQ0NZNG1OZEdXTDVPamtObEwzR1J6ZUgrc2VPbS9R?= =?utf-8?B?YVZaK1VxU1NvVk5xeTFtM2ZvOXViL25lVmZqYllxOHROK252Uy9QU3F5cnhX?= =?utf-8?B?UFpVczJ4OXVBUW9qTk1wT3h6TnJOd2x1RzcwbjF0QitpREFvWEhwZWV2K0hL?= =?utf-8?B?Tk9wdEVJS2NCemd2azZPbjdXT0xGNlRvZE90ZmJXZTBQQ1BVbDV1M2kyVjR0?= =?utf-8?B?d092blV1Qjg4V1BxSnlVV3hwYkkveUZHbHF6Y3c1dDBQY2dXUitCTFdhQ3M1?= =?utf-8?B?Q0piRkplRW5ic29tZzl6M1B5Rlk5eWhOa3IzZ2dIelJoYWRHeWtaZ0xTM29W?= =?utf-8?B?Z3Frb1RTUEJUMENkRzVibThKWENaY1Qya2pHaXRaUndoYkVtQWF0TGxHYW5v?= =?utf-8?B?SDlNeHRnNVhLZzFJd2MyKzFNMVkyNHdxck1hdVVVUUZJN2ptcnptS3ZZSEhl?= =?utf-8?B?N1huYXdmWVk3b3dNUnFQQ1Fxb0EvU3dmclJLUVRpUEwwb3BFVmpvYmI1bG5T?= =?utf-8?B?OERlSU9jQlIwRFZNTWZ4bXVGTk5haFR0RkY2NVJLK0lLVW9vRDBoNHBJWEI1?= =?utf-8?B?ZGREOVM4NUdVcXZVQzJWMU1OTW1oU2tUSG9qNDYyaE5rV2hrc1djSUZvejJr?= =?utf-8?B?NzE1MHRKS3dQMTdRaVFpNjdmVXI3L0lGMUdFWFgzOVJHaTlRcFF3dUZTM3Fy?= =?utf-8?B?OEo0TXozeWFkRTUyQTgxTUhZcEwwV0x1NEI5aFd2UjA0QWQ5U3lkOHlObzhn?= =?utf-8?B?VzNGdWJiZnd4V25lZFpoU3hiNlZlZS91WFpCUkFEZW1PaTRoSmNOdEs0YnpL?= =?utf-8?B?V1dYTnlmbkY1Q1RwNGRMMnJvaGFMc0lPbXAvMWFvN2pzWHJreldsU0JDNnNu?= =?utf-8?B?czJpTlN2cmVVRWt1MzZXTzhybFErMnA0Rk9jNEpPcGpHcWNsNGxrai96R240?= =?utf-8?B?QUVSZWszdUlFWVFJZ2RnakZoVys5VE1vWU1KdHFFK3dObzRJdEdoVUorbC92?= =?utf-8?B?YW9YUE8wV2tXOGR5THJmNHFQckhoSjAwN3NoUlBoT2VDd1doRm1DR1V2bEJi?= =?utf-8?B?Z1laMVZGUGhTTjhBVEEySmxmeXNWU0VPTEtuWVVWNE9YYmljdFpSTW4xV000?= =?utf-8?B?djFiZS9zclhJeVZaM0M0MXBleCsxb1NMbVk4dHJhZk9WelhnbnlobjhKdWRs?= =?utf-8?B?ajBmMkZMZHNSbm5oaE0wWTNJUW1BSkZRVlZ1aUhzbWJ2L1ZZUG1JdDBWa2U1?= =?utf-8?B?YUkvbHZlZjFIMHhCTTJoZWtQbTgwVWw3aDl4MmlIN1dhNi9nT3BaSlFPZFFj?= =?utf-8?B?aThRUFBpWmtmU2oxRW1LVGlRcDQ1NWpzOWl0N2RIZUgra2ZubFBCeHpEYURl?= =?utf-8?B?TUVEek5Sd3VaSVZUSjhKTUdlSTd3OExIRzBrZzR5OW8xTEs1MGgzbXlGVmVL?= =?utf-8?B?QUpSZXNDUTNxNnFmQTM1UXhBK1BxN1NNYUpha3VUYlI1ZDgvemdPVWdrT0xY?= =?utf-8?B?OGJLVFhuVExsTkF0U3RRSCs5Q3RxYmlpQmZHNzRGaVZRYnFIWWZUMVNKQkFY?= =?utf-8?B?RmQzMUQ2SlpqYVZVaFFjT21VR0hObFhPM2VJaThia3E4RXladk1EbjYvMWZ2?= =?utf-8?B?aXRzbEZhY0R6eENDSld2OVBzWHZDOFRObnJZYTYxZ3d6MS9NY1h1MlFUQ1FU?= =?utf-8?B?WWMzbWR4M3dGaXJLY1RBNkxBdmw1SjBxNHBFUWIzc3kyaHpKOVRvQ2lLY2Nn?= =?utf-8?B?azlVcURiQ2QrbVBkTWJ6ZjlTQ2RBPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 067d3392-77e9-4fa9-a6ca-08db3ee71343 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2023 01:57:18.5922 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: M1lYooSyF/usEe/eRYrJQlsZ5GzjcbuZTIRa40gh1WrU4k0VLA8IGPZkmFbzVGgwUQ/tXYQ+CGf2s5+9LM1uqCmf1Qa0wOIqNU8DocxjHR4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB6114 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------FXMUadtXPLKMdqPfwsmmBPOq" Content-Language: en-US Subject: Re: [Starlink] 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: Mon, 17 Apr 2023 01:57:26 -0000 --------------FXMUadtXPLKMdqPfwsmmBPOq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 17/04/2023 12:27 pm, David P. Reed via Starlink wrote: > > #2: DNS service doesn't specify that "geolocation" is a function of=20 > the DNS service. It is the job of the endpoint *after resolving the=20 > DNS name to one of many IP addresses* to decide which IP address to=20 > use for the DNS name. That is, "geolocation" is an endpoint function,=20 > not something that the network does by spying on packet contents and=20 > faking a response from real DNS servers. > Oh dear. I think I didn't express myself well here - I didn't mean=20 "geolocation" in the "Internet" sense of "Where is that IP address?" but=20 in the sense of having a DNS server on a satellite that "knows" that=20 querying clients are in its topological proximity, and is able to do a=20 recursive DNS lookup for them from its own gateway DNS server (assuming=20 that gateways will function as such) - yielding the topologically=20 closest CDN server where applicable. Or - looking at it from the gateway=20 DNS perspective - knowing that any DNS queries it gets are=20 "topologically close". I shouldn't have used the term "geolocation" there. > #4: In general, IP as a protocol underlying ALL of the Internet=20 > protocols is required to deliver the content to the address specified=20 > by the sender, *without either reading or modifying the content*.=20 > There are certain cases where "masquerading" as the destination is=20 > sometimes OK, but ONLY when the sender and receiver are specifically=20 > AWARE of this interception. This is called a Man In The Middle=20 > *attack* otherwise. > Never mind connection-breaking performance-enhancing proxies ;-) > > > #6: The idea that one can "identify" DNS requests by snooping on layer=20 > 2 packets is so crazy it is not even wrong. Layer 2 packets have layer=20 > 2 addresses (like Ethernet addresses, e.g.). Their contents above=20 > Layer 2 cannot be decoded. My DNS requests are DNS-over-HTTPS, except=20 > within my home I cache the answers on a local server that uses=20 > DNS/UDP/IP. I certainly don't trust any Elon Musk corporation not to=20 > spy on my traffic. > Um, yes, indeed. Except that there is no reason that a satellite=20 couldn't function as a fully fledged upstream DNS server (so you don't=20 need all that layer 2 snooping stuff, which seems strange indeed). Every=20 home DSL router has for years, and there's no reason you couldn't cache=20 a bit more stuff either. Even on your home router, there's nothing that=20 stops you from using a DNS server elsewhere. The question is whether it=20 makes sense and is worth the effort, and my point is that it's very=20 little gain for a lot of effort. E.g., you'd have to ensure dynamic=20 (CDN) entries age off whenever the satellite changes gateway, because at=20 that point, any clients that use the sat will be in a different=20 topological location. > #7: The general idea that one should put more function into Starlink=20 > Satellites basically will start to "fork" Starlink Enterprises (the=20 > Musk companies) as an "alternate Internet" where applications must use=20 > only the functions that Starlink supports (where other Internet=20 > providers may support broader standards or not support the special=20 > "Starlink-only" functions). This is a way to balkanize the Internet,=20 > and maybe Musk who loves Monopoly Power after all because it makes him=20 > more Powerful, sees that as a great thing. Certainly the Chinese=20 > Communist Party is trying hard to balkanize a Chinese-only Internet,=20 > spending a lot of money to block interoperability. Musk may envy=20 > China, I don't know. > > If you want a Balkanized, non-interoperable Internet, where the=20 > carriers feel free to examine all the traffic and create their own,=20 > non-interoperable protocol set, I'd suggest China might be a good=20 > place to move. Or maybe Mars? > Taken as read. --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------FXMUadtXPLKMdqPfwsmmBPOq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 17/04/2023 12:27 pm, David P. Reed via Starlink wrote:

 

#2: DNS service doesn't specify that "geolocation" is a function of the DNS ser= vice. It is the job of the endpoint *after resolving the DNS name to one of many IP addresses* to decide which IP address to use for the DNS name. That is, "geolocation" is an endpoint function, not something that the network does by spying on packet contents and faking a response from real DNS servers.

Oh dear. I think I didn't express myself well here - I didn't mean "geolocation" = in the "Internet" sense of "Where is that IP address?&quo= t; but in the sense of having a DNS server on a satellite that "knows"= ; that querying clients are in its topological proximity, and is able to do a recursive DNS lookup for them from its own gateway DNS server (assuming that gateways will function as such) - yielding the topologically closest CDN server where applicable. Or - looking at it from the gateway DNS perspective - knowing that any DNS queries it gets are "topologically close". I shouldn't have used the term "geolocation" there.

 

#4: In general, IP as a protocol underlying ALL of the Internet protocols is required to deliver the content to the address specified by the sender, *without either reading or modifying the content*. There are certain cases where "masquerading" as the destination i= s sometimes OK, but ONLY when the sender and receiver are specifically AWARE of this interception. This is called a Man In The Middle *attack* otherwise.

Never mind connection-breaking performance-enhancing proxies ;-)

 

#6: The idea that one can "identify" DNS requests by snooping on layer 2 packets = is so crazy it is not even wrong. Layer 2 packets have layer 2 addresses (like Ethernet addresses, e.g.). Their contents above Layer 2 cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my home I cache the answers on a local server that uses DNS/UDP/IP. I certainly don't trust any Elon Musk corporation not to spy on my traffic.

Um, yes, indeed. Except that there is no reason that a satellite couldn't function as a fully fledged upstream DNS server (so you don't need all that layer 2 snooping stuff, which seems strange indeed). Every home DSL router has for years, and there's no reason you couldn't cache a bit more stuff either. Even on your home router, there's nothing that stops you from using a DNS server elsewhere. Th= e question is whether it makes sense and is worth the effort, and my point is that it's very little gain for a lot of effort. E.g., you'd have to ensure dynamic (CDN) entries age off whenever the satellite changes gateway, because at that point, any clients that use the sat will be in a different topological location.

 

#7: The general idea that one should put more function into Starlink Satellites basically will start to "fork" Starlink Enterprises (th= e Musk companies) as an "alternate Internet" where application= s must use only the functions that Starlink supports (where other Internet providers may support broader standards or not support the special "Starlink-only" functions). This is= a way to balkanize the Internet, and maybe Musk who loves Monopoly Power after all because it makes him more Powerful, sees that as a great thing. Certainly the Chinese Communist Party is trying hard to balkanize a Chinese-only Internet, spending a lot of money to block interoperability. Musk may envy China, I don't know.

If you want a Balkanized, non-interoperable Internet, where the carriers feel free to examine all the traffic and create their own, non-interoperable protocol set, I'd suggest China might be a good place to move. Or maybe Mars?

Taken as read. 

--=20
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz=20
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
--------------FXMUadtXPLKMdqPfwsmmBPOq--