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) < pthub...@cisco.com> 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ć <malisa.vuci...@inria.fr> > *Sent:* jeudi 19 avril 2018 15:32 > *To:* Pascal Thubert (pthubert) <pthub...@cisco.com> > *Cc:* Michael Richardson <mcr+i...@sandelman.ca>; 6tisch@ietf.org > > > *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) < > pthub...@cisco.com> 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 <6tisch-boun...@ietf.org> *On Behalf Of *Mališa Vucinic > *Sent:* mercredi 18 avril 2018 19:37 > *To:* Michael Richardson <mcr+i...@sandelman.ca> > *Cc:* 6tisch@ietf.org > *Subject:* Re: [6tisch] Optimizing Neighbor Discovery during the join > process > > > > > > On Wed, 18 Apr 2018 at 19:17, Michael Richardson <mcr+i...@sandelman.ca> > 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
