From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 9DE4B3CB37 for ; Tue, 13 Feb 2024 12:44:04 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 41DHi3aS045195; Tue, 13 Feb 2024 18:44:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ECBBF206E0C; Tue, 13 Feb 2024 18:44:02 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E02C6206E08; Tue, 13 Feb 2024 18:44:02 +0100 (CET) Received: from [10.11.240.42] ([10.11.240.42]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 41DHhAuX061353; Tue, 13 Feb 2024 18:44:02 +0100 Message-ID: <763d1876-0ad6-4f70-a69e-d42a985c2ba3@gmail.com> Date: Tue, 13 Feb 2024 18:44:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: J Pan Cc: starlink@lists.bufferbloat.net References: <5323051a-5835-4e42-9850-2f3349a8bd77@gmail.com> From: Alexandre Petrescu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CEA-Virus: SOPHOS_SAVI_ERROR_OLD_VIRUS_DATA Subject: Re: [Starlink] Measuring the Satellite Links of a LEO Network 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, 13 Feb 2024 17:44:04 -0000 Le 13/02/2024 à 18:12, J Pan a écrit : > yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a > virtual mac used by the virtual router redundancy protocol commonly > used by service providers in point-of-presence?) maybe they should rather use the IPv6 anycast concept? Alex > -- > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan > > On Mon, Feb 12, 2024 at 6:14 AM Alexandre Petrescu via Starlink > wrote: >> this is an issue for 6MAN WG at IETF, but this is the text with the >> issue in the paper: >> >>> From the user device or customer router at 192.168.1.1, >>> we can reach its GS gateway at 100.64.0.1 (or equivalently >>> fe80::200:5eff:fe00:101 for IPv6) >> That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80' >> and the rest is an 'Interface ID', in RFC parlance. >> >> That IID should be more random in its appearance. It is called an >> 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with >> SLAAC" of year 2014. >> >> That IPv6 address corresponds to earlier forms of these IIDs (RFC2464 of >> year 1998); they had that IID to be derived from a 48bit MAC address and >> inserted an 'ff:fe' string in it to become 64bit. >> >> Most embedded linux platforms (v2.x kernels?) still use that ff:fe. >> Migrating these kernels is sometimes very difficult. One might not want >> to migrate an kernel to a bloated and slower v3 or higher just for that >> little 'ff:fe'. Maybe one wants to migrate just its IPv6 stack, but >> it's not easy. >> >> The reason of making this IID more opaque is to resist scanning >> attacks. A scanning attack is when a user might have somehow an >> illegitimate starlink terminal and tries to connect to the legitimate >> starlink network. Part of that trying is to know the IP address of the >> next hop. With IPv6 it comes down to testing all these addresses. If >> they have a constant 'ff:fe' in them, it is easier to find them by brute >> force than if they were opaque. It is also true that if in IPv4 that >> next hop is always the same then the easiest attack is to simply use >> IPv4 instead of IPv6. But this 'opaqueness' of the IID in the IPv6 ll >> address might still be needed when IPv4 is get rid of. >> >> This could be discussed at IETF, could be suggested to starlink to >> upgrade, etc. >> >> Alex >> >> Le 12/02/2024 à 07:59, J Pan via Starlink a écrit : >>> http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at >>> ieee icc 2024. feedback welcome, especially during the camera-ready >>> stage this week. thanks! -j >>> -- >>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink