Subject: Re: Thoughts and comments on draft-linkova-6man-grand-01

From: Jen Linkova <[email-masked]>
Date: Tue, 10 Mar 2020 10:52:44 +1100

Hi Mark,

First of all, thanks a lot for review and suggestions, highly
appreciated! sorry for not responding earlier..

I've just submitted -00 version of the WG document, which shall have
your comments addressed:

https://datatracker.ietf.org/doc/draft-ietf-6man-grand/

Also see my comments below:

On Sun, Jan 19, 2020 at 4:55 PM Mark Smith <[email-masked]> wrote:
> I initially was concerned about an increase in multicasts, which I think we need to remember to try to minimise because of how common Wifi is. However, I've since realised that these gratuitous unsolicited ND NAs towards routers are generally replacements for the ND NSes the routers would be sending, so it probably isn't going to result in an increase in multicasts, or at least be a significant increase in multicasts. It might be worth mentioning this in the ID.

Good point. I've updated the section 2.1.

> It is also probably worth mentioning that if the link layer devices are performing MLD snooping per RFC4541, then these unsolicited NAs towards the link's routers will only be sent to the routers on the link rather than flooded to all nodes due to being sent to the all-routers multicast address. This is a mitigation to the Security Considerations 3rd paragraph concern about announcing new host addresses.

Thanks, I've updated the section 2.1 and the Security Consideration section.

> As the number of routers on a link is likely and usually small, the node could perform the multicast packet replication itself for each router and then link-layer unicast the unsolicited NA to each router, per RFC6086, "Address Mapping of IPv6 Multicast Packets on Ethernet".
>I think this should probably be a recommendation way to send these gratuitous ND NAs, as it not only avoids link-layer multicasts entirely for these gratuitous NAs, it also mitigates the security issue described in the Security Considerations 3rd paragraph regarding hosts announcing their new addresses. It's a better mitigation than MLD snooping because that's a capability that needs to be available and switched on, where as link-layer unicast is of course inherent. (It's not a perfect prevention though because of the possibility of link-layer Unknown DA frame flooding.)

Interesting idea. I've updated the section 2.1. However I'm not sure
it should be the recommended approach as it relies on the fact that
the host has the full list of routes.

> This mechanism would only be needed if there are routers on the link, so sending gratuitous unsolicited NAs to all routers could be made dependent on routers being present on the link. It could and probably should be even be more narrowly limited to only being used when the host can send traffic off-link. For example, a host might have received RAs, however if the RAs Router Lifetimes are Zero (so they're not announcing default routers), and those RAs don't contain RA Route Information Options for off-link destinations, then these gratuitous NAs don't need to be sent.

Are you suggesting that the host does not send  gratuitous unsolicited
NAs if it does not have any off-link routes? I see two issues here:
1) race condition: let's say I have two routers on link, serving the
same subnet, for first-hop redundancy. I drained one of them for a
maintenance.
The host joins the network, sends an RS, gets an RA from the drained
router, configure optimistic address, decided NOT to send a gratuitous
unsolicited NA (no default route yet) and then an RA from the second
router (the active one) arrives.
2) looks like a complication in the algorithm logic. Also it means
that the host routing table needs to be checked during the address
assignment process - not sure how much trouble it is from implementors
point of view..

> As this is effectively a simple address registration mechanism for hosts to register their new addresses with routers, it also further assists with mitigating ND cache exhaustion DoS attacks as described in RFC3756, 4.3.2., so it is probably worth mentioning this further mitigation assistance and referencing that RFC.

Thanks, updated the Security Consideration text.

> "As hosts willing to speed up their network stack
>    configuration are most likely to be affected by the problem outlined
>    in this document it seems reasonable for such hosts to advertise
>    their optimistic GUAs by sending unsolicited NAs."
>
> This problem can of course happen with ULAs too,

ULAs are of the global scope ;-P

--
SY, Jen Linkova aka Furry