Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-09-29 Thread Michael Richardson 

Toerless Eckert  wrote:
> On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
brian> Toerless explained elsewhere why he thinks the duplication is
brian> needed.
>>
>> I read that after my email.
>> I simply can't agree.

> I don't think i was suggesting duplication. I was suggesting for
> one document to define an extensibel objective and the other draft to
> extend it.

Objectives are so easy to define and require so little IANA coordination that
I don't see why we would want to extend it without also updating the BRSKI
document.

So to be clear: this is overly general, and I am opposed to this.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-09-25 Thread Toerless Eckert 
On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
> brian> Toerless explained elsewhere why he thinks the duplication is
> brian> needed.
> 
> I read that after my email.
> I simply can't agree.

I don't think i was suggesting duplication. I was suggesting for
one document to define an extensibel objective and the other draft to
extend it. 

The extensibel notation i was suggesting would also result in the
definition of a brski-enrol service name that would be useable outside
of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.

> >> == section 11
> >> This document may be considered to be updating the IPv6 addressing
> >> architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
> >> addresses ([RFC4193]) depending on how strict specific statements in
> >>
> >> I don't like this statement.  Either it violates the spec, and updates 
> it, or
> >> it does not.  I do not think that it violates.  This is not a 
> multi-link
> >> subnet, this is a prefix that is not on-link.
> 
> brian> As readers of the 6man list know, this has been a very contentious 
> topic.
> brian> I think it's safer to duck it in the ACP draft: say what we do, 
> but say
> brian> nothing about RFC4291 etc.
> 
> I agree.

I can easily remove the whole section 11 from the ACP document and we can bring 
it
back if/when 6man review is asking for it, no problem.

> >> It is possible, that this scheme constitutes an update to RFC4191
> >> because the same 64 bit subnet prefix is used across many ACP
> >> devices.  The ACP Zone addressing Sub-Scheme is very similar to the
> >> common operational practices of assigning /128 loopback addresses to
> >> network devices from the same /48 or /64 subnet prefix.
> >>
> >> It does not. Brian? Do you concur?
> 
> > Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't 
> assign
> > them using SLAAC. It doesn't use conventionally sized /64 subnets. So 
> in that
> > sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router 
> Links").
> > But we don't need to apologise. As you say, we're simply assigning /128
> > addresses to (virtual) interfaces using our own scheme. And we're 
> relying
> > on BCP 198 (RFC 7608) which says that routing prefixes can be any length
> > up to /128. If you want to cite anything, cite RFC 7608.
> 
> Toerless, do you want text to say this?

Always happy to get text suggested, but please also with a fitting place,
especially if you do not like section 11. And then do not blame me if we
again get more and more explanatory text into standards sections ;-P (which i do
like, but which normal IETF reviewer usually bitch about).

