Hello Mališa All the below makes sense to me and I agree with the general direction that you are taking. Let’s see the final text – and don’t forget to signal in the join that the LL derives from the MAC so on the way back we skip the look up!
Take care, Pascal From: Mališa Vučinić <[email protected]> Sent: vendredi 20 avril 2018 15:30 To: Pascal Thubert (pthubert) <[email protected]> Cc: Michael Richardson <[email protected]>; [email protected] Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process Hi Pascal, Thanks for the clarifications. One point I strongly disagree with is about the cost of the ND exchange. ND is indeed done on one-hop but in 6TiSCH case this maps to the shared cell, where the collisions happen. Once we get pass that critical first hop, things are much easier as we have dedicated cells towards the 6LBR. So, I would by no means underestimate the effect of doubling the communication overhead on the shared cell due to ND. I also think that a solution where ND is done for the first time once the pledge becomes a joined node, and JP or pledge do not have to worry about insecure NCE is quite clean. With that, JP becomes stateless at all levels, including IP, which is quite good from the security point of view during the join process. It also removes 50% of overhead on the shared cell in a fully generic setting. To me, it seems that you are recommending to give up from that because 1) some people will not like it; 2) some stacks might need to be amended to support either destination all-zeros, or source all-JPs. That said, please note that the existing text in -05 already mentions ND as a phase in the join process. We do not detail how ND is done, and I don't think we should by any means do it in the minimal-security draft. In the existing text, we reference Section 5.5.1 of RFC6775. We also give a recommendation that the NCE resulting from the ND exchange should be kept separately, as the pledge is not yet authenticated. A specific optimization when JP's LL is constructed from its L2 address with a bit in the EB is more of a workaround to me, but I can live with it. I guess this would belong to the richardson-enahnced-beacon document? Mališa On Fri, Apr 20, 2018 at 11:20 AM Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Hello Mališa The all-0 destination is tricky, not done anymore that I know off. Trying that may get us through hell at 6MAN and/or IESG. I think that as an RFC you must described the clean way and then the optimizations when the LLs are based on EUI 64. IMHO, the spec should say that: - That the pledge sends an RS to all-JPs at l3, L2 dest = unicast MAC of the JP. - That the pledge registers its LL using ND EARO. With that we are clean from the standards perspective. And then, to address your concern, the spec would then indicate that if the pledge or the JP LL are derived from EUI 64 then some optimizations are possible. If the JP LL derives from EUI 64 you may: - Have a bit in the beacon that indicates so. If the pledge LL derives from EUI 64 you may: - Skip the ND EARO to register the LL to the JP - Indicate in the join message that the LL derives from the MAC - Use it on the way back to skip the look up Notes: - The JP just needs to have a threshold of unsecured NCE, and a sensible lifetime for these, but that’s not that difficult. - If the NCE for the pledge is no more there when the join response comes in then the JP needs to do a NS look up. Also, I do not necessarily agree that the ND phase is that expensive. It is just a one-hop exchange. Cheers, Pascal From: Mališa Vučinić <[email protected]<mailto:[email protected]>> Sent: jeudi 19 avril 2018 15:32 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: Michael Richardson <[email protected]<mailto:mcr%[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process Pascal, If we were to use the unspecified address, would the following be OK: - Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source: pledge EUI; L3 destination: JP EUI from the Beacon - Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2 source: JP EUI; L2 destination: Pledge EUI (Join Request and Join Response refer to packets exchanged between the pledge and the JP.) This seems to: - resolve Michael's concern about CoAP libraries expecting the response to come from the same IPv6 address where it was sent to - not introduce any additional packet overhead - avoid an ND exchange doubling communication overhead - avoid the need to keep a separate insecure cache at JP. How this would be implemented is implementation specific, one example is an ephemeral cache entry discussed in previous emails. Let me know if you see any pitfalls, to me it looks quite appealing as an option. Mališa On Thu, Apr 19, 2018 at 2:41 PM Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Hello all : Guessing the Link Local of the JP looks like a very bad idea. Because the JP may not form a link local from EUI. This is being discouraged for privacy reasons. Guessing is really unclean any way. To resolve the address of the device at the JP you could - Piggy back an ARO in the join request, implicitly associated with the link local of the device. The JP may store it or not, I guess it could have a bounded amount of NCE for this use. At least, it could immediately reject the Join if the LL is a duplicate with another node, in which case a NA (status/=0) would work. Otherwise duplicate LL may be an issue for a non-EUI64-based LL. - Lookup the Link Local of the device on the way back, if there is no NCE, but that’s a multicast from the JP to locate the JN To reverse resolve the IP - If the prefix is known, we can define an anycast address “any JP on this prefix” similar to the home agent anycast address in RFC 3775. - Else you can define a multicast all-JPs and use the multicast IP over unicast MAC trick by extension to RFC 6085. - Early implementations / pre standards can ship with FF02::2 instead of all-JPs, but the standard should be correct otherwise we’ll pay it at the IESG. For the mail below: - There is no such thing as traffic from all-routers. With RFC 6085 we are tricking “all” at L3 with a unicast L2 to make the L3 multicast become a sort of anycast and where we get to choose which JP. - There is such thing as traffic source set to unspecified address (all zeroes) though. If that’s enough for you, you may use that. - With RFC 6775 update, ND registration for a link local is a one hop thing, does not fly to the root or what, so the cost is really limited Take care, Pascal From: 6tisch <[email protected]<mailto:[email protected]>> On Behalf Of Mališa Vucinic Sent: mercredi 18 avril 2018 19:37 To: Michael Richardson <[email protected]<mailto:mcr%[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process On Wed, 18 Apr 2018 at 19:17, Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: > Yes, I guess you could call it an ephemeral cache entry > constructed by CoAP at JP when the join response is received, > before being forwarded to the pledge. As soon as the packet is > passed to L2, the cache entry is removed. Can we do this? I think that we can do this. It might be better if the traffic came from ff02::2, but I'm not sure that would be acceptable for IPv6 reasons. I am concerned that a reply from a different L3 address will not be acceptable to some coap libraries. Indeed, good point about a different adress in the response. @Pascal, would it be possible for JP to use all-routers as the source IPv6 address? If not, does it help if we define our own well-known address?
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
