On 03/05/2017 12:47, Martin Thomson wrote: > 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,
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 > confidentiality for the general discovery case is unwise and not > having authentication for the same seems like a real deal-breaker. 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. > > On 3 May 2017 at 07:06, Brian E Carpenter <[email protected]> wrote: >> (IETF list removed from CCs. Nothing secret here, it just seems >> unnecessary to fill several thousand inboxes with this...) > > 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. > >> 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. > > Both are informative. 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. > >>> 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. > > 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. *** 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. >>> 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. Indeed, but the ACP is supposed to provide this. >> 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. > > See above. > >>> 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. > > That's up to you, I'm just trying to help. > >> 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. > > 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. 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
