On 15/03/2018 19:56, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> > I have aligned my Python demos** of the BRSKI discovery mechanisms with
> > the -12 draft.
> > Here are dumps of the received flood messages, with discussion:
>
> > (1) Flood sent by the registrar as received by the proxy. This is
> Python output
> > (so the b'...' strings are hexdumps of bytes objects.)
>
> > [9, 1729214102, b'2406e00741ec000128ccdc4c97036781', 120000,
> [['AN_join_registrar', 5, 255, 'EST-TLS'], [103,
> b'2406e00741ec000128ccdc4c97036781', 6, 80]]]
>
> > Nothing serious to report here. Since the draft only defines the
> 'EST-TLS'
> > form, I haven't included any alternatives. My code could also handle
> announcing
> > IP-in-IP for example.
>
> > Compare to the example in the draft:
>
> > [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
> > ["AN_join_registrar", 4, 255, "EST-TLS"],
> > [O_IPv6_LOCATOR,
> > h'fda379a6f6ee00000200000064000001', TCP, 80]]
>
> > I'd prefer to see TCP represented as IPPROTO_TCP to align with the
> > GRASP spec.
>
> I think that what I did was confuse some of the abstract and specific value.
> Because things like M_FLOOD and O_IPv6_LOCATOR are symbolic representations
> of numbers, while TCP was just something that I thought I could abstract
> myself.
>
> I've changed it to say IPPROTO_TCP everywhere.
Thanks. (I have a little gripe that IANA doesn't control these names, which
are pretty much universal, but only defined in C files that float around
in cyberspace.)
>
> > [9, 160559994, b'2406e00741ec000128ccdc4c97036781', 180000,
> [['AN_proxy', 5, 1, ''], [103, b'fe8000000000000028ccdc4c97036781', 6,
> 11805]]]
>
> > Compare to the example in the draft:
>
> > [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
> > ["AN_Proxy", 4, 1, ""],
> > [O_IPv6_LOCATOR,
> > h'fe800000000000000000000000000001', 'TCP', 4443]]
>
> > Several comments:
>
> > 1. The 3rd element is the 'initiator' address. The draft shows that as
> > a link-local. It doesn't matter too much, but my code uses a routeable
> > address. It's only there for disambiguation in a multi-hop flood,
> > which doesn't apply in this case. The address that matters is the second
> > one, in the locator. The packet itself is sent link-local.
>
> Since it's a link-local, DULL single-hop "flood" that can never get forwarded
> in any way, and the it's occuring on the "bare" wire, using any GUA (or ACP
> ULA) would seem to leak information that should remain safely inside the ACP.
That's not what the GRASP spec says:
The 'initiator' field in the message is a globally unique IP address
of the initiator, for the sole purpose of disambiguating the Session
ID in other nodes. If for some reason the initiator does not have a
globally unique IP address, it MUST use a link-local address for this
purpose that is highly likely to be unique, for example using
[RFC7217]. Determination of a node's globally unique IP address is
implementation-dependent.
Maybe we should have mandated link-local for DULL, but we didn't.
Can we hold that as a possible GRASP erratum?
> > 2. 'TCP' shouldn't be a string, it should be IPPROTO_TCP as above.
>
> Agreed.
>
> > 3. The objective is defined as having a null value. Why isn't it
> > "EST-TLS" again?
>
> I'm not sure, I thought that the objective-value was what we were looking
> for. I.e. if some device is trying to find a place to backup 1GB,
> then it might have an objective of "KERNEL:DUMP" with an objective-value
> of 1073741824.
>
> Since we don't care what the dimension of the objective, I thought leaving it
> empty was the best thing.
That's fine if it was intentional. It would also be easy to define non-null
values later if we found them useful.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
