Hi Toerless,
Slight change of subject header to bring us up to date.
Thanks for all the work. I think the -10 version is much better.
No comments on the -08 to -09 revisions.
On -09 to -10 revisions:
...
>>> 5. Inside the ACP VRF, each node sets up a virtual (loopback)
>>> interface with its ULA IPv6 address.
>>
>> I think we have cases where a node has multiple ULAs.
>
> Right now, an ACP would have exacty one Certificate derived ULA
> and 0 or more configured ones for autonomic-connect interfaces in case
> the operator wants to use the manual addressing sub-scheme on the autonomic
> connect interface.
>
> What other cases are you thinking of ?
I forget but I think Michael R had a case for this. Or possibly Michael B.
...
>>> anima.acp+<acp-address>{+<rsub>{+<extensions>}}@<domain>
>>
>> What notation is that? Is {} supposed to be an optional item?
>> If so, why not use [] as in ABNF, and cite ABNF.
>
> acp-10: Done. Please check again. Got a lot more complex by using ABNF, but
> maybe more precise.
Looks OK to me, except for some surviving {} in {+<extensions>}}
...
On the question of duplicate description of the "AN_join_registrar" objective:
> b), c) BRSKI only specifies zero touch bootstrap, but not certificate
> maintenance/renewal.
>
> ACP should be modular, eg: we should be able to combine it with any initial
> bootstrap
> (BRSKI of course preferred and only BRSKI+ANIMA+GRASP = ANI, but
> netconf-zero-touch or
> other would be possible option if so desired). So we need zero-touch
> certificate
> (renewal, revocation) specification in ACP doc>
> Cert renewal in ACP spec is using EST (RFC7030). Use of GRASP is specified in
> ACP draft
> is solely to support this EST renewal. Without GRASP to find EST-Server, we
> can not
> support EST-Server redundancy: YOu can specify a URL for reneal in the
> certificate,
> but if that URL goes down, you're lost. Without ACP/GRASP you would have had
> to setup some
> form of anycast domain-name or ip-address in the URL - or worse yet list
> multiple registrar.
>
> The GRASP objective in BRSKI is BRSKI-TLS and is discovered by bootstrap
> proxies, the
> GRASP objective in ACP is EST-TLS and is discovered by encrolled ACP members
> for their
> own Cert renewal. Big difference.
Understood, but we can't have two standards track documents claiming to define
the same objective. If it's *different* from the one in BRSKI it needs a
different name. If it's the *same* one and you are extending its semantics,
you have to say that, and BRSKI becomes a normative reference.
The latest BRSKI draft calls it "AN_registrar" but I assume it is intended to
be the same thing. Anyway I suggest that the ACP authors and the BRSKI authors
agree on what you want. I'm very happy to help with the GRASP details but only
when it's clear what you want.
> c) Initially i thought too that RSKI would be a superset of everything that
> we'd need
> for certificate maintenance, but thats not the goal of BRSKI. It is only
> meant o specify
> initial bootstrap, but not cert renewal or the like.
>
> a) I think to remember that MichaelR was pretty positive on the mike in
> Prague about
> the inclusion of EST in ACP spec for renewal. But i am sure he will chime in.
>
> The confusing bits may be how to use GRASP. Here is what current ACP and
> BRSKI text
> would lead to:
>
> - ACP registrar without BRSKI: registrar == EST-server
> registrar announces AN_join_registrar with only EST-TLS objective value
>
> - ACP registrar with BRSKI: registrar == EST-server + BRSKI spec
> registrar announces AN_join_registrar with both EST-TLS and EST-BRSKI
> objective values
I agree, it should work.
>
>>> The loop-count MUST be sete to 255. When an ACP node
>>> receives the M_FLOOD, it will have been reduced by the number of hops
>>> from the EST server.
>>
>> I don't like that. The role of the loop count is loop prevention,
>> so it should be set to a reasonable upper bound on the "radius"
>> of the network. GRASP has two measures for loop detection, this
>> one and detection of duplicate session IDs, but that was
>> intentional redundancy.]
>
> Sure, and if we set loop-count to a well-known value such as 255 then
> we do use it in the same way as IP uses TTL: Just as a way of last defense.
> Primary method is loop-free routing protocols (IP) or duplicate session ID
> (GRASP).
>
> [50% rant:]
> Every new technology seems to think that TTL is a great tool, only then to
> figure out later that its only a good protection of last resort. IP unicast
> did this, and today, nobody really uses any TTL other than 255 or 1.
> IP multicast regurgitated TTL values for "TTL scoping" and it took almost
> 10 years to get rid of it, we depreciated that, and since ~2000 IP multicast
> also only uses 255 or 1 since then. IMHO: Same learning curve is necessary
> for GRASP.
> Maybe we will come up with good use cases for 1 < TTL < 255 still, but i doubt
> it. Unless you have very specific variations of eg: ACP for networks with
> well-knon smaller max-TTL, i do not see it.
> [/rant]
>
> But you do not need to buy into this logic of mine. I just want to put you in
> the
> bind for an ability in GRASP to discover the closest instance of an objective.
> Thats i think something you agreed GRASP will support a long time ago.
>
> If you do not like to use the fixed TTL value of 255 as a mechanism to help
> support the "closest objective announcer" mechanism, then i need to specify
> a more complex way to discover the closest objective announcer:
>
> - objective-values for AN_join_registrar would need to be extended to be a
> structure like:
>
> objective-value = [ sender-ttl, method-list [, future-extensions]* ]
> method-list = [ method ]*1
> methd = BRSKI-TLS | EST-TLS | ...
> sender-ttl = NUM
>
> (pretty sure i didn't get the CBOR template not right, but i am sure you
> get the idea)
Not only do I get the idea, I tested it out many months ago; actually after the
discussions in Berlin, I think. In my Pythonic world it was very easy, but it is
indeed a bit more complicated than the 255-N method.
>
> That way, the recipient can compare sender-ttl with the TTL of the received
> objective
> and threeby figue out which one is closest.
>
> I fine either way. I just tried to go for the most simple, logical option.
Right, so the question for the WG (are you all listening?) is whether we
want to defend the value of the loop count in limiting propagation of multicast
messages. (Remember that it has another role in negotiation sessions, where
it really is a loop-prevention counter.)
I will note that in testing on looped topologies I have seen looped multicasts
dropped because of the session ID; theoretically that is sufficient, and the
loop count is logically redundant.
Otherwise, me happy.
Thanks again for all the work,
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
