In line...
On 03/11/2016 03:34, Michael Richardson wrote:
>
> Toerless Eckert <[email protected]> wrote:
> te> b) I have just posted ACP draft -04 in which i have reversed the
> choice
> te> of mDNS for ACP discovery by neighbors from the -03 text which had
> te> mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more
> te> details.
>
> 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.
>
> te> Pls check out the text on discover in -04, i hope it justifies use
> te> of GRASP for neighbor discovery.
>
This was te> not brian>:
> brian> When GRASP is run securely in its two forms for the ACP, it is
> brian> always protected/ encrypted by the ACP, so i think your security
> brian> concern would then not be valid.
This was brian>:
> brian> I'm still waiting to see a clear explanation of how the ACP will
> brian> secure LL multicast, however.
>
> te> I am not sure i understand the documentation ask. The ACP has a bunch
> te> of (virtual) interfaces. In the most simple implementation option,
> each
> te> ACP channel to an ACP neighbor is its own (p2p) L3 interface in the
> te> ACP. And thats all the interfaces the ACP has.
>
> Your quoting style makes it hard for me to understand the flow.
> I think that I requoted it correctly?
>
> There are two LL multicast involved:
> a) outside of ACP LL multicast on the underlying link.
> b) inside of the ACP LL multicast, which is really just p2p traffic.
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?
Using LL multicast is more than convenience. If GRASP sends an LL multicast,
it must be sent from a designated physical interface and must not travel more
than one hop. Otherwise it defeats the point. The fact that it's being
encapsulated and secured and replicated is kind of irrelevant to GRASP.
> > All packets, unicast or multicast that are sent into or received from
> > those interfaces are protected/encrypted by the fact that they are
> > transmitted encrypted by the seleted ACP channel encryption protocol.
>
> >> Do you see some IoT context where you would use insecure GRASP
> >> instead of DNS-SD/mDNS, eg: in some IoT context ?
> >>
> >> Michael can answer that for himself, but the reason we noted the
> >> *possibility* of doing this in grasp-08 is because it seems clearly
> >> harmless. So from the GRASP spec point of view, I consider the issue
> >> closed.
>
> > Ues, i am mostly interested in use-case explanations Michael has in
> > mind.
>
> > The other piece was that Michael was trying to figure out how to avoid
> > using LL multicast and instead use unicast:
>
> 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.
> > A good exampe for replacing multicast with unicast is WiFI where
> > luckily hosts do accept multicast packets as L2 unicast instead of L2
> > multicast. And thats done to get the benefit of L2 retransmissions,
> > that do not exist for L2 multicast.
>
> but, also because L2 multicast must be sent at the data rate/power-level of
> the weakest receiver, so L2-multicasts can eat hundreds of unicast TxOps.
Indeed, but I don't in general see that as being in AN scope. (It may well
be in BRSKI scope.)
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
