From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 6332D3CB37 for ; Tue, 13 Feb 2024 12:39:59 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 41DHduDi061728; Tue, 13 Feb 2024 18:39:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6FD4206E0E; Tue, 13 Feb 2024 18:39:56 +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 A9BF9206DD4; Tue, 13 Feb 2024 18:39:56 +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 41DHduJG060219; Tue, 13 Feb 2024 18:39:56 +0100 Message-ID: Date: Tue, 13 Feb 2024 18:39:56 +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:39:59 -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?) Do you mean that VRRP requires the use of that MAC address? In that case, the VRRP spec (RFC) should be clear that the IPv6 address _must not_ use that MAC address to form a link-local address, and rather use opaque IIDs. I mean, where the the VRRP RFC5798 tells OLD: > IPv6 routers running VRRP MUST create their Interface Identifiers in > the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet > Networks" [RFC2464 ]). it should tell NEW: > IPv6 routers running VRRP MUST create their Interface Identifiers in > the normal manner, that is RFC7217 "A Method for Generating Semantically Opaque Interface Identifiers > with IPv6 Stateless Address Autoconfiguration (SLAAC)" (it includes link-local address formation). Hopefully starlink agrees with it and implements it before we blink :-) 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