[Anima] review of grasp-08

[Michael Richardson <[e-mail]>]

I'm sorry for the wide-ranging comments here; I started on Sunday on the
airplane, but didn't finish until today.   We talked M_FLOOD yesterday at the
bootstrap call, and we will edit to synchronize with my comments here.

Chairs: Are we using the issue tracker? It's not in the menu at:
    https://tools.ietf.org/wg/anima/

If not, where did the issue # that Brian and co. used to track my previous
comments?   Oh, it's just numbers in the issues part of the document...

I went through my previous comments which are at:
  https://www.ietf.org/mail-archive/web/anima/current/msg02148.html

I think that sections 3.3 and 3.4 are a response to my request for
an operating overview, and I think that this works well.

I asked for examples, and they are in Appendix D, but while reading the
document, I had forgot about it, and nothing told me to go look there in the
text.  A see D.1 would be good.
Could I ask for small change:

from:   The initiator multicasts a discovery message:
to:     The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a discovery message:

   [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 2, 2, 0]]

and ditto for "A peer (X) responds", as it took me a minute or two to figure
out what this third argument was, that it was the initiator address.


Now to comments on the -08 text...

2.1 --- does this belong in GRASP, vs reference model document?
    Would like MB and Toerless to confirm that it is consistent in wording
    with reference model document!

>   D8.  The discovery process must not generate excessive traffic and
>   must take account of sleeping nodes in the case of a constrained-node
>   network [RFC7228].

I think this actually out of charter, and furthermore, GRASP doesn't do a
very good job of taking this into account.  I think it should be striked out.

SN7.
orig:  o  Dependencies and conflicts: In order to decide a configuration on
          a given device, the device may need information from neighbors.

orig:  o  Dependencies and conflicts: In order to decide upon a configuration
      for a given device, the device may need information from neighbors.


>      be as automatic as possible.  The protocol's role is limited to
>      the ability to handle discovery, synchronization and negotiation
>      at any time, in case an ASA detects an anomaly such as a
>      negotiation counterpart failing.

I think this sentence could use some work.  Maybe:
   The protocol's role is limited to discovery, synchronization and
   negotiation.  This process can occur at any time, and an ASA may
   need to repeat any of these steps when the ASA detects an anomaly
   such as a negotiation counterpart failing.

3.1. terminology

was:
      Discovery, Negotiation and Synchronization.  In the protocol, an
      objective is represented by an identifier and if relevant a value.

new:
      Discovery, Negotiation and Synchronization.  In the protocol, an
      objective is represented by an identifier and -- if relevant -- a value.

      (or maybe two comma are more correct)

There is too much functional description in the XYZ Objective descriptions.
At least, it needs to have a forward reference.

