Eric Rescorla has entered the following ballot position for draft-ietf-anima-grasp-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ISSUE 1 The security situation here is pretty unspecified here, in at least two respects: 1. In terms of communication security, you seem to have two modes: (a) Punt it to ACP (b) Use TLS as specified in S 3.5.2.1 I'm not reviewing ACP here (though I have some comments on that too) but S 3.5.2.1 doesn't (for) instance explain how to do certificate validation, which it clearly needs to do. Finally, I don't understand the security story for the multicast packets. This is especially relevant for Rapid mode, where you are attaching real work to these multicast packets. 2. I didn't find the security model very clear. As I understand things, basically anyone on the network who has ACP credentials is trusted to engage in negotiation with you, so, for instance, if you want to get parameter X, then you basically just trust whoever on the network offers you X. is that correct? That seems like it needs to be very explicitly called out. And if that's not true, then I don't understand the spec. ISSUE 2 This document seems like it provides incomplete guidance on how to actually implement it. For instance: discovery messages to a reasonable value, in order to mitigate possible denial of service attacks. It MUST cache the Session ID value and initiator address of each relayed Discovery message until What's "reasonable"? ISSUE 3. I don't think I understand how the transition from UDP multicast to TCP/TLS unicast works. Maybe I'm just misreading the spec, so could you point me to the section that describes this. Finally, I don't see a spec for how you map CBOR onto the wire. Do you just shove them on? Something else? I see that Martin Thomson raised a number of these issues in his review in more detail. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 3.5.4.3. After a GRASP device successfully discovers a locator for a Discovery Responder supporting a specific objective, it MUST cache this information, including the interface index via which it was discovered. This cache record MAY be used for future negotiation or synchronization, and the locator SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator. What's an "interface index" S 3.5.4.4. Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds. I'm not sure I'm following here. Does the relay instance retransmit with its own timeout? It MUST cache the Session ID value and initiator address of each relayed Discovery message until any Discovery Responses have arrived or the discovery process has timed out. How does this behave if the original initiator's timeout is longer than GRASP_DEF_TIMEOUT? S 3.5.5. A negotiation procedure concerns one objective and one counterpart. Both the initiator and the counterpart may take part in simultaneous negotiations with various other ASAs, or in simultaneous negotiations about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. "multi-threaded" is an odd word here. I assume you mean that you are doing multiple stuff at once, but you might actually write the system using non-multi-threaded techniques. S 3.7. You seem to be going to a lot of trouble to deal wit session ID collisions. Why don't you just make session IDs 128-bit random values and then you won't have to worry about collisions. The Session ID SHOULD have a very low collision rate locally. It MUST be generated by a pseudo-random algorithm using a locally generated seed which is unlikely to be used by any other device in the same network [RFC4086]. Why don't you just require a cryptographically secure PRNG? That will be required to implement the rest of this protocol S 3.8.2. You seem to introduce a normative dependency on CDDL here. I see that it's in your changelog here, but what are your intentions about this document, given that CDDL seems to not even be a WG document S 3.8.5. It MUST contain a time-to-live (ttl) for the validity of the response, given as a positive integer value in milliseconds. Zero is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). Why do this, rather than just forbidding 0. S 3.8.6. If a node receives a Request message for an objective for which no ASA is currently listening, it MUST immediately close the relevant socket to indicate this to the initiator. This is to avoid unnecessary timeouts if, for example, an ASA exits prematurely but the GRASP core is listening on its behalf. This is not secure. You need a secure indication of non-knowledge, not a transport-level close. S 3.9.5.4. What are the semantics of a Divert URI? What do I dow ith the path part? S 3.10.4. The semantics of "dry run" seem pretty unclear. Is it just "tell me if you would be sad about doing this"? _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
