Subject: [Anima] Multicast in the ACP?

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Apr 2015 12:41:36 +1200

This is a question to the authors of draft-behringer-anima-autonomic-control-plane.

The discovery component of GDNP includes link-local multicast
messages. As far as we know, there is no way to secure these
messages, but by definition they are only intended for
autonomic nodes, which should all be part of the ACP.

So, is there any way to support secure link-local multicast
within the ACP?

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Apr 2015 16:46:51 +0000

Brian, 

> The discovery component of GDNP includes link-local multicast messages.
> As far as we know, there is no way to secure these messages, but by
> definition they are only intended for autonomic nodes, which should all be
> part of the ACP.
> 
> So, is there any way to support secure link-local multicast within the ACP?

The ACP as described in draft-behringer-anima-autonomic-control-plane is based on a hop by hop tunnel infrastructure. So far those tunnels are all point to point. I guess you can send a link-local multicast packet through such a tunnel, and it would automatically benefit from the security of that tunnel. But of course there is only one other node on that "link". 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Apr 2015 08:09:19 +1200

> The ACP as described in draft-behringer-anima-autonomic-control-plane is based on a hop by hop tunnel infrastructure. So far those tunnels are all point to point. I guess you can send a link-local…

Right, so we would have to specify a "replicast", where the sender copies the message
to each ACP tunnel. That seems like a lot of overhead.

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Apr 2015 17:26:34 -0400

Brian E Carpenter <[email-masked]> wrote:
    >>> messages, but by definition they are only intended for autonomic
    >>> nodes, which should all be part of the ACP.
    >>>
    >> The ACP as described in draft-behringer-anima-autonomic-control-plane
    >> is based on a hop by hop tunnel infrastructure. So far those tunnels
    >> are all point to point. I guess you can send a link-local multicast
    >> packet through such a tunnel, and it would automatically benefit from
    >> the security of that tunnel. But of course there is only one other
    >> node on that "link".

    > Right, so we would have to specify a "replicast", where the sender
    > copies the message to each ACP tunnel. That seems like a lot of
    > overhead.

http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
describes a way to do multicast across that collection of links... that is if
we can ever get it through the IESG.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Apr 2015 10:56:05 +1200

> we can ever get it through the IESG.

Interesting. That looks like overkill for ACPs that run over non-constrained
networks, but it suggests to me that we need a modular approach, so that it
could be used in networks that call for it.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 23 Apr 2015 09:21:20 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 22 April 2015 22:09
> To: Michael Behringer (mbehring); Anima WG
> Subject: Re: [Anima] Multicast in the ACP?
> 
> messages.
> >> definition they are only intended for autonomic nodes, which should
> >> all be part of the ACP.
> >>
> is based on a hop by hop tunnel infrastructure. So far those tunnels are all
> point to point. I guess you can send a link-local multicast packet through
> such a tunnel, and it would automatically benefit from the security of that
> tunnel. But of course there is only one other node on that "link".
> 
> Right, so we would have to specify a "replicast", where the sender copies
> the message to each ACP tunnel. That seems like a lot of overhead.

Not sure I'm with you. A tunnel is presented like an interface. Whether you send the packet out a normal interface or a tunnel is the same? Can you expand? ...

Michael

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Apr 2015 10:41:43 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> >> The ACP as described in
    >> draft-behringer-anima-autonomic-control-plane >> is based on a hop by
    >> hop tunnel infrastructure. So far those tunnels >> are all point to
    >> point. I guess you can send a link-local multicast >> packet through
    >> such a tunnel, and it would automatically benefit from >> the security
    >> of that tunnel. But of course there is only one other >> node on that
    >> "link".
    >>
    >> > Right, so we would have to specify a "replicast", where the sender >
    >> copies the message to each ACP tunnel. That seems like a lot of >
    >> overhead.
    >>
    >> describes a way to do multicast across that collection of
    >> links... that is if we can ever get it through the IESG.

    > Interesting. That looks like overkill for ACPs that run over
    > non-constrained networks, but it suggests to me that we need a modular
    > approach, so that it could be used in networks that call for it.

Given that the ACP's forwarding plane might be implemented in the control
plane processor, the mismatch between link speeds and available processing
power might cause one to conclude that while the network isn't constrained,
the router is!

I would consider, for instance, implementing the ACP as a user-space
virtual-machine in the control plane processor.  User-Mode-Linux can be
compiled to run on a bunch of POSIX platforms, although Linux and FreeBSD are
the ones most often tested.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Apr 2015 10:45:21 -0400

> Not sure I'm with you. A tunnel is presented like an interface. Whether
    > you send the packet out a normal interface or a tunnel is the same? Can
    > you expand? ...

As I understand it, (and I haven't read a document that specifies this: it
was just hallway conversation, but maybe your latest round has something),
the tunnel is an IPv6-over-IPsec-over-link-layer.

I can even imagine, in order to get the traffic up to where it needs to be,
that we might even consider running the ESP(-and-IKE)-over-UDP on a port!=500.
(ESP-o-UDP is usually used for IPv4 NAT traversal...)

As such, this traffic might never get seen (on purpose) by any of the ASICs
that know how to do efficiently do multicast...

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 23 Apr 2015 10:03:21 -0700

Michael:

