Subject: [Anima-bootstrap] anima bootstrap design team -- admin and logistics

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2015 22:52:49 -0400

Hi, this email is long overdue, and I appologize for it; start of school year
stuff, vacations...

The ANIMA bootstrap design team meets weekly at 10am EDT (7am
PDT; I write EDT, because it is unclear what will happen when DST is over).
We use audio from webex, but rarely any other of its' mechanisms, at:
  https://cisco.webex.com/ciscosales/j.php?MTID=ma5a7178d02a2edcb0c6d7b43e5315f08
  Meeting number: 200 557 721
  Meeting password: boot
  dial: +1-866-432-9903 Call-in toll-free number (US/Canada)
        +1-408-525-6800 Call-in toll number (US/Canada)

We use an etherpad for notes and minutes, which for reasons of a typo is at:
   http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true

People who have been participating include:

Our schedule was set in August as:
    2015-09-02 * CANCELLED     (but some people met anyway)
    2015-09-09
    2015-09-16  * tomorrow
    2015-09-23
    2015-09-30
    2015-10-07
    2015-10-14
    2015-10-21
    2015-11-01 is IETF94 week; we plan to find time for a lunch.

My job is to post a set of minutes, and it is in this regard that I'm remiss,
and so I'll be sending a few emails as replies to this one because writing
one big long one will take long enough that I'll never get done.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2015 23:01:39 -0400

> People who have been participating include:

forgot to fill this in:
       Max Pritikin
       Michael Richardson
       Michael Behringer
       Sandeep Kumar (did I get that right?)
       Kent Watsen
       Robert Craigie
       Toerless Eckert

not everyone has been at every call.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2015 23:07:14 -0400

Our first meeting was something like June 4, with meetings being mostly
Thursdays or Fridays that month.  What happened was that Max and I went
through draft-pritikin-anima-bootstrapping-keyinfra carefully and made sure that we
agreed on terminology, and what new things to bring in.
We updated the XML, and got it ready for submission as -01.
We also went through to produce the anima-bootstrap design team charter text,
which we edited onto the wiki in that period, and emails were produced
detailing that.

The notes from July/June can be seen in the anima-boostrap etherpad from the
point: "POST IETF93 action items:"

We did not meet much in July due to travel and vacations and IETF coming up.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2015 23:27:36 -0400

The next meeting was August 5.
August 5th meeting: present Max Pritikin, Michael Richardson

