Subject: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 8 Jul 2016 12:59:20 +0000

ANIMA WG, 

Here is the latest version of the ACP draft, with quite a lot of changes and updates. 

As discussed since the last IETF, we now assume that neighbour discovery is not with GRASP, but mDNS. 

Also, the channel selection process has changed, see section 5.4 and 5.5. 

Lots of editorial updates as well. It's certainly worth having another read through. Note that we've merged to main sections into one (5), so there will still be some clean-up to do in terms of readability, etc. 

Comments welcome!
Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 08 July 2016 14:54
> To: Michael Behringer (mbehring) <[email-masked]>; Toerless Eckert
> (eckert) <[email-masked]>; Steinthor Bjarnason <[email-masked]>
> Subject: New Version Notification for draft-ietf-anima-autonomic-control-
> plane-03.txt
> 
> 
> A new version of I-D, draft-ietf-anima-autonomic-control-plane-03.txt
> has been successfully submitted by Michael H. Behringer and posted to the
> IETF repository.
> 
> Name:		draft-ietf-anima-autonomic-control-plane
> Revision:	03
> Title:		An Autonomic Control Plane
> Document date:	2016-07-08
> Group:		anima
> Pages:		32
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-anima-autonomic-
> control-plane-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-
> control-plane/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-
> plane-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-
> control-plane-03
> 
> Abstract:
>    Autonomic functions need a control plane to communicate, which
>    depends on some addressing and routing.  This Autonomic Control Plane
>    should ideally be self-managing, and as independent as possible of
>    configuration.  This document defines an "Autonomic Control Plane",
>    with the primary use as a control plane for autonomic functions.  It
>    also serves as a "virtual out of band channel" for OAM communications
>    over a network that is not configured, or mis-configured.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jul 2016 05:25:10 +1200

Hi,

I have one big issue with this version, and a few other comments below.

> 5.2.  Neighbor discovery via mDNS/DNS-SD	
> 
> Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local	
> address of autonomic neighbors across L2 adjacencies.  The result is	
> stored in the AN Adjacency Table, see Section 5.1.2.

Why? We have carefully designed GRASP discovery so that it could do this.
While I understand that bootstrap wants to use mDNS/DNSSD to cover the case
of non-AN devices, the ACP by definition is only active in AN devices which
will all support GRASP by definition.

There are two arguments hidden in the change log that seem spurious to me:

> Bootstrap	
> protocol team decided to go with mDNS to discover bootstrap proxy,	
> and ACP should be consistent with this.

Why? ACP should also be consistent with the rest of Anima. That's
a magical argument, not a technical one.

> ... b) Using GRASP both for the	
> insecure neighbor discovery and secure ACP operatations raises the	
> risk of introducing security issues through implementation issues/	
> non-isolation between those two instances of GRASP.

Firstly, as mentioned again below, there may indeed be no isolation
because the implementation may use internal modes, not separate
instances. But the argument is empty: the fact that discovery requests
are public (unsecured link-local multicast) doesn't make GRASP itself
vulnerable. Discovery responses can be secured by GRASP/TLS as soon
as bootstrap has occurred.

I think this is the completely wrong approach for Anima.
(As I said in another message, making mDNS/DNSSD mandatory-to-implement
for bootstrap is reasonable, but bootstrap needs to support
GRASP discovery as well, to allow "100 pure Anima" deployments.)

--- Other comments ---

> An example:	
> 		 		
> anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email-masked]	
>	 		
> The ACP address MUST be specified in its canonical form, as specified	
> in [RFC5952], to allow for easy textual comparisons.

RFC5952 requires lower-case, so your example is wrong and should be
 anima.acp+fd99:b02d:8ec3:0:200:0:6400:[email-masked]

> 5.5.4.  GRASP/TLS negotiation
...
> TBD: The exact negotiation steps in GRASP to achieve this outcome.

Right; the first thing is to define the format of the relevant GRASP
objective, then I think the rest will follow very naturally. We should
try to hold a side meeting about this in Berlin.

> 5.5.5.  ACP Security Profiles	
> 		 		
> A baseline autonomic device MUST support IPsec and SHOULD support	
> GRASP/TLS 

