Subject: [Anima] big pictures diagrams --- how bootstrap fits into signaling and discovery

From: Michael Richardson <[email-masked]>
Date: Sun, 05 Jul 2015 16:29:59 -0400

After reading Brians' slides last week, I felt that there was some bigger
picture concepts/questions that were missing.  I drew these diagrams since.
While I've discussed this with Max, they are my own views.

There are 9 of them, located at:
  http://www.sandelman.ca/SSW/ietf/anima/diagrams/
also at:
  https://github.com/ietf-roll/ANIMA-Reference-Model/tree/diagrams
if someone wants to checkout the DIA files and edit them.

1) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network1-reference.svg

   Four routers (R1 to R4), just out of the box. Turned on in some random
   order, but let's assume here that it is about the same time.
   Connected by some links: one link is wifi, and one
   link is some kind of L2 switched LAN.  The others whatever you like... T1,
   SONET, a single lambda on a 100G cross-continent connect...

2) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network2-discovery.svg

  A discovery process occurs.  This can be expressed as either some kind of
  a) "I am R1, and I'm *here*", or as b) "I am a router looking for other routers"
  mDNS/Bonjour is more of type (a).  I believe that CDP/LLDP(IEEE 802.1AB) is
  also of type (a).
  DHCP and GDNP is more of type (b).
  I'm not sure how to characterize HNCP or DNS-SD as yet.

  I will also say that I think that discovery process should include running
  DHCP(v6).  I'm also unconvinced that GDNP/GRASP shouldn't be other than
  DHCPv6, and if it should be other, then should be DNCP based.

  *DISCOVERY* should, I think, occur at layer 2 and layer 3, and the results
  taken together.

3) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network3-awareness.svg

  In this diagram the awareness links are shown in orange.
  Note that I added two additional things: a potential BGP peer (maybe that
  LAN is an IX), and a wifi uplink discoveredy via DHCP.

4) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network4-identity.svg

   Okay, here is the first controversial slide.

   In this slide I suggest that a *prospective* ACP is brought up.
   That's the lines in purple --- one option would be an IKEv2 tunnel over
   link-local addresses --- with the authentication of the tunnels provided by
   the built-in 802.1AR certificates.  Note that while a vendorA device might
   be able to validate the chain of another device from vendorA, in general,
   the links are untrustworthy.

   This slide also shows brown ACP links to the BGP peer from R2 and R4.
   The BGP peer is assumed to be already running and imprinted, and we know
   that it is not part of the domain that is built.  The BGP peer however,
   does not know who R2 and R4 are, nor do R2 and R4 know that the BGP peer
   isn't part of the domain they will be told to join.  But, in order for
   the BGP peer to figure out that R2 and R4 do not belong, it has to build
   a trial relationship.  Not shown is some process whereby the BGP peer
   goes to talk to it's domain controller and learns that R2/R4 are not welcome.

   Several people had expressed needs to have the ACP potentially traverse
   domain boundaries, and this is an example of discovering a boundary.

5) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network5-routing.svg

   On top of these point to point tunnels, an RPL (rfc6550) instance would
   run, and what I'll call a *prospective* ACP would be formed.
   Note that the dashed red lines with the half-arrows denotes the acyclic
   parent relationship of the DODAG.

   Note that the R4/R3 wifi link was not preferred, but the ACP tunnel was
   brought up across it in order to determine that it was not preferred.

   Note also that the Uplink connectivity is still shown on R3, and having
   found something willing to transmit some packets, R3 announces some kind
   of default route. (Could be a coffee shop wifi, and the uplink could be
   v4 only, and R3 might be willing to become a NAT64/DNS64, and it should
   run an ASA that announces that)

6) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network6-imprint.svg

   Devices call "home".
   In the first version of this diagram, the devices called the vendor A,
   and vendor B boxes directly.  That could be the case, and they could be
   redirected to the domain owner based upon sales records, or it could be
   that the uplink, being provided by the domain owner, intercepts all
   traffic and directs it to the registrar.  Or the domain registrar could
   be running an ASA, and could have joined the ACP as well.

   *here be dragons*

7) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network7-domainjoined.svg

   The lines have changed from blue to green.
   That means that the domain owner and the devices have gone through an
   enrollment process, and the devices have imprint'ed on the domain.
   The lines are green now because both ends of the green line now possess a
   credential that can be verified by the other end.
   The ACP is still prospective, and parts of it could remain prospective
   for awhile, and it might even be the case that some devices in the middle
   do not in fact belong!

   The process of evaluating the 802.1AR certificates as well as some signed
   statement of device ownership is within the scope of the bootstrap design
   team.

   Determining how steps 1-6 work is *not* part of the bootstrap team!

   The other thing that the green domain owner box would return, either via
   the secure green channels, or via ACP + GRASP perhaps, is an intent for
   the devices.

   Let's say that the intent in this case is:
         number the network from this IPv6/40, and announce network at IX
         using BGP4.

8) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network8-secured.svg

   The ACP tunnels have rekeyed with the new identies, with the result that
   the ACP links are now green, as each router is able to authenticate the
   new identity.

   In addition, as a result of the new identity, the BGP peer now recognizes
   the R2 router (and I guess R4 could be green too).  It doesn't believe
   that it should be part of the same domain, but it is willing to agree that
   yes, it does have a BGP daemon that could be connected to.

9) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network9-uplink-discovery.svg

   Stuff happens, and the BGP connections come up, and the network goes
   online.

===== alternatives ======

In step 4, a prospective ACP is created in order to route traffic, in
particular, enrollment and imprinting traffic, but also other things.
If the network had to (s)elect a registrar, then that could be done across
this prospective ACP!
One could even imagine a situation where one device had a SIM card with which
to call home, but no signal, and another device had a 3G signal but not
credentials...  (Sounds like an episode of Sesame Street on sharing...)

An alternative to a prospective ACP is a half-up ACP.  The tunnel protocols
could get part-way up, and start exchanging EAP messages.
Could even be 802.1x rather than IKEv2 over link-local.

Routers R1/R2/R4 would have no way to do anything with the EAP messages,
but router R3, having discovered an uplink that it can use, would be able to
forward those EAP messages to some vendor MASA to validate them.
But, the only place that R3 would know to contact would be the built-in
relationship with it's vendor.  Would R3's vendor (not shown), know
how to get R1's EAP-TLS messages to vendor A's system?

If this can be solved (and eduroam, and the existing of roaming across the
3GPP network using radius is evidence that it can be solved), then the link
between R1 and R3 could become green, with the result that R1 would then be
able to send EAP messages from R2 upwards, eventually the entire network goes
green.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jul 2015 12:14:43 +1200

Hi Michael,

Cherry-picking in your message:
On 06/07/2015 08:29, Michael Richardson wrote:
> 
> After reading Brians' slides last week, 

Those were draft slides sent only to the signaling design team.
When they're ready they will of course be for the whole WG.

> I felt that there was some bigger

Very interesting. This, IMHO, should be distilled into input to the reference
model draft.

>   http://www.sandelman.ca/SSW/ietf/anima/diagrams/

...
>   DHCP(v6).  

Please explain how that works in a network with no administrator
and no pre-existing default configs. I don't see where a north-south
direction would even come from, let alone a designated DHCPv6
server.

> I'm also unconvinced that GDNP/GRASP shouldn't be other than
>   DHCPv6, 

We have a list of 25 requirements. I don't think DHCP fits them,
not even close. (I don't care about packet formats; in fact I'm
pretty sure we'll have use cases where carrying DHCP options in
anima signaling is entirely appropriate.)

> and if it should be other, then should be DNCP based.

I don't think DNCP fits the 25 requirements either, and I tried
quite hard to make it, since at least it isn't a north-south
protocol like DHCP. (Again, I don't care about packet formats;
the current GDNP TLV format is intentionally compatible with DNCP,
but Toerless has argued passionately for a change to JSON/CBOR.)

Please review the requirements and Appendix A in
draft-carpenter-anima-gdn-protocol-04, and if you can show in full
detail how DHCP(v6) or DNCP can meet the requirements, we can have
the discussion.

>   *DISCOVERY* should, I think, occur at layer 2 and layer 3, and the results

Discovery of what? In Anima signaling, we are only interested in
discovering Anima signaling peers. We are not particularly
interested in topology or nearest-neighbor discovery. The routing
system may need that kind of discovery but IMHO that is simply
a different problem.
...
> 4) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network4-identity.svg
...
> Not shown is some process whereby the BGP peer

I think that is the tricky bit - how does an entity know *in a zero-touch way*
which domain it is in and how to trust the domain registrar/controller?

>    domain boundaries, and this is an example of discovering a boundary.

I suspect that trust *across* domain boundaries will only be possible
with explicit Intent distribution (saying "it's OK to trust BGP speakers
in domain X presenting credenial Y").
>    run, 

but... but... only some Anima networks will run RPL. We definitely need to
be agnostic about the choice of IGP. If we've learned one thing from
homenet, we've learned that, surely?

...

>    traffic and directs it to the registrar.  

"Intercepts" is a bad word. IMHO we need to devices to discover whether
there is a local registrar first, and not waste their time trying to
call home to a vendor in deployments where that is impossible. (There
is a chicken/egg problem here, since that should be a matter of Intent
but you can't get Intent until you have been authenticated.)

>    Or the domain registrar could

Definitely.

I will stop there because I think we need the ACP authors to
comment on much of what you said. But thanks for the systematic
thinking.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jul 2015 04:50:34 -0400

> When they're ready they will of course be for the whole WG.

Yes, so I'm not responding to something specific in your slides, but rather
realizing that there I feel that there is some high level stuff missing.
I agree that it belongs in the framework document, but I don't find it
useful to argue in text until after we have argued in pictures (using crayons).

    > direction would even come from, let alone a designated DHCPv6

I'm saying, when a new node turns on, that running a DHCPv6 DISCOVERY process
should be part of learning what is going on.  Clearly, if all the other
connected nodes are in a similar state, nobody is going to answer, but in the
case where there is existing infrastructure, that it could reply.

    > anima signaling is entirely appropriate.)

If we stick with a TLV format, I think that we can make it work inside
DHCPv6.  Maybe we won't use the exact same set of DHCPv6 messages, but I
think that DHCPv6 SOLICIT and DHCPv6 ADVERTISE might be very much what
we want for the discovery process.

    > detail how DHCP(v6) or DNCP can meet the requirements, we can have

I'll review the 25 requirements.

    > homenet, we've learned that, surely?

What I learned is that we had better decide what we are doing up-front.
If we aren't building a routed ACP to faciliate end-to-end management
traffic, then we'd better put that in the *charter*.

As for RPL vs another one, if we don't pick *one* routing protocol, then we
probably don't have interoperability period, and we should go home.

(And, my questions on Monday about the Data Plane ACP essentially amount to:
if the Data Plane can't route traffic, then the ASAs have to proxy traffic,
i.e. do layer-7 routing, and that had better be in context if someone
thinks they really want to throw away e2e for management traffic)

    > but you can't get Intent until you have been authenticated.)

I don't agree.
Intents should be signed objects; the device doesn't need to authenticate
itself to the network before it can see the Intent.  The device may be unable
to authenticate the Intent; but if the device has nothing else to do, and the
Intent says, "Get network online", and the device can do that, it might as
well do it.

    > comment on much of what you said. But thanks for the systematic

Sorry for leaving this draft in my edit box for over a week.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2015 21:04:02 +1200

> case where there is existing infrastructure, that it could reply.

In fact I believe we should specify that a node SHOULD run the whole
DNA machinery (RFC6059).

   Brian

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2015 21:17:07 +1200

Sorry, pressed send too soon.

> we want for the discovery process.

Multi-hop?

> traffic, then we'd better put that in the *charter*.

The ACP will be routed, afaik. We were talking yesterday about picking
a default without going down the same rat hole as HOMENET.

> probably don't have interoperability period, and we should go home.

Well, there might be a model where you do network-wide discovery to find
which routing protocols are supported. But without agreeing on a lowest
common denominator "MUST implement" protocol, it becomes a procurement
requirement issue, and I don't like that conclusion.

> thinks they really want to throw away e2e for management traffic)

