MPLS Transport Profile (MPLS-TP) Security Framework
draft-ietf-mpls-tp-security-framework-09

[Ballot comment]
1) s4: Contains the following:

  Authentication includes entity authentication for
  identity verification, encryption for confidentiality, management
  system authentication, peer-to-peer authentication, ...

Now my head is full of cough medicine but does authentication really include encryption for confidentiality?  Should that bit be struck from the sentence?

2) s4: r/authentication,the/authentication, the

3) For what it's worth I agree with Stephen's comments.

[Ballot comment]
Minor editorial comment

OLD
  Security reference model 1(a) An MPLS-TP network with Single Segment
  Pseudowire (SS-PW) from PE1 to PE2.  The trusted zone is PE1 to PE2
  as illustrated in Figure 1.

NEW
  Security reference model 1(a)

  An MPLS-TP network with Single Segment
  Pseudowire (SS-PW) from PE1 to PE2.  The trusted zone is PE1 to PE2
  as illustrated in Figure 1.

[Ballot comment]

I guess as an abstract framework there's not much to
critique here, so feel free to take or leave the following
comments.

- I think you're right to focus on the NMS. I'm not sure
if there's any way to validate what's going on from two
independent points on the n/w using different vendor's kit,
but that might be something to consider.

- I think there's a missing threat, which is running
insufficiently audited or even malicious vendor supplied
(i.e. genuine) code on devices. Not all operators seem to
be trusting of all vendors these days.

- The inside==trusted; outside==there-be-dragons model is
probably less useful than was once the case. Many "inside"
systems end up being compromisable via e.g.  laptops that
get connected in the wrong places or USB sticks etc. While
that ought not happen, it does.  That does call into
question the "full control" statements in section 2 here.
Section 3 does however consider this to an extent.

- The use of isolated infrastructure wasn't that effective
in the face of a determined attacker in e.g. the case of
stuxnet. And that was with an air gap reportedly, whereas
use of "non-IP based communication paths" seems more like
just security by obscurity.

IANA has reviewed draft-ietf-mpls-tp-security-framework-07, which is
currently in Last Call, and has the following comments:

We understand 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:  (MPLS-TP Security Framework) to Informational RFC


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS-TP Security Framework'
  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 2013-02-06. 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 document provides a security framework for Multiprotocol Label
  Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS
  technologies and introduces new OAM capabilities, a transport-
  oriented path protection mechanism, and strong emphasis on static
  provisioning supported by network management systems. This document
  addresses the security aspects relevant in the context of MPLS-TP
  specifically. It describes potential security threats, security
  requirements for MPLS-TP, and mitigation procedures for MPLS-TP
  networks and MPLS-TP interconnection to other MPLS and GMPLS
  networks. This document is built on RFC5920 "MPLS and GMPLS MPLS and
  GMPLS security framework" by providing additional security
  considerations which are applicable to the MPLS-TP extensions. All
  the security considerations from RFC5920 are assumed to apply.

  This document is a product of a joint Internet Engineering Task Force
  (IETF) / International Telecommunication Union Telecommunication
  Standardization Sector (ITU-T) effort to include an MPLS Transport
  Profile within the IETF MPLS and PWE3 architectures to support the
  capabilities and functionality of a packet transport network.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-security-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-security-framework/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review

Hi authors of draft-ietf-mpls-tp-security-framework

As usual I have done an AD review of your draft as part of the publication request process. This has raised a number of issues that I have set out below and which lead me to believe that the I-D is not yet ready to go forward for publication as an RFC.

I shall mark the I-D as needing a new revision, and simply tell the working group that you and I are discussing some revisions. Please talk with the working group chairs about the most effective way to make the updates, and engage with me in a debate about what we should do with this document, and about any or all of the points I raise.

Thanks,
Adrian

===

Many of my concerns may be clustered under the topic of the focus of the draft:

- Why does this document need to describe or specify MPLS-TP itself?
- Why does this document identify security issues that are generic to
  all MPLS networks?
- What is the meaning of setting requirements on "MPLS-TP" in this
  document?

I wasn't really expecting a very large document. MPLS-TP is not a very big increment on MPLS. You might observe heavier use of the G-ACh, and new OAM protocols - both need protection. You might observe that some of the new OAM techniques provide attack vectors as well as security mechanisms. And you might observe that some of the constraints that apply in MPLS-TP (e.g. PHP being off by default) may help bolster security. But otherwise, I am not sure there is much to say.

The descriptions of security reference models are interesting, but they are no different to the models for MPLS PWs. And, in any case, you don't seem to make a great deal of reference to them in the rest of the text.

I should be really interested to hear if there is strong working group consensus to support the document in its current state. I certainly understand that there is consensus that *a* document is needed to describe the security framework for MPLS-TP, but I am raising the doubt that this is *the* document in its current form.

---

The document formatting is all messed up. Need to indent text and insert page breaks. (The missing page breaks are identified by idnits!)

---

Please split Authors' Addresses into Authors' Addresses (front page people) and Contributors' Addresses (other authors).

---

It is no longer necessary to include the following in the Abstract:

  This Informational Internet-Draft is aimed at achieving IETF
  Consensus before publication as an RFC and will be subject to an IETF
  Last Call.

  [RFC Editor, please remove this note before publication as an RFC and
  insert the correct Streams Boilerplate to indicate that the published
  RFC has IETF Consensus.]

All Informational I-Ds in the IETF Stream are now subject to IETF last call, and the RFC editor automatically includes the appropriate
boilerplate.

---

RFC 5920 looks like it needs to be a Normative reference.

---

I think the Abstract should mention RFC 5920 and indicate that this document builds on 5920 by adding additional security considerations
applicable to the MPLS-TP extensions. All the security features and considerations from 5920 are assumed to apply.

---

Section 1.1

Why is it necessary to say in this document what the intent of MPLS-TP is? I found that a distraction, and surely it is covered elsewhere.

---

A number of acronyms are used without expansion in Section 1.

---

s/G-Ach/G-ACh/

---

Please don't say "GAL label" !

---

Section 1.4

GAL does not stand for Generic Alert Label!
RSVP is not used in the document.

---

Section 1.5 is a waste of time given the presence of the Table of Contents.

---

In Figures 2, 3 and 4, the trusted zone extends slightly too far to the left. Also the "PSN cloud" edges are not aligned correctly.

BTW. What is a "PSN cloud"? There is no mention of "cloud" in the text and I think you could safely relabel the figures with "PSN".

---

Section 2.4

  A key requirement of MPLS-TP networks is that the security of a
trusted zone MUST NOT be compromised by interconnecting one SP's
MPLS-TP or MPLS infrastructure with another SP's core devices, T-PE
devices, or end users.

Unclear whether this means that you must not interconnect, or that you may interconnect but doing so must not compromise security.

---

I don't understand the caption to Figure 7

Surely T-PE1, S-PE1, and S-PE2 are part of the trusted zone. Compare with Figure 3.

How is Provider B a neighbor? Either devices or domains are neighbors.

CE2 does not look to be a neighbor for Provider A. How is it considered?

---

I think Section 3 is a bit jumbled between attack vectors and effects.
For example:

      a.  GAL label or BFD label manipulation, which includes insertion
          of false labels or messages and modification, deletion, or
          replay of GAL labels or messages.

...is not an effect.

I do believe that you are attempting the right separation between the
things that can be done, and the impact they might have on the network.
However, I don't think you have achieved the separation correctly.

---

Section 3

We need a reference for:

  Even though surveys show that 40% to
  60% of attacks originate from insiders

Otherwise you might as well say "surveys show that 76% of all statistics
are invented to suit the authors."

---

I don't find anything in Section 3.1 that is new to MPLS-TP. Am I
missing the point? I thought the document was only a delta on existing
MPLS/GMPLS security.

---

Ditto 3.2

---

Section 4 does not sit well in this document. Why are there requirements in a Framework document? Do you want to turn this into a Requirements Statement? If so, should it be Standards Track?

What is the reader supposed to do with the requirements? The requirements are voiced as "MPLS-TP must do foo". That is an MPLS-TP design consideration, which is fine, but does it belong here? Shouldn't a framework tell you how to apply the MPLS-TP toolkit to obtain security?

---

Section 4. R01. This feature already exists in MPLS-TP. Why describe it as a requirement? OTOH, "should support" does not mean "must support" and is not "must implement" or "should deploy".

---

Section 4. R02. This function is already included in MPLS-TP. What does it mean to make it a requirement at this stage?

---

Section 4. R03. What does this mean?

---

Section 4. R04 and R05. Aren't these general MPLS security features?

---

Section 4. R06 and R07. What is a dynamic MPLS network inter-connection protocol?

---

Section 4. R08. This pretty much says "everything must be protected". Can you break it out into separate distinct pieces so that it is easier to develop against?

---

Section 4. R09. This seems to mix two issues: hiding information and DDoS prevention. How closely are they related?

---

Section 4. R10 and R11. How are these actionable requirements for "MPLS-TP"?

---

... I gave up on Section 4.

---

Section 5. Finally, real meat!

However, I am struggling to see text here that is specific to MPLS-TP.

5.1.1, 5.1.2, 5.1.3, and 5.2 all seem fully applicable to MPLS networks.

5.3 has some specific interest for MPLS-TP in as much as MPLS networks would not typically make this separation.

5.4 is back to a generic MPLS security statement. Indeed, in MPLS it would be hard to avoid this positive feature. You could make a point here that in MPLS-TP it is possible to separate the management flows, but that would be a bad idea and you should behave as normal.

5.5 is just general apple pie applicable to MPLS.

Finally 5.6 leverages features that are enhanced in MPLS-TP and so may aid making MPLS-TP more secure. Of course, we should note that these mechanisms are now also available in any MPLS.

---

Section 6 is also good material, but how is it specific to MPLS-TP? What have you said that does not apply equally to MPLS?

---

I think Section 7 says very nicely what the document should have done :-(

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The MPLS working group request that:


                    MPLS-TP Security Framework
            draft-ietf-mpls-tp-security-framework-04

  is published as an Informational RFC.

  This document is one of the mpls-tp frameworks and like all the other
  frameworks it is an informational document.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:



Technical Summary

  This document provides a security framework for Multiprotocol Label
  Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS
  technologies and introduces new OAM capabilities, a transport-
  oriented path protection mechanism, and strong emphasis on static
  provisioning supported by network management systems. This document
  addresses the security aspects relevant in the context of
  MPLS-TP specifically. It describes potential security threats,
  security requirements for MPLS-TP, and mitigation procedures for
  MPLS-TP networks and MPLS-TP interconnection to other MPLS and GMPLS
  networks.



Working Group Summary



Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  This document has a strong support in the working group
  and has been well reviewed.

  The orgaqnization, structure, and content of this document
  benefit from multiple reviews, in particular, reviews by the
  co-chair of the KARP WG.
 
  ITU-T SG15 has been notified of all reviews and working group
  last calls for this doecument, there are no unresolved comments
  or issues.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  This an informational document, it presents a framework
  that might be used when implementing, deploying, configurating
  and operating networks, but it is not possible to say that
  there are implementations.
  The document has had the review that is needed, the working
  group last call was brought to the attention of SG15 in
  ITU-T.


Personnel



  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.



(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  This document is an MPLS-TP framework and has been part of the
  ongoing discussion in the MPLS-TP project. The document shepherd
  has reviewed the document several times, e.g. the first individual
  version, when it was polled to become a wg document and at the wg
  last call, and at least one time in between.
  The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The security community have be involved in developing this draft
  and the people active in the KARP wg has reviewed and commented
  on it.
  Nevertheless a targeted security directorate review during the
  IESG review would be of value."



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns!

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  There are no IPRs filed against this document.
  The working group last call started the working group chairs
  sent last step before requestion publication was sending a mail to the
  working group and the authors, asking any members of the working group
  whom were aware of IPRs to speak up and requiring the authors either
  to indicate if they were aware of IPRs or say that they were not.



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR filed for this document.



(9) 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?

  The working group is behind this document. It has been well discussed
  and reviewed as part of the MPLS-TP discussion.
  It has also been discussed and reviewed in pats of ITU-T SG15.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  This document passes cleanly through the nits-tool.



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no such formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No, all normative references are to existing RFCs.



(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No changes to existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  No request for IANA allocations.



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  No request for IANA allocations.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language.