Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-08.txt

From: [email-masked]
Date: Mon, 2 Mar 2009 14:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: RSVP Extensions for Path-Triggered RSVP Receiver Proxy
	Author(s)	: F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, L. Faucheur
	Filename	: draft-ietf-tsvwg-rsvp-proxy-proto-08.txt
	Pages		: 32
	Date		: 2009-3-2
	
RSVP signaling can be used to make end-to-end resource reservations
   in an IP network in order to guarantee the QoS required by certain
   flows.  With conventional RSVP, both the data sender and receiver of
   a given flow take part in RSVP signaling.  Yet, there are many use
   cases where resource reservation is required, but the receiver, the
   sender, or both, is not RSVP-capable.  Where the receiver is not
   RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
   thereby performing RSVP signaling on behalf of the receiver.  This
   allows resource reservations to be established on the segment of the
   end-to-end path from the sender to the RSVP Receiver Proxy.  However,
   as discussed in the companion document presenting RSVP Proxy
   approaches, RSVP extensions are needed to facilitate operations with
   an RSVP Receiver Proxy whose signaling is triggered by receipt of
   RSVP Path messages from the sender.  This document specifies these
   extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 3 Mar 2009 13:31:17 +0100

Hello,

> 	Filename	: draft-ietf-tsvwg-rsvp-proxy-proto-08.txt

Version -08 addresses Steve Kent's security directorate's review  
comments. See the thread below for comments + proposed resolution.

Francois

Begin forwarded message:
> From: Francois Le Faucheur IMAP <[email-masked]>
> Date: 1 February 2009 18:00:57 CEST
> To: Stephen Kent <[email-masked]>
> Cc: Francois Le Faucheur IMAP <[email-masked]>, [email-masked] 
> , [email-masked], [email-masked], [email-masked], [email-masked] 
> , [email-masked], [email-masked]
> Subject: Re: Comments  on draft-ietf-tsvwg-rsvp-proxy-proto-07.txt
>
> Hello Steve,
>
> Thanks a lot for your comments.
>
> We will post a new rev shortly aiming at addressing your comments.  
> Let us know if you have comments/concerns on the proposed resolution  
> approaches as described embedded below:
>
> On 17 Dec 2008, at 03:29, Stephen Kent wrote:
>
>> 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 companion document (draft-tsvwg-rsvp-proxy-approaches) is going  
> for Information Track while the present document is going for  
> Standards Track. We understand it is not appropriate to normative  
> downref an Informational doc from a Standards doc. If this is not  
> the case, we can certainly move the ref to the Normative Ref section.
>
>>
>>
>> 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.
>
> great.
>
>>
>> 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.
>
> The reason we see this case as a scalability issue rather than DDOS  
> is because the device that receives all the multiple PathErr  
> messages is actually the device that can trigger those in the first  
> place (by sending a Path). So we just pointed out that a well- 
> behaved sender may (in some large scale multicast environment) get  
> more PathErr than he'd like. A mis-behaved sender would primarily  
> trigger a self-DDOS than real DDOS.
>
> Of course, there is the general security concern about a node  
> sending many RSVP messages to an RSVP neighbor thereby DOSing it (or  
> potentially DDOSing other RSVP nodes since some RSVP messages may in  
> turn trigger multiple RSVP messages). But that is not really  
> specific to PathErr messages and is addressed generically in teh  
> security considerations section when discussing use of RSVP  
> Authentication mechanisms.
>
>>
>> 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?
>
> Yes, the current text is ambiguous.
>
> The right behavior would be that the receiver proxy sends a PathErr  
> message to all the senders.
>
> So text will be changed to something like:
> "
> For Wildcard-Filter (WF) style reservations, it is not always  
> possible for the Receiver Proxy to reliably know which sender caused  
> the reservation failure.  Therefore, the Receiver Proxy SHOULD send  
> a PathErr towards each sender. This means that all the senders will  
> receive a notification that the reservation is not established,  
> including senders that did not cause the reservation failure.  
> Therefore, the method of sender notification via PathErr message is  
> somewhat over-conservative (i.e. in some cases rejecting  
> reservations from some senders when those could have actually been  
> established) when used in combination with Wildcard-Filter style  
> (and when there is more than one sender).
> "
>
> Your comment also made us realize that:
> 	* we didn't use 2119 terminology when discussing the FF and SE  
> styles. so we will :
>               s/the Receiver Proxy sends/the Receiver Proxy MUST send/
> 	* we did not include the equivalent discussion on applicability to  
> multicast and WF/SE/FF in section 3.2. So we will add that discussion.
>
>>
>>
>> I have attached copy of the document, with numerous proposed edits  
>> that I believe will improve readability.
>>
>
> I included your suggestions (and addressed the few comments  
> embedded) in teh new rev that will be posted soon..
> Thanks for this very thorough review.
>
> Francois
>
>> Steve<draft-ietf-tsvwg-rsvp-proxy-proto-07.pdf>
>
>