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.
te> Pls check out the text on discover in -04, i hope it justifies use
te> of GRASP for neighbor discovery.
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.
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.
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.
> 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.
> 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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
