Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
RFC 5946

Note: This ballot was opened for revision 11 and is now closed.

(Cullen Jennings) Discuss

Discuss (2010-01-14 for -)
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain. 

For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy. 

Why are section 4.1 and 4.1 SHOULD and MAY implement. It seem like they need to be MUST.

How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services. 

Need to specify "predetermined time" in section 4.1. Not willing to have it be zero. 

Why is the Receiver-Proxy-Needed needed?

RAO paragraph in security consideration does not seem right. 

The dissection in last para of stein 5 is no longer true with the other changes.

Don't understand why this needs the group-keying work

For something like triggered approach, when does the reservation get town down?

The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS. 

The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify. 

ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use. 

Has the working group considered if there are ways to achieve this that are not IPR encumbered?

(Lars Eggert) (was No Objection) Yes

(Adrian Farrel) Yes

Comment (2009-04-29 for -)
No email
send info

Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor
misses them.
I think the documents should be marked as "Updates RFC 3305"
Section 1 line 1 
Section 1 para 1
s/network need to operate/network needs to operate/
Section 1
   However, we note that multicast applications do not always mesh well
   with RSVP Receiver Proxies
s/mesh/coexist/  ?
I am a little bothered by the use of "protected by an RSVP reservation"
throughout the document. This is not the use of "protection" that I am
familiar with. Perhaps "guaranteed" or "enabled"?
Figure 4
The key does not explain NotifyU

Magnus Westerlund (was No Objection, Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

Comment (2009-05-21 for -)
No email
send info
I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network). 

I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail. 

I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.

(Gonzalo Camarillo) (was Discuss) No Objection

(Ralph Droms) No Objection

Comment (2009-05-19 for -)
No email
send info
Is the problem described in this text from section 3 a new problem introduced by RSVP receiver proxies:

   While the sender could infer reservation failure from the fact that
   it has not received a Resv message after a certain time, there are
   clear benefits in ensuring that the sender gets a prompt, explicit
   notification in case of reservation failure.  This includes faster
   end-user notification at application layer (e.g., busy signal),
   faster application level reaction (e.g., application level
   rerouting), as well as faster release of application-level resources.

(Lisa Dusseault) No Objection

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2009-05-19)
No email
send info
The document currently doesn't discuss how a proxy knows to act as a proxy. It appears that if a proxy as defined in this document is placed in front of a RSVP capable endpoint, that endpoint will cease to be allowed to participate in RSVP with no indication of why. Was that the intent, and if so, shouldn't this be explained in the document?

(Ron Bonica) (was Discuss) Abstain

Comment (2009-05-19 for -)
No email
send info
I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.

For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.

Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.

The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.