Re: [Anima] review of grasp-08

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

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:

On 24/11/2016 11:47, Michael Richardson wrote:

...
> 2.1 [Requirements for Discovery] --- 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!

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.

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

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
> operation!

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

...

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

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.

> 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'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
> included in part 2.

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.

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

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?

> 
> ADD:
>    A neighbor SHOULD NOT respond with a cached response on an interface
>    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