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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Aug 2017 14:39:03 +1200

Hi,

Here are my comments on ACP version -08. First the ones I rank
as substantive isssues, then a few nits.

Issues:
-------

> 2.  Terminology
...
> ULA  "Unique Local Address".  The IPv6 equivalent to RFC1918 IPv4
> addresses.  ACP addresses are ULA.

No, they are *not* equivalent to RFC1918, because those are ambiguous
and ULAs are not. Please avoid controversy, just cite RFC4193.

> 3.2.  Secure Bootstrap over an Unconfigured Network
...
> ...This does not require any configuration
> on intermediate nodes, because they can communicate through the ACP.

s/they can communicate/they can communicate securely/

> 4.  Requirements
...
> ACP4:  The ACP MUST be generic.  Usable by all the functions and
>        protocols of the AN infrastructure.  It MUST NOT be tied to a
>        particular protocol.

I'm not sure what the last sentence is saying. Do you mean
"MUST NOT be tied to a particular transport protocol" or
"MUST NOT be tied to a particular security protocol"?
Or do you mean "MUST NOT restrict the choice of upper layer
protocol"? Or do you simply mean "MUST provide a generic
IPv6 service"?

Also, there's no requirement about performance or the
expected traffic density. Should we say something either
in the Requirements section or in the Notes in the
Overview section? I assume that performance is not critical
and ACP traffic density is expected to be low.

> 5.  Overview
...
>   Default policy is: To all adjacent nodes in the
>   same domain.

I know this is explained later, but I think both
"adjacent" and "domain" need some qualification.
For example:

  Default policy is: To all adjacent link-layer autonomic
  nodes in the same autonomic domain.

...
>    5.  Inside the ACP VRF, each node sets up a virtual (loopback)
>        interface with its ULA IPv6 address.

I think we have cases where a node has multiple ULAs.

> 6.1.  Domain Certificate
> 
>    To establish an ACP securely, an ACP device MUST have a globally
>    unique domain certificate (LDevID),...

You need a normative reference for the LDevID format.

> 6.1.1.  ACP information
> 
>    The domain certificate (LDevID) of an autonomic node MUST contain ACP
>    specific information, specifically the domain name, the address of
>    the device in the ACP with the Zone-ID set to zero ("ACP address").

You need a cross-reference for Zone-ID, which is undefined at this point.

...
>    anima.acp+<acp-address>{+<rsub>{+<extensions>}}@<domain>

What notation is that? Is {} supposed to be an optional item?
If so, why not use [] as in ABNF, and cite ABNF.

>  <domain> is used to indicate...

Is that required to respect DNS syntax? If so, please say so.

> {<rsub>.}<domain>

That's wrong. <domain> is preceded by "@" in your syntax, and 
in your example, the dot is in the <extensions> element
"area51.research".

Is there a length limit on the rfc822Name ?

> 6.1.2.  Maintenance

As Michael R said, all the stuff about the registrar
should be in BRSKI, not duplicated here. In fact, it's
very confusing to have it here. If we want a cert
renewal mechanism, surely that's part of BRSKI?

[One detail however:

>    The loop-count MUST be sete to 255.  When an ACP node
>    receives the M_FLOOD, it will have been reduced by the number of hops
>    from the EST server.

I don't like that. The role of the loop count is loop prevention,
so it should be set to a reasonable upper bound on the "radius"
of the network. GRASP has two measures for loop detection, this
one and detection of duplicate session IDs, but that was
intentional redundancy.]

> 6.2.  AN Adjacency Table
> 
>    To know to which nodes to establish an ACP channel, every autonomic
>    node maintains an adjacency table.  The adjacency table contains
>    information about adjacent autonomic nodes, at a minimum: node-ID, IP
>    address, domain, certificate.

Please specify which IP address(es) you mean. Link-Local, ACP
Address(es), or both?

Can you also indicate that an API to this table is needed (at 
least by the GRASP core, and possibly by any ASA that wants to
make direct use of the ACP)?

