On Wed, Nov 02, 2016 at 10:34:39AM -0400, Michael Richardson 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.
See my last email to Brian et.al. on the signaling list, aka:
GRASP-08: A responder MAY send a Discovery Response message
I also think that should be a MUST NOT or SHOULD NOT.
> Why not simply respond to the ACP discovery with a key management initiation
> to the sender of the multicast?
Right. Thats what would happen if there is no response at the GRASP level.
either IPsec session setup or eg: TLS with gRASP inside to negotiate
the ACP channel protocol.
> 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.
Right. The GRASP responses serve no requirement that i know in the
case of DULL GRASP instances. I think they where kept in the spec so far
because the original signaling exchange was discovery, discovery response,
and then synchronization. Which was the sequence Brian implemented
before the unsolicited "flood-sync" which wraps it all up into one
message. Aka: What i want is the "flood-sync" that minimizes signaling and
IMHO makes responses unnecessary.
> 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.
Right. Logically it could be one implementation with multiple
objectives (ACP, BRSKY,...), but technically its very good that
each of these services could run it's own uGRASP instance without
collision: As long as the sockets are opened with SO_REUSEADDR ;-)
> 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.
Maybe we should open a separate thread about that. Its certainly
attractive to conside RPL as a carrier for additional flooded messages,
but i have seen a long history of doing that in a variety of IGP, and
it has always lead to a lot of frustrations when there where multiple
coices of IGPs So i'd for now stick by a rule that the IGP should only
flood info that only the IGP needs, the rest would be flooded by
a mandatory soulution specific protocol approach. eg: GRASP in our case.
> 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.
By specifying the use of LL multicast for GRASP discovery, we
make it most easily reuseable in arbitrary contexts: There is no
dependency against "ACP", but only against "some underlying security".
For example, i could build IOT networks without ACP and still use
GRASP as long as i am sure all my links have eg: 802.1x or the like.
A lot of IoT wireless networks will come with link-security.
I am also not sure where/how we would actually make anything simpler
by not using LL multicast: For the ACP, all interfaces are p2p ACP
secure channels, whether i send LL multicast or LL unicast doesn't make
a difference. Except that i'd need to learn the LL 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.
Another good point for optimizing the insecure GRASP the way we
seem to agree upon (only LL multicast announcements).
Ok, but that has IMHO two separate conclusions:
-> For DULL GRASP we only need LL multicast announcements, no replies
-> If we want to proliferate GRASP into IoT contexts without TCP,
we need to specify how to run GRASP there. For GRASP today,
Brian an I seem to be the priamry fans of TCP for reliability,
flow-control etc -> which is why thats mandated for GRASP eg:
in ACP. BRSKY has started to add text about CoAP as the TCP
alternative . Maybe we need that for GRASP as well ? I have not
yet tried to understand the properties of COAP well enough to
see how well it would fit, but most GRASP exchange should be
similarily simple as BRSKY, so it would probably fit easily. Except
that one needs to write all that text about the encoding...
> > 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.
In IPv6, receivers MUST use MLD for all groups. Senders can track this
and know the power level required for the furthest away receiver for
each group and send packets for each group with the minimum required level
for that receiver. That would make multicast TX always equal or better than
unicast TX (better as soon as there are two or more receivers reachable by
the same beam). Its just that no wireless technology specifies this behavior.
RX is the bigger issue. I bet there is a lot of unnecessary wakeup for
multicast packets not needed. Aka: Would need per multicast-address wakeup
HW like there is for the unicast address.
Periodic unsolicited announcements like in DULL GRASP are definitely
offenders in such low powr networks. Depending on the type of network
one can optimize the periodic part away or leverage some central
component (AP etc.) as a helper.
Cheers
Toerless
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
