Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-12.txt

From: [email-masked]
Date: Mon, 05 Mar 2018 14:44:23 -0800

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 WG of the IETF.

        Title           : Bootstrapping Remote Secure Key Infrastructures (BRSKI)
        Authors         : Max Pritikin
                          Michael C. Richardson
                          Michael H. Behringer
                          Steinthor Bjarnason
                          Kent Watsen
	Filename        : draft-ietf-anima-bootstrapping-keyinfra-12.txt
	Pages           : 87
	Date            : 2018-03-05

Abstract:
   This document specifies automated bootstrapping of a remote secure
   key infrastructure (BRSKI) using manufacturer installed X.509
   certificate, in combination with a manufacturer's authorizing
   service, both online and offline.  Bootstrapping a new device can
   occur using a routable address and a cloud service, or using only
   link-local connectivity, or on limited/disconnected networks.
   Support for lower security models, including devices with minimal
   identity, is described for legacy reasons but not encouraged.
   Bootstrapping is complete when the cryptographic identity of the new
   key infrastructure is successfully deployed to the device but the
   established secure connection can be used to deploy a locally issued
   certificate to the device as well.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-12
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-12

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/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Mar 2018 18:01:58 -0500

> A New Internet-Draft is available from the on-line Internet-Drafts

...

    > https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-12

So in case you aren't following the other thread, this version -12 represents
about 70% of Toerless' Shepherd comments (a total of 1900 lines).

Expect a -13 to be submitted when draft submissions open with the rest of the
changes and the additional comments that are in the queue.

Please note that there are multiple questions and issues being raised.
There are things that I did not accept as friendly amendments, and things
where I did not know if I agreed or not and asked QUESTION:

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Mar 2018 16:44:52 +1300

Hi,

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.
The other differences are unimportant (my network has global IPv6 addresses
instead of ULAs, I set the 'discoverable' flag bit, and I used a different timeout).

(2) Flood sent by the proxy as received by the pledge, also Python output.

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

2. 'TCP' shouldn't be a string, it should be IPPROTO_TCP as above.

3. The objective is defined as having a null value. Why isn't it
"EST-TLS" again?

** Code at https://github.com/becarpenter/graspy (Reggie.py, Procksy.py, Pledji.py)

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Mar 2018 06:56:33 +0000

> I'd prefer to see TCP represented as IPPROTO_TCP to align with the

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.

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

    > 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

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2018 08:35:58 +1300

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

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

> 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