On 12/11/2016 15:56, Michael Richardson wrote:
>
> 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)?
Certainly. We have no limits on the content of an objective, and actually
M_FLOOD
is defined to carry more than one objective if required. This seems like
a good approach to me.
>
> > 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.
Duh.
>
> >> 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.
>
Good!
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
