[secdir] secdir review of draft-ietf-mpls-soft-preemption-18.txt

[Stephen Kent <[e-mail]>]

I reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document (draft-ietf-mpls-soft-preemption-18.txt) defines a set 
of modifications to MPLS RSVP-TE to accommodate _soft_ preemption. 
The preemption facility is intended to offer a less draconian 
alternative to the basic preemption facility of MPLS RSVP, i.e., 
immediate displacement of a preempted LSP (label-switched path). The 
approach described here adopts a _make before break_ strategy, to 
minimize the impact of rerouting an LSP that is being preempted. In 
this model, preemption is initiated at some midpoint along an LSP, 
e.g., because another, higher priority traffic flow has been assigned 
to traverse the router in question. The authors note that if the 
cause of the preemption is the allocation of resources for a new 
flow, rather than actual data plane congestion, the hard preemption 
option is unduly disruptive. This is especially true if the 
environment in which the traffic is being carried supports multiple 
Diff-Serv levels.

The security considerations section of this document refers to RFC 
3209, the RSVP-TE (Extensions to RSVP for LSP tunnels) spec, stating 
that no new security issues arise as a result of defining the soft 
preemption capability introduced here. Since soft preemption is less 
intrusive than the (default) hard preemption, it seems likely that 
any DoS security  concerns for LSPs that are preempted are subsumed 
by the more general RSVP security concerns addressed in 3209. An 
attack that would cause one or more router to inappropriately preempt 
traffic would have a less severe impact in this context, than in the 
current RSVP preemption model. However, as the authors note, soft 
preemption can cause temporary under provisioning of one of more 
nodes/links in a path, and this does represent a new security 
concern.  I suggest that the authors notes this explicitly in the 
Security Considerations section. (They cite under-provisioning as a 
possible effect of this preemption approach, so it seems reasonable 
to cite this as a possible security issue.)

RFC 3209 has a one paragraph security considerations section. For the 
most part this paragraph refers to the base RSVP spec (RFC 2205). It 
does note that the use of LSP tunnels reduces the filtering options 
available to an ?administration? and thus it suggests using address 
family SESSION objects of type IPv4 or IPv6.  (This seems to be a 
very minimal filtering capability compared to normal IP 
source/destination address pair filtering.)

A quick look at RFC 2205 shows that it contains a non-trivial 
security section (not the security considerations section mandated in 
later RFCs, but still about a page of text). This discussion is a bit 
superficial and uses technically poor security terminology. It also 
refers to a "work in progress" for "a part of the base RSVP 
specification" despite the normative nature of the cited document, 
(which was not issued as an RFC for over 2 years). RFC 2205 says that 
node authentication is effected via an Integrity object, an odd 
terminology mismatch. 2205 also uses the term "encrypted hash 
function" in pointing to the document that was later issued as RFC 
2747. RFC 2747 describes use of a "keyed hash function" for 
integrity, and cites HMAC-MD5 as mandatory. The correct, generic 
terminology is a hash-based MAC, but the security AD at the time was 
not a stickler for technically accurate terminology, c.f. the TCP-MD5 
"signature" option :.  This suggests that an update to these earlier 
document may be in order.

There are several minor typos in the text, but I'm confident that the 
RFC Editor will fix them during the AUTH48 interval.