Survey of Possibilities for the Automated Configuration of Large IP Networks
draft-ietf-opsawg-automated-network-configuration-05

[Ballot discuss]
In my opinion, the title of this document is inaccurate.  Any problem
statement is interleaved with the solution model, the problem is
incompletely described (is this document aimed at configuring any network
device, just customer edge devices, constrained devices; what is the
relationship between the networks in the inter-domain case), and the
problems derive in many cases from the assumed solution.

I *think* there is a useful set of abstract, solution independent
problems somewhere in the document, but I don't think the document is
of value in its current form.

My action to clear this Discuss would be for the working group to
rewrite the document, extracting the problems from the rest of the
solution framework, taxonomy, etc.

Brian very clearly stated several specific issues with the document
and I support his Discuss on those issues.

[Ballot discuss]
After some discussion and further consideration on this, I'm changing my position to DISCUSS: I don't see where this document is going, what its value is, and how it meets the goals it purports to set out.  Brian's DISCUSS text says it all excellently, so I'll refer to that for more detail.

[Ballot comment]
I'm in support of the other DISCUSSes and do have an issue with the draft as it is right now. It is rather confusing and is probably neglecting the fact that there are working mechanisms on automated network configuration for a number of access network technologies.

I have also doubts that the draft really represents the consensus of the WG. The shepherd write-up hints to this. Lines starting with > are from the shepherd write-up.

> (6) The only concern that the shepherd has about the document is the relatively limited discussion about the contents of the document that took place as well as what could be a relatively limited impact of the document itself (i.e. how much change in behavior or process that the document will actually engender).

> (9) This document has the strong consensus of a subset of the working group, with the remainder of the working group silent.


Furthermore, I do doubt that level of review was sufficient:
> (5) The working group does not believe that any other specialized review is necessary of the document.
But, did somebody with BBF or 3GPP background review the draft?


I do also miss the conclusion in the shepherd write-up for this question:
> 1) Was this work actually going to change behavior of the reader. Was there substantive value in the material presented.

[Ballot comment]
I'm in support of the other DISCUSSes and do have an issue with the draft as it is right now. It is rather confusing and is probably neglecting the fact that there are working mechanisms on automated network configuration for a number of access network technologies.

I have also doubts if the draft really represents the consensus of the WG. The shepherd write-up hints to this:
> (6) The only concern that the shepherd has about the document is the relatively limited discussion about the contents of the document that took place as well as what could be a relatively limited impact of the document itself (i.e. how much change in behavior or process that the document will actually engender).

> (9) This document has the strong consensus of a subset of the working group, with the remainder of the working group silent.

Furthermore, I do doubt that some more review would have been appropriate:
> (5) The working group does not believe that any other specialized review is necessary of the document.
But, did somebody with BBF or 3GPP background review the draft?


I do also miss the conclusion in the shepherd write-up for this question:
> 1) Was this work actually going to change behavior of the reader. Was there substantive value in the material presented.

[Ballot comment]

  I agree with the suggestions made by Vijay Gurbani in the
  Gen-ART Review posted on 13-Aug-2012.  Please consider the
  comments. The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07678.html

[Ballot discuss]
1) general: it's not until s5 that term "constrained device" is used.  Is this draft targeted specifically at that market segment or the more general case?

2) general: I don't think you should assume that further specifications are required for the gaps you've identified.  I don't want to see this document used as a club later on to specify things that might turn out to not be needed or unwanted.  It makes more sense to say these items require further study.

3) s4: I think that the "requirement" (noting the lower case) for an invariant ID is shared by many enterprise users, but I doubt my mom and dad want that.  Is this targeted at devices to be included in enterprise networks or the general Internet case?

[Ballot discuss]
1) general: it's not until s5 that term "constrained device" is used.  Is this draft targeted specifically at that market segment or the more general case?

2) general: I don't think you should assume that further specifications are required for the gaps you've identified.  I don't want to see this RFC used as a club later on to specify things that might turn out to not be needed or unwanted.  It makes more sense to say these items require further study.

3) s4: I think that the "requirement" (noting the lower case) for an invariant ID is shared by many enterprise users, but I doubt my mom and dad want that.  Is this targeted at devices to be included in enterprise networks or the general Internet case?

[Ballot comment]
1) I agree with everything Brian said.

2) a/s1: known solutions exist ;)
  r/known solutions where they exist/known solutions

