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

[Brian E Carpenter <[e-mail]>]

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