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

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Sun, 1 Feb 2009 18:00:57 +0100

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>

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