A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering
draft-ietf-ccamp-inter-domain-framework-06

[Ballot discuss]
Thanks for the improved security considerations section.  This gives
us an excellent starting point as I think it does a good job of
describing the issues.

However, I disagree with the security direction that the WG proposes
to take.  The working group claims that existing mechanisms are
adequate even though their importance is higher and the key management
problem is more complicated because of the inter-domain issues. 

I am concerned though that the existing mechanisms are adequate.
Routing security tends to be deployed infrequently and tends to be
operationally challenging to manage.  I believe that the importance of
security in the inter-domain environment (as stated in these
requirements) requires that we make sure we have easy to use and
manage routing security mechanisms for the inter-domain extensions to
normatively depend on.  In particular, I believe that  RFC 4107 analysis needs to be done for this new deployment environment.  I believe that analysis will require automated  key management be a mandatory feature.
It is also important that we consider the usability  of the security mechanisms we recommend.

One possibility would be for us to have a document describing
automated key management for the appropriate protocols (or referencing
descriptions elsewhere) and to normatively require that the extensions
defined in support of this effort require these security features be
available in the supporting protocols.

[Ballot discuss]
Section 6 says:
  >
  > Requirements for security within domains are unchanged from [RFC3209]
  > and [RFC3473], but requirements for inter-domain security are, if
  > anything, more significant.
  >
  If this document is not going to contain the "more significant"
  security considerations, where will they be?

  Based on email from the authors, I expect this text to be replaced with:
  >
  > Requirements for security within domains are unchanged from [RFC3209]
  > and [RFC3473], and from [RFC3630] and [RFC3784]. That is, all
  > security procedures for existing protocols in the MPLS context
  > continue to apply for the intra-domain cases.

  Section 6 also says:
  >
  > Confidentiality may also be considered to be security factors.
  >
  It is not clear to me what "Confidentiality" means here.  I suspect
  that the authors do not mean confidentiality of the subscriber
  traffic.  Please clarify.

  Based on email from the authors, I expect this text to be replaced with:
  >
  > One new security concept is introduced by inter-domain MPLS TE. This
  > is the preservation of confidentiality of topology information. That
  > is, one domain may wish to keep secret the way that its network is
  > constructed and the availability (or otherwise) of end-to-end network
  > resources.

[Ballot comment]
Some things I noted while reading the draft:

- should reference some document (RFC4206?) when it discusses LSP hierarchies.
- expand acronyms IGP, EGP

[Ballot discuss]
Section 6 says:
  >
  > Requirements for security within domains are unchanged from [RFC3209]
  > and [RFC3473], but requirements for inter-domain security are, if
  > anything, more significant.
  >
  If this document is not going to contain the "more significant"
  security considerations, where will they be?

  Section 6 also says:
  >
  > Confidentiality may also be considered to be security factors.
  >
  It is not clear to me what "Confidentiality" means here.  I suspect
  that the authors do not mean confidentiality of the subscriber
  traffic.  Please clarify.

[Ballot comment]
Section 3.1 mentions the possibility of path computation to be performed by offline tools or by a network planner with the resultant path being supplied to the ingress LSR as part of the TE LSP or service request. There is no mention however in Section 6 - Security Considerations about the security implications of having the information needed for path computation available to a offline tool (confidentiality, authetication) and of supplying configuration information accross multiple administrative domains (authentication, authorization, non-repudiation).

[Ballot discuss]
The security considerations section roughly says that security is
going to be challenging but is a subject for future work.

I need to know where that future work is going to take place and where
it will be appropriate to insert normative security requirements.  I
am concerned that the work in this space appears to be a lot of small
protocol extensions without any documents other than this one that tie
the whole thing together.  If that's true then this document must tie
the security picture together as well.

If there is another place where we can describe the normative security
story, then please include at least an informative pointer here.


If things haven't progressed far enough that we know where the
security work will be conducted and where we can tie it into a
description of the whole system, then we are not ready to publish the
framework.

[Ballot comment]
If this is a framework and not a PS, why does it need normative
MUSTs and SHOULDs?

-----
Nits from Gen-ART review by Gonzalo Camarillo

The Copyright Notice on the first page should be updated: remove "All
Rights Reserved".

Acronyms should be expanded the first time they appear in the draft. In
particular, MPLS should be expanded in the title.

Nit at the end of Section  2.5:
OLD:
capable of estbalishing LSPs
NEW:
capable of establishing LSPs
              ^^

WG Chair's PROTO writeup (by Adrian Farrel):

draft-ietf-ccamp-inter-domain-framework-04.txt

> 1. Have the chairs personally reviewed this version of the Internet
> Draft (ID), and in particular, do they believe this ID is ready to
> forward to the IESG for publication?

Yes. Kireeti and I looked at this I-D.
Note that I am a co-author and have done most of the editing.


> 2. Has the document had adequate review from both key WG members and
> key non-WG members? Do you have any concerns about the depth or
> breadth of the reviews that have been performed?

Pretty thorough review in WG and a good number of comments. Resulted in a
second WG last call.

Took its input from the tewg, but that has been closed so was not
consulted.

Both WG last calls were copied to the MPLS WG which is very significantly
impacted by this work.

This I-D was contributory to the creation of the PCE WG and is referenced
there frequently.


> 3. Do you have concerns that the document needs more review from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, etc.)?

I think everything necessary is already done.


> 4. Do you have any specific concerns/issues with this document that you
> believe the ADs and/or IESG should be aware of? For example, perhaps you
> are uncomfortable with certain parts of the document, or have concerns
> whether there really is a need for it. In any event, if your issues have
> been discussed in the WG and the WG has indicated it that it still
> wishes to advance the document, detail those concerns in the
> write-up.

As main editor, I am comfortable.
However, in that role, I suggest that AD review should be cautious.

Note:
- The I-D explicitly avoids hierarchical domains
- The I-D skirts around issues of diverse path establishment. A separate
  I-D is being produced for this function.


> 5. How solid is the WG consensus behind this document? Does it represent
> the strong concurrence of a few individuals, with others being silent,
> or does the WG as a whole understand and agree with it?

Pretty good consensus.
There has been some muttering about:
- the fact that the I-D suggests BGP-TE might be a bad idea
- the fact that the I-D suggests that PCE might be a good idea

But I have probed these points hard with the complainants (main Dimitri)
and find no technical objection, but some philosophical issues.


> 6. Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email to the Responsible Area Director.

Nothing threatened or rumoured.


> 7. Have the chairs verified that the document adheres to all of the ID
> Checklist items ?

The chairs have done their best.


> 8. Is the document split into normative and informative references?
> - Are there normative references to IDs, where the IDs are not also
> ready for advancement or are otherwise in an unclear state? (note
> here that the RFC editor will not publish an RFC with normative
> references to IDs, it will delay publication until all such IDs are
> also ready for publication as RFCs.)

Split is OK
Note that since being submitted for publication, several informational
references have become RFCs. I'm sure the RFC Ed will sort this out.
Note that several informational references were ahead of this I-D in the
publication request queue, but I would prefer that we do not wait.


> 9. What is the intended status of the document? (e.g., Proposed
> Standard, Informational?)

Informational


> For Standards Track and BCP documents, the IESG approval announcement
> includes a write-up section with the following sections:

Hoorah for informational I-Ds!

Adrian