Survey of Possibilities for the Automated Configuration of Large IP Networks

Summary: Needs a YES. Has a DISCUSS.

(Ralph Droms) Discuss

Discuss (2012-08-15 for -04)
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.

(Adrian Farrel) (was No Objection) Discuss

Discuss (2012-08-14 for -04)
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
Comment (2012-08-11 for -04)
No email
send info
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


Figure 1 has a misalignment.

(Brian Haberman) (was No Objection) Discuss

Discuss (2012-08-14 for -04)
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?
Comment (2012-08-14 for -04)
No email
send info
1. I support the DISCUSS and COMMENT raised by Adrian (on Stewart's behalf).

Barry Leiba (was No Objection) Discuss

Discuss (2012-08-15 for -04)
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.

(Sean Turner) Discuss

Discuss (2012-08-14 for -04)
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?
Comment (2012-08-14 for -04)
No email
send info
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.

(Ron Bonica) Yes

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-08-14 for -04)
No email
send info
Adrian is taking over my Discuss as I will not be on the call this week.

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2012-08-12 for -04)
No email
send info

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.


- 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.

(Russ Housley) No Objection

Comment (2012-08-15 for -04)
No email
send info
  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:

(Pete Resnick) No Objection

Comment (2012-08-16 for -04)
No email
send info
I agree with Brian's DISCUSS.

5.1: Is PPP not worth mentioning here?

(Robert Sparks) No Objection

Comment (2012-08-13 for -04)
No email
send info
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.

(Martin Stiemerling) Abstain

Comment (2012-08-15 for -04)
No email
send info
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.

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Martin Duke No Record

Benjamin Kaduk No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record