On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote:
> Now getting to Eric's COMMENTs: > > On 25/05/2017 14:32, Eric Rescorla wrote: > ... > > ---------------------------------------------------------------------- > > 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" > > It's a term of art in the socket API: > https://tools.ietf.org/html/rfc3493#section-4 > Does it need a reference? > Yes. > > 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. > > Well, yes, the odds would be better with 128 than 32 but > that's extra bits on the wire and there'd still be the > birthday paradox... Why is this amount of extra bits on the wire significant? As far as birthday paradox, I suspect this protocol is going to break down well before 2^32 endpoints, let alone 2^64. > 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 > > Well, certainly there will be for the security bootstrap > and the ACP. Is there a different reference for that? > I'm not understanding the question here. You basically can't build any cryptographic system without a secure PRNG (in the worst case, if you have a private key you can use that to seed the PRNG). > 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. > > I don't see this as a security issue. There would be an alternative, > which is to send back an immediate M_DECLINE, but that is quite > a bit harder to implement and I don't really see an advantage: > the requester will just get back an error code in either case. > An ASA must always be ready for an error return. > If the attacker can force an error when the other side didn't want one then that implicates the security of the system. > > S 3.9.5.4. > > What are the semantics of a Divert URI? What do I dow ith the > > path part? > > Two things on this: > Following Alexy's comment, we are likely to add protocol/port > to this type of locator option. Given that, is there anything special > about the Divert case? A URI should be valid however you receive it. > Again, what do you do with the path section of the URI? > > 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"? > > This is explained better in an earlier section: > https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.5 This just seems to say "it's up to the ASA" -Ekr > > > We will try to clarify this, at least with a cross-reference. > > Thanks, > Brian >
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
