Comments in line..
On 25/11/2016 09:37, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> 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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
