On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter < [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]> 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. > Yeah, I hear this stuff a lot, but I'd want to see some real analysis of whether this is an issue. > 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? > 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). > > >> 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. > >>> 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" -Ekr > >> > >> 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
