Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-11

[Ballot discuss]
I am picking up Cullen's discusses on draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt and draft-ietf-tsvwg-rsvp-proxy-proto-11

Discuss (2010-03-22)

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?

[Ballot discuss]
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?

[Ballot discuss]
As currently defined the deployment of RSVP porxy will prevent end-to-end to work as long as the proxy is in place. To me the damage this extension will cause to regular RSVP and the current model is just to great too allow publication until their is a better co-existence story in place.

[Ballot discuss]
I have placed all my issues for this spec into the discuss for proxy-approaches as it seemed better to have them in one place. Once we resolve theses, we can figure out what to do here. I would expect for important things like deployment applicability, for theses to occur in this specification and not just by reference to an informational document.

[Ballot discuss]
I have placed all my issues for this spec into the discuss for proxy-approaches as it seemed better to have them in one place. Once we resolve theses, we can figure out what to do here. I would expect for important things like deployment applicability, for theses to occur in this specification and not just by reference to an informational document.

[Ballot comment]
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.

[Ballot comment]
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 of course 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.

[Ballot discuss]
The specification implies that use of these extensions is restricted to Receiver Proxies, but as I
understand it, the sender has no way to determine whether they are performing end-to-end
RSVP or communicating with a proxy.  If a Regular RSVP Receiver implemented sender
notification, what are the consequences (if any)?

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
Is the problem described in this text from section 3 a new problem introducted 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.

[Ballot discuss]
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?

[Ballot discuss]
At this point, this is a DISCUSS DISCUSS.

I we were to massively deploy RSVP proxies, would that cause a massive increase in the amount of RAO traffic arriving at provider boundaries? Would that traffic be dropped? If not, could it cause problems for provider equipment?

[Ballot comment]
draft-ietf-tsvwg-rsvp-proxy-proto-08.txt

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
s/Qos/QoS/
---
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
===

[Ballot comment]
draft-ietf-tsvwg-rsvp-proxy-proto-08.txt

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
s/Qos/QoS/
---
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
===

draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt
---
I am surprised that all of your references are Informative. Surely some of these are prerequisites for understanding your work?
---

[Ballot comment]
draft-ietf-tsvwg-rsvp-proxy-proto-08.txt

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
s/Qos/QoS/
---
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
---

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
changes in the "Error Codes and Globally-Defined Error Value
Sub-Codes"registry at
http://www.iana.org/assignments/rsvp-parameters

OLD:

Error Code Meaning

1 Admission Control Failure [RFC2205]

...

2 Policy Control Failure [RFC2205]

NEW:

Error Code Meaning

1 Admission Control Failure
[RFC2205][RFC-tsvwg-rsvp-proxy-proto-07]

...

2 Policy Control Failure
[RFC2205][RFC-tsvwg-rsvp-proxy-proto-07]



Action 2:

Upon approval of this document, the IANA will make the following
assignment in the "Error Codes and Globally-Defined Error Value
Sub-Codes" registry at
http://www.iana.org/assignments/rsvp-parameters

Error Code Meaning

[TBD] Unrecoverable Receiver Proxy Error [RFC-tsvwg-rsvp-proxy-proto-07]

The sixteen bits of the Error Value field are defined in
[RFC-tsvwg-rsvp-proxy-proto-07]


We understand the above to be the only IANA Actions for this document.

This is writeup for the two documents:
draft-ietf-tsvwg-rsvp-proxy-proto (proposed standard)
draft-ietf-tsvwg-rsvp-proxy-approaches (informational)

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
         
Magnus Westerlund is the Document shepherd. The AD review made it
clear some improvements where needed.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?
         
It has received reasonable review from the RSVP interested folks. I
think the document could have benefitted from more wide review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?
         
I think the operational aspects may require more review.         

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
       
I hope by clarifying the AD review comments these concerns will be removed.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
         
Strong consensus from a couple of individuals.         

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
         
No         

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Yes, there is one downref needed to be take care of.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
         
Yes, one downref that can be changed to informational ref.         

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?
         
Yes, protos IANA seems okay.         

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
         
No formal language used.         

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
                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.
               
                The Proto document defines the RSVP extensions that are
                needed to facilitate operations with an RSVP Receiver
                Proxy whose signaling is triggered by receipt of RSVP
                Path messages from the sender. 

          Working Group Summary
            The consensus for the publication was strong but from a
            small group within the WG.

          Document Quality
            The shepherd doesn't know of any implementations.
           
          Personnel
            WG Shepherd and responsible AD is Magnus Westerlund.