Subject: Re: [RTG-DIR] [Anima] Rtgdir telechat review of? draft-ietf-anima-autonomic-control-plane-13

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Jun 2018 22:37:00 +0200

On Mon, May 14, 2018 at 11:15:58PM -0400, Joel M. Halpern wrote:
> (Sorry about the excess caps.  Did not intentd to shout.)
> 
> From some off-line disucssions, I understand that the actual address
> allocation is tied to the registration process.  The registration process is
> not described in this document.
> 
> As far as I can tell, the ACP does not depend upon the address allocation
> strategy.  The address allocation strategy does require the ACP.  And it
> requires and is closely coupled to the registration process.
> 
> If that is true, the address allocation seems to be better described with
> the registration process.  Which I presume is in the BRSKI document.
> 
> All I would put in here is the basic ULA allocation (hash based generation)
> mechanism.

Hi Joel (round 3)

Here is the github version after the fixes discussed below

https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt

Here is the diff vs. the prior version (round 2)

http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt

Alas (but i think for the better), after
all the questions from and discussion with you, i tried to figure out how
to best document the answers to the questions you raised, and it started
answering why we need multiple address range - because have to waste
48/46 bits on Registrar-IDs. Ok, Why ? Because we want multiple uncoordinated
registrars. Ok, what is a registrar. Especially when ACP does not use
BRSKI, which it claims it can. And how does certificate maintenance work
when you have multiple registrars. Aka: once i started to write text to
asnwer your questions i kinda got sucked into having the spec also answer
other questions.

So, with this rev., we now define and use the term "ACP Registrar",
and define that thats a BRSKI Registrar in ANI nodes, but it can be
anything in non-ANI ACP nodes. Does not have to be software. It could
be you, if you want the job.  Maybe Netconf or other protocols that 
want to compete with BRSKI.

Actually, verified i can be a registrar a long time ago, using old
crypto PKI CLI on ACP capable routers to manually hack in certificates
with specific properties i wanted. And getting them via web interface from
a CA.

So, i think this is a very clean solution of documentation. The normative
part of the spec now has what i think was the minimum to define the
requirements for any ACP registrar including the most simple address
allocation example.

So, then there is an informative section explaining the need for the
multiple address spaces because of those uncoordinated registrars.
And an informative section about how you would need to set up
such uncoordinated registrars, aka: each with their own sub-CA. All
in section 10.3 now.

