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.
> > 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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
