Subject: [Anima] review of grasp-08

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Nov 2016 17:47:40 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2016 16:41:34 +1300

Thanks Michael, we will wait a few more days before rolling up all comments
received. I am fine with most of your suggestions. A few things caught my eye:

>> in the case of a constrained-node network [RFC7228].

Yes, that clause is out of scope.

...
> I still don't know why "kernel mode" is used here.

You're correct, it's unnecessary.

> The reference to RFC2608 seems unwaranteed on page 13.

A matter of taste I guess. But it can be dropped with no pain.

> would specify it more completely,

If we did that, we'd need at least to say that it's out of scope. I certainly
agree that it's underspecified at the moment, which probably worse than
saying nothing.

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

What was the point there? (Clearly, discovered link-local addresses MUST NOT
be sent on to another interface, is that it? But that affects the Discovery
Response process, not the relay process. Must check my code, too...)

> This would make external auditing/debugging (such as via network sniffer)

Hmm. That needs some thought. I thought that the semantics of this was
very hard to capture in a generic way.

(One way would be to add a new flag value, so that an objective could
be labelled F_NEG for negotiation and F_NEG_DRY for dry-run negotiation.
That has a great advantage - it could be retrofitted any time, and can be
rejected with an M_INVALID by a node without dry-run capability.)

> place if not be the right ASA?

This covers the case where the ASA crashes at the critical moment - without
this provision (depending on implementation details) the socket would
be left hanging. Also consider that discovery results can be cached, so
there might be a real time gap between the M_RESPONSE and the M_REQ_NEG,
giving  more chance that the ASA crashes or even exits cleanly.

>         No port number or protocol (UDP/TCP), right?

Correct, as currently specified. It's only there to disambiguate the
session ID in the minute chance of an ID collision.

>           ["ACP", flags, 1, ["bootstrap-okay"]]

I think so, but I'll need to run it through my primitive validation chain...

> Could an O_DIVERT occur in an M_FLOOD?

Not in the current syntax, and I'm not sure why we'd need it.

> Can we have more than one locator option?

No. That is a feature - if you embed multiple objectives in a single M_FLOOD,
they are all associated with the same locator option. If that's a problem,
now would be a good time to say so ;-).

Regards
   Brian

On 24/11/2016 11:47, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Nov 2016 15:37:27 -0500

Brian E Carpenter <[email-masked]> wrote:
    > Thanks Michael, we will wait a few more days before rolling up all
    > comments received. I am fine with most of your suggestions. A few
    > things caught my eye:

Cool.

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

    > What was the point there? (Clearly, discovered link-local addresses
    > MUST NOT be sent on to another interface, is that it? But that affects
    > the Discovery Response process, not the relay process. Must check my
    > code, too...)

I think that's the point.  Should we even relay discovery messages from LL
origins?

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

    > be labelled F_NEG for negotiation and F_NEG_DRY for dry-run
    > negotiation.  That has a great advantage - it could be retrofitted any
    > time, and can be rejected with an M_INVALID by a node without dry-run
    > capability.)

I very much like this.

    >> if the time sequence is: initiator ----M_DISCOVERY---> responder
    >> (GRASP core) (UDP)
    ...> pass details to ASA

    > This covers the case where the ASA crashes at the critical moment -
    > without this provision (depending on implementation details) the socket
    > would be left hanging. Also consider that discovery results can be
    > cached, so there might be a real time gap between the M_RESPONSE and
    > the M_REQ_NEG, giving more chance that the ASA crashes or even exits
    > cleanly.

So, are you saying that on some systems that the ASA could crash without
closing the socket that is opened for the M_RESPONSE?

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

    > I think so, but I'll need to run it through my primitive validation

okay, I want to make sure that I understand it.

    > Not in the current syntax, and I'm not sure why we'd need it.

I don't think we do, but I'm just asking random questions as to why not...

    > No. That is a feature - if you embed multiple objectives in a single
    > M_FLOOD, they are all associated with the same locator option. If
    > that's a problem, now would be a good time to say so ;-).

I think that we physically can, it's an object inside an array.
Could we have an IPv4 and an IPv6 address?  Or a UDP and a TCP locator, or...?

I'm thinking about how to construct the ACP neighbour awareness M_FLOOD such
that it can also carry the Proxy locator.  I think it's probably not a
problem, as the locator can be the Proxy locator, and the ACP is implicitely
port-500 IKEv2, except that I'm reading the ACP document, and see that
actually there are many options for ACP security, but I haven't gotten that
far yet.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2016 10:35:24 +1300

Comments in line..
> I think that's the point.  Should we even relay discovery messages from LL

No. I definitely need to check this and add some words.

>     > time, and can be rejected with an M_INVALID by a node without dry-run

It's low cost to add to the spec, and harmless if not used. I also think I like it,
but what do other people think?

> closing the socket that is opened for the M_RESPONSE?

Yes - if the the actual listen() and accept() are in a separate thread
started by the GRASP engine, whereas the listen_negotiate() call is
in a thread started by the ASA. (I have a lot of threads and queues in
my prototype, because Python makes this extremely easy...)

> actually there are many options for ACP security, but I haven't gotten that

Right. But to be very clear, at the moment the M_FLOOD syntax is

 flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option / []), +objective]

