Michael, In the situation where the DAO from the JA carries the information about the > JN, then the LBR/DODAG root would receive that information. The LBR needs > to > be told where the JCE is by out-of-scope means. I.e. you have to configure > it: But of the common case where it's co-located. it's a no-op. > As the JCE then reaches out *to* the JN, neither the JN nor the JA need to > know who/where the JCE is.
You seem to assume the JN does not talk end-to-end with the JCE, but the LBR serves as an application-layer proxy? Man-in-the-middle? I must be missing something. Related question: does the JN at some point learn the address of JCE and/or PCE? More generally, how is the "handover" done between the JCE and PCE? The JCE and/or PCE would have to enable the JA to actually function as a JA: > I think that there may be topological knowledge required to make sure that > there are enough JA enabled, and not too many. +1 Thomas On Thu, Apr 30, 2015 at 6:51 PM, Michael Richardson <[email protected]> wrote: > > Kris Pister <[email protected]> wrote: > > * In section 3.2 you refer to > kelsey-intrarea-mesh-link-establishment a > > couple of > > times as a way to do key exchange. Reading that document it seems > to me like > > it gives me a way to exchange parameters, but doesn't define > anything with > > regard to key exchange, yes? > > That's a good point: MLE was supposed to grow ways to do key exchange, but > as > the document seems to have gotten lost in the IETF independent submission > track it has perhaps failed to get anywhere, and I'm just going on what I > was > told MLE would do for the world. > 802.15.9 is/has defined a way to use (diet)HIP, or IKEv2 over the link; > I think that in the name of code space/protocol reuse, one would like to > have > a DTLS-based mechanism, but to date I'm told no TLS person has specified > something. > > Yes, there is a major gaping hole here. > > > * 3.4 Was there a final decision on End to End? Do you have a strong > > opinion? > > It seems to me that DAO is the right answer. > > Yes, the JA "announces" the attachment of the JN via DAO. In a non-storing > DODAG, that DAO is unicast to the route, so intermediate parts of the mesh > neither see anything nor know anything of the new node. > > JN traffic flows upwards without any special considerations (other than > bandwidth limits, and potentially being programmed into specific tracks), > and > that it flows downwards using source routes, i.e. using RH3. > > We still have some conflict as to whether the address of the JN can be a > link-local address, whether this address is permitted in an RH3, and if the > JA happens to have more than one interface (such as two kinds of radios), > if > the JA can make sense of that link local address without some interface > context. > I think that this specific topic should be addressed in the just > re-chartered > ROLL WG work on RH3. > > Pascal has taken the approach that we need to provision each JA with a > fresh > set of /64 ULA for joining nodes (one per interface), and while that felt > really messy to me at first, I've warmed to the idea recently. > > > * 6.1.8 I feel like I'm missing how the JN or JA or LBR figures out > who the > > JCE is. > > In the situation where the DAO from the JA carries the information about > the > JN, then the LBR/DODAG root would receive that information. The LBR needs > to > be told where the JCE is by out-of-scope means. I.e. you have to configure > it: But of the common case where it's co-located. it's a no-op. > As the JCE then reaches out *to* the JN, neither the JN nor the JA need to > know who/where the JCE is. > > There is perhaps some concern that the JN/JA could be experience some kind > of > DoS by other nodes pretending to be the JCE; those nodes would have to be > already-joined nodes that went rogue though, and the traffic would always > be > internal. > The question then becomes should the JA allow anything through, and if the > answer is no, then I think that the JCE needs to, when it provisioned the > JA > (as the JA was at some point, a JN itself), tell the JA there JCE traffic > comes from. > > The JCE and/or PCE would have to enable the JA to actually function as a > JA: > I think that there may be topological knowledge required to make sure that > there are enough JA enabled, and not too many. > > We could go a step further and define/allocate some kind of anycast or well > known address for the JCE (to use as a source IP), but I think that this > would get in the way of potentially having more than one JCE, and is > probably > unnecessary. > > > * 12.2 jamming: "what prevents a node from transmitting when it is > not their > > turn" > > nothing, unfortunately. > > Some of these questions from things asked on design team calls. > I actually think both questions in 12.2 are actually out of scope. > > > * 12.2 "can a node successfully communicate with a peer at a time > when not > > supposed to" > > this is up to us to some extent. The MAC is certainly capable of > strictly > > enforcing > > the schedule, so in an RX slot from A it can (and will, in the > products that > > Dust ships) > > reject a packet from B even if it has the right MIC. Doesn't help > in aloha > > slots of course. > > The detail is, I think, that the MAC does this without waking up > higher-level functions, and that the packet doesn't get forwarded so the > the > "cheating" node does not benefit. > The MAC still has to be awake, and the transmission still might interfere > with a legitimate sender. > > > At a high level, it seems like you are leaving open the possibility > that the > > joining network > > and the production network might be physically the same devices but > with > > different > > DODAG, L2 resources, etc? I'm trying to figure out why I need the > new > > LDevID. Won't I need to go through essentially the same process > again > > with the production network? > > I feel like I'm missing something. > > Part of the reason to reject building a seperate join network is that it > will > require significant resources (larger memory in particular) which will > mostly > never be used. So if we can minimize the unique L2 resources to be at the > edge, and avoid a second DODAG that is good. > > If your network is designed to do per-node-pair keying, then the LDevID is > what > you'd be using to authentication for that key exchange. You could also use > it to provide L3 security at the RPL level, and it might also be used by > applications. > If your network will just provision a MasterKey for network-wide L2 keying > (via JCE), then no LDevID need be provided, but it might still be useful > for the applications. There is a place right here to bootstrap a secure > relationship between an ACE (Client) Authorization Server and Client/RS. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
