Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-security-framework-07.txt> (MPLS-TP Security Framework) to Informational RFC

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Feb 2013 22:00:45 +0900

> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'MPLS-TP Security Framework'
>   <draft-ietf-mpls-tp-security-framework-07.txt> as Informational RFC

Some Last Call comments in advance of IESG Evaluation:

-- Abstract --
   This document is built on RFC5920 "MPLS and GMPLS MPLS and
   GMPLS security framework"

Bit of a stuttering typo there.

-- General --

There are lots of abbreviations throughout here that aren't expanded.
You do send us to documentation (the last paragraph of Section 1), so
I wonder how much we should expect every one to be expanded on first
use.  But I see OAM, GMPLS, PWE3, PE (with and without S- and T-),
GAL, G-ACh, BFD, DoS, LSP.

On the other hand, I'm not sure we want to clutter things up with a
lot of expansions that anyone who reads the document will already
know.  So I'll just leave this as a passing comment.

-- Sections 2.1 and 2.2 --

It's a small point, but the diagrams for security reference models
1(b), 2(a), 2(b), and 2(c) aren't labelled exactly as the text states.
 The bad ones are 2(a) and (b), where the diagrams have "SPE1" and the
text has "S-PE".  In the others, it's just a question of a "-" in the
text and none in the diagram.  As I say, it's a small point, but I'd
prefer it if the text and the diagrams matched exactly; removing the
dashes in the text seems easiest (and fixing the "1" in the text for
the two "S-PE" cases).

-- Section 3 --

   This section discuss various network security threats which are to
   MPLS-TP and may endanger MPLS-TP networks.

Is this missing the word "new" somewhere?  (And make it "discusses",
while you're fixing that.  We'll let the RFC Editor do the
"which"->"that" change; they need something to do.)

   A successful attack on a particular MPLS-TP network or on a SP's
   MPLS-TP infrastructure may cause one or more adverse effects.

Yes, that would sort of be the definition of a successful attack, I
should think.  (You might consider deleting this paragraph.)

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

To make the list clearer, I suggest this:

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

      - DoS attack through in-band OAM G-ACh/GAL and BFD messages.

You mean *excessive*, unproductive messages, of course.  Is there a
good way to say this that can help someone detect when these messages
become a DoS attack, or otherwise give some more information?  (Maybe
there isn't...)

   When a NMS is used for LSP setup, the attacks to NMS can cause the
   above effect as well. Although this is not unique to MPLS-TP, but
   MPLS-TP network can be particularly venerable as static provisioning
   through NMS is a commonly used model.

"Vulnerable", not venerable.  But I don't understand why the fact that
static provisioning through NMS causes any greater vulnerability than
otherwise.  Can you expand on that a bit?

   Observation (including traffic pattern analysis), modification, or
   deletion of a provider's or user's data, as well as replay or
   insertion of inauthentic data into a provider's or user's data
   stream.

This isn't a complete sentence, so I'm not sure what you're trying to
say.  Are you just saying that these are security threats?  Again,
that seems clear, and rather obvious.  Can you perhaps split these up,
and say a bit more about some of them?  The observation part seems
particularly interesting: I'd like to know what can be observed that
causes security issues.  And you've given one example, but haven't
said much about it.  What is it that traffic pattern analysis can
reveal in MPLS-TP that is sensitive?  What other things can be
observed that might be sensitive?

(The other points don't need expansion, I guess, and you cover defense
in the next section.  But see below for a comment about that.)

   The threats may be resulting from malicious behavior or accidental
   errors. For example: Users of the MPLS-TP network may attack the
   network or other users; employees of the MPLS-TP operators,
   especially people who operate the NMS, attackers who obtain physical
   access to a MPLS-TP SP's site; Other SPs in the case of MPLS-TP
   inter-provider connection.

I find this paragraph hard to follow: I don't know what to do with the
semicolon-separated list.  I think you're giving me a list of examples
of how malicious behaviour or accidental errors.  And what I see is
this:

1. Users of the MPLS-TP network may attack the network or other users.

--- Yep... got that.

2. Employees of the MPLS-TP operators, especially people who operate
the NMS, attackers who obtain physical access to a MPLS-TP SP's site.

--- I can't parse that, and don't know what you're trying to say.

3. Other SPs in the case of MPLS-TP inter-provider connection.

--- That's just a subject with no verb, and, again, I'm not sure what
you want to say.

-- Section 4 --

   The techniques discussed here include [...long list...]

I expected to see those techniques discussed here.  Then I saw, "Where
these techniques apply to MPLS and GMPLS in general, they are
described in Section 5.2 of [RFC5920]." That's fine, but then please
don't say "The techniques discussed here".  Maybe "Techniques to
defend against the security threats in Section 4 include
[...list...]."

   Thisis one way to protect the infrastructure used for support of
   MPLS-TP to separate the resources for support of MPLS-TP services
   from the resources used for other purposes. For example, in security
   model 2 (Section 2.2), the potential risk of attacks on the S-PE or
   T-PE in the trusted zone may be reduced by using non-IP-based
   communication paths.

The first sentence is confused and hard to understand.  Please re-write it.

In the second sentence (I'm not an MPLS guy, so please bear with me
and educate me if I'm completely off base here), is the point really
about non-IP-based communication paths, in particular?  Or is it more
generally that the communication paths in the trusted zone are not
accessible outside the zone?  If so, adding that would help ("...by
using non-IP-based communication paths, so that the paths in the
trusted zone...").

   Note that the
   connectivity verification are now developed for general MPLS networks
   as well.

Is there a word missing here?  Connectivity verification tools?
Techniques?  Something else?

In the last paragraph, items 3 and 4 are the same.  I think this list
would benefit from being shown as a regular numbered list, rather than
grouped together in a paragraph.

In general, in this section I expected to see what defensive
techniques could be used with the specific threats in Section 3.
Instead, I have to try to match them up, and maybe they're not very
matchable.  Given the brevity of Section 3, I think a better
arrangement of this document would have one section that had a list of
threats along with the defense against each threat.  Something like
this:

Threat: GAL or BFD label manipulation, which includes insertion of
        false labels and modification, deletion, or replay of messages.
Defense: [Whatever]

Threat: DoS attack through in-band OAM G-ACh/GAL and BFD messages.
Defense: [Whatever else]

Perhaps you thought this would be a longer document, so you arranged
it this way, but with most things applying to MPLS in general, and not
being specific to MPLS-TP, you have the opportunity to arrange it more
directly.  Is it possible to do that?

Barry

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 6 Feb 2013 05:54:58 +0000

Hi Barry,

Thank you very much for your review and detailed comments/suggestions, and
thanks for your discussion.
I uploaded the new version that addressed all your comments, as well as
Dan's Gen-ART review comments, and acknowledged your help.

http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-0
8.txt

Please see in-line.

-----Original Message-----
From: Barry Leiba <[email-masked]>
Date: Monday, February 4, 2013 5:00 AM
To: "[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF discussion list <[email-masked]>
Subject: Re: [mpls] Last Call:
<draft-ietf-mpls-tp-security-framework-07.txt> (MPLS-TP Security
Framework) to Informational RFC

>Bit of a stuttering typo there.

[luyuan] Fixed. 

>GAL, G-ACh, BFD, DoS, LSP.

[luyuan] We initially had terminology section, it was taken out during the
last call discussion. Based on the comments from you and Dan for Gen-ART,
I added the term section back with a new list of terms that are relevant
to this document.

>dashes in the text seems easiest (and fixing the "1" in the text for

[luyuan] Fixed all.
>"which"->"that" change; they need something to do.)

[luyuan] Fixed.
New text: This section discusses various network security threats that are
unique to MPLS-TP and may endanger MPLS-TP networks.

>should think.  (You might consider deleting this paragraph.)

[luyuan] Removed.

>      labels and modification, deletion, or replay of messages.

[luyuan] Used suggested text.
>become a DoS attack, or otherwise give some more information?  (Maybe

[luyuan] New text:
DoS attack through in-band OAM by generating excessive G-ACh/GAL and BFD
messages which consume significant bandwidth and potentially cause
congestion.
>otherwise.  Can you expand on that a bit?

[luyuan] New text:
When a NMS is used for LSP setup, the attacks to NMS can cause the above
effect as well. Although this is not unique to MPLS-TP, MPLS-TP network
can be particularly vulnerable to NMS attack due to the fact that static
provisioning
through NMS is a commonly used model. In the static provisioning model, a
compromised NMS can potentially be comparable to a comprised control plane
plus a comprised management plane in the dynamic controlled network model.

>that seems clear, and rather obvious.

[luyuan] Adding the following text at the beginning of the paragraph:
There are other more generic security threat, such as:

> Can you perhaps split these up,

[luyuan] The following is a sub-section in RFC5920 that explains
observation, so I added a pointer to RFC5920.

"4.2.1.  Unauthorized Observation of Data Traffic

    This refers to "sniffing" provider or end user packets and examining
    their contents.  This can result in exposure of confidential
    information.  It can also be a first step in other attacks (described
    below) in which the recorded data is modified and re-inserted, or
    simply replayed later."

>--- That's just a subject with no verb, and, again, I'm not sure what

[luyuan] New text:
The threats may be resulting from malicious behavior or accidental errors.
Example 1: Attack from users: Users of the MPLS-TP network may attack the
network infrastructure or attack other users.
Example 2: Attack from insiders: Employees of the operators may attack the
MPLS-TP network, especially through NMS.
Example 3: Attack from inter-connecting SPs or other partners: Other SPs
may attack the MPLS-TP network, particularly through the inter-provider
connections.
Example 4: Attack as the result of operation errors: Operation staff may
fail to follow the operational procedures or make operational mistakes.

>The first sentence is confused and hard to understand.  Please re-write

[luyuan] New text:
One way to protect the MPLS-TP infrastructure network is to use dedicated
network resources for MPLS-TP transport services.

>using non-IP-based communication paths, so that the paths in the

[luyuan] New text:
For example, in security model 2 (Section 2.2), the potential risk of
attacks on the S-PE1 or T-PE1 in the trusted zone may be reduced by using
non-IP-based communication paths, so that the paths in the trusted zone
cannot be reached from the outside via IP.

>Techniques?  Something else?

[luyuan] Added "tools".

>grouped together in a paragraph.
[luyuan] Fixed.
>directly.  Is it possible to do that?

[luyuan] The draft was much longer before. We shortened it based on AD's
review comments, and now focusing on threat and defense that are unique to
MPLS-TP. At this point, we would prefer to keep it this way without new
structure change. But I added the text to address your points on matching
the defense technique to the treat talked in Section 3.

New text:

Authentication is the primary defense technique to mitigate the risk of
the  MPLS-TP security threat "GAL or BFD label manipulation", and "DoS
attack through in-band OAM" discussed in Section 3. Authentication refers
to methods to ensure that message sources are properly identified by the
MPLS-TP devices with which they communicate. Authentication includes
entity authentication for identity verification, encryption for
confidentiality, management system authentication, peer-to-peer
authentication, message integrity and replay detection to ensure the
validity of message streams, network-based access controls such as packet
filtering and firewalls, host-based access controls, isolation,
aggregation, protection against denial of service, and event logging.
Where these techniques apply to MPLS and GMPLS in general, they are
described in Section 5.2 of [RFC5920].

>
>Barry
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

Thanks,
Luyuan

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Feb 2013 05:47:22 +0800

> Dan's Gen-ART review comments, and acknowledged your help.

Thanks for the reply, Luyuan.  I'm happy with all the resolutions.

Barry

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 6 Feb 2013 21:51:15 +0000

Barry,

Thanks again for your help and support!
Luyuan

-----Original Message-----
From: Barry Leiba <[email-masked]>
Date: Wednesday, February 6, 2013 1:47 PM
To: Luyuan Fang <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>, IETF discussion list <[email-masked]>
Subject: Re: [mpls] Last Call:
<draft-ietf-mpls-tp-security-framework-07.txt> (MPLS-TP Security
Framework) to Informational RFC