3) s3: Certificates aren't much good without the private keys that go with them - and not all devices will use certificates - some might use bare keys.  Maybe swap out certificate with authentication data (e.g., identity, keys, certificates, trust anchors). 

3) s5.3: Had to same issues Stephen did with this paragraph.

4) s5.4: I have no idea if you thought about this but there is a protocol to manage trust anchors: RFC5934.

5) s6: I have no idea if you thought about this but there is a firmware distribution protocol: RFC 4108.

[Ballot discuss]
1. I am unsure of this document's goal.  The title purports it to be a problem statement on the automatic configuration of network devices.  However, most of the document is a taxonomy on the existing methods used to configure the network devices. The abstract makes no mention of being a problem statement and the introduction specifically says it is a taxonomy.  Which is it?  What is the document trying to accomplish?

2. The definition of the inter-domain scenario seems incomplete.  Is there a requirement that the two networks have some type of predefined relationship (e.g., business partnership) in order for the new device to actually connect to its home network?

3. In describing the relative merits of some of the possible solutions to the identified problems, the document attempts to rank those solutions against one another.  However, the relative ranking of those solutions are dependent on each operator's network, administrative model, business goals, etc.  I see no reasonable way that this document can say one solution is better than another.  Those types of statements should be stricken from the document unless you can elaborate why those rankings hold in all situations.

4. The document overall is unclear on what types of devices it is describing when discussing configuration information.  At best, it talks about "large IP networks", but doesn't delineate between types of devices.  For example, is there an expectation that a transit service provider would use this model to configure its core routers?

[Ballot discuss]
Taking over Stewart's discuss as he will be absent fron the telechat....

The authors say:

  It should be noted that some steps in the described process, in
  particular the bootstrapping phase, may not be secure and it is thus
  important to verify the identity of the device and the identity of
  the configuration server when a secure connection to a configuration
  server is established.

Surely bootstrapping should either be out of scope, or listed in the
gapa analysis section as an issue that needs to be addressed

[Ballot comment]
If you haven't already looked at them, you might find some of the considerations called out in RFC6080 and RFC6011 useful input to the gap analysis.

[Ballot discuss]
The authors say:

It should be noted that some steps in the described process, in
  particular the bootstrapping phase, may not be secure and it is thus
  important to verify the identity of the device and the identity of
  the configuration server when a secure connection to a configuration
  server is established.

Surely bootstrapping should either be out of scope, or listed in the
gapa analysis section as an issue that needs to be addressed.

[Ballot comment]


While I'm not objecting to this document, the last two
points in particular would have been discusses if this had
been proposed as a BCP.

- I think you should be clear as to whether you're only
talking about tangible or also virtual devices.

- "(The expansion of eNodeB is too unwieldy to spell out.)"
Nice. Don't let anyone make you change that :-) It might be
nice to say what it does though.

- "Vendor" is a bit ambiguous here, it could be the device
manufacturer or the network operator (who sells a service).
Probably better to avoid the term.

- Section 3, bootstrapping: recent results seem to imply
that a lack of good sources of randomness at this point
and/or lack of variation at first-boot, can be problematic
e.g. leading to the generation of bad RSA private keys. [1]
I think this document could benefit from mentioning that.
I'm not sure if you have any recommendations to make on how
to get better randomness at this point, but if you do,
that'd be welcome.

  [1] http://eprint.iacr.org/2012/064

- The reference to 3118 in 5.2 is very weird. I'm told by
DHCP folks that its never, ever, used.

- 5.3: "Furthermore, this approach can lead to problems if
certificates are used to authenticate the involved parties
if a service provider tries to prevent the usage of a
vendor's redirection service." This seems plain wrong. Why
would an SP try prevent use of a vendor's re-direction
service, which is how the device would get to the SP in the
first place? I'd say delete it or explain whatever problem
you mean properly.

- 5.3: s/not recommended/NOT RECOMMENDED/ but then you have
no 2119 reference so I guess you don't want that?

- 5.3, last para: this assumes the device announces its
type/id and then the server provides config but that isn't
the only way it can be done. (You say "needs to.") Instead,
the server could offer a directory service and the device
could download a bunch of configs that include the one it
needs. That latter is not coverered here and is arguably (a
little) more privacy and security friendly.