> 6.3.  Neighbor Discovery with DULL GRASP
...
>           [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1,
>               ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"],
>               [O_IPv6_LOCATOR,
>                    h'fe80000000000000c0011001FEEF0000, UDP, 15000]
>           ]

Once we are fully settled on this I can generate an example and
its binary value for complete clarity. I have one comment which is
that when I last updated draft-carpenter-anima-ani-objectives,
I replaced "SYNCH-FLAG" with "5" (the actual value of the flag
byte) - otherwise you have to define SYNCH-FLAG. Actually
the value 5 indicates discovery+synchronization; everything
should work just the same if it was 4 (synchronization alone),
since it's flooded. I don't know if we care about that difference.

...
>    The ttl and loop-count are fixed at 1 since this is a link-local
>    operation.

No, the ttl is milliseconds - the valid lifetime of the flood.
You have that correct in your version of AN_join_registrar.

> 6.8.2.  ACP as the Security and Transport substrate for GRASP
...
>    GRASP inside the ACP uses link-local UDP IPv6 multicast across the
>    ACP virtual interfaces for GRASP neighbor discovery...

and flooding

Also, you might want to add a reminder that GRASP does its own
relaying of multicast packets between interfaces; the ACP is
not required to provide multicast routing.

>                                                  ...and IPv6 over TLS
>    across the ACP virtual interfaces for any of its unicast messages.

Wait, what are you saying here? Do you really mean IPv6
over TLS, or TLS over TCP over IPv6?

As Eric Rescorla asked us at one point, please draw a ladder
diagram of the protocol stack.

...
>    TLS is mandated for GRASP because the ACP secure channel mandatory
>    authentication and encryption protects only against attacks from the
>    outside but not against attacks from the inside - compromised ACP
>    members

I think the threat model really needs a clearer explanation. I assume
that Bob and Alice are good guys, and Eve is a malicious ACP member.
So a packet from Alice to Bob is encrypted from Alice to Eve, decrypted
by Eve, then encrypted from Eve to Bob. So Eve can do what she wants
with the decrypted packet.

Now, who does the TLS wrapping? Will that be done by the ACP,
or by the GRASP core? If the latter, you still need to explain
how the ACP conveys the cert information to GRASP.

> 6.10.1.  Fundamental Concepts of Autonomic Addressing
...
>    o  Addresses in the ACP are permanent, and do not support temporary
>       addresses as defined in [RFC4941].

Add something like:

  o  Addresses in the ACP are not considered sensitive on
     privacy grounds, so do not need to be pseudo-random
     as discussed in [RFC7721].

(You probably also need to discuss why the ACP is not subject
to scanning attacks: because ULAs are not propagated across
domain boundaries.)

> 6.10.2.  The ACP Addressing Base Scheme
> 
>    The Base ULA addressing scheme for autonomic nodes has the following
>    format:
> 
>   8      40             2                     78
> +--+-----------------+------+------------------------------------------+
> |FD| hash(subdomain) | Type |             (sub-scheme)                 |
> +--+-----------------+------+------------------------------------------+
> 
>                    Figure 2: ACP Addressing Base Scheme
> 
>    The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
>    which a type field is added:
> 
>    o  "FD" identifies a locally defined ULA address.

For the Nth time, please s/FD/fd/ as required by RFC5952

> 
>    o  Type: This field allows different address sub-schemes in the
>       future.  The goal is to start with a single sub-schemes, but to
>       allow for extensions later if and when required.  This addresses
>       the "upgradability" requirement.  Assignment of types for this
>       field should be maintained by IANA.

You need to write precise directions to IANA.

> 6.10.3.  ACP Zone Addressing Sub-Scheme
> 
>    The sub-scheme defined here is defined by the Type value 0 (zero) in
>    the base scheme.
> 
>            51            1     13                    63             1
>  +---------------------+---+---------+-----------------------------+---+
>  |    (base scheme)    | Z | Zone-ID |         Device-ID           | V |
>  |                     |   |         | Registrar-ID | Device-Number|   |
>  +---------------------+---+---------+--------------+--------------+---+
>                                              48           15

s/51/50/

Although I think it would be simpler to do this:

           48        2   1     13                    63             1
 +----------------+----+---+---------+-----------------------------+---+
 | ULA prefix     |Type| Z | Zone-ID |         Device-ID           | V |
 |                | 00 |   |         | Registrar-ID | Device-Number|   |
 +----------------+----+---+---------+--------------+--------------+---+
                                             48           15

> 
> 6.10.4.  ACP V8 Addressing Sub-Scheme
> 
>    The sub-scheme defined here is defined by the Type value 1 (one) in
>    the base scheme.
> 
>              51                           63                 8
>    +---------------------+-----------------------------+----------+
>    |    (base scheme)    |         Device-ID           |        V |
>    |                     | Registrar-ID | Device-Number|          |
>    +---------------------+--------------+--------------+----------+
>                                46             32

Same comments.

> 6.10.5.  Other ACP Addressing Sub-Schemes
> 
>    Other ACP addressing sub-schemes can be defined if and when required.
>    IANA would need to assign a new "type" for each new addressing sub-
>    scheme.  With the current allocations, 5 more schemes are possible

That's confusing. In your terminology, only two more types are
possible (10 and 11). It would be simpler to simply define 3 type
bits.

A general remark: when a wider audience looks at this, there will
be complaints that we are re-creating classful addressing. I suggest
adding some text about this. (Along the lines of: it's true, and
here is why it doesn't matter.)

>    Every ACP device (RPL node) announces an IPv7 prefix

Forward into the future!

> 6.12.4.  ACP interfaces
...
>    These packets are of course redundant (unnecessary) and would be
>    discarded by GRASP on receipt as duplicates.

...by use of the GRASP Session ID.

> 7.2.  How (per L2 port DULL GRASP)
...
> L3/L2 devices SHOULD support per-L2 port ACP.

Clarify that ACP (and GRASP) capable devices do
not need to depend on MLD snooping, since they
catch LL multicasts directly per port. But non-ACP
switches MUST either support MLDv2 snooping or
operate as pure L2 bridges for all multicast
packets.

Also, is there anything to say here about VLANs?
 
> 11.  Security Considerations

I think you need to insert cross-references to
various security discussions elswhere in the draft.
 
> 12.  IANA Considerations

TBD!

Nits:
-----

> 2.  Terminology
...
>    ACP VRF  The ACP is modelled in this document as a "Virtual Routing
>       and Forwarding" (VRF) component in a network device.

I suggest listing this alphabetically as VRF, not under A.

>    AN "Autonomic Network".  A network according to
>       [I-D.ietf-anima-reference-model].  Its main components are Intent,
>       Autonomic Functions and ANI.

I find the second sentence doesn't help, especially by referring to Intent.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Aug 2017 02:36:57 -0400

> one and detection of duplicate session IDs, but that was

If we were using RPL in non-storing mode, we'd get DAO messages from the
leaves directly to the root indicating their parent.  The DODAG root would
therefore know exactly what the deepest leaf was.  That would be the radius
From the root to the furthest node, but of course discovery might happen from
edge to edge, so the longest path would therefore be 2x that size (up the
tree to the top and down again).

As we are using RPL in storing mode, the DAOs are summarized at each level,
we won't know that information.  That's kind too bad I think, because each
node knows how deep it is, they just don't report it to the root in anyway.

It would be easy to add a CHILD_MAX_RANK DAO option to the DAO packet.
It wouldn't make it to the top unless all nodes supported it, but it still
might be worth writing it down.

Unless someone else can figure out a way with existing information for a
DODAG root to know how deep the network is?

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Aug 2017 02:57:44 -0400

I like this much better.

    > here is why it doesn't matter.)

Agreed. But they are assignment classes, not routing classes.

    > Also, is there anything to say here about VLANs?

There are some chicken and egg problems here.

On the one hand (other hand in next email), there may be a variety of L2
technologies ("LAN EXTENSION") which may be provided by other providers which
the ACP should "bridge" across as if it was just a wire.   A configuration
which is not-uncommon (but seemed to surprise more than multiple sales
engineers from more than three major companies) is for an (incumbent) telco
to offer a service that connects one location (the datacenter, DC) to many
locations.  The central location has a VLAN tag that leads to each other
locations, and at that other location (customer premises, CP), the VLAN tag
does not appear.

Now, hook things up and do not tell the devices at either end about this
scenario ("remote hands" have just unpacked the drop-shipped equipment).

This is a *PRIME* use for autonomic networking.  (I actually tried to do this
all with DHCP/TFTP for unconfigured devices, btw, with some success, but then
the manufacturer of the high-quality $300 CPE device screwed up their
platform OS making it a low-quality $300 device)

On the CP side it's all good, because the freshly unpacked equipment would
see the GRASP M_FLOODs (whether proxy announcements for an unimprinted
device, or AN_ACP announcements for an imprinted device) without a VLAN tag.

But, the DC device has a problem.  All it knows about is a fiber of 1GbE or 10GbE
Ethernet here.  Any untagged packets it sent will be dropped.

If the CP device would send some kind of traffic, then the DC device would
see it, with the VLAN tag, and could autonomically configure a VLAN interface
for it, and begin to talk to it.   That would be great.

If the CP device is imprinted, the AN_ACPs would just go out, and it would be
all well.  But, in the bootstrapping case, we've said that the pledge should
remain quiet...  so maybe we want to revise that?  On the other hand, the
pledge actually won't be completely quiet.  It will send out DADs for any LL
addresses it might have configured.
(Today, we wrote that Pledges should configure fresh RFC4941 temporary
addresses for use in enrollment.  And that they should try new addresses
whenever all of their prospects fail, in case some of the problems are
related in some way to their choices of address)

So, perhaps we should write is that, on an unconfigured interface, if one
sees VLAN encapsulated traffic on an interface on which, and one *would* send
out the AN_ACP/AN_Proxy messages, that one should start sending some M_FLOODs
for awhile on that VLAN interface.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Aug 2017 03:18:31 -0400

> the ACP should "bridge" across as if it was just a wire.   A

Now, let's look at the question from the point of view of the the LAN
EXTENSION provider.  Of course they are also using autonomic switches, and
they'd like to be able to plug stuff together randomly and have their ACPs
formed so that they can maintain service.

The LAN EXTENSION provider also may have a drop-ship device to the customer
premises (which, using the previous example, is both the "DC" and the "CP"
ends, because both ends are their customer, being the L3-ISP that bought the
L2 transport).   The LAN EXTENSION customer doesn't always know if the fiber
will plug directly into the customer's equipment, or if some kind of media
converter from copper to fiber will be used.  The straight media converters
are remarkably unreliable because they attempt by fail to pass MII across and
fail, and you have to lock ports to HD, etc.  Meanwhile multiport switches
with SFP ports are common, and sometimes one winds up serving multiple
customers from the same demark...

So that means that the tagged side of the circuit, which is at the DC,
probably has AN_ACP messages coming out *untagged* from the L2-provider.
The L3-ISP's device is going to see them, but of course the ACP connection
ought to fail. (baring some kind of out of band arrangement, which is out of
scope here)

At the previously mentioned "CP" side of things, despite the media converters
*trying* to be stupid optical to electrical converts, it turns out that they
often have a management VLAN on the optical side, and if an AN_ACP packet
were to arrive with that preconfigured VLAN ID, it would be accepted.  The
customer's traffic actually might also arrive in another VLAN tag, and that
media-converter device would be charged with removing the tag.  Or, everyone
might agree that the extra device is stupid, and plug things directly into
the real CPE.

Once the LAN EXTENSION provider has their ACP up to the demark devices, the
sensible thing for them to do is to disable ACP messages on their "access"
ports.  Sensible, but maybe not reliable... I think that a device that loses
all ACP connectivity *SHOULD* disable that disabling, and starting sending
some AN_ACP messages on all ports....

I should say that I assumed a flat ethernet on the fiber side of things, but
it could also be a wide variety of metro-ethernet-ring technologies... PBB,
TRILL, and six or so other 802.FOO things.