On 31/05/2017 14:17, Eric Rescorla wrote: > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > [email protected]> 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.
Will fix. > >>> 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? We do have people in Anima who care about every extra byte, in case this stuff does end up in constrained devices. > As far as birthday paradox, I suspect this protocol is going to > break down well before 2^32 endpoints, let alone 2^64. Of course, but it's the number of overlapping sessions that would be relevant for the birthday paradox. However, my point is that regardless of the odds, the implementer needs to check for a collision; that's just correct programming. >> 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). Sure. I just meant is that covered by RFC4086? Now I have to go look... yes, I guess it is. OK, will fix. > > > >> 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. True, but I don't think your suggestion helps. Let me explain: Suppose that we add a new use of the M_DECLINE message for this case. Then the ASA which is currently not accepting Request messages will send an M_DECLINE followed by a TCP FIN. The initiator receives an M_DECLINE, closes its socket and returns an error code to the API. If it receives an unexpected FIN (or RST) it closes its socket and returns an error code to the API anyway. It has to; there's nothing else it can do. As far as the ASA involved is concerned, it's a failure in any case. If it's an attacker, or some other random event, that causes the failure, it really looks no different than a failure caused by the remote ASA. (OK, one possible difference: the error code in the API might be 18 #"Socket error sending negotiation request" instead of 23 #"Negotiation peer not listening", depending on the exact timing.) But this doesn't affect what the ASA does in any way: it shrugs its shoulders, probably waits for a few seconds, and tries again. Inserting the M_DECLINE really makes no difference. >>> 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? Note 2: Normal GRASP operations are not expected to use this option. It is intended for special purposes such as discovering external services. Therefore its use is not further described in this specification. GRASP is just the carrier so is completely agnostic about your question. >>> 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" Yes. FYI, draft-carpenter-anima-asa-guidelines, "Guidelines for Autonomic Service Agents" will hopefully be filling in a number of gaps in future. (I think one the issues here is that GRASP is just part of a complete system, which happens to have reached the IESG first.) Rgds Brian >> >> We will try to clarify this, at least with a cross-reference. >> >> Thanks, >> Brian >> > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
