Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11

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

(IETF list removed from CCs. Nothing secret here, it just seems
unnecessary to fill several thousand inboxes with this...)

Thanks for the review, Martin. Responses below:

On 02/05/2017 14:39, Martin Thomson wrote:
> Reviewer: Martin Thomson
> Review result: Not Ready
> 
> This document describes a generic protocol that is for doing just
> about anything and run over just about any transport protocol.  Within
> that remit, the document is coherent and though I agree with Barry
> about unnecessary verbiage, it seems to achieve the goals it sets.
> 
> I don't believe that this document describes a protocol that could be
> deployed.

Obviously, the WG disagrees, so I will try to see below where the
discrepancy lies.

In a few places I've marked points where IMHO a text change is
needed by ***. But generally I hope the issue is just that it's
a long, complex document.

> Caveat here: I didn't review this as thoroughly as I would have liked.
>  It's a large document,

Yes. If we could have made it shorter, we would have :-(

> though it's clear that it isn't large enough
> to cover its intended scope in a couple of key areas.  There is with
> lots of content in some areas - some of it quite detailed.  But there
> is surprisingly little detail in areas that I would have imagined to
> be critical.  The two areas that concern me most are transport and
> security.

Security as such is simply out of scope. This protocol does not
secure itself. I thought that was very clearly stated, e.g.
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#page-14

The main references for external security are
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane
which are indeed normative dependencies.

> The draft talks very little about how messages get to their
> destinations.  There's a brief section on UDP/TCP usage in one place
> and an admonishment to use DTLS/TLS in another, but those sections
> don't seem to have ever met each other.  I'm forced to conclude that
> this is well ahead of the other pieces that will fill in those gaps.

This puzzles me, because
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.3
says:

>>    GRASP discovery and flooding messages are designed for use over link-
>>    local multicast UDP.  They MUST NOT be fragmented, and therefore MUST
>>    NOT exceed the link MTU size.
>> 
>>    All other GRASP messages are unicast and could in principle run over
>>    any transport protocol.  An implementation MUST support use of TCP.
>>    It MAY support use of another transport protocol.  However, GRASP
>>    itself does not provide for error detection or retransmission.  Use
>>    of an unreliable transport protocol is therefore NOT RECOMMENDED.

What more do we need to say in general? See below, where we do say more
for sepcific message types.

> Given that there are no drafts associated with the ANIMA working group
> that attempt to fill those gaps, I really don't know how this would
> ever get deployed.  The status of the implementations only really
> confirms this.

Actually we sent packets from a more recent version of the BUPT
implementation to the Python implementation in Chicago, but it
revealed problems with the BUPT code that couldn't be fixed during
the week. But it did verify that they could send CBOR and we could
receive it; just the wrong CBOR ;-).

> As an aside, use of UDP needs a few more details.

Why? It's NOT RECOMMENDED except for the link-local multicasts.

You're correct that *if* we recommended UDP for the unicast messages,
we'd need more details. In fact, I did make a start on changing my
prototype to do that, and decided that it was a complex matter
and not worth the effort. You give some of the reasons below, and I
think there are others. If we wanted to change this to a recommended
approach, it would very likely need a separate document. Basically,
having to cope with any number of simultaneous overlapping UDP
sessions requires a lot of mechanism, all of which comes for free
with SOCK_STREAM.

> A few that spring to mind:
> 
>   Congestion - Since this appears to be a lock-step protocol, that is
> probably acceptable (one packet per round trip is generally considered
> fine).
> 
>   Loss - This doesn't appear to have any provision for loss recovery. 
> For a long-running negotiation that includes wait steps, this seems
> necessary.

True, but the GRASP timeout mechanism would kick in - the session
would fail. An ASA has to be designed to recover from failure anyway.
However, in an overloaded network we want the autonomic solution to work
even when everything else is broken, which is IMHO a good argument
against UDP.
 
>   Middleboxes - If a peer has to wait a long time for a negotiation,
> what happens if the NAT binding goes away in the meantime?  How does a
> peer ensure reachability?  Can middleboxes verify that endpoints are
> willing to communicate?

