Re: [nmrg] I-D Action: draft-behringer-autonomic-bootstrap-00.txt

[Brian E Carpenter <[e-mail]>]

Hi,

Here are a few comments on the bootstrap use case:

>    On the side of the new network element, an unskilled person should be
>    able to connect the device following a simple cabling scheme, perhaps
>    only supplying power to a wireless device.  Once connected, the
>    device must be powered on. 

Or not even that! Consider a wireless IoT device with solar power.
All you do is take it out of its box and Blu-Tack it in place.
No cable, no battery, no switch.

>    While
>    authorization of the UDI is required, it can be further automated,
>    for example providing a white list of valid device UDIs.  The actual
>    process of enrolment and bootstrapping should be zero-touch for the
>    operator.

What about the BlueTooth approach, where a device is white-listed
by a manual button-push during a short window of opportunity? There
are scenarios where that is acceptable (I have just unwrapped a
new device and want to validate it as part of my network).

>    For a fully secure
>    process, the device requires an IEEE 802.1AR [IDevID] credential.

Do we really want to specify the exact solution in a use case?
I think the reference should just be an example here.

More important, I don't think this is optional. Authentication of
every device is a MUST. Otherwise, the NSA can just add a spybot
to any network it finds interesting.

>    All
>    communications are link local

You state that as a fact, and of course it must be true at
the start of bootstrapping, but it creates a requirement:
every physical link (including wireless domain) must include
at least one proxy. Then you say

>    The neighbouring device acts as a
>    proxy 

OK, but there's another thing: which is "the" neighbour
on a link? Or could any neighbour act as a proxy?

Also, do the proxies need their own use case?

>    A new device exchanges data through the neighboring proxy with two
>    entities:
> 
>    o  A "Registrar" device, acting as the trust anchor of the domain.

So will you do a separate use case for autonomic configuration
of the registrar in the case of human-free networks? I touched
on that in the homenet use case, but without enough detail.

>    o  A cloud service provided by the vendor to facilitate autonomic
>       mechanisms. 

Surely that is not always needed? Don't you want disconnected networks
to be autonomic too?

>   Intent is not required for this autonomic process.

That surprises me. Isn't it possible that such questions as
crypto strength, and whether or not strict privacy is required,
might be delivered as intent?

> 7. Security Considerations

I think this is a bit relaxed. Enrolment is a critical
event in the security history of a site, and wireless
networks are especially vulnerable. Also, you should
perhaps note that privacy may require enrolments to be
conducted completely secretly, with no visible ID
escaping.

    Brian