Subject: [Anima-bootstrap] bootstrap purpose

From: peter van der Stok <[email-masked]>
Date: Tue, 24 May 2016 09:22:47 +0200

Hi all,

I looked again at the keyinfra draft and did not recognize an explicit 
description of the purpose of securing the network with the bootstrap.

As far as I understood there are 2 objectives;
1) a packet sent by an unauthorized node is not routed through the 
network
2) An unauthorized node cannot interpret a packet sent by an authorized 
node

Neither does the text tell us how this is achieved once the bootstrap 
has successfully concluded.
Do we aim at a specific protocol or do we want to leave this open?

-- 
Peter van der Stok
vanderstok consultancy

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 24 May 2016 11:23:13 +0000

Hi Peter, 

The primary purpose of draft-ietf-anima-bootstrapping-keyinfra is to deploy a domain specific key infrastructure. You're not mentioning that, I assume because it's obvious? 

What a device does with that key material is outside scope of this document. Although, 3.5 and 3.6 go a little step in that direction. IMO we should keep the bootstrap of key material (current objective of doc) clearly separate from what to do with this key material. So we should probably be clearer that 3.5 are just examples. 

To me, the objectives you mention: 

> 1) a packet sent by an unauthorized node is not routed through the network

are not the main objective of this work, but of course a security consideration for the bootstrap process. 

Since I'm not sure I understood you fully, please let me know whether we're in line!
Michael

> -----Original Message-----
> From: Anima-bootstrap [mailto:[email-masked]] On
> Behalf Of peter van der Stok
> Sent: 24 May 2016 09:23
> To: Anima-bootstrap <[email-masked]>
> Subject: [Anima-bootstrap] bootstrap purpose
> 
> Hi all,
> 
> 1) a packet sent by an unauthorized node is not routed through the network
> Neither does the text tell us how this is achieved once the bootstrap has
> successfully concluded.
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 May 2016 17:02:06 +0200

Hi Michael,

In earlier versions of the bootstrapping the purpose was to add an 
unsecured node to a secured mesh network.
Nodes on the secured network exchanged encrypted messages.
New nodes had to learn the keys to encrypt.
New nodes were not allowed to communicate with other secured nodes but 
for starting the acquisition of the keys.

Therefore the joining node needed a neighbouring proxy, because 
unsecured messages were not routed over the secured network.
I don't find the concept of secured network any more and start wondering 
why we need the neighbouring proxy.

Peter

Michael Behringer (mbehring) schreef op 2016-05-24 13:23:
> Hi Peter,
> 
> The primary purpose of draft-ietf-anima-bootstrapping-keyinfra is to
> deploy a domain specific key infrastructure. You're not mentioning
> that, I assume because it's obvious?
> 
> What a device does with that key material is outside scope of this
> document. Although, 3.5 and 3.6 go a little step in that direction.
> IMO we should keep the bootstrap of key material (current objective of
> doc) clearly separate from what to do with this key material. So we
> should probably be clearer that 3.5 are just examples.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2016 08:34:35 +1200

On 25/05/2016 03:02, peter van der Stok wrote:
> Hi Michael,
> 
> In earlier versions of the bootstrapping the purpose was to add an unsecured node to a secured mesh network.
> New nodes were not allowed to communicate with other secured nodes but for starting the acquisition of the keys.
> 
> Therefore the joining node needed a neighbouring proxy, because unsecured messages were not routed over the secured network.
> I don't find the concept of secured network any more and start wondering why we need the neighbouring proxy.

The secured network is the ACP, so I wouldn't expect any of that discussion in
the bootstrap work. It should be in the description of how the ACP is formed.
(In the non-ACP case, the assumption we make is that the nodes all have appropriate
certificates for (D)TLS, and those certificates will be sufficient to keep traffic
within the AN domain.)

I though the proxy was simply the way to reach the domain registrar?

    Brian