I don't see that. Surely there will be ASAs (in routers) whose job
after bootstrap is to bring up the data plane?

> Intent says, "Get network online", and the device can do that, it might as

I'm not sure how the network can trust the device at that time. Maybe we
don't want to send Intent to an untrusted device?

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 22 Jul 2015 11:06:09 +0000

One comment below,

> don't want to send Intent to an untrusted device?

An interesting point. Is intent information confidential to the anima domain?

My naive assumption would be that one doesn’t get to see intent or anything until bootstrapping is complete — in which case the device *can* be authenticated. I’m not commenting on the requirements discussion concerning if it *should* be authenticated.

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2015 23:41:45 +1200

On 22/07/2015 23:06, Max Pritikin (pritikin) wrote:
...
> An interesting point. Is intent information confidential to the anima domain?

It might be considered proprietary information or in some way useful
to an attacker. So I think it must be possible to protect it.

> My naive assumption would be that one doesn’t get to see intent or anything until bootstrapping is complete — in which case the device *can* be authenticated. I’m not commenting on the requirements…

Yes, but maybe we will have to make an exception for any intent that
is actually necessary to complete the bootstrap. I don't have an example
in mind, but like the first steps of discovery, there might need to be
an insecure mode.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 22 Jul 2015 11:54:24 +0000

> in mind, but like the first steps of discovery, there might need to be

hmm, so where the bootstrapping discussions currently consider initial configuration information to include a very minimal set of information such as:
1) join this ‘domain’ using enrollment mechanism X. 
2) use this management mechanism [e.g. management system uri, or distributed management protocol]
You are generalizing to think of this as ‘bootstrapping intent’? 
And going to the next step toward wondering if this information must be somehow kept confidential? 

The security considerations I discussed earlier effectively argue that this information should be:
	a) kept very simple/vague (intent level)
	b) be limited to these very simple areas
	c) not be shared with the vendor service
Which, I argued on monday, means they don’t need to be encrypted for confidentiality. This reduces the complexity of bootstrapping — which is a good thing! 

I think we’re in agreement again, 

- max

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Jul 2015 13:07:09 +0000

I would prefer if we could keep a clear line: 
- Intent is shared with trusted domain members only, ie after bootstrap.
- if you need parameters to bootstrap (and it's not clear we do), then signal them directly, but don't call it Intent. 

Michael

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 22 July 2015 14:06
> To: Max Pritikin (pritikin)
> Cc: Michael Richardson; anima
> Subject: Re: [Anima] Secret intent [was big pictures diagrams --- how
> bootstrap fits into signaling and discovery]
> 
> On 22/07/2015 23:54, Max Pritikin (pritikin) wrote:
> >
> >>>> I'm not sure how the network can trust the device at that time.
> >>>> Maybe we don't want to send Intent to an untrusted device?
> >>>
> >>> My naive assumption would be that one doesn’t get to see intent or
> anything until bootstrapping is complete — in which case the device *can*
> be authenticated. I’m not commenting on the requirements discussion
> concerning if it *should* be authenticated.
> >>
> >> is actually necessary to complete the bootstrap. I don't have an
> >> example in mind, but like the first steps of discovery, there might
> >> need to be an insecure mode.
> >
> > hmm, so where the bootstrapping discussions currently consider initial
> configuration information to include a very minimal set of information such
> as:
> > 2) use this management mechanism [e.g. management system uri, or
> > distributed management protocol] You are generalizing to think of this as
> ‘bootstrapping intent’?
> > 	c) not be shared with the vendor service Which, I argued on
> monday,
> > means they don’t need to be encrypted for confidentiality. This reduces
> the complexity of bootstrapping — which is a good thing!
> >
> Yes. And if we succeed in modeling Intent as an Objective that is flooded via
> GRASP, it would be a use case for insecure GRASP too :-).
> 
>    Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 01:16:41 +1200