Some specific result was:
     The bootstrapping document might be able to get away with indicating a
     requirement to signaling team (e.g. "end to end connectivity for EAP
     messages" or something). We are not sure we can require a "concentric tree
     ring" growth process. Might be reasonable to have a second doc that

that meeting went into the next week, and there was some multiple iterations
of recap...

August 12:
present were: Max Pritikin, Michael Richardson and Michael Behringer

(We didn't have the host key for sharing so we moved to:
    cisco.webex.com/join/mbehring, and max stayed on the original webex as
    well to watch for late attendees. )

behringer shared a bootstrapping process slide to build on the discussion of
(1) and (2) from last week's meeting.

MCR: Need to capture a key point:
     - the designation of something as the Registrar is a non-autonomic
       operation! MCR thinks that this is controversial, and needs to be
       brought to the WG for consensus.

     - the administrator is involved because an ACL or pointer to a trusted
	cloud ACL or [whatever] is an administrative action
	This is equivalent to the "intent" abstraction

During parts of July and August, we discussed the idea of a prospective ACP;
or an ACP which is isolated from the production ACP and which is created
without full authentication.  The purpose is to provide enough connectivity
so that the devices can enroll.

We constrasted this to a proxied, or EAP/1x type of process, where new nodes
communicate over the layer-2 to a proxy (or authenticator, or
join-assistant....) which then relays the EAP messages to a registrar.  Such
a system requires a concentric inside to outside enrollment process. Michael
shared the description a requirement to do bootstrapping in a non-concentric
way, but the details could not be shared publically (as yet: these notes are
BCCed to the party in question)

We constrasted this to systems like TR-069 (used to supply configurations to
cables modems and some DSL models),  but in those situations the the modems
never validate the ISP.

MCR called the proxy process as "layer-5 routing" while Max preferred to
think of this in 1x terms as selective layer-2 EAP-encapsulation.  Vs a prospective ACP
method which would be layer-3 forwarding, something we know how to do quite
well. A prospective ACP could make use of routing protocols and have multiple
paths/redundancy and even do discovery such the registry function might not
need to be "decreed by god"

In particular, MCR does not have a problem with the layer2-5 approach. He is
concerned about 'creep' on that approach wrt identifying new nodes,
redundancy, load balancing registrars, etc. Eventually he argues you've
re-invented the ACP but in an ad hoc fashion.

Other notes that discuss this say:
	MCR argues that the complexity of (2) is hidden at first but once the
	system is "at scale" the complexity grows to match the (1) but is now
	haphazard and not as well thought out. Suggests it is better to go
	head with (1) but flag the overlay as "for bootstrapping"

	On the other hand (2) could be designed rather quickly: just add an
	EAP role as an 'authenticator forwarding'. So this would be less a
	reinvention but rather leveraging the existing EAP architecture.

August 19 was cancelled for vacations.

2015-08-26 meeting notes
 present: Max, Sandeep, Kent, Michael, Robert Craigie

We set the schedule for schedule for future meetings:
		2. 2015-09-02 * CANCELLED.
		2. 2015-09-09
		2. 2015-09-16
		2. 2015-09-23
		2. 2015-09-30
		2. 2015-10-07
		2. 2015-10-14
		2. 2015-10-21
		2. 2015-11-01 is IETF94 week, should plan a lunch.

** need to be more rigorous with notes to mailing lists **

We set out to start:
   review of the requirements section of
   draft-ietf-anima-grasp-00:https://tools.ietf.org/html/draft-ietf-anima-grasp-00#section-2The
   requirements are numbered 1..25. If you have comments, please mentionthe
   requirement number, or propose a completely new requirement.

We started on item 25, and it occupied most of the meeting, I think, as we
cycled through the prospective ACP vs proxy discussion again.

MCR concluded that the afore-mentioned requirement for non-concentric
bootstrap was incorrectly conceived.  What that situation actually needs a
non-concentric configuration of the data plane, and the tool to that is a
functional ACP, and it matters not if the ACP is bootstraped concentrically,
as long as it can then be used to build non-concentric (and possibly
non-connected) data-plane instance in each "apartment"

   re: “Re: [Anima-bootstrap] issues and trees [was schedules and
   agendas]”M. Behringer, do you agree with B. Carpenter's statement that
   “GRASP may have to run insecure discovery”? That positions GRASP as the
   communications method even over the “IPv6 link local” in your diagram
   (albeit an unsecured instantiation of it)?

What are our requirements on GRASP? (If GRASP is to be used as the ipv6 link
layer communication...)

	* must be able to come up protected from passive attacks but not
	active, in some form of quarantine mode. This speaks to req 25:

	25.  The protocol needs to be fully secured against forged messages
   and man-in-the middle attacks, and secured as much as reasonably
   possible against denial of service attacks.  It needs to be capable
   of encryption in order to resist unwanted monitoring, although this
   capability may not be required in all deployments.  However, it is
   not required that the protocol itself provides these security
   features; it may depend on an existing secure environment.

We discussed IKEv2 as the hop-by-hop security method, noting that it can use
EAP as well as PANA and has some other advantages, but it does not provide
discovery.

NOTE: If GRASP uses ikev2 then PANA/EAP methods are possible. It would be
possible to do all key bootstrapping over an EAP method and then GRASP comes
up without ever having run insecurely. This wouldn't be a requirement on
GRASP so much as a requiement on the ACP transport that GRASP runs over.

 * Is there a clear statement about how GRASP/ACP comes up in a
	mesh[terminology? when there is no infrastructure] state?

ACTION: MCR to ask this question of the GRASP team (from 'bootstrapping' to
        'signaling')

* bootstrapping key infrastructures requires some key infrastructure; we do
	not care if the key infrastructure itself we as autonomically created

MCR's concern here: what is the registrar is booted a while after the
	connectivity components. Should basic connectivity be provided even
	before the registrar is available for bootstrapping?

MCP: I agree with this discussion but contend that to bootstrap a device in
     to the key infrastructure this must already be solved.

MCR to fomulate autonomic-registrar use case.

4. push out anima version of doc
	!!) Can we resolve the "constrained networks" statement before it
        becomes an anima doc (replace word in the abstract)

MCR did resolve this, and we pushed a new document,
see:
        https://github.com/ietf-roll/anima-bootstrap/commit/f9616a33d78a4a0ecc54d63ee6fa87a573b33394

5. For the transitive introduction can we choose between "end 2 end transport
security" (e.g. HTTPS) vs "message based" (e.g. MASA) or do we need to be
able to do both? If we blend them can we limit the discrete message types.

6. re: “adopt draft-pritikin-anima-bootstrapping-keyinfra as ANIMA WG
document”The tail end of this thread has some terminology discussionsref:
RFC6973 (I don’t see the terms Hannes is pointing to here)ref: RFC7228 (about
constrained devices/networks)there is a note here as well about
“bootstrapping” vs “management”. sigh. what about “keystrapping”!?

7. re: “EST in anima thoughts” This thread trails off with questions about
   PANA. What is our overlap with PANA?

2015-09-09 meeting notes:
    present: mcr,

0. mcp recaps current bootstrapping section 5

1. mcr recaps lighting problem, suggests that lighting "bootstrap" is really
	network provisioning.

We take this as a set of requirements:
	a) concentric bring up is ok
	b) devices that can't reach the registrar "wait"
	c) once a registrar is identified everything comes up in a timely fashion
		might require some sort of 'advertisement' (TBD mechanism)

2. We can't populate s5.1 of bootstrapping until we better understand:
	is this 802.1x
	or is this ikev2 during an ACP handshake?

DISCUSSION about whether or not the bootstrap process is seperate, or an
		integral part of forming the ACP.

Michael Behringer describes scenario where bootstrap could be proxied, but
ACP would not be: MCR would like to see this clearly articulated as a usecase
that we should solve.

MCR thinks that the point of the bootstraping is to bring up the ACP, and in
some cases, that the 802.1AR certificates might be in-them-selves completely
acceptable to forming the ACP, but you can't know that until you actually try
using them when forming the ACP.

MCR re-iterates his TODO items, btw:
	1. nail down for dtbootstrap what device types are in scope (constrained devices and challenged networks)
	2. requirements from bootstrap to signaling
	3. write summary, minutes and plans to list (including schedule of
	calls) [this email makes this DONE]