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

[Francois Le Faucheur IMAP <[e-mail]>]

Hello,

> 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

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 <[e-mail]>
> Date: 1 February 2009 18:00:57 CEST
> To: Stephen Kent <[e-mail]>
> Cc: Francois Le Faucheur IMAP <[e-mail]>, [e-mail] 
> , [e-mail], [e-mail], [e-mail], [e-mail] 
> , [e-mail], [e-mail]
> 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>
>
>