On Wed, May 31, 2017 at 4:41 PM, Brian E Carpenter < [email protected]> wrote:
> Eric, > > On 01/06/2017 09:09, Eric Rescorla wrote: > > > > > > On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter < > [email protected] <mailto:[email protected]>> wrote: > > > > On 31/05/2017 14:17, Eric Rescorla wrote: > > > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > > > [email protected] <mailto:[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 < > 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. > Sure, it doesn't need to be cryptographic, just statistically unique. And as you say, 2^{32} *isn't* large enough for that, but 2^{128} is. > 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. That's not good, it's bad. It means it's a code path which is likely not to be tested correctly. So I think we'd better agree to differ. Yes, I agree that this is within WG discretion. > > > 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. > If you opt not to change it, you need to call it out in the security considerations, because truncation attacks are a real thing. > 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. > This seems like a distinction without a difference. -Ekr
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
