On 04/11/2016 11:55, Toerless Eckert wrote:
> 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.
I assume you mean that in the restricted contex of bootstrap, because
in any other case of course the unicast response is needed. It's a MAY
because an ASA might want to hide for some reason.
>
>> 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 that is so, definitely use Flood not Discover. It's designed to have
no reply.
>
> -> If we want to proliferate GRASP into IoT contexts without TCP,
Out of scope for Anima, surely?
Brian
> 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
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