The ACP is transparent, and we definitely recommend IPv6 anyway,
so NATs are out of scope. That's stated as a note at
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.9.5
*** It should be stated more prominently, however, probably in
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.2

> The locators concept relates to this.  It would appear to be
> under-specified, largely as a result of not having any concrete
> transport definitions.  For instance, how would you use each of the
> different locators used in the protocol?  Though it might seem
> obvious, even the IPv6 locator doesn't actually include a definition
> of what you might do with it.  
> 
> Does the endpoint construct a UDP packet with the CBOR of a GRASP
> message as its payload and unicast it to the identified IP and port? 
> Seems obvious, needs writing down.

UDP for multicast, TCP for unicast, but yes.

We are explicit at several points, for example
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.2
for discovery messages,
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.2
for discovery responses,
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6
for request messages.
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6
for flood messages.

We aren't explicit for the other unicast messages because they are
direct replies within a TCP connection, so it truly seems obvious.
   
> The same goes for the FQDN, which I suppose involves an AAAA/A record
> lookup. It needs to say that, unless it's really SRV or something
> else.  And URIs aren't generically usable, so a lot more work would be
> needed to make sense of a URI.

We do in fact say something about them in
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6
but I agree it is a bit wrong. FQDNs are clear enough, but URI usage
would definitely depend on the use case. We still want to define them
as a locator type, because somebody is certain to define such a use case. 
*** So that does need a change to the text, leaving the usage
of URIs explicitly for future work.
 
> Security seems to be critical, but the key question of establishing a
> trust domain is left out of scope.  That conveniently removes some
> hard problems, but I believe that there were a few inconvenient
> problems that were removed at the same time.  For instance,
> authentication and confidentiality mechanisms for discovery seem to be
> non-existent.  (D)TLS can't secure a multicast signal, but no effort
> has been put into providing an authentication framework.

As above, that whole issue is covered in the Anima secure bootstrap
work and the autonomic control plane. Since they are normative
dependencies, the GRASP RFC cannot appear without them.
 
> Nits
> 
> The document really isn't clear about how multi-round negotiation
> works.  A picture might help here.  I ask because the definition of
> how timers run is a little unclear.  I probably missed the text about
> this, but I assume that an endpoint that responds to M_REQ_NEG with
> M_NEGOTIATE  starts a new timer, and if a multiple rounds are used the
> timer is reset each time that M_NEGOTIATE is sent.  Is there any need
> for any overall negotiation timer, or do you just multiply out the hop
> (loop) count?

Firstly, the sample message exchanges in Appendix D, especially
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#appendix-D.5
were intended to help on this point. IMHO, ASCII art wouldn't
add much.

https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.5
explains how timeouts work for initial negotiation requests. But we
have cunningly hidden the explanation of timeout for the whole
negotiation in
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 :

   When an initiator sends a Request Negotiation message, it MUST
   initialize a negotiation timer for the new negotiation thread.  The
   default is GRASP_DEF_TIMEOUT milliseconds.  Unless this timeout is
   modified by a Confirm Waiting message (Section 3.8.9), the initiator
   will consider that the negotiation has failed when the timer expires.

*** At the minimum, we need a forward reference to that in section 3.5.5.

(Of course the actual timeout values are local, so they don't appear
in the protocol, but they do appear in the API, which is not a WG
item at present: draft-liu-anima-grasp-api)
 
> The existence of "dry run" negotiations leads me to ask how a protocol
> participant is expected to behave when negotiating.  Is it expected to
> enact intermediate values, or does it commit only when the negotiation
> concludes?

That depends on the semantics of the individual objective; including the
flag in the protocol is a sort of convenience function. We should cover
this point somewhere; there's another non-WG draft where that probably
belongs (draft-carpenter-anima-asa-guidelines).

We do say this in
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.10.4 :

   An issue requiring particular attention is that GRASP itself is a
   stateless protocol.  Any state associated with a dry run operation,
   such as temporarily reserving a resource for subsequent use in a live
   run, is entirely a matter for the designer of the ASA concerned.

Personally I imagine that an ASA would mark a resource as 'reserved'
during a dry-run negotiation but only commit it when a live negotiation
ensues. But we don't want to over-specify before there is some
experience with writing full scale ASAs.

Hope all this helps,

     Brian