> draft> The goal for the 8 or 16-bit addresses available to an ACP device 
> in
> draft> this scheme is to assign them as required to software components,
> draft> which in autonomic networking are called ASA (Autonomic Service
> 
> mcr> We are not providing 8-bit or 16-bit IIDs.
> mcr> We are providing 256 or 65536 /128 addresses which are conveniently
> mcr> aggregated for routing purposes.

Hmm... I guess you are implying but also prefer not to explicitly say:
-> If an implementation wants to pick any shorter than /127 prefix from thiss
block of addresses to assign to a subnet, then it's up to that implementation
to argue how such an implementation will fit the IPv6 architecture. The 
ACP document does no require or prescribe any such approaches.

> draft> In practical terms, the ACP should be enabled to create from its /8
> draft> or /16 prefix one or more device internal virtual subnets and to
> draft> start software components connected to those virtual subnets.
> 
> mcr> No, don't say this, and don't do this in practice.  Create /128 
> routes to LL
> mcr> address of the internal VM and configure the /128 as a loopback 
> address
> mcr> inside the VM.
> 
> brian> So yes, I concur with Michael.

Ok, let me see how to best deal with this all.

> 
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-09-25 Thread Michael Richardson 

Brian E Carpenter  wrote:
> I get a bit confused by the way your mail agent doesn't distinguish
> new and old text, but in line...

Well, there isn't any old text in it, rather there are quotes from the document!

brian> Toerless explained elsewhere why he thinks the duplication is
brian> needed.

I read that after my email.
I simply can't agree.

>> == section 11
>> This document may be considered to be updating the IPv6 addressing
>> architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
>> addresses ([RFC4193]) depending on how strict specific statements in
>>
>> I don't like this statement.  Either it violates the spec, and updates 
it, or
>> it does not.  I do not think that it violates.  This is not a multi-link
>> subnet, this is a prefix that is not on-link.

brian> As readers of the 6man list know, this has been a very contentious 
topic.
brian> I think it's safer to duck it in the ACP draft: say what we do, but 
say
brian> nothing about RFC4291 etc.

I agree.

>> It is possible, that this scheme constitutes an update to RFC4191
>> because the same 64 bit subnet prefix is used across many ACP
>> devices.  The ACP Zone addressing Sub-Scheme is very similar to the
>> common operational practices of assigning /128 loopback addresses to
>> network devices from the same /48 or /64 subnet prefix.
>>
>> It does not. Brian? Do you concur?

> Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't 
assign
> them using SLAAC. It doesn't use conventionally sized /64 subnets. So in 
that
> sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router 
Links").
> But we don't need to apologise. As you say, we're simply assigning /128
> addresses to (virtual) interfaces using our own scheme. And we're relying
> on BCP 198 (RFC 7608) which says that routing prefixes can be any length
> up to /128. If you want to cite anything, cite RFC 7608.

Toerless, do you want text to say this?

draft> The goal for the 8 or 16-bit addresses available to an ACP device in
draft> this scheme is to assign them as required to software components,
draft> which in autonomic networking are called ASA (Autonomic Service

mcr> We are not providing 8-bit or 16-bit IIDs.
mcr> We are providing 256 or 65536 /128 addresses which are conveniently
mcr> aggregated for routing purposes.

draft> In practical terms, the ACP should be enabled to create from its /8
draft> or /16 prefix one or more device internal virtual subnets and to
draft> start software components connected to those virtual subnets.

mcr> No, don't say this, and don't do this in practice.  Create /128 routes 
to LL
mcr> address of the internal VM and configure the /128 as a loopback address
mcr> inside the VM.

brian> So yes, I concur with Michael.



--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-09-23 Thread Brian E Carpenter 
Michael,

I get a bit confused by the way your mail agent doesn't distinguish
new and old text, but in line...

On 24/09/2017 08:35, Michael Richardson wrote:
> 
> Toerless, thank you for this version.  We are very very close!
> Brian, Max, I invoke your name in my comments... please read and +1,
> or disagree with me.
> 
> I noticed in this version has two places with no space after the .:
> 
>  across the network.[RFC7575] defines the fundamental ideas and design
>and it should be re-usable by all autonomic functions.[RFC7575]
>calls
> 
> 
> Can we avoid semantic/normative statments like "ACP routing table may include
> multiple" in a terminology section?
> 
> Change:
> ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
> normal/simple case, the ACP has one ULA prefix, see Section 6.10.
> The ACP routing table may include multiple ULA prefixes if the
> "rsub" option is used to create addresses from more than one ULA
> prefix.  See Section 6.1.1.  The ACP may also include non-ULA
> prefixes if those are configured on ACP connect interfaces.  See
> Section 8.1.1.
> 
> to:
>   ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
> normative case, the ACP has one ULA prefix as specified in
>   Section 6.10.  The cases where multiple prefixes are present
>   are explained in Section 6.1.1, and use of non-ULA prefixes
>   are explained in Section 8.1.1.
> 
> There are some good updates to the ACP domain.  I want to bring up this issue
> From BRSKI here:
>https://github.com/anima-wg/anima-bootstrap/issues/20
> 
> I was suggesting that the information for the Pledge's CSR should be broken
> up such that the pledge will create the right CN from the pieces, which it
> needs to know anyway. I had suggested:
> 
>"ACPinfo" : { "acp-prefix" : "fda379A6f6ee02006401",
> "acp-prefix-length": 96,
> "acp-plus-part": "area51.research",
> "acp-domain": "acp.example.com"
>}
> 
> I don't like your text:
>If the operator does not own any FQDN, it should
>  choose am FQDN format string that intends to be equally unique.
> 
> I suggest that:
>   If they don't own any FQDN, then, aside from WTF?, that they form a
>   unique name as: $(uuidgen).example.com.
>   Or, perhaps that they use ${ULA}.example.com.
> 
> the only real-life situation where this is going to happen is in a test lab
> run by co-op students, and in that case, the software might as well have a
> pre-configured default.
> 
> ==
> 
> Brian, Max and I asked you to remove the EST requirements on announcements
> From the ACP document.

Toerless explained elsewhere why he thinks the duplication is needed.
 
> ==
>ACP secure channel MUST imediately be terminated when the lifetime of
>  any certificate in the chain used to authenticate the neighbor
>  expires or becomes revoked.  Note that is is not standard behavior in
>  secure channel protocols such as IPsec because the certificate
>  authentication only influences the setup of the secure channel in
>  these protocols.
> 
> This is rather impractical to implement in real life, that's why IPsec
> doesn't do that.  I strongly suggest you sit down with some Cisco, Juniper
> (Netscreen) and Checkpoint IPsec product managers, and ask them what they
> actually do, and why.
> 
> Assuming you really want to have this kind of behaviour, then the correct way
> to do this is to make statements about the rekey intervals on the channels.
> 
>ACP secure channels created with the use of certificates will include some
>lifetimes for the certificates. The set of lifetimes includes:
>  1) the expiry date of the certificate
>  2) the lifetime of the OCSP response
>  3) the validity time of the CRL response
> 
>The earliest date provided by these provides a time at which the
>keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed.
> 
> 
> 6.10.4.  ACP Manual Addressing Sub-Scheme
> 
>The sub-scheme defined here is defined by the Type value 1 (one) in
> 
> was changed to:
>The sub-scheme defined here is defined by the Type value 00b (zero)
> 
> I think that this is a typo, and should be 01b ?
> Or does the Manual mechanism somehow fit into the
>ACP Zone Addressing Sub-Scheme because the Z bit is different?
> 
> Do you explain this manual zone better somewhere?
> 
> 
> Can you show the two Types with their bits set at the end of the base scheme?
> 
> 64 64
> +-+-+---++-+
> |(base scheme)  01|Subnet-ID| Z || Interface Identifier|
>

Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-09-23 Thread Michael Richardson 