It's the GRASP spec that says that a GRASP implementation MUST
support TLS when there is no ACP. And every autonomic device
MUST support GRASP. So I think this should say

 A baseline autonomic device MUST support IPsec and GRASP

> ... and dTLS.  A constrained autonomic device MUST support	
> dTLS.

Hmm. I think we need to talk about dTLS. I find it hard to believe
that a node incapable of supporting TLS will ever be an autonomic node.
Also, if dTLS is a MUST for some nodes and a SHOULD for others,
we don't have guaranteed connectivity.

> Autonomic devices need to specify in documentation the set of secure	
> ACP mechanisms they suppport.

That doesn't help anybody. Autonomic nodes need to interoperate in
plug and play mode without any human needing to consult documentation
or check consistency. Security has to deploy itself with no intervention.

> 5.6.  GRASP instance details	
> 		 		
> Received GRASP packets are assigned to an instance of GRASP by the	
> context they are received on:	
>
> o  GRASP packets received on an ACP (virtual) interfaces are assigned	
>    to the ACP instance of GRASP	
> 
> o  GRASP packets received inside a TLS connection established for	
>    GRASP/TLS ACP negotiation are assigned to a separate instance of	
>    GRASP for that negotiation.

Just to repeat what I said a while back, this might not be how it's
implemented. There might equally be a single instance of GRASP in a
node but with several modes (insecure/ACP/TLS) that apply to individual
sessions. Sessions are distinguished explicitly in the GRASP protocol,
as well as by port number. Even if the implementation chooses to
launch separate instances of GRASP (rather than just a single multi-threaded
instance) there have to be common data structures shared between them.

>  TBD: The Details of the GRASP objective/packet formats still need to	
>  be defined.  Eg: Need to define an allocation for the objective of	
>  "Autonomic Node".

Yes. And its primary application would be ACP neighbor discovery, which
is why we don't need mDNS/DNSSD.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 8 Jul 2016 14:38:23 -0700

Inline

> GRASP discovery as well, to allow "100 pure Anima" deployments.)

I hope that we have all the folks in Berlin in the room to get to better rough
consensus on this. I was just writing into this version of the ACP draft what
seemed to be best aligned with the choices the current bootstrap draft has
made, but:

a) I did vote for GRASP in the bootstrap meetings but was the only one.
b) I always wanted to make sure that bootstrap can be adopted by non-anima
   solutions that wouldn't use ACP. mDNS might be an easier sell there.
c) Interpreting your text above seems to point to the option that the
   bootstrap draft could say that bootstrap used for an anima solution
   must use Grasp, and used outside of an anima solution should support
   mDNS ... does that sound like a good compromise ?
d) My preference of isolation is based on concepts i understand. I don't
   think that you need "separate protocols" for isolation. I understand
   how "instances" create very clear isolation independent of the protocol
   choosen. I am still not clear about your "mode" concept, hopefully
   i can "grasp" that in berlin.
e) The more complex the protocol is, the more attack vector i fear (FUD) it
   may have. Even though the discovery needed for anima is simple, mDNS
   is quite feature rich, and if the argument is to share a pre-existing
   mDNS library, then that makes me worried (admittedly FUD!). Simple
   example: Alice wants to discover bootstrap proxy, Bob is bootstrap proxy,
   but Dos (3rd device on Lan), responds with misleading responses about
   Bobs services. How well would a randomn "pre-existing" mDNS
   library be able to ignore Dos. How well could we specify Grasp to
   do this.

>  anima.acp+fd99:b02d:8ec3:0:200:0:6400:[email-masked]

Haha. We did it again. Michael must also have looked at some Cisco IOS
output. But you're now awarded the golden metal as the RFC5952 defender ;-)

>  A baseline autonomic device MUST support IPsec and GRASP

So my thinking was:

-> Negotiation of ACP between two neighbors:
   In many cases, devices will only support one security option.
   That makes the approach of simply probing the security option
   the most lightweight one. Thats why i wrote (already in the prior
   version of ACP draft), that ACP channel negotiation via TLS/GRASP
   was optional and primarily required when you need a more intelligent
   negotiation outcome than "probe channel options, each option has
   priority. Highest priority option that works wins".

