Eric, On 01/06/2017 09:09, Eric Rescorla wrote: > > > On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter > <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote: > > On 31/05/2017 14:17, Eric Rescorla wrote: > > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > > brian.e.carpen...@gmail.com <mailto: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 > <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. > > > Yeah, I hear this stuff a lot, but I'd want to see some real analysis of > whether > this is an issue.
Well, I read the published RFC on constrained systems at the beginning of Anima, so it isn't clear in my mind today, but I think the people working in that area really do care about every byte. But it's a side issue really. The main point is that afaik it's still a lot easier to manipulate 32 bit numbers than say 128 bit numbers, and 2^32 seems plenty big enough for this particular (non-cryptographic) purpose. > > 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. > > > You think you're going to have anywhere near 2^64 sessions? Not likely, even 2^32 is a lot. > However, my point is that > > regardless of the odds, the implementer needs to check for a collision; > that's just correct programming. > > > No, I don't agree with this. Once collisions are sufficiently statistically > unlikely, you can assume they will not happen. Note that we routinely > assume this in situations where the results of collisions are far more > severe (e.g., generating cryptographic keys). This only adds one uint32 test in the code if clash.id_source == session_inst.id_source: which will almost never test true. So I think we'd better agree to differ. > > >> 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. > > > Not necessarily. You might, for instance, log an error and do something > when you believe that your network is under attack/broken. We can do that anyway. "Negotiation peer not listening" is not a normal situation anyway; if it persists it should be logged and investigated. (This is not just thoughtware - when I've run test ASAs with full diagnostic logging, this is in fact one of the errors I've used for debugging.) Note, I'm not saying it's unreasonable to add the M_DECLINED message in this case; it easily passes my test of "can I code this?" But I'd need a clear message from the WG to be convinced. > > >>> 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. > > > Yeah, I'm not generally a big fan of "here is some placeholder we have > no idea what we're going to do with" It's not really a placeholder IMHO. It's something that GRASP, as an infrastructure component, provides for app (the ASA) to use as it needs. Brian > > -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