> 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