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(_at_)computer(_dot_)org>
Date: Monday, February 4, 2013 5:00 AM
To:
"draft-ietf-mpls-tp-security-framework(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org"
<draft-ietf-mpls-tp-security-framework(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>
Cc: "mpls(_at_)ietf(_dot_)org" <mpls(_at_)ietf(_dot_)org>, IETF discussion list
<ietf(_at_)ietf(_dot_)org>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
Thanks,
Luyuan