but to associate a locator with each objective it would need to be

 flood-message = [M_FLOOD, session-id, initiator, ttl, +[(locator-option / []), objective]]

That would be more powerful for the case you describe. Since the locator
option could be a URI, it would suit EST quite well, wouldn't it?

Rgds
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Nov 2016 00:30:05 -0500

> That would be more powerful for the case you describe. Since the
    > locator option could be a URI, it would suit EST quite well, wouldn't
    > it?

yes-ish, but really, the proxy is in charge of where the Registrar is.
In a pure-ANIMA scenario, we don't use an EST URI.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Nov 2016 08:12:14 +1300

> In a pure-ANIMA scenario, we don't use an EST URI.

Ack. In any case, do you think we should make this change? It's now or never.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Nov 2016 21:44:20 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> Brian E Carpenter <[email-masked]> wrote: > Right. But to
    >> be very clear, at the moment the M_FLOOD syntax is
    >>
    >> > flood-message = [M_FLOOD, session-id, initiator, ttl,
    >> (locator-option > / []), +objective]
    >>
    >> > flood-message = [M_FLOOD, session-id, initiator, ttl, >
    >> +[(locator-option / []), objective]]
    >>
    >> > That would be more powerful for the case you describe. Since the >

    > Ack. In any case, do you think we should make this change? It's now or

I will propose something by Monday...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Nov 2016 13:27:27 +1300

> I think that's the point.  Should we even relay discovery messages from LL

In fact, this point is covered in the formal spec of the Locator Option. I propose
to augment it slightly thus:

<t>Note 1: The IPv6 address MUST normally have global scope. Exceptionally, during initialisation,
a link-local address MAY be used for specific objectives only (<xref target="secinst"/>). In this case
the corresponding Discovery Response message MUST be sent via the interface to which the link-local
address applies.</t>

<t>Note 2: A link-local IPv6 address MUST NOT be used when this option is included in a Divert option.</t>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Nov 2016 13:46:28 +1300

> Can we please have an example for M_FLOOD?

Was there a problem with the one at https://tools.ietf.org/html/draft-ietf-anima-grasp-08#appendix-D.2 ?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Nov 2016 11:50:52 +1300

Replying on some details in Michael's review. Points that are omitted here
are either obvious and will be fixed in the next version, or are already
the subject of other threads:

...
> 2.1 [Requirements for Discovery] --- does this belong in GRASP, vs reference model document?

It's lot more detailed than the reference model, and IMHO it is needed here
to provide context for the actual design. As far as consistency goes, Bing and
I are co-authors of the reference model so I guess it's our job to check. As far
as I know there is no inconsistency.

> very good job of taking this into account.  I think it should be striked out.

Agreed for the 'constrained node' part. I think that traffic volume and sleeping
nodes always apply.

...

> section 3.3 was good to write down, but seems like it is too much like a discussion.

We can try to tighten up the language. It seems like useful material, though/

> I would like the bullets as subsections, as they are really modes of

Hmm. Other opinions? That would make a *lot* of small subsections.

...

>    limitations of such an instance.

Hmm. I have a counter-proposal. I'm reluctant to drop all mention of TLS
from the draft, because otherwise, who knows what people might do - so how
about this (with other mentions of TLS removed):

3.5.2.1. No ACP

As mentioned in Section 3.3, some GRASP operations might be
performed across an administrative domain boundary by mutual
agreement, without the benefit of an ACP. Such operations
MUST be confined to a separate instance of GRASP with its
own copy of all GRASP data structures. Messages MUST be
authenticated and SHOULD be encrypted. TLS [RFC5246] and
DTLS [RFC6347] based on a Public Key Infrastructure (PKI)
[RFC5280] are RECOMMENDED for this purpose. Further details
are out of scope for this document.

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

I'm confused. I don't think we want any specifics about bootrap or ACP formation
in this draft. What we need here is the rules of the game for the GRASP
implementer, and I think the existing formulation (with the updates already
suggested by Toerless) is more appropriate. How DULL is *used* belongs in
the ACP draft, of course.

Specifically, I don't think we should exclude discovery messages. I don't think
it's wise to *use* them, but that choice belongs in the BRSKI and ACP drafts.
And we definitely should not say anything about specific objectives in the
GRASP draft - it needs to be completely agnostic about that.

> I want to suggest that point (3), about ACP formation be dropped, as it is

Well, that's an argument you need to have with Toerless.
There are two key differences between DULL and SONN:

1. SONN says "with unicast messages secured by TLS" (and don't ask me where
the PKI comes from, I only work here).

2. SONN says: Any type of GRASP message MAY be sent.

...
>    SHOULD respond with a cached discovery response if it was learnt from

Question to the WG - do you like that idea (inserting the message mnemonics
at various points)? It seems natural enough to me, because of course I use them
in my code, but is it the right thing to do in an RFC?

>    if it learnt that information from the same interface.

That's a subtle point. If it does so, it will very likely generate redundant
traffic. But if it doesn't do so, there might be cases of discovery failure.
(Also, this is the wrong thing to say on an NBMA network, I think.)
I propose to change it as Michael suggests, but I have a slight doubt.
The SHOULD NOT leaves us some wiggle room.

Thanks again for a very thorough review!

   Brian