Brian E Carpenter <[email protected]> wrote: >> I have no problem with the use of a GRASP multicast discovery here. >> >> I wonder about the utility of the GRASP unicast TCP response to the >> ACP discovery. >> >> Why not simply respond to the ACP discovery with a key management >> initiation to the sender of the multicast? >> >> My reasoning is as follows: 1) four TCP packets across the insecure >> ("public") LAN just to say "okay" 2) insecure GRASP instance must open >> TCP port on insecure LAN, and accept connections from anything. (See >> discussion about possible CBOR encoding attacks). 3) discovery of ACP >> peers is meaningless outside of the the local-link. 4) IKEv2 (whether >> used for IPsec keying, or MACsec keying [%]) already provides all the >> negotiation we need, and does it with higher privacy and security than >> GRASP could. >> >> Yes, I realize that this is an "exception" case for GRASP, but I also >> claim that all insecure instances of GRASP will be extremely minimal, >> purpose built things. Call it uGRASP if you like.
> I was trying to think of a reason why this wouldn't work, and can't
> really find one. It could be sent as a GRASP discovery with a very
> short timeout, so from the GRASP point of view it would fail promptly,
> but the IKE message would arrive as if by magic.
> Alternatively we could turn it round and use a GRASP flood (also LL
> multicast), which never gets a TCP reply anyway.
This seems like the right answer to me.
I hadn't understood it's purpose.
Could an M_FLOOD announce a node as an ACP peer, and also indicate if it
could be a Join Assistant? (in a single message)?
> Well, yes, all ACP is p2p traffic at the physical layer, but
>> Brian, RPL has an associated multicast routing protocol called "MPL".
>> We discussed it before, but it might be worth discussing it again to
>> be sure we went down the right path. We decided that GRASP would do
>> application layer multicasting -- as such, there will be hardly any
>> actual layer-2 multicast, as all the ACP links are p2p. Using
>> multicast destinations here is a convenience to not knowing what the
>> peer's address is, except that once we have the first response via
>> TCP, we do know the peer, and we might as well just use that channel
>> for future communication.
> Can MPL support LL scope?
You don't need MPL for LL scope :-)
MPL is to permit scope > 2 multicast to propogate across the RPL mesh the
same way that a network that is entirely onlink would get multicast.
>> I see no places in IoT where we would want to use insecure GRASP on an
>> insecure link. The killer is the TCP reply, which implies a TCP
>> stack, which most which to avoid.
> Yes, but then GRASP's scope is between autonomic nodes, not between all
> Things. I expect that most Things will be managed by an ASA in a
> bigger autonomic node.
agreed.
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
