Re: [Anima-bootstrap] a repost of summary

["Michael Behringer (mbehring)" <[e-mail]>]

Michael, team, 

I wasn't involved in the charter definition, so I have a few questions, referring mostly to the design team charter at https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap%20Design%20Team%20Charter: 

- Probably a nit: I'm missing the words "trust infrastructure". To me, we're setting up a trust infrastructure, and we also need to discuss the setup of the registrar, CA, not only the bootstrapping elements. The word "trust" is completely missing - is there are reason for it? 

- Goal 1: Is this the certificate format and fields? 

- Goal 2: I think security needs to also be discussed in the reference model, we need to see how we can split that? Or do you see that the bootstrap doc would cover that all? 

- I think there is overlap with the netconf zero-touch work, and we should probably be explicit: Do we want to find common groud (would hope so), or is it too late? Since that has been discussed, we should be explicit about this point I think. Which other groups do you have in mind when talking about "adjacent IETF WGs"? Can we list them? 

- somewhere the charter should state more explicitly: Define protocols and data models for the bootstrap process. I guess that's goal 3, but it sounds cryptic. To me, we need 1) requirements, 2) a protocol, 3) a data model, including certificate format and fields. 

- in the reference model I'm referring to the bootstrap process in a new way, in the ASA thinking. There is an ASA for a new element, one for the proxy, and one for the registrar. (Previously those functions were included in the infrastructure, but logically they should be ASAs). Do you agree with this thinking, and if so, should we adopt this wording here as well? 

- Do we want to include downloading a config? (I read "optimized configuration distribution) - somehow that doesn't seem to be in scope, in my reading. Can we exclude that? To me, the process ends when the device has a domain cert. 

- The milestone is very cryptic. Are we planning a new spin of draft-pritikin before the IETF? Or is this a completely new draft? you say "draft(s)" - what does that mean? 

Michael



> -----Original Message-----
> From: Anima-bootstrap [mailto:[e-mail]] On
> Behalf Of Michael Richardson
> Sent: 24 June 2015 16:06
> To: [e-mail]
> Subject: [Anima-bootstrap] a repost of summary
> 
> 
> [this is a repost to put something in this list]
> 
> The bootstrap design team is still bootstrapping, but Max, Toerless and I
> have had three 1hr phone conferences (May 29 meeting cancelled). They
> have been Friday at 1700UTC, but are now Thursday at 1400UTC, and will
> occur June 11 as well.  A doodle poll to confirm a regular time will go out
> next week once the list of parties has been identified.
> I think that the AD still has to approve things.
> 
> We started with a discussion of the charter for the DT, and how it relates to
> the charter for the WG, and the result is at:
>     https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap
> 
> the places where it says "OWN" means, it's in scope for this DT, where it
> says REQUIRE, means that we are assuming it as input, and where it says
> PROVIDE, means that they are outputs.
> 
> We continued with a recap discussion and partial walkthrough of
>     draft-pritikin-anima-bootstrapping-keyinfra-01
> 
> We have some ideas about terminology that we think might be useful along
> the lines of ducking/imprinting (cf: Konrad Lorenz and
> http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also
> thought of fraternities and pledges.  If you didn't grow up with
> http://en.wikipedia.org/wiki/Animal_House, or
> http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide
> some explanation.  The idea that during the bootstrap process, there is a
> period when the network (the ACP aka fraternity) and the new node (the
> peldge) check each other out for fitness.  Wikipedia says this about
> fraternities:
>    Requirements may be imposed on those wishing to pledge either by the
>    school or the organization itself, often including a minimum grade point
>    average, wearing a pledge pin, learning about the history and structure of
>    the organization, and performing public service. When a school places an
> age
>    or tenure requirement on joining, this is called "deferred recruitment", as
>    joining is deferred for a semester or year. The pledgeship period also
> serves
>    as a probationary period in which both the organization and the pledge
> decide
>    if they are compatible and will have a fulfilling experience.
> 
> In today's telecon, we discussed some of the 6tisch specific requirements
> on bootstrap, specifically:
>   1) the "pledges" (or joining nodes) are constrained in CPU, code space, and
>      energy (if battery powered, etc)
>   2) more importantly, the network is very constrained, 250Kbit/s max, 127
>      byte fraglets, and 6tisch likely would be configured to further
>      restricts the bandwidth in the network available to joining nodes.
>      Calculations suggest that just transmitting a DH pair and associated
>      parts between adjacent nodes could take between 2 and 40s.
>   3) most protocols will require an authorization protocol that will need to
>      travel through the LLN mesh up to a non-constrained node. The
>      convergence of many such setup processes may well overwhelm the
> parts of
>      the network closer to the root of the tree.  Congestion is an issue,
>      and retransmissions cost energy.
> 
> I explained some the ideas/conclusions from
>   draft-richardson-6tisch-security-architecture-02
> and draft-richardson-6tisch--security-6top-04, which were:
>   a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top")
> plans
>      for 6tisch node/PCE communication, maximizing code reuse.
> 
>   b) initiating the secure bootstrap process from the non-constrained side,
>      and having the constrained nodes remain silent after an initial "hello"
>      packet, allowed the network manager to protect, conserve and prioritize
>      the join bandwidth.
> 
>   c) it turns out there is an additional benefit in making the constrained
>      node the TLS "Server" -- side. Specifically, it means that the selection
>      of crypto parameters is done by the more constrained device, and the
>      Server sends it's certificate payload first.  The non-constrained node
>      (or "JCE" == Join Coordination Entity) will receive that certificate,
>      and can consult whatever network (or human) resources is needs to
>      before responding with a Client Certificate that will satisfy the
>      constrained node.  It can also know via Trusted CA extension what
>      certificate chain (if any) it needs to provide.
> 
> It is observed that point (c) is not essential; that a similiar thing can be
> accomplished with less grace using SNI (RFC6066) and some other
> extensions.
> 
> Note that while 6tisch is/plans-to specify that 6top is the protocol that runs
> over the resulting CoAP/DTLS channel, and that secure join to 6tisch consists
> of provisioning certain identities and parameters through that channel,  the
> resulting channel could be used for anything.
> 
> We also noted that in the context of two routers plugged in together on a
> lonesome grassy knoll would need to form a secure connection; that one
> needs to be the initiator ("client") and the other the responder ("server") is
> obvious, but whether both systems need to always support both roles is
> open for discussion.  Perhaps in the constrained case, it is acceptable that
> constrained devices can always be responders, and in the non-constrained
> case, they assume both roles.
> 
> I also note, recalling I was told that one implementation of the ACP consists
> of IKEv2 initiated channels over IPv6-link-local addresses, that the essential
> properties the bootstrap design team intends to provide work just fine for
> IKEv2 as they do for DTLS.
> 
> I don't know if the ANIMA signaling protocol should occur before such a
> channel is established, or inside of this (provisional) channel, or whether it
> should instead run inside IKEv2 (maybe inside EAP).
> 
> I note that 6tisch has a few potential, "I am here" messages, with RPL DAOs
> and Efficient-ND (E)AROs being the two ones.  GDNP or HNCP or just
> IKE-port-500 messages are in my opinion also possibilities.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>