Subject: [secdir] Comments on draft-ietf-tsvwg-rsvp-proxy-proto-07.txt

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Dec 2008 21:29:48 -0500

I have 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 defines extensions to RSVP to enable a router to act as 
an RSVP "Receiver Proxy," when a sender invokes the proxy through use 
of an RSVP Path message (so-called Path-triggered RSVP). (An RSVP 
Receiver Proxy is employed when the sender (reservation requestor) is 
more than one hop away from the first router that implements RSVP.). 
A companion document (ietf-tsvwg-rsvp-proxy-approaches) is cited as 
an informative reference, but given that this document makes 
extensive use of definitions from that document, I think it is more 
properly a normative reference.

The use of a receiver proxy for RSVP reverses the usual roles in the 
RSVP protocol, and this suggests that there may be new security 
concerns, distinct form those usually addressed by RSVP. I expected 
he security considerations section address this possible issue, and 
about 40% of the text in that section is devoted to this topic, and 
it is appropriately addressed.

On page 12 the authors note that certain error cases in multicast 
environments could result in transmission of a large number of 
PathErr messages to a sender by many receivers. This is cited as a 
possible "scalability issue," which I interpret as a euphemism for 
DDoS attacks. I also expected to see a mention of this in the 
security considerations section, but there was no further discussion 
of this DoS issue.

Page 12 also notes that the mandated behavior described in "this 
section" (but presumably subsequent sections, i.e., 3.1.1-3.1.4) does 
not apply in the case of wildcard filtered reservations. That seems a 
bit ambiguous; does this mean that the routers SHOULD/MUST do nothing 
in the error cases described later, or that they MAY do anything that 
implementors please?

I have attached copy of the document, with numerous proposed edits 
that I believe will improve readability.

Steve

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir