Re: [IPv6] ULA vs. 1918

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Ted:

I realize I failed to respond. Sorry for that!

> 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.


About observation 1) The decisions in question are
a) for SAS whether to prefer ULA<->ULA over GUA<->GUA. 
b) for the destination to accept the packet and answer
c) for the hosts and network to play EH games that are only valid within a domain

about a) see thread Best Source / Destination address pair 
about b) the receiver knows at least that the answer stays within the domain. This can be a SYN attack, but once the 3-way is done, the receiver knows that the sender is inside the domain (or has a trojan inside). This is some level of security, not claiming absolute security.
About c) it's a safer to place EHs in ULA<->ULA packets because the EH may cause issues when leaked outside. 


About observation 2) I'm missing the point. Can you provide an good use case example where GUA<->GUA is preferable over ULA<->ULA, provided that the ULA pair works?


All the best

Pascal

On Fri, Jun 16, 2023 at 2:11 PM Pascal Thubert (pthubert) <mailto:[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 <mailto:[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) <mailto:[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 <mailto:[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) <mailto:[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 <mailto:[e-mail]>
Envoyé : vendredi 16 juin 2023 16:53
À : Pascal Thubert (pthubert) <mailto:[e-mail]>
Cc : Brian E Carpenter <mailto:[e-mail]>; mailto:[e-mail] <mailto:[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=mailto:[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 <mailto:[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 <mailto:[e-mail]> a écrit :

On 15-Jun-23 10:33, David Farmer wrote:
On Wed, Jun 14, 2023 at 17:01 Brian E Carpenter <mailto:[e-mail] <mailto: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 mailto:[e-mail] <mailto: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
mailto:[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
mailto:[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------