Re: [Anima] review of grasp-08

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.

>>    >system calls with core GRASP functions running in kernel mode.  For
...
> 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.

> I'd prefer that all the mention of TLS be removed to another document that
> 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.

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

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

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

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

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

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.

> 3.8.11:
>         I think that the "initiator" option is just an IP address.
>         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.

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

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:
> 
> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 