Re: [IPv6] ULA vs. 1918

[Ted Lemon <[e-mail]>]

At this point I can only answer generally. I think it makes sense to choose
the most narrowly scoped source and destination address. But this shouldn't
be solved by putting a ULA into a DNS RRset that's advertised globally. The
"hard problem we don't need to solve" is making a correct choice when we
see a DNS RRset with AAAA records in a ULA prefix and other AAAA records in
a GUA prefix, and the ULA prefix isn't reachable from where we did the
query. This is a misconfiguration—it shouldn't happen in practice, and is
easy to fix. So hard coding something into an IP stack to do the right
thing in this case seems unnecessary. If you want the scoping behavior I
just described, scope your DNS as well, rather than expecting the network
stack to be able to figure out what you mean.


On Wed, Aug 16, 2023 at 11:43 AM Pascal Thubert (pthubert) <
[e-mail]> wrote:

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