> - if you need parameters to bootstrap (and it's not clear we do), then signal them directly, but don't call it Intent.

Well sure, we can call it whatever we like, but it will come from
a central authority.

    Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 22 Jul 2015 13:24:21 +0000

Hi.
In fact, I am going to present draft-du-anima-an-intent-01 (please read it)
tomorrow and there are some assumptions and questions about how we "frame"
an intent. Despite not being exactly the discussion points (secret intent,
bootstrap intent) which are described now in the draft, probably the result
of such discussion could be addressed in a future version.
Best.
Jéferson

Em qua, 22 de jul de 2015 às 10:07, Michael Behringer (mbehring) <
[email-masked]> escreveu:

> - if you need parameters to bootstrap (and it's not clear we do), then
> signal them directly, but don't call it Intent.
>
> Michael
>
> > > The security considerations I discussed earlier effectively argue that
> this
> > information should be:

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 22 Jul 2015 13:25:31 +0000

Hi.

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 22 Jul 2015 16:21:36 +0200

Hello,

> Well sure, we can call it whatever we like, but it will come from
Not necessarily _come_ from a central entity: the Intent (or whatever we 
end up calling it) could be shared by a neighbor already in possession 
of the Intent.

However, I do agree that the original Intent should be _defined_ by a 
central entity.

In answer to Michael: why not call it / make it part of the Intent?
     -we thus need to define only one concept/element in ANIMA to carry 
objectives/parameters, which make the Intent even more useful/powerful.
     -the intent can be "compartmentalized" so that if we are at the 
bootstrap stage, only a portion of it is disclosed (by the responding 
neighbor, or (central) management system).
For me, it is as important to drive the behavior at start-time via the 
concept/vehicule of Intent as it is for other times (after bootstrap), 
i.e. isn't there a real 'intent' of the operator on what/how the system 
shall behave when bootstrapping?

In comment to Brian and Max's first exchanges on the topic:
I see the Intent disclosure a being a kind of an iterative/hierarchical 
process, and the Intent is not monobloc rather modular/segmented.
At bootstrap, only a minimal portion of the Intent is made 
available/shared with new entities. Once the bootstrap (work same way 
for other phases), then another process take over and further portions 
of the Intent are disclosed/shared (e.g. routing aspects, monitoring...).
In this way, the joining/booting entity builds up its "stack" 
dynamically and always with the minimal set/delta of information to 
complete the ongoing/current process.
This seems compatible with the constraints expressed by Max and Brian.

Best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Jul 2015 16:22:20 +0000

> Sent: 22 July 2015 11:04
> To: Michael Richardson; anima
> Subject: Re: [Anima] big pictures diagrams --- how bootstrap fits into
> signaling and discovery
[...]
> > I'm saying, when a new node turns on, that running a DHCPv6 DISCOVERY
> > process should be part of learning what is going on.  Clearly, if all
> > the other connected nodes are in a similar state, nobody is going to
> > answer, but in the case where there is existing infrastructure, that it could
> reply.
> 
> In fact I believe we should specify that a node SHOULD run the whole DNA
> machinery (RFC6059).

Hmm.... I think a node will do some autonomic and some traditional things. And when bootstrapping, since a device doesn't know where it's going to wake up, it has to "try" both normal and AN bootstrapping. 

If the above discussion is in the context of "non-autonomic" - I have it all clear. (and really don't care ;-)

If we're saying we'd use these mechanisms to start some autonomic process, I'm confused / concerned. 

Which one? 
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 04:28:18 +1200

> If we're saying we'd use these mechanisms to start some autonomic process, I'm confused / concerned. 

A mixture :-). Maybe it is out of scope, but my instinct is that in an AN, the
nodes SHOULD maximize their basic (link layer) connectivity, because we build
the ACP on top of that. Maybe I have misunderstood DNA, though.

    Brian