Last Call Review of draft-ietf-mpls-soft-preemption-
review-ietf-mpls-soft-preemption-secdir-lc-kent-2009-08-27-00

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.