Telechat Review of draft-ietf-anima-grasp-11
review-ietf-anima-grasp-11-artart-telechat-thomson-2017-05-01-00

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.

Caveat here: I didn't review this as thoroughly as I would have liked.  It's a
large document, 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.

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

As an aside, use of UDP needs a few more details.  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.

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

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.

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.

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?

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?