Telechat Review of draft-ietf-anima-grasp-11
review-ietf-anima-grasp-11-artart-telechat-thomson-2017-05-01-00
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?