Subject: [mpls] Comments on draft-ietf-mpls-tp-security-framework

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 07 Nov 2011 16:38:08 -0500

Major:
Several of these requirements are pure assertions. For the reader to use 
them, it is very helpful if explanations of the security analysis that 
goes with the assertion exist somewhere. (This applies to mechanism 
requirements. Requirements like "preventing DoS" don't need explanations 
of what the security issue is :-) I think this is an important part of 
the framework that users need.

Structurally, it seems very odd to have the requirements before the
threats. In my experience, the threats drive the requirements.

Moderate:
In describing the requirements in section 3, the text first says:
"This document does not mandate that an MPLS-TP network must fulfill all 
security requirements listed to be secure."
I understand the general idea of this statement. However, it is not
clear how this statements relates to the MUST phrasing in the list which 
follows that. Are the MUSTs mandatory? I think that the idea is better 
described in section 5.
Related to this, some of the bullets use "or" terminology, resulting in 
it being unclear what is being mandated. For example, in the second 
bullet, it says "MUST support … with or without NMS or OSS". Does that 
mean that the requirement is met if the system supports only CLI, or 
only SNMP, or does the text actually require that both be supported?

It seems that the connection in the second requirement between 
non-control plane provisioning support and trust boundaries really needs 
some justification.

I understand that service providers have a requirement for hiding 
topology. But is that really a security requirement?

In section 4, I am not sure what "A MPLS-TP configuration transiting the 
public Internet" is. It does not seem to match any of the scenarios. I 
presume "transiting" was carefully chosen to be different from 
"connecting to". It would seem helpful if there were more explanation of 
what was intended.

The text leading into sections 4.1 and 4.2 says "The following sections 
discuss …" But sections 4.1 and 4.2 are merely enumerated lists. They do 
not discuss anything. It is not even clear what the enumeration 
accomplishes, since it includes things that are MPLS general, things 
that are nearly impossible in MPLS-TP, and things that are MPLS-TP 
specific. It seems to me that if this is the MPLS-TP Security Framework 
that we need to be clear in the threats list as to which threats are 
dealt with elsewhere, which threats are changed by the MPLS-TP 
mechanisms, and which threats are new with MPLS-TP. Also, we should 
either discuss the threats, or not claim to be discussing them.

Minor:
Could there be some clarification on what is meant by non-IP path 
options vs IP loopback option? Maybe a section reference to another 
document, or a few extra words as to what thing is not IP. I would 
suggest that the extra wording path would allow for some explanation of 
why the use of non-IP address may help improve security. (It is very 
common for operators to filter control traffic at the border already.)

Could "port access control" in the MCC requirements be better explained? 
I can think of several possible meanings in this context.

The next to last requirement is not written as a requirement. It is a 
list of general things that are useful to do.

In section 4, it refers to security being generally a tradeoff between 
"expense and risk". There are several possible meanings for this 
sentence. For at least some of them, I would think "cost" (which 
includes manpower and other issues as well as actual cash expenses) 
would be a better word than "expense".

Editorial:
Section 1.1, fourth paragraph: I think the reference to 5921 was 
supposed to be a reference to 5920?

Why is AC: Attachment Circuit defined in section 2.1 instead of in the 
list of terminology in section 1?

Should Security Reference Model 3 (section 2.3) state explicitly that 
the two PEs and the devices in between are under the control of a single 
operator?

It would be easier to reference the requirements if they had numbers. 
(R.1, R.2… for example.)

Is there a reason that in the list of requirements in section 3 some 
items have o and some have *? (If these are replaced with unique ids, 
then the question becomes moot.)

Section 5.5 is empty.