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