Re: [IPv6] ULA vs. 1918

[Ted Lemon <[e-mail]>]

Two observations here. First, it's never a good security practice to make
decisions based on source address. So I don't think this is a very
convincing use case. Second, this use case presumes that we can solve the
really hard problem that I think we all know we can't readily solve. We are
throwing good use cases in the trash to support a use case of questionable
value that's really hard to get right. I just don't see the benefit.

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

> Oh you’re right, my logic is flawed there. I was expressing a real
> property but not applicable there as you point out.
>
> Step back:
>
> Say the stack has all addresses but knows that it can reach a server GUA
> with a ULA. The server that replies will know that the client is local and
> that can change the security posture of the connection. This is for the
> original case. In that regard ULA is better than GUA.
>
> And a node with only ULA as you point out can control its external
> reachability eg by obtaining temporary GUAs from a home agent at the border
> of the domain, using the ULA as CoA and the GUA as home address as in
> section 4.4 of RFC 4864. Compared to rfc 1918 and NAT this places the
> control in the host as opposed to the NAT box. In that regard ULA is better
> than rfc 1918.
>
> But it only works if the host knows that ULA will work proactively or very
> quickly on demand…
>
> Regards,
>
> Pascal
>
> Le 16 juin 2023 à 19:33, Ted Lemon <[e-mail]> a écrit :
>
> 
> 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
>>> --------------------------------------------------------------------
>>>
>>>