Toerless, thank you for this version.  We are very very close!
Brian, Max, I invoke your name in my comments... please read and +1,
or disagree with me.

I noticed in this version has two places with no space after the .:

   across the network.[RFC7575] defines the fundamental ideas and design
   and it should be re-usable by all autonomic functions.[RFC7575]
   calls


Can we avoid semantic/normative statments like "ACP routing table may include
multiple" in a terminology section?

Change:
ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
  normal/simple case, the ACP has one ULA prefix, see Section 6.10.
  The ACP routing table may include multiple ULA prefixes if the
  "rsub" option is used to create addresses from more than one ULA
  prefix.  See Section 6.1.1.  The ACP may also include non-ULA
  prefixes if those are configured on ACP connect interfaces.  See
  Section 8.1.1.

to:
  ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
  normative case, the ACP has one ULA prefix as specified in
  Section 6.10.  The cases where multiple prefixes are present
  are explained in Section 6.1.1, and use of non-ULA prefixes
  are explained in Section 8.1.1.

There are some good updates to the ACP domain.  I want to bring up this issue
From BRSKI here:
   https://github.com/anima-wg/anima-bootstrap/issues/20

I was suggesting that the information for the Pledge's CSR should be broken
up such that the pledge will create the right CN from the pieces, which it
needs to know anyway. I had suggested:

   "ACPinfo" : { "acp-prefix" : "fda379A6f6ee02006401",
"acp-prefix-length": 96,
"acp-plus-part": "area51.research",
"acp-domain": "acp.example.com"
   }