Then of course the whole point you made about about ACP addresses
being identifiers or not. So i wanted to document the point  that they
are, but that also meant to explain how the ACP address information
will survive in the presence of renewal and re-enrollment with a different registrar
(which may not know the nodes assigned ACP address unless its presented
during re-enrollment/renewal). Then of course the case where a cert
is revoked maybe indirectly, because the registrar was attacked, not
the ACP node gets a new cert from another registrar but of course this is
is the only case where you want it to get a certificate with new ACP
address information (because the prior registrar became untrusted so
you don't trust what ACP information it assigned).

So, this ended up being two new normative subsections in 6.1.3 -
re-enrollment and failing certificates, describing the requirements against ACP nodes
during renewal or failure of their cert.

The informative part of the doc also got a section about registrars documenting
hopefully the key pieces: how it works in general (so folks get
an idea how they would be built with or without BRSKI), what parameters
they need, discussion about that multi-registrar renewal and sub-CA
case, and finally a discussion about how registrars could integrate
with centralized policy control. After all, the world is SDN, so if
we'd only document the cool distributed registrar case, this wouldn't sell well
in todays world *sigh*.

The reasoning for this new text sections is all summarized/documented in the changelog for -14.

I'd like to point out  that even though this is a bunch of additional text,
it is in no way changing the way the ACP or registrars are meant to
operate. It is really just adding missing documentation about it.

Hope this answers your questions and resolves your discuss.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Jun 2018 23:51:45 +0200

Ooopss.. diff was not pointing to absolute label for second URL, here is working one:

http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/57825aac69216fd01d388810ee804c7f25e8ab7d/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt

-- 
---
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jun 2018 17:09:37 -0400

Thank you for all your work on this.

While I still find the presence of the address allocation mechanism 
strange to find in this document, I can live with it.  So with this 
complaint done, I will shut up about it already.

Aside from some items noted below, this seems to be in good shape.

Moderate:

     Section 10.3.4 has a helpful discussion of some of the complexities 
of determining where to auto-enable the ACP.  I am a bit surprised not 
to see some discussion of which VLANs to enable for ACP in an Ethernet 
environment.  For WDM< since wavelength usage is configured, I presume 
that ACP would never try to auto-enable a frequency band?

Minor comments:
    In section 6.1.1 the text and the ABNF says that an rsub is a full 
domain (using the same domain-name construct as the "domain" which is an 
FQDN.  However, the example shows a partial domain string which is 
concatenated with the "domain" to produce an FQDN.  And the syntqx of 
"routing-subdomain" shows that concatenation.  This suggests that the 
text needs to be clear as to what the syntactic content of the rsub 
field is.  Might it be better not to define it as a "domain-name" but to 
define it as FFS, with a caveat that whatever usage is later defined 
needs to be suitable for combining with the "domain" for generating the 
hash for the ULA Global ID?  (Just to be clear, as written the text 
seems to end up with <domain<.<domain> where <domain> is from RFC 1034.

     Section 6.1.2 bullet one states that "The peer certificate is valid 
as proven by the security association protocol exchange."  I may be 
overstepping my knowledge, but I think there are two different things. 
First is the certificate validity, which is an internal property of the 
certificate.  The second is the certficate applicability which may be 
informed by the protocol exchange.
     Related to that, please put in a reference to which protocol 
exchange you mean?

     Either there is a document inconsistency, or there is a typo in the 
first paragraph of section 6.10.7.3, in that the address prefix length 
for the zone address sub-scheme is /127, not /126.

Yours,
Joel

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 9 Jun 2018 01:04:16 +0200

Thanks, Joel

Replies Inline

Changes for feedback from Mirja, Kumar and Joel committed to -16,
didn't create separate diff for individual reviewers as diff is not large. 
(Just ignore whole section 11 moved to appendix in diff.)

https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt

Cheers
    Toerless

On Thu, Jun 07, 2018 at 05:09:37PM -0400, Joel M. Halpern wrote:
> While I still find the presence of the address allocation mechanism strange
> to find in this document, I can live with it.
> So with this complaint done, I will shut up about it already.

Thanks. Lets take it offline. I am still interested to understand that
point, especially after the text i added in the hope to clear this concern.

Answers inline.

Thanks
    Toerless

>     Section 10.3.4 has a helpful discussion of some of the complexities of
> determining where to auto-enable the ACP.  I am a bit surprised not to see
> some discussion of which VLANs to enable for ACP in an Ethernet environment.

Thats a topic better to be discussed in followup work. Cisco IOS ACP
implementation does support automatic VLAN discovery & selection.
Lot of experience/insight from that.  Trust me, it would be scope creep
for the ACP document itself.

> For WDM< since wavelength usage is configured, I presume that ACP would
> never try to auto-enable a frequency band?

Right. Given the experience with VLANs, the clean cut we could make
for this basic ACP specification is to logically sit on top of
IPv6 subnet interfaces, ignore all L2/L1 complexities 
and live with the dependency against IPv6 being able to bring up
link-local-scope reachability to neighbors. [ And then write followup
docs if/when we ever get this first doc out as an RFC ;-) ]

The way i would imagine WDM is a bit more like ethernet switches in section 7
though: You'd want to get ACP connectivity across your optical equipment
and also be able to reach through the ACP your optical equipment, but
that would not use special colors, but more likely should be added
to / leverage the existing in-band management channels of the optical
equipment. Long discussion. Let me rather stop.

> Minor comments:
>    In section 6.1.1 the text and the ABNF says that an rsub is a full domain
> (using the same domain-name construct as the "domain" which is an FQDN.
> However, the example shows a partial domain string which is concatenated
> with the "domain" to produce an FQDN.  And the syntqx of "routing-subdomain"
> shows that concatenation.  This suggests that the text needs to be clear as
> to what the syntactic content of the rsub field is.

Hmm... RFC1034 does not even mention the term "fully qualified (domain name)" / FQDN,
You seem to read RFC1034 3.5 to mean that all domain are FQDN, but that is
not clear to me. In the RR examples of RFC1034, FQDNs are identified by ending
with a ".", which AFAIK is the standard for FQDN,but the 3.5 syntax doesn't
even allow you to create such an FQDN, so i was thinking that 3.5 "domain"
do not have to be FQDNs, and therefore i am assuming that is is also perfectly
legal to use a syntax of domain3 = domain2 . domain1,
as in routing-subdomain = rsub . domain-domain-name.

> Might it be better not
> to define it as a "domain-name" but to define it as FFS, with a caveat that
> whatever usage is later defined needs to be suitable for combining with the
> "domain" for generating the hash for the ULA Global ID? 

Well, it does have to be some RFC822-local-part-FFS, but i think its a
lot better if its constrained to the domain name syntax, because it is
quite normal operations to have for every actual routing subdomain in the
network also some associated domain name, and that is what "routing-subdomain"
is.

So if i build a parser for configuring my segmented routing with the ACP,
its a lot more logical to allow only longer domain names for
routing-subdomain that all have the same parent domain (domain).

> Just to be clear, as written the text seems to end up with <domain<.<domain>
> where <domain> is from RFC 1034.

Right. See above.

I tried to figure out how to unconfuse this.

I changed "domain" to "acp-domain-name", so that its not confused
with RFC1034 "domain", eliminated "domain-name", and also changed
the definition of rsub to use RFC1034 "subdomain" instead of "domain",
even though i can for the heck of it not figure out what the difference
between domain and subdomain is, except that a domain can be " ", 
which seems to be the domain root, but its not really defined. 
But at least it should hopefully eliminate the misconception that rsub
has to be an FQDN.

>     Section 6.1.2 bullet one states that "The peer certificate is valid as
> proven by the security association protocol exchange."  I may be
> overstepping my knowledge, but I think there are two different things. First
> is the certificate validity, which is an internal property of the

Good catch. Fixed as follows:

The following points constitute the ACP domain membership check of a possible peer certificate, independent of the protocol used:
 The peer certificate is valid (lifetime).
 The peer has proved ownership of the private key associated with the certifictes public key.

>     Related to that, please put in a reference to which protocol exchange
> you mean?

No, the goal is to define this independent of protocol.

> first paragraph of section 6.10.7.3, in that the address prefix length for
> the zone address sub-scheme is /127, not /126.
> 
> 
> Yours,
> Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 Jun 2018 19:47:18 -0400

Thank you.  Those fixes make sense.  You might want to talk to a DNS 
expert about what the right terminology is for what youa re trying to 
achieve with the rsub content.  I think I understand it, and I think it 
is reasonable.  And I am insufficiently expert to tell what the right 
formalism is for it (thinks have evolved since 1034.)

Net: good enough for me.

Yours,
Joel