Re: [Anima] review of grasp-08

[Michael Richardson <[e-mail]>]

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?

    >> 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.

    >> 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?

    >> 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.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-