Subject: Re: [Anima] GRASP Issue 28: Does ACP support secure link-local multicast?

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Mar 2016 00:44:26 -0800

Brian, Michael:

Once we agree on the answers, i think those answers need to be documented
somewhere. ACP draft ? Michael ?

1. We may have one instance of GRASP run across L2 to find candidate
   ACP neighbors. This would be a minimal instance as its insecure.
   And we have to figure out if we want GRASP here or use some other
   potentially pre-eisting protocol like mDNS. Eg "Find ACP service on LAN".

   I am not a fan of using mDNS for this because i see a high likelyhood
   of creating deployment problems when so many hosts on LANs speak mDNS.

   Once neighbor is seen in this discovery, we would start secure negotiation
   with - still to pick IPsec/(DIKE)/(d)TLS.

   So, this initial instance would be insecure.

2. For GRAP run inside of ACP, there will of course be support for
   link-local multicast.
   
   There is one interesting level of design that would be good to work
   through and write down:
   
   All "simple" security associations negotiation are p2p. Eg: IKE, SSL.
   so i would like to standardize for ACP first only such p2p ACP
   neighborships. Doing p2mp ACP tunnels should be a later extension
   if demand justifies it. I am saying this because i know how complex
   GDOI etc. become.

   Every L2 interface (with ACP neighbors) would have one or more
   ACP "tunnels" - one per neighbor. This leads to two possible APIs
   (this is all stuff we've done in IP multicast since the 90th):

   a) L2-subnet API / "L2 pseudo broadcast":

      You send a multicast (link-local) to an L2-subnet.
      ACP does send a copy to every ACP p2p tunnel on that interface.
   
   b) per-neighbor API:

      You send multicast (link-local) to a specific ACP tunnel.
   
   The important thing is really just that any application that
   wants to use LL multicast understands how to use these options
   and uses them consistently.

   If you want to do flooding, option a) is usually easier:
   
   GARP on node AN1 on LANx sends LL-MC to LANx. ACP
   replicates to all ACP tunnels associated with LANx. 
   AN2 on LANx receives the LL-MC, passes to GARP. GARP replicates/
   modifies messages. Replicates it out to all other LANs, but must
   not send a copy back to LANx.

   Option b) is better when you have some multicast that only
   needs to go to some subset of ACP neighbors on a LAN. Then the
   application, like GARP would need to take care of replicating per
   neighbor. In Option b) the app like GARP could of course still
   know for every neighbor/p2p-interface which underlying L2 interface
   it's associated with and therefore replicate the behavior of a)
   by itself if desired.

Cheers
    toerless

On Thu, Feb 04, 2016 at 01:43:09PM +1300, Brian E Carpenter wrote:
>    o  28.  Does ACP support secure link-local multicast?
> 
> The issue here is that GRASP has no choice but to use multicast
> for discovery or flood messages, and such messages are intrinsically
> insecure. So this isn't really an open issue for the protocol, but it
> is a question for the ACP designers. Can they provide an ACP virtual
> interface that supports secure LL multicast?
> 
> For the GRASP draft, this should probably be changed from being an open
> issue into a specific paragraph in the Security Considerations.
> 
>    Brian
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Mar 2016 07:51:17 +1300

Hi,
>    So, this initial instance would be insecure.

Sure. GRASP is certainly an option for that. We just need IANA to assign
ALL_GRASP_NEIGHBOR_6 and GRASP_LISTEN_PORT. (I am currently using ff02::114
and 1021.)

>       ACP does send a copy to every ACP p2p tunnel on that interface.

I prefer that. It simply means that when the ACP comes up, GRASP
uses that L2 interface instead of the underlying physical interface
that it uses in insecure mode. Presumably the necessary information
will be in the ACP adjacency table that Michael proposed some time
ago.

>    If you want to do flooding, option a) is usually easier:

GRASP floods both Discovery and Flood Synchronization messages,
since every AN is potentially a target, so I think we need a)

>    not send a copy back to LANx.

Right, but Joel recently identified a slight complication there:
if there's a loop in the router topology, we have to prevent a copy
being sent back to LANx indirectly. That's actually a defect in the
GRASP -03 specification and the prototype code, which we will fix of
course.

Regards
    Brian