Re: [IPv6] ULA vs. 1918

[Ted Lemon <[e-mail]>]

The message I was replying to said:

packets to/from the ULA can only be injected within the ULA domain of
> routability. This creates an isolation against external attackers which
> have to be inside or use a trojan to attack an ULA only node.
>
So that means that the node is ULA-only, and is not reachable via GUA or
1918. If the node has all three, then isn't it the case that it's
attackable using the GUA, and hence the security concern doesn't apply? And
if it only has ULA, it's only attackable from within the routing domain of
the ULA, and hence there's no security issue? Sorry to belabor the point,
but if you think there's a security issue here it would be good to
characterize it clearly.

On Fri, Jun 16, 2023 at 1:23 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Ok we’re not on the same case that’s why.
> I was discussing the preference between GUA ULA and 1918. When a node has
> them all. Saying that actually ULA when done well could have the best
> properties while the state of the art makes it least preferred…
>
>
> Regards,
>
> Pascal
>
> Le 16 juin 2023 à 19:16, Ted Lemon <[e-mail]> a écrit :
>
> 
> Okay, but it seems like there's no problem then, since the node is
> ULA-only. It's only when you number the node with a GUA and publish it that
> it becomes reachable. So, from an operational perspective, what is the use
> case you are thinking of where this is a problem in a practical sense?
>
> On Fri, Jun 16, 2023 at 11:12 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
>> Hello Ted
>>
>> packets to/from the ULA can only be injected within the ULA domain of
>> routability.
>> This creates an isolation against external attackers which have to be
>> inside or use a trojan to attack an ULA only node.
>>
>> regards,
>>
>> Pascal
>> ------------------------------
>> *De :* Ted Lemon <[e-mail]>
>> *Envoyé :* vendredi 16 juin 2023 16:53
>> *À :* Pascal Thubert (pthubert) <[e-mail]>
>> *Cc :* Brian E Carpenter <[e-mail]>; [e-mail] <
>> [e-mail]>
>> *Objet :* Re: [IPv6] ULA vs. 1918
>>
>> What do you mean by “secure” here!
>>
>> Op vr 16 jun 2023 om 03:02 schreef Pascal Thubert (pthubert) <pthubert=
>> [e-mail]>
>>
>> Hello Brian
>>
>> If I have a ULA and my destination has a ULA and routing enables
>> connectivity between the 2, ULA to ULA seems to be the most secured choice
>> (because there’s some control on the diameter where an attacker can
>> operate).
>>
>> But then how does my stack know? Sure, routing does to a point (default
>> routes obfuscate). So I could leave it to trial and error / eyeballs. But
>> isn’t that a demonstration that the information available at the stack is
>> lacking?
>>
>> What we want is the stack to know which prefixes a ULA can reach from the
>> routing standpoint, and if an ULA can reach a prefix, allow to prefer a ULA.
>>
>> The ULA to ULA routability could be expected / inferred within a 48, but
>> my point above is that it’s doubly a mistake to resort on that.
>>
>> I’ll add that outside the 48 boundary, ULA longest match is not your
>> friend. If you have 2 ULAs a and b and a destination c outside a’s and b’s
>> 48s, but a longer bitwise match with b, does that mean anything about which
>> of a or b can be routed to c? Ne.
>>
>> This is why for each PIO of an ULA there should be a train of prefixes
>> that an address formed from the address in that PIO can reach, with a
>> preference (vs other PiOs) That’s the only way to unleash the power of ULAs.
>>
>> Note along that vein: there’s no point making GUA prefixes special in
>> that logic. If the ULA can reach a GUA, then the ULA is still a more secure
>> source address. Placing a GUA in the train with a preference should be
>> acceptable. For the return path, the GUA should assume symmetrical
>> routability: if the ULA packet reaches me I can reach it back (because it
>> is hopefully filtered at the site boundary).
>>
>> IOW we could consider RIO as the router-level “the originating router can
>> reach this destination prefix with this preference “ and a RIO-prime
>> attached to a PIO would be the source address-level “a source address
>> formed from the prefix in the PIO above can reach this destination prefix
>> with this preference “. This destination prefix being a global address, ULA
>> or GUA.
>>
>> Note that RPL use that sort of semantics very successfully. More so with
>> upcoming signaling in
>> https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/. I’m
>> not asking you to read the draft but it’s a good hint at how powerful the
>> concept of AGP can become.
>>
>> Take care,
>>
>> Pascal
>>
>> Le 15 juin 2023 à 22:40, Brian E Carpenter <[e-mail]>
>> a écrit :
>>
>> On 15-Jun-23 19:38, Pascal Thubert (pthubert) wrote:
>>
>> Hello Brian
>>
>> Today the only reachability that is assumed seems to be the /64. Based on
>> the current standards one could assume that /48 is reachable as well but
>> I’d not like to case that in stone in the stacks. The /64 experience with
>> SLAAC should have taught us a thing or 2.
>>
>>
>> Routing will determine whether the whole /48 is reachable. There's not
>> too much we can do about that at the address selection stage. This is more
>> a matter of scope; and as things have evolved, the nearest thing we still
>> have to site-local scope is a ULA /48. I completely agree that this is
>> classful addressing (even link-local is classful). However, it would not be
>> cast in stone in the code, since it would be in a configuration table. Do
>> we have a better solution for the *default* behaviour?
>>
>> (There is an argument for the default table being defined by v6ops, not
>> by 6man.)
>>
>>    Brian
>>
>> This is why I jumped in the thread. The ULA may reach a shorter
>> aggregation (even if to Lorenzo’s point that is not fully legal with the
>> current text), and it may reach other ULA prefixes. So hardcoding the /48
>> is not only repeating an error of the past but also not sufficient to avoid
>> the need of DHCP, as soon as the network gets fancier.
>>
>> And it will. SNAC is just one example.
>>
>> I’m looking forward to seeing what the new draft proposes. I hope for a
>> per PIO option inspired by RIO. Basically for ULA all the access le
>> prefixes would be listed with a preference.
>>
>> Along the same vein I hope for another per PIO option, also inspired by
>> RIO, that indicates the router preference for a source address derived from
>> that prefix.
>>
>> Regards,
>>
>> Pascal
>>
>> Le 15 juin 2023 à 00:52, Brian E Carpenter <[e-mail]>
>> a écrit :
>>
>>
>> On 15-Jun-23 10:33, David Farmer wrote:
>>
>> On Wed, Jun 14, 2023 at 17:01 Brian E Carpenter <
>> [e-mail] <mailto:[e-mail]>> wrote:
>>
>>    On 15-Jun-23 04:56, David Farmer wrote:
>>
>>     > I've been thinking we should extend RFC 8028's use of a PIO with
>> A=0 and L=0 for choosing the first-hop router. By adding to that, if the
>> prefix is from the ULA range, then the host should also treat the prefix as
>> a Local ULA prefix from an RFC 6472 section 10.3 perspective and add it to
>> the table as a local ULA prefix.
>>
>>    What is specific about A=L=0 in this case? Why wouldn't this apply to
>> any PIO in the ULA range?
>>
>> If A=1 and the prefix length isn’t 64, some people are going to have
>> words with you, I’m fine with it, but I’m not really looking to pick a
>> fight today, and those seem to be fighting words.
>>
>>
>> I was assuming the PIO would be for a prefix of whatever length happens
>> to be in use on the subnet in question (which would be indeed be 64 today).
>> But one can legitimately assume that if fdxx:xxxx:xxxx:yyyy::/64 is
>> announced, the applicable ULA prefix is fdxx:xxxx:xxxx::/48.
>>
>>
>>   Brian
>>
>>
>> Also, L=1 is making a different statement about the prefix. A=L=0 isn’t
>> making any other statement about the prefix than it might be a ULA that the
>> host should treat as local and the router announcing the RA knows how to
>> route for.
>>
>> But it doesn’t specifically have to be A=L=0, but that is probably the
>> safest statement to make.
>>
>> Thanks
>>
>> --
>>
>> ===============================================
>>
>> David Farmer Email:[e-mail] <mailto:[e-mail]>
>>
>> Networking & Telecommunication Services
>>
>> Office of Information Technology
>>
>> University of Minnesota
>>
>> 2218 University Ave SE        Phone: [phone]
>>
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>
>> ===============================================
>>
>> --------------------------------------------------------------------
>>
>> IETF IPv6 working group mailing list
>>
>> [e-mail]
>>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>