going on, remove *cut*/*tuc*

   o  Discovery Responder: a peer that either contains an ASA supporting
      the discovery objective indicated by the discovery initiator, or
      caches the locator(s) of the ASA(s) supporting the objective.  *cut*The
      locator(s) are indicated in a Discovery Response, which is
      normally sent by the protocol kernel, as described later.*tuc*

3.2:
   >Interface (API) will be needed between GRASP and the ASAs.  In some
   >implementations, ASAs would run in user space with a GRASP library
   >providing the API, and this library would in turn communicate via
   >system calls with core GRASP functions running in kernel mode.  For

I still don't know why "kernel mode" is used here.  Certainly on Linux and
Windows, we don't need code in the "kernel", just a priviledged process if
we are allocated a <1024 port, otherwise, just an unprivledged system daemon.

On a Cisco/Huawei/Broacade router, I don't know a lot about OS architecture, but on
Juniper a straight FreeBSD process would work fine.
        "operating system core module" (section 3.4) is much better.
I think I mentioned "kernel" issue before.

The reference to RFC2608 seems unwaranteed on page 13.

section 3.3 was good to write down, but seems like it is too much like a discussion.
I would like the bullets as subsections, as they are really modes of
operation!

3.4 should mention M_FLOOD along with M_DISCOVERY.
or, perhaps the M_FLOOD mechanism can be clearly labelled as providing
awareness of an ASA.

I appreciate 3.5.1 trying to establish some security via (D)TLS, but it
simply doesn't say enough to result in interoperability. (for instance,
should certificates be validated? If so, what should be in the CN? Do we need
PFS? When do we rekey? Are client-side certificates important? Is there a
link between IP addresses and something in the CN?)

I'd prefer that all the mention of TLS be removed to another document that
would specify it more completely, a document titled something like:
      "Using GRASP between service providers"
or:   "Securing GRASP using TLS"
or:   "CoAP/DTLS mode for GRASP"


I'd like 3.5.2 point (1) be numbered 3.5.2.1 so it can be better referenced,
and I'd like it say something like:

3.5.2.1 Inter-domain GRASP Instance
   As mentioned in Section 3.3, some GRASP operations might be performed
   across an administrative domain boundary by mutual agreement.
   Such operations MUST be confined to a separate instance of GRASP with its
   own copy of all GRASP data structures.  Details of this mode are the
   subject of a future document that would clearly detail the security
   limitations of such an instance.

3.5.2.2 Bootstrap and ACP GRASP Instance (DULL)

   This instance is nicknamed DULL - Discovery Unsolicited Link Local.

   The bootstrap process uses only M_FLOOD messages to announce the location
   of the bootstrap proxy.  This message is used only on-link using
   link-local multicast, on the underlying (insecure) media.

   Full ANIMA nodes that act are willing to act as bootstrap proxies will
   include a flag indicating this into this message.  Full ANIMA nodes
   looking for ACP peers will also indicate that in the message.

   Full ANIMA nodes MAY listen for M_FLOOD messages on insecure interfaces.
   Other messages MUST be discarded.  M_FLOOD messages which are improperly
   formatted such as:

   o  having a loop count > 1
   o  having a GRASP message type != M_FLOOD
   o  having a non-link-local source address

   MUST be discarded.  It is acceptable for the M_FLOOD to be to the
   ALL_GRASP_NEIGHBOR multicast address, or to be unicast to the host in
   question.

   ANIMA nodes in bootstrap mode listen on the ALL_GRASP_NEIGHBOR multicast
   address, and listen according to the same rules above, but examine the
   BOOTSTRAP_PROXY attribute only.

   Details of DULL are included in: [I-D.ietf-anima-autonomic-control-plane]


I want to suggest that point (3), about ACP formation be dropped, as it is
included in part 2.

In 3.5.3, please delete:

   In particular,
   to guarantee interoperability during bootstrap and startup, using TCP
   for discovery responses is strongly advised.

I don't think it makes any sense at this point.
Bootstrap discovery will use M_FLOOD, while actual bootstrap uses either EST
(RFC7030) which is HTTP/TCP, or possibly one of the EST over CoAP proposal(s)
[yes, currently plural, alas]

Again, please omit further discussion of TLS.

In section 3.5.4.1, can we write:

   The discovery (M_DISCOVERY) action will normally be followed by a
   negotiation (M_REQ_NEG) or
   synchronization (M_REQ_SYN) action.  The discovery results could be utilized by
   the negotiation protocol to decide which ASA the initiator will
   negotiate with.

3.5.4.2:

   A complete discovery process will start with a multicast (of M_DISCOVERY)
   on the local
   link.  On-link neighbors supporting the discovery objective will
   respond directly (with M_DISCOVERY).  A neighbor with multiple interfaces
   SHOULD respond with a cached discovery response if it was learnt from
   another interface.

ADD:
   A neighbor SHOULD NOT respond with a cached response on an interface
   if it learnt that information from the same interface.

3.5.4.3:
        s/GRASP kernel/GRASP core/


3.5.4.4:
QUERY re:
   The relayed discovery message MUST have the same Session ID as the
   incoming discovery message and MUST be tagged with the IP address of
   its original initiator (see Section 3.8.4).

I thought we were adding something about Link Local addresses here?

3.5.5:
re:
   The details, including the
   distinction between dry run and an actual configuration change, will
   be defined separately for each type of negotiation objective.

I would very much like it if dry-run/real-run request was standardized.
This would make external auditing/debugging (such as via network sniffer)
much easier to see.

Can we change this paragraph to include message types?

   If the counterpart can immediately apply the requested configuration,
   it will give an immediate positive (accept) answer (using M_END).  This
   will end the negotiation phase immediately.  Otherwise, it will negotiate
   (using M_NEGOTIATE)
   It will reply with a proposed alternative configuration that it can
   apply (typically, a configuration that uses fewer resources than
   requested by the negotiation initiator).  This will start a bi-
   directional negotiation (using M_NEGOTIATE) to reach a compromise between
   the two ASAs.

...
   a peer to insert latency in a negotiation process if necessary
   (Section 3.8.9, M_WAIT).

3.5.5.1:
change:
   A Discovery message MAY include a Negotiation Objective option.  In
   this case the Discovery message also acts as a Request Negotiation
   message to indicate to the Discovery Responder that it could directly
   reply to the Discovery Initiator with a Negotiation message for rapid
   processing, if it could act as the corresponding negotiation
   counterpart.  However, the indication is only advisory not
   prescriptive.

to:
   A Discovery message MAY include a Negotiation Objective option.  In
   this case it is as if the initiator sent the sequence M_DISCOVERY,
   followed by M_REQ_NEG.  This has implications for the construction of
   the GRASP core, as it must carefully pass the contents of the Negotiation
   Objective option to the ASA so that it may evaluate the objective directly.

   When a Negotiation Objective option is present the ASA replies with an
   M_NEGOTIATE message (or M_END if it is immediately satisfied with the
   proposal), rather than with an M_RESPONSE.

3.5.6.1:
   s/GRASP kernel/GRASP core/

Please add, after para 4, ("..with multiple link-layer.."):

   Link-Layer Flooding is supported by GRASP by setting the loop count to
   1, and sending with a link-layer source address.  Floods with link-layer
   source addresses and a loop count larger than 1 are not supported, and
   such messages MUST be discarded.

My comments about section 3.5.5.1 would seem to apply to 3.5.6.2 as well.

3.8.3:
please add:
   The CBOR parser used by GRASP should be configured to know about
   the GRASP_DEF_MAX_SIZE so that it may defend against overly long
   messages.

3.8.4:

   Exceptionally, a Discovery message MAY be sent unicast to a peer
   node (via UDP or TCP), which will then proceed exactly as if the message
   had been multicast, except that when TCP is used, the response will be
   on the same socket as the query.

3.8.6, about:

>   If a node receives a Request message for an objective for which no
>   ASA is currently listening, it MUST immediately close the relevant
>   socket to indicate this to the initiator.

if the time sequence is:
   initiator ----M_DISCOVERY--->  responder (GRASP core) (UDP)
       ...> pass details to ASA
   initiator<----M_RESPONSE-----  ASA (TCP)
   initiator-----M_REQ_NEG----->  ASA (same socket)

then, according to above, why would an ASA have responded in the first
place if not be the right ASA?

3.8.11:
        I think that the "initiator" option is just an IP address.
        No port number or protocol (UDP/TCP), right?

        Can we please have an example for M_FLOOD?

        Is this valid:

[M_FLOOD, 124567, fe80::1234, 27,
          [[O_IPv6_LOCATOR, fe80::1234, IPPROTO_UDP, 500]],
          ["ACP", flags, 1, ["bootstrap-okay"]]

Could an O_DIVERT occur in an M_FLOOD?
Can we have more than one locator option?








--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-