From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 685183CB37 for ; Tue, 13 Feb 2024 12:43:12 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 41DHhA8w022878 for ; Tue, 13 Feb 2024 18:43:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD811206E20 for ; Tue, 13 Feb 2024 18:43:10 +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 D61CA206E0C for ; Tue, 13 Feb 2024 18:43:10 +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 41DHhAuW061353 for ; Tue, 13 Feb 2024 18:43:10 +0100 Message-ID: Date: Tue, 13 Feb 2024 18:43:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: 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:43:12 -0000 or maybe the VRRP people dont want that address to be opaque at all, I dont know. Le 13/02/2024 à 18:39, Alexandre Petrescu via Starlink a écrit : > > 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 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink