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 =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