-> The main reason to make that negotiation optional is that we
   haven't yet brainstormed IMHO any interesting negotiation choices
   that are more complex, and unless we have those, we couldn't even
   define the GRASP messaging for the negotiation. Thats why i felt
   it was better to make it this way, so we could have any more intelligent
   ACP channel negotiation via GRASP done in a separate draft when we've
   gollected some more complex negotiation elements. I am not sure
   how soon we'd need those. I think we'd only need those when wee start
   seeing more complex security channel options with parameters to
   negotiate.

> we don't have guaranteed connectivity.

CoAP devices supposedly will not have dTLS because they do not need TCP.
Carsten explained to me why they choose not to use TCP.

The ACP text shuold have good explanations why we do IMHO not need
any-to-eny connectivity. Aka: I will not connect a sensor to a
service provider core-router. [ The port on that core router costs
$50,000, you do not want to waste it on a $5 sensor]. Aka: its quite
useful to consider protocol profiles and have devices support a
subset of profiles that they need to talk to neighbors. Enterprise
edge-switches would likely be the ones with both some "IoT" profile
(dTLS) and some "basline" profile (TLS).

> or check consistency. Security has to deploy itself with no intervention.

See above on why i think that any-to-any connectivity isn't even
a requirement. Yes, its a very nice vision, but when it comes at the
cost of having to implement a "lowest-common-denominator" protocol
stack thats undesired dead weight on many devices, then the vision
becomes undesirable IMHO.

> instance) there have to be common data structures shared between them.

For instances, i don't think that's true. Ideally, different instanes
are different processes with totally independent data memory (code shared
of course). I also don't see off the top of my head any savings through
sharing data memory across the GRASP instances we're talking about. 

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jul 2016 19:19:36 +1200

Hi Toerless,

>    solutions that wouldn't use ACP. mDNS might be an easier sell there.

Yes, I agree with that. That's why I have no problem with mDNS/DNSSD
being REQUIRED for bootstrap. But that does not exclude GRASP Discovery.

>    mDNS ... does that sound like a good compromise ?

I didn't try to write exact normative text yet, and the phrase "mandatory
to implement" is actually ambiguous (does it mean "mandatory to write the
code" or "mandatory to switch on"?). But I think I lean towards saying that
any device that supports GRASP MUST use GRASP Discovery for bootstrap,
and any device that doesn't support GRASP MUST use mDNS/DNSSD for bootstrap.
Therefore proxies must respond to both, to allow mixed scenarios.

I don't especially like this but I think it is realistic and doesn't add
significantly to software footprints. Non-AN devices don't need any GRASP
code and AN devices will have GRASP code anyway, and are very likely to have
DNS code for other reasons. It also means that the "market" can naturally
choose the best solution.

>    i can "grasp" that in berlin.

The issue with genuinely separate instances is that they turn out to need
common data. In my Python-infected brain, they need to share things such as:

ASA_registry (and its lock)
objective_registry (and its lock)
discovery_cache (and its lock)
session_id_cache (and its lock)
flood_cache (and its lock)
FIFO queues for pending discovery operations

To be clear: we need a node-wide ASA registry so that we can guarantee
only one instance of a given ASA is active; we need a node-wide objective
registry to guarantee that only one ASA is managing a given objective (or
alternatively, to allow coordinated management by multiple ASAs); we need
a node-wide session_ID cache to guarantee no clashes of session_IDs. Then
it's much more efficient to share the discovery cache and queues and the
flood cache.

Given that amount of shared state, being hammered by separate threads
for each active ASA plus some internal threads for the GRASP kernel
itself, I can't visualize how to make separate instances provide genuine
isolation. (Of course, you could run genuinely separate instances in one
node but then each one would need its own IP address too.)

(Full disclosure: I run tests with my prototype by invoking separate
Python instances in one node, and they happily talk to each other even
with the same IP address, but there's a little bit of fakery to prevent
instance 1 discovering itself as well as discovering instances 2 and 3...)

>    library be able to ignore Dos. How well could we specify Grasp to

I certainly can't answer for mDNS and probably nobody can answer yet for
DNSSD. For GRASP, discovery *only* responds with a locator (address, protocol, port).
If both Bob and Dos reply to GRASP discovery, Alice gets to choose.
If she chooses Dos, we can't help her ;-).

Regards
    Brian