Whatever we do for message distribution should work for whatever
secure hop-by-hop connectivity we use. IPsec has benefits of
HW-acceleration support in routers. dTLS has benefits of ease of implemention
at process level.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 23 Apr 2015 10:16:04 -0700

As contributor:

Brian:

I think there is a more fundamental decision for GDNP, and
we discussed this a bit during our discussions last IETF:

I understand there are two basic approaches to distributed discovery (meaning:
no central component):

a) The service-client sends out a request which gets flooded
   and the server replies.
b) The server sends out an announcements which gets flooded and
   the service client remembers it and uses when needed.

Your approach is a). mDNS flooding is a bit of a hybrid between
a) and b). The opaque LSA mechanisms popping up in IGPs these
days are b).

I am worried about scaling of a) when there are a lot of clients.

I would guess in AN we have few services and many clients - most
services, every AN device is a client of.

Does that not mean we should have flooding of announcements
instead of flooding of queries ?

Of course, the mechanism could have both...

Cheers
    Toerless

On Wed, Apr 22, 2015 at 12:41:36PM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 23 Apr 2015 10:39:20 -0700

[individual]

> we can ever get it through the IESG.

MPL is flooding with sequence numbers for loop/duplicate avoidance.
It then uses Trickle for link transmission which also doing
link-level duplicate avoidance by sequence number (observing what
others have sent, do not send yourself again). Kinda like CSMA/SA
(Send Avoidance ;-)

If we have p2p secure associations between neighbors, there will
likely not be a lot of benefit for the Trickle part though, so
might end up having some amount of overdesign for what we need.

I also would prefer the idea of hop-by-hop reliable forwarding.
All this datagram multicasting across slow/unreliable networks
is IMHO a mistake. MPL could introduce that hop-by-hop reliability
i think it doesn't do it so far, and its reinventing reliability.

Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2015 08:19:44 +1200

> Not sure I'm with you. A tunnel is presented like an interface. Whether you send the packet out a normal interface or a tunnel is the same? Can you expand? ...

If I want to send a discovery message to all autonomic nodes on the same
physical link as me, as far as I can see I have two choices:

1. Send one insecure link-local multicast packet.
2. Send a copy of the message to each ACP tunnel interface (because I have
a link-local tunnel to each other autonomic node on the same link).

So if I have 10 peers in the ACP on the same link, I either send one
insecure multicast packet or 10 secure copies of the same packet.

(This doesn't need a multicast protocol, just a "send a copy to
everybody" API.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2015 08:47:28 +1200

Hi Toerless,
On 24/04/2015 05:16, Toerless Eckert wrote:
> Your approach is a). 

Yes, but it's a conservative version of a) with explicit caching by the
relays and with an explicit throttle on the relayed messages. As a victim
of ARP broadcast storms in my youth, I am very much aware of the risks.

> mDNS flooding is a bit of a hybrid between

Well, we're talking about ASAs discovering each other. I see that
as a peer relationship, not a server-client relationship, so I'm not
sure the scaling problem is quite that bad. Perhaps we need to
invent some scenarios to get a feeling for the numbers.

> Of course, the mechanism could have both...

Yes. In fact we had a half-baked "unsolicited response" in version -02
to do exactly that - effectively preload the discovery caches. That
would largely avoid the relaying of queries off-link. We took it out
of version -03 because it was half-baked, but if the WG wants, of course
we can reinstate it.

I'm pretty sure we will always need the query flooding, to support
nodes that spend a lot of time asleep; see the reasons why IPv6
needs "resilient RS".

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 27 Apr 2015 04:01:54 +0000

Hi, Toerless and Brian,

I am not sure the assumption we have the servers in Autonomic Network (although the message exchange may be in server/client model when it happens in a certain pair devices). This assumption would give us robustness issue. In our charter, we claim to work on "distributed network elements". So, it is better to assume every network element is the same and try to NOT depend on any centralized servers as much as we can. That says, in the discovery case, we should not dependent on any help from any centralized servers.

Best regards,

Sheng

>From: Anima [mailto:[email-masked]] On Behalf Of Toerless Eckert
>Sent: Friday, April 24, 2015 1:16 AM
>To: Brian E Carpenter
>Cc: Anima WG
>Subject: Re: [Anima] GDNP: flooding discovery or announcement (was:
>Multicast in the ACP?)
>
>As contributor:
>
>Brian:
>
>> This is a question to the authors of
>draft-behringer-anima-autonomic-control-plane.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Apr 2015 16:32:34 +1200

> I am not sure the assumption we have the servers in Autonomic Network (although the message exchange may be in server/client model when it happens in a certain pair devices). This assumption would…

Agreed, or let us say: there are no special features for centralized servers.
If such a server exists, it can use the general mechanisms.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 27 Apr 2015 06:09:51 +0000

>> Not sure I'm with you. A tunnel is presented like an interface. Whether you
>send the packet out a normal interface or a tunnel is the same? Can you
>expand? ...
>

My interest here is beyond a single physical link. Since ACP has in theory establish the possibility to communication with any autonomic node in the domain, can we broadcast (the same, it does NOT need to be multicast) to all these node? This would be a very useful function to have, particularly when it has been secured and separated from data plane by ACP.

Best regards,

Sheng