Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-02.txt

From: [email-masked]
Date: Mon, 21 Mar 2016 16:44:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF.

        Title           : An Autonomic Control Plane
        Authors         : Michael H. Behringer
                          Steinthor Bjarnason
                          Balaji BL
                          Toerless Eckert
	Filename        : draft-ietf-anima-autonomic-control-plane-02.txt
	Pages           : 32
	Date            : 2016-03-21

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Apr 2016 14:03:02 +1300

Hi,

A few points I noticed:

> 3.  Requirements
...
>    The default mode of operation of the ACP is hop-by-hop, because this
>    interaction can be built on IPv6 link local addressing, which is
>    autonomic, and has no dependency on configuration (requirement 1).

This statement assumes that the link interfaces concerned have stable interface
identifiers that do not need to be configured. Somewhere it needs to be
specified how these identifiers are set, for example by citing RFC7217.

> 5.3.  Capability Negotiation
> 
>    Autonomic devices may have different capabilities based on the type
>    of device, OS version, etc.  To establish a trusted secure ACP
>    channel, devices must first negotiate their mutual capabilities in
>    the data plane.  This allows for the support of different channel
>    types in the future.

Unless I have misunderstood, we need to say "in the link-local data plane".
That is all we can assume at power-on.

> 5.4.  Channel Establishment
...
>    The channel establishment MUST be authenticated.  Whether or not, and
>    how, a channel is encrypted is part of the capability negotiation,
>    potentially controlled by Intent.
...
>    Since channels are by default established between adjacent neighbors,
>    the resulting overlay network does hop by hop encryption.  Each node
>    decrypts incoming traffic from the ACP, and encrypts outgoing traffic
>    to its neighbors in the ACP.  Routing is discussed in Section 5.7.

The first quoted paragraph says that encryption is optional, but the second
one just says that there is encryption. Which is it? Perhaps we should say
that encryption MUST be enabled by default, unless Intent says otherwise.

> 5.6.2.  The Base Addressing Scheme
...
>      8      40          3                     77
>    +--+--------------+------+------------------------------------------+
>    |FD| hash(domain) | Type |             (sub-scheme)                 |
>    +--+--------------+------+------------------------------------------+
...
>    o  "FD" identifies a locally defined ULA address.

According to RFC 5952, IPv6 addresses should use lower case, so s/FD/fd/.

> 5.6.3.1.  Sub-Scheme 1
...
>    o  Device ID: A unique value for each device.
> 
>    The device ID is derived as follows:

There is some commentary needed here. Firstly, this field in IPv6 is
called the Interface ID. It's OK to consider it as a device ID, but what
it really is is the Interface ID used for addresses assigned to the
ACP instance of loopback interface.

Secondly, the IPv6 addressing architecture requires it to be 64 bits;
that isn't a choice. (Long story, if you want the details see RFC 7136,
RFC 7421, RFC 7608, and draft-ietf-6man-rfc4291bis.)

> 5.6.4.  Usage of the Zone Field
...
>    If aggregation is required, the 13 bit value allows for up to 8191
>    zones.
...
>    ...In this case the ACP loopback is
>    configured with two ACP addresses: One for zone 0 and one for the
>    assigned zone.  This method allows for a smooth transition between a
>    flat addressing scheme and an hierarchical one.

I suggest citing RFC 7608 which makes it clear that the different "zone IDs"
are really just subnets within the overlay network, and routed as such. The
only trickery here is multihoming the node into two networks, which isn't
trickery at all. However, it is necessary to specify the address selection
method to be applied (vanilla RFC 6724 or something else?)

>  [We could divide the zone space
>    into manual and automatic space - to be discussed.]

I hate to see 'manual' in any Anima document, but especially here. Don't
we want the ACP to re-form itself after an earthquake, without any need for
humans?

> 7.4.  GRASP instance details

One implementation comment: I don't think we will really run multiple GRASP
instances (which would mean duplicating some data structures in a very
tricky way). I think we will actually tag each on-going Session ID within
GRASP to say whether it's running in (e.g.) insecure mode, secure-with-TLS mode,
or secure-via-ACP mode. The external effect will be the same, and per-session
granularity seems correct. We probably need to add some optional parameters to
the GRASP API to capture this.

...
>    o  GRASP packets received on an ACP (virtual) interfaces are assigned
>       to the ACP instance of GRASP
> 
>    o  GRASP/UDP packets received on L2 interfaces where the device is
>       willing to run ACP across are are assigned to a separate instance
>       of GRASP for that L2 interface.  We call those instances of GRASP
>       the "insecure L2 GRASP instances" and the ASA to perform the
>       discovery the "insecure L2 discovery ASA" (IL2D).

Here we hit a problem I've been concerned about for a while. Unless you
explicitly add support for link-local multicast to the ACP, GRASP/UDP
is insecure, because the only use of UDP is for LL multicast. But this
draft doesn't talk anywhere about how the ACP could support LL multicast.
Therefore, all GRASP Discovery and Flood Synchronization messages are
currently insecure. (Discovery Response, Synchronization and negotiation
are unicast and can be secured.)

Confirming some comments I made to Toerless a week or two ago:

>    For every L2-discovery instance of GRASP and its IL2D, the following
>    rules apply, amending and overriding the recommendations in
>    [I-D.ietf-anima-grasp]:
>
>    o  GRASP link-local multicast discovery messages MUST use GTSM
>       [RFC5082].  With GTSM, discovery packets are sent with a TTL of
>       255 and packets received with a TTL smaller than 255 are ignored
>       upon receipt.

I see no problem in adding that on any stack where the socket API permits.
Actually we could operate Discovery and Flood Synchronization in that
way all the time, but with link-local addresses we are probably safe
anyway.

>    o  The GRASP loop count of GRASP discovery packets must be set to 1
>       on sending.

That limits the scope of discovery to the LAN.

>    o  GRASP MUST send response messages for the discovery objected
>       defined here (overriding the MAY).

That's fine; it's only MAY in GRASP in case a node wants to hide.

>    o  GRASP MUST NOT respond to discovery objectives with the Divert
>       option - objectives learned and cached are solely for local
>       consumption.

That's not a problem. (Also, as insurance, the receiver can be coded to
ignore any discovered locators that were Diverts.)

>    o  GRASP MUST NOT relay discovery or any other messages across
>       different interfaces.

That is guaranteed by the loop count = 1.

>    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".

Sure, see my message yesterday. But let's get the conceptual level right first.

Regards
    Brian