I don't like your text:
   If the operator does not own any FQDN, it should
   choose am FQDN format string that intends to be equally unique.

I suggest that:
  If they don't own any FQDN, then, aside from WTF?, that they form a
  unique name as: $(uuidgen).example.com.
  Or, perhaps that they use ${ULA}.example.com.

the only real-life situation where this is going to happen is in a test lab
run by co-op students, and in that case, the software might as well have a
pre-configured default.

==

Brian, Max and I asked you to remove the EST requirements on announcements
From the ACP document.


==
   ACP secure channel MUST imediately be terminated when the lifetime of
   any certificate in the chain used to authenticate the neighbor
   expires or becomes revoked.  Note that is is not standard behavior in
   secure channel protocols such as IPsec because the certificate
   authentication only influences the setup of the secure channel in
   these protocols.

This is rather impractical to implement in real life, that's why IPsec
doesn't do that.  I strongly suggest you sit down with some Cisco, Juniper
(Netscreen) and Checkpoint IPsec product managers, and ask them what they
actually do, and why.

Assuming you really want to have this kind of behaviour, then the correct way
to do this is to make statements about the rekey intervals on the channels.

   ACP secure channels created with the use of certificates will include some
   lifetimes for the certificates. The set of lifetimes includes:
 1) the expiry date of the certificate
 2) the lifetime of the OCSP response
 3) the validity time of the CRL response

   The earliest date provided by these provides a time at which the
   keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed.


6.10.4.  ACP Manual Addressing Sub-Scheme

   The sub-scheme defined here is defined by the Type value 1 (one) in

was changed to:
   The sub-scheme defined here is defined by the Type value 00b (zero)

I think that this is a typo, and should be 01b ?
Or does the Manual mechanism somehow fit into the
   ACP Zone Addressing Sub-Scheme because the Z bit is different?

Do you explain this manual zone better somewhere?


Can you show the two Types with their bits set at the end of the base scheme?

64 64
+-+-+---++-+
|(base scheme)  01|Subnet-ID| Z || Interface Identifier|
+-+-+---++-+
<---48->TT13  1


section 8.8.1, starting at:
The ACP connect interface must be (auto-)configured with an IPv6

seems to be missing articles and/or words, and needs an english editing pass.

== section 11
   This document may be considered to be updating the IPv6 addressing
   architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast

Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-09-18 Thread Toerless Eckert 
On Wed, Aug 02, 2017 at 02:39:03PM +1200, Brian E Carpenter wrote:
> Hi,
> 
> Here are my comments on ACP version -08. First the ones I rank
> as substantive isssues, then a few nits.

Thanks so much Brian, lots of help to improve quality.

Alas, i got derailed from finishing the fixes for your review because the
reviews/last-call for stable connectivity which had me figure out a bunch of
changes to ACP document, and i first put all of those in acp-09 (and then i
had a bunch of business travel, so i thin i hadn't even sent out a note
about -09 to the list).

Changes -08 - 09:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-08.txt=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt

Might be useful to check that diff out separately, key big blocks:

- Made the V8 scheme more flexible (allow 16 bit addresses, eg: for the
  the stateless BRSKI proxy mechanisms you and MichaelR where discussing.
- All RPL profile detail fixups from MichaelR's review
- Expanded ACP connect section (taken over from stable-connectivity).
- introduced manual addressing sub-scheme for more consistent autonomic-connect
  (also as outcome of stable-connectivity review)
- Doc now claims to update RFC4291/RFC4193, section to summarize
  those updates - aka: that section is meant for later review by 6ops or 6man.

Details of changes of course in changelog of the draft.

The changes from your review below then got into acp -10 that i just posted:

Changes -09 - 10:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-10.txt

See below. Hopefully all answers to your points are satisfactory.

Cheers
   Toerless

> Issues:
> ---
> 
> > 2.  Terminology
> ...
> > ULA  "Unique Local Address".  The IPv6 equivalent to RFC1918 IPv4
> > addresses.  ACP addresses are ULA.
> 
> No, they are *not* equivalent to RFC1918, because those are ambiguous
> and ULAs are not. Please avoid controversy, just cite RFC4193.


IMHO, a terminology section has to try to explain terms without making the 
reader refer to ever mor ereferences.  Had a lot of customers who didn't know 
what ULA are, but who klicked when
i mentioned 1918. And differences/benefits over 1918 become obvious later in 
doc anyhow (ambiguity).

acp-10 text:

   A "Unique Local Address" (ULA) is an IPv6 address in the block fc00::/7, 
defined in 
   . It is the approximate IPv6 counterpart of the IPv4 
private address 
   ().

If you do not like that, please fix in Wikipedia wherer i stole this from:
https://en.wikipedia.org/wiki/Unique_local_address
;-)

> > 3.2.  Secure Bootstrap over an Unconfigured Network
> ...
> > ...This does not require any configuration
> > on intermediate nodes, because they can communicate through the ACP.
> 
> s/they can communicate/they can communicate securely/

ACK

> > 4.  Requirements
> ...
> > ACP4:  The ACP MUST be generic.  Usable by all the functions and
> >protocols of the AN infrastructure.  It MUST NOT be tied to a
> >particular protocol.
> 
> I'm not sure what the last sentence is saying. Do you mean
> "MUST NOT be tied to a particular transport protocol" or
> "MUST NOT be tied to a particular security protocol"?
> Or do you mean "MUST NOT restrict the choice of upper layer
> protocol"? Or do you simply mean "MUST provide a generic
> IPv6 service"?

This goes back to very early discussions in ANIMA when we argued that
a greenfield autonomic networking design would not need any protocol other
than GRASP for any ASA to ASA communications. In which case there would
not have been a good argument for ACPs concept of a virtual IPv6 network
to transport any management traffic. 

acp-10: "NOT be tied to a particular application or transport protocol.".

Please suggest better text if thats not sufficient.

> Also, there's no requirement about performance or the
> expected traffic density. Should we say something either
> in the Requirements section or in the Notes in the
> Overview section? I assume that performance is not critical
> and ACP traffic density is expected to be low.

My practical experience was that proliferation of implementation was
easier when you did not have performance requirements but when you could
implement also in just software forwarding path. This did then lead
to text in stable connectivity arguing about using the ACP primarily
for critical operations. 

acp-10 has a new performance section restate that position:


There are no performance requirements against ACP implementations defined in 
this document because the performance requirements depend on the intended use 
case. It is expected that full autonomic devices with a wide range of ASA can 
require high forwarding plane performance in the ACP, for example for 
telemetry, but that determination

[Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

2017-07-18 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach of the IETF.

Title   : An Autonomic Control Plane (ACP)
Authors : Michael H. Behringer
  Toerless Eckert
  Steinthor Bjarnason
Filename: draft-ietf-anima-autonomic-control-plane-08.txt
Pages   : 64
Date: 2017-07-18

Abstract:
   Autonomic functions need a control plane to communicate, which
   depends on some addressing and routing.  This Autonomic Control Plane
   should ideally be self-managing, and as independent as possible of
   configuration.  This document defines an "Autonomic Control Plane",
   with the primary use as a control plane for autonomic functions.  It
   also serves as a "virtual out of band channel" for OAM communications
   over a network that is not configured, or mis-configured.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-08
https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima