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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <barryleiba@xxxxxxxxxxxx>
Date: Monday, February 4, 2013 5:00 AM
To: "draft-ietf-mpls-tp-security-framework.all@xxxxxxxxxxxxxx"
<draft-ietf-mpls-tp-security-framework.all@xxxxxxxxxxxxxx>
Cc: "mpls@xxxxxxxx" <mpls@xxxxxxxx>, IETF discussion list <ietf@xxxxxxxx>
Subject: Re: [mpls] Last Call:
<draft-ietf-mpls-tp-security-framework-07.txt> (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'
>>   <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.

[luyuan] Fixed. 

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

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


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

[luyuan] Fixed all.
>
>-- 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.)

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


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

[luyuan] Removed.

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

[luyuan] Used suggested text.
>      - 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...)

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

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

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

[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,
>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?

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


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

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


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

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


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

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

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

[luyuan] Added "tools".


>
>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.
[luyuan] Fixed.
>
>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?

[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
>mpls@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/mpls


Thanks,
Luyuan





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]