Subject: [art] Artart telechat review of draft-ietf-anima-grasp-11

From: Martin Thomson <[email-masked]>
Date: Mon, 01 May 2017 19:39:50 -0700

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?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 May 2017 09:06:09 +1200

(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:

> I don't believe that this document describes a protocol that could be

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.

>  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

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.

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

> ever get deployed.  The status of the implementations only really

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

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.
 
> peer ensure reachability?  Can middleboxes verify that endpoints are

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

> 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.
   
> 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.
 
> 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.
 
> for any overall negotiation timer, or do you just multiply out the hop

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)
 
> enact intermediate values, or does it commit only when the negotiation

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 May 2017 10:47:01 +1000

Thanks for the replies Brian,

It seems like I missed the transport stuff entirely.  I'd selfishly
and sheepishly suggest making that text more precise, but I will
respect your editorial discretion.

I remain deeply concerned about the security parts.  At a minimum, the
protocol needs a clear definition of how authentication and
confidentiality mechanisms are used, even if the process by which keys
and so forth are established is left to other work.  In part, that's
easy, all the unicast stuff can use TLS and you can wave your hands
about how trust anchors get around.  However, given that this
traverses the Internet, I am going to suggest that not having
confidentiality for the general discovery case is unwise and not
having authentication for the same seems like a real deal-breaker.

> unnecessary to fill several thousand inboxes with this...)

Yeah, the tool added that.  That might have been an unwise choice.  (Alexey?)

> which are indeed normative dependencies.

Both are informative.

> for sepcific message types.

OK, that isn't as imperative as I am used to.  "designed for" isn't
the same as "are sent using".  And the leading sentence of the second
paragraph does a great job of obfuscating things.

There are still a couple of pieces missing.  I assume that you create
a CBOR serialization of the message and put those end to end on a TCP
socket; or you create a CBOR serialization of the message and put that
in a UDP datagram.  Saying that would genuinely help, even if it seems
even absurdly obvious.  (Caveat: I would naturally ask where TLS fits
in when you do this...)

> dependencies, the GRASP RFC cannot appear without them.

See above.

> were intended to help on this point. IMHO, ASCII art wouldn't

That's up to you, I'm just trying to help.

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

So my understanding is that the timeout runs for the entire
multi-message exchange?  That seems unfortunate because it can't then
be based on the observed RTT.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 May 2017 13:58:12 +1200

On 03/05/2017 12:47, Martin Thomson wrote:
> traverses the Internet, 

No. In the recommended scenario, it is confined to the ACP.
In the scenario of a limited deployment across an operator
boundary, we do recommend TLS:
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.2.1

> I am going to suggest that not having

Link-local multicasts don't traverse the Internet, and the relaying
process is limited by the loop count even if there is no ACP. Except
during bootstrap, everything is supposed to go over the ACP, even 
the LL multicasts. During the insecure part bootstrap, there is no
relaying of multicasts off-link. However, as far as we know that
is the only exposure, and nobody knows a way round it.
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.2.2
After that, all the nodes in the ACP are authenticated.

> Yeah, the tool added that.  That might have been an unwise choice.  (Alexey?)

You can delete it manually in the review tool. I often do that
when reviewing, unless there does seem to be an IETF-wide issue.

>> which are indeed normative dependencies.

Oh. Well, technically you don't need to know how they work in order
to implement GRASP. I'll do whatever the community wants, of course.

> even absurdly obvious.

*** We can add that early in 
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8

> (Caveat: I would naturally ask where TLS fits
> in when you do this...)

If there's no ACP, then yes, we need to use TLS but "Further details are
out of scope for this document." If the community shows any signs of
wanting to do this, as for the UDP case, another document would be
needed, I think.

>>> has been put into providing an authentication framework.

Indeed, but the ACP is supposed to provide this.

> be based on the observed RTT.

True. It's more aimed at being based on the nature of the autonomic
function concerned, which might involve some time-consuming action,
like making a measurement, resetting a slave device, or even
physically moving an antenna. And in the far future, maybe even
invoking a machine learning algorithm or some other slow process. 

We do have a mechanism for extending the timeout (the Confirm Waiting
message). That was included on the assumption that occasionally an
agent might to go off and do some homework before replying to a request.
I must say I hadn't thought of RTT as an issue, because we tend to assume
that the timescale for an autonomic action will be far greater than
an RTT, so timeouts will be milliseconds to seconds, and RTTs within
the autonomic domain will be sub-millisecond in many cases.

Are you suggesting we should be able to reduce the timeout as well?
(That would simply mean the parameter in the Confirm Waiting message
would become a signed integer, I guess.)

    Brian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 May 2017 12:32:17 +1000

You seem to have covered the other points well enough.  I won't say
that I'm happy with the security story; I would strongly prefer that
you at least say that unicast messages are added to TLS.

In fact, here's an idea: use TLS for unicast always and leave the
rules about what authentication is offered and accepted to the other
documents.  Then you only have the link-local multicast stuff in the
clear.

On the topic of link-local multicast, you definitely want text in
"3.5.4.5.  Rapid Mode (Discovery/Negotiation binding)" on the
implications for security.  I would prefer that you forbid triggering
a negotiation during a multicast discovery because it lacks any form
of protection.

> the autonomic domain will be sub-millisecond in many cases.

Ahh, I always assume that machines work faster than the network, so
the opposite really..

> Are you suggesting we should be able to reduce the timeout as well?

Can't it already do that?  I mean, it can't account for any time
already spent waiting, but it could include the value 0, which means
don't wait any more when you receive this (a nonsensical thing here,
but it demonstrates that a reduction is possible).

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 May 2017 14:45:53 +1200

Duly noted.

At this point I think we'll wait for direction from the AD. I expect
other points will come up from the IESG.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 May 2017 13:51:08 +1200

Just one point while working on the text:

...
> but it demonstrates that a reduction is possible).

Actually it's redundant. If the peer replies with another Negotiation
message we keep going; if it replies with a Negotiation End message
we're done anyway. So there's never anything to gain by shortening
the timeout that I can see.

    Brian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 May 2017 12:29:16 +1000

> the timeout that I can see.

WFM

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 May 2017 14:47:20 +1200

...
> to implement GRASP. I'll do whatever the community wants, of course.

The reason that these two references are currently Informative
in GRASP is that a person coding the protocol has no need to 
understand their details. (She will need to understand the ACP's
API, but that is not described in the ACP draft.) Therefore,
technically, although using the ACP is a SHOULD requirement in
GRASP, my understanding of the rules is that it is not a
normative reference.

The downside is that if we get into the RFC Editor queue, GRASP
could in theory be published before the ACP becomes an RFC.
That seems wrong.

Opinions, please!

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 May 2017 15:25:20 -0400

> about how trust anchors get around.  However, given that this

I've argued strongly against doing this.
"Use TLS" with hand-waving is akin to rfc5406 "Use IPsec": it gets us nowhere.

We are doing quite a lot of work to get trust anchors in the right place
(BRSKI), to describe how to bring up IP (or maybe GRE) over IPsec in the ACP
document.

GRASP does not stand alone.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 07:18:27 +1000

> GRASP does not stand alone.

I have to assess the document on its own merits.  As already
established, there are no normative dependencies on any sort of key
management.

That this work has been done suggests that perhaps a small change to
the structure of this and other documents could be made to rectify the
problem.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 May 2017 12:47:05 +1200

> the structure of this and other documents could be made to rectify the

The ACP will now be a normative reference for GRASP. It's the ACP whose
trust model depends on the security bootstrap, which will therefore need
to be a normative reference for the ACP.

How trust is established when there is no ACP is explicitly out of scope,
see section 3.5.2.1.

    Brian