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.