- 5.4 says its best to include a device ID. Recalling the
fiasco of the Intel processor serial number, I disagree.
Privacy consideraions would seem to argue against such a
recommendaiton, at least for many kinds of device. I also
see no reason why, in general, a device needs to
authenticate itself to the config server - what threat is
being countered by that? What does it mean for a trust
anchor to "reside" somewhere? Is RFC 3414 really an
equivalent to IPsec or TLS? Seems Odd. I think this entire
section need work to be honest for it to be useful.

[Ballot comment]
IETF Last Call drew a comment about the appropriateness and
contentiousness of Section 10. I did not see an answer to this comment
and believe that all IETF Last Call comments should at least receive an
answer.

---

Figure 1 has a misalignment.

IANA has reviewed draft-ietf-opsawg-automated-network-configuration-04, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Problem Statement for the Automated Configuration of Large IP Networks) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'Problem Statement for the Automated Configuration of Large IP
Networks'
  as
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-08-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo discusses the steps required to bring a large number of
  devices into service in IP networks in an automated fashion.  The
  goal of this document is to list known solutions where they exist, to
  point out approaches proven to be problematic, and to identify gaps
  that require further specifications.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-automated-network-configuration/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-automated-network-configuration/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1706/
  http://datatracker.ietf.org/ipr/1735/

> (1) the working group is requesting this document to be published as an informational RFC as identified in the header of the document. We believe that this is appropriate as it identifies approaches to automatic network configuration, and does not define any new protocol or standards activities. It identifies problems in this space, and a set of tools defined by the IETF that could be used to address those issues.
>
> (2)
>
> Technical Summary
>
> This memo discusses the steps required to bring a large number of
> devices into service in IP networks in an automated fashion. The
> goal of this document is to list known solutions where they exist, to
> point out approaches proven to be problematic, and to identify gaps
> that require further specifications.
>
> Working Group Summary
>
> This document had a long process through the working group, mainly due to two points.
> 1) Was this work actually going to change behavior of the reader. Was there substantive value in the material presented.
> 2) There was an IPR claim made by one of the Author's employer on the document. There was discussion about IPR on an informational document. The IPR claimant clarified that IPR existed around a potential solution to problems presented by the document (i.e. if the tools mentioned in the document were "assembled" in a specific configuration to address the issues identified in the document, then there was the chance that IPR may become involved). This was discussed and accepted by the working group.
>
> Document Quality
>
> As this document specifies no new standards or MIBs, and is not an implementation target, there are no interoperability concerns. The document is reasonably well and clearly written for a practitioner in the space to understand.
>
> Personnel
>
> the document shepherd is Christopher Liljenstolpe, and the AD is Ron Bonica.
> Director?
>
> (3) The shepherd as run the document through the extensive nits tool and found no substantive nits. The only outstanding comment from the tool was reference to one obsoleted RFC, which will be cleaned up by the authors before publishing.
>
> (4) The shepherd has no substantial concerns about the depth of the review, other than the audience that undertook the review was relatively small.
>
>
>
> (5) The working group does not believe that any other specialized review is necessary of the document.
>
> (6) The only concern that the shepherd has about the document is the relatively limited discussion about the contents of the document that took place as well as what could be a relatively limited impact of the document itself (i.e. how much change in behavior or process that the document will actually engender).
>
> (7 & 8) The working group is aware of a (revised) IPR claim on this document. We believe that BCP 78 & 79 have been addressed. It is the understanding of the working group that the IPR claim does NOT actually make a claim against the discussion in this informational document. It is our understanding that it is more of a "warning" that there exists a body of IPR that may be infringed on if some subset of the tools discussed in the document are assembled in a specific way to address one or more of the issues identified by the document. Any entity working on addressing the issues identified by this document should be aware of potential IPR infringements.
>
> (9) This document has the strong consensus of a subset of the working group, with the remainder of the working group silent.
>
> (10) There have been no threats of appeal or other examples of substantial friction over this document.
>
> (11) As discussed above, a thorough nit check was performed by the shepherd. The only comment from the tool was one reference to an obsoleted RFC. This has been passed to the authors for consideration.
>
> (12) No review is necessary for MIBs URIs, etc.
>
> (13) All references have been classified
>
> (14 & 15) There are no normative references.
>
> (16) This document, if published, will change NO existent RFC's
>
>
> (17 & 18) This document makes NO requests of IANA.
>
> (19) There is NO formal language in this document.
>

The document completed last call in March but not progressed.  A heads-up was sent to the working group 10 june 2012, and we've now completed last call.  A write-up is underway.