Re: [Anima] review of grasp-08

[Brian E Carpenter <[e-mail]>]

Comments in line..
On 25/11/2016 09:37, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     > Thanks Michael, we will wait a few more days before rolling up all
>     > comments received. I am fine with most of your suggestions. A few
>     > things caught my eye:
> 
> Cool.
> 
>     >> 3.5.4.4: QUERY re: The relayed discovery message MUST have the same
>     >> Session ID as the incoming discovery message and MUST be tagged with
>     >> the IP address of its original initiator (see Section 3.8.4).
>     >>
>     >> I thought we were adding something about Link Local addresses here?
> 
>     > What was the point there? (Clearly, discovered link-local addresses
>     > MUST NOT be sent on to another interface, is that it? But that affects
>     > the Discovery Response process, not the relay process. Must check my
>     > code, too...)
> 
> I think that's the point.  Should we even relay discovery messages from LL
> origins?

No. I definitely need to check this and add some words.

> 
>     >> 3.5.5: re: The details, including the distinction between dry run and
>     >> an actual configuration change, will be defined separately for each
>     >> type of negotiation objective.
>     >>
>     >> I would very much like it if dry-run/real-run request was
>     >> standardized.  This would make external auditing/debugging (such as
>     >> via network sniffer) much easier to see.
> 
>     > Hmm. That needs some thought. I thought that the semantics of this was
>     > very hard to capture in a generic way.
> 
>     > (One way would be to add a new flag value, so that an objective could
>     > be labelled F_NEG for negotiation and F_NEG_DRY for dry-run
>     > negotiation.  That has a great advantage - it could be retrofitted any
>     > time, and can be rejected with an M_INVALID by a node without dry-run
>     > capability.)
> 
> I very much like this.

It's low cost to add to the spec, and harmless if not used. I also think I like it,
but what do other people think?

> 
>     >> 3.8.6, about:
>     >>
>     >>> 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.
>     >>
>     >> if the time sequence is: initiator ----M_DISCOVERY---> responder
>     >> (GRASP core) (UDP)
>     ...> pass details to ASA
>     >> initiator<----M_RESPONSE----- ASA (TCP)
>     initiator-----M_REQ_NEG-----> ASA (same socket)
>     >>
>     >> then, according to above, why would an ASA have responded in the first
>     >> place if not be the right ASA?
> 
>     > This covers the case where the ASA crashes at the critical moment -
>     > without this provision (depending on implementation details) the socket
>     > would be left hanging. Also consider that discovery results can be
>     > cached, so there might be a real time gap between the M_RESPONSE and
>     > the M_REQ_NEG, giving more chance that the ASA crashes or even exits
>     > cleanly.
> 
> So, are you saying that on some systems that the ASA could crash without
> closing the socket that is opened for the M_RESPONSE?

Yes - if the the actual listen() and accept() are in a separate thread
started by the GRASP engine, whereas the listen_negotiate() call is
in a thread started by the ASA. (I have a lot of threads and queues in
my prototype, because Python makes this extremely easy...)

>     >> Can we please have an example for M_FLOOD?
>     >>
>     >> Is this valid:
>     >>
>     >> [M_FLOOD, 124567, fe80::1234, 27, [[O_IPv6_LOCATOR, fe80::1234,
>     >> IPPROTO_UDP, 500]], ["ACP", flags, 1, ["bootstrap-okay"]]
> 
>     > I think so, but I'll need to run it through my primitive validation
>     > chain...
> 
> okay, I want to make sure that I understand it.
> 
>     >> Could an O_DIVERT occur in an M_FLOOD?
> 
>     > Not in the current syntax, and I'm not sure why we'd need it.
> 
> I don't think we do, but I'm just asking random questions as to why not...
> 
>     >> Can we have more than one locator option?
> 
>     > No. That is a feature - if you embed multiple objectives in a single
>     > M_FLOOD, they are all associated with the same locator option. If
>     > that's a problem, now would be a good time to say so ;-).
> 
> I think that we physically can, it's an object inside an array.
> Could we have an IPv4 and an IPv6 address?  Or a UDP and a TCP locator, or...?
> 
> I'm thinking about how to construct the ACP neighbour awareness M_FLOOD such
> that it can also carry the Proxy locator.  I think it's probably not a
> problem, as the locator can be the Proxy locator, and the ACP is implicitely
> port-500 IKEv2, except that I'm reading the ACP document, and see that
> actually there are many options for ACP security, but I haven't gotten that
> far yet.

Right. But to be very clear, at the moment the M_FLOOD syntax is

 flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option / []), +objective]

but to associate a locator with each objective it would need to be

 flood-message = [M_FLOOD, session-id, initiator, ttl, +[(locator-option / []), objective]]

That would be more powerful for the case you describe. Since the locator
option could be a URI, it would suit EST quite well, wouldn't it?

Rgds
    Brian