Eric, On 25/05/2017 14:32, Eric Rescorla wrote: ... > ---------------------------------------------------------------------- > 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)
Yes, that certainly needs a thorough security review ASAP. > but S 3.5.2.1 doesn't (for) instance explain how to do certificate > validation, Indeed not. But... > which it clearly needs to do. We intentionally want to leave this for further study. Surely that is allowed? The text seems very clear on that. Personally, I'm not competent to design that, and this draft is already plenty long enough. So what can we write if we can't write "Further details are out of scope for this document."? > Finally, I don't > understand the security story for the multicast packets. I think I already typed this a day or two ago, but with an ACP, they are secured, because the ACP is a secure virtual overlay network. With no ACP they are of course wide open, unless some new magic has been invented that I'm not aware of. Hence the restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" > This is especially relevant for Rapid mode, where you are > attaching real work to these multicast packets. Correct. I think we need to forbid that in the no-ACP case. > 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. That is the trust model, but really as an explanatory matter I think it belongs in draft-ietf-anima-reference-model rather than here. I will add a few words in the High Level Deployment Model section and/or the Security Considerations. What we do say already is that authorization of ASAs is out of scope. I am certain that it needs to be tackled, but not here. > 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"? Yes, we will fix various instances of "reasonable" but I daresay further experience will shed new light. > > > 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. This only arises for discovery; the discovery result explicitly includes the address/protocol/port for the actual operation. For discovery it's in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.4 <t>The listening port used for TCP MUST be the same port as used for sending the Discovery UDP multicast, on a given interface. In a low-end implementation this MAY be GRASP_LISTEN_PORT. In a more complex implementation, the GRASP discovery mechanism will find, for each interface, a dynamic port that it can bind to for both UDP and TCP before initiating any discovery.</t> Python code on request ;-) > Finally, I don't see a spec for how you map CBOR onto the wire. Do you > just shove them on? Something else? Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't think we need to say anything more. > > I see that Martin Thomson raised a number of these issues in his review > in more detail. > Martin Stiemerling I think. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- Almost dinner time. I will get to your other comments tomorrow. Thanks Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
