Resource Reservation Protocol (RSVP) Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-09

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

The example in A.3 seems really confused about how SBC work.

As I am sure the authors of this draft are aware, the example in A.5 was something the SIP WG had more than one strong hum on this was not an appropriate use of SIP.

[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.

How does one migrate out proxy RSVP to end to end RSVP?

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.


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?

The example in A.3 seems really confused about how SBC work.

As I am sure the authors of this draft are aware, the example in A.5 was something the SIP WG had more than one strong hum on this was not an appropriate use of SIP.

[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]
In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater for notification of the sender of the reservation failure."  It's not clear to me why the sender needs to be notified of reservation failure.  Is this addressing a problem with RSVP generally or just RSVP Receiver Proxy?  I speculate that the problem here may be that the Proxy receives the ResvErr, so neither the application receiver nor the sender is explicitly notified of the reservation failure; do I have that right?  Would someone more familiar with RSVP than I am be able to deduce the reason for sender notification?  I'm happy to be educated as I'm not well-versed in RSVP.

Nit: "cater for" might read better as "cater to" or "provide for"

[Ballot comment]
In Section 4.5:

  Candidate protocols for realizing such interface
  include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the
  Extensible Markup Language (XML) and DIAMETER ([RFC3588]). 

SNMP is seldom used for configuration purposes over the Internet in real life. COPS-PR has very little reported deployment if at all. XML is manguage to present information and not a protocol.

I suggest to take out XML, and to consider whether SNMP and COPS-PR should be left in the text. On the other hand I believe that it would be appropriate to mention here NETCONF (RFC 4741) which is a protocol that uses XML-encoding for performing configuration management operations on network devices.

[Ballot discuss]
I am not against publishing these specifications (and I guess
even the authors see them as necessary evil in comparison to the
end-to-end RSVP model). However, I think the documents should
describe more clearly their implications and limitations. A
Surgeon General's Warning if you will.

I'll note that I am not an RSVP expert. I may have missed something.
In that case, please educate me and I'll clear this Discuss.

In particular, Section 4.1 says:

  In order to build the Resv message, the RSVP Receiver Proxy can take
  into account information received in the Path message.  For example,
  the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv
  message which mirrors the SENDER_TSPEC object in the received Path
  message.

RSVP has separate flow reservations for the two directions, and
just copying the flow spec from one direction to another is
a severely limited approach. Or perhaps even a potentially harmful
approach. For instance, in any streaming or IPTV situation this
approach would clearly lead to problems. One could ask how well the
network works (a) with the proxy QoS reservations or (b) without any
reservations. The ability to make the reservations allows bandwidth
to be reserved, and increases the likelihood of, say, successful
video transmission. However, the guessing involved in the mirroring
process leads to incorrect reservations. For instance, the user's DSL
link might have 24 megabits downlink and 1 megabit uplink capacity.
Without any reservations a 10 megabits/s stream can easily be downloaded.
But with proxy reservations, the system would report a conclusive
error that the capacity is insufficient. Compare this to the situation
where you would just not answer the RSVP messages and the sender would
attempt best effort service.

The application triggered mechanisms have a better chance of a
successful outcome, but they imply fairly severe involvement in the
application signaling process, such as the introduction of a b2bua.
What's the likelihood of a b2bua on the signaling path disrupting
your intended communication setup? I'd claim its a non-zero probability...

I would suggest that Section 4.1 needs to include additional text to
document the problems associated with mirroring. Also, the introduction
should provide stronger guidance on the overall benefits vs.
disadvantages associated with the proxies, and suggest that the proxies
only be setup for very specific networks, applications, and flows to
specific destinations.

[Ballot discuss]
I am not against publishing these specifications (and I guess
even the authors see them as necessary evil in comparison to the
end-to-end RSVP model). However, I think the documents should
describe more clearly their implications and limitations. A
Surgeon General's Warning if you will.

I'll note that I am not an RSVP expert. I may have missed something.
In that case, please educate me and I'll clear this Discuss.

In particular, Section 4.1 says:

  In order to build the Resv message, the RSVP Receiver Proxy can take
  into account information received in the Path message.  For example,
  the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv
  message which mirrors the SENDER_TSPEC object in the received Path
  message.

RSVP has separate flow reservations for the two directions, and
just copying the flow spec from one direction to another is
a severely limited approach. Or perhaps even a potentially harmful
approach. For instance, in any streaming or IPTV situation this
approach would clearly lead to problems. One could ask how well the
network works (a) with the proxy QoS reservations or (b) without any
reservations. The ability to make the reservations allows bandwidth
to be reserved, and increases the likelihood of, say, successful
video transmission. However, the guessing involved in the mirroring
process leads to incorrect reservations. For instance, the user's DSL
link might have 24 megabits downlink and 1 megabit uplink capacity.
Without any reservations a 10 megabits/s stream can easily be downloaded.
But with proxy reservations, the system would report a conclusive
error that the capacity is insufficient. Compare this to the situation
where you would just not answer the RSVP messages and the sender would
attempt best effort service.

The application triggered mechanisms have a better chance of a
successful outcome, but they imply fairly severe involvement in the
application signaling process, such as the introduction of a b2bua.
What's the likelihood of a b2bua on the signaling path disrupting
your intended communication setup? I'd claim its a non-zero probabilit...

I would suggest that Section 4.1 needs to include additional text to
document the problems associated with mirroring. Also, the introduction
should provide stronger guidance on the overall benefits vs.
disadvantages associated with the proxies, and suggest that the proxies
only be setup for very specific networks, applications, and flows to
specific destinations.

[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 comment]
section 1:

"presents several fundamental RSVP proxy approaches insisting on how ..."

I don't think "insisting" is the right word here!

section 4.4:
s/cortresponding/corresponding/
s/implicitely/implicitly/

[Ballot discuss]
Two issues: number one is actionable, the second is a discuss-discuss...

Issue #1:
The security considerations do a nice job highlighting the issues introduced by proxies, but
more detail is needed with respect to RSVP proxies that operate under control of another
entity (Para 4).  These models introduce new security requirements for communication between
the proxy and the controlling entity that are outside the scope of RSVP or this document.
Specifically, these models introduce authentication and confidentiality requirements to protect
against a variety of attacks.  The current text indicates the controlling entity needs to be
trusted, which is also true, but is insufficient.

Issue #2:
(Section 1, Introduction)  What are the consequences of violating the topological constraints
and having two Receiver Proxies on path?  It seems that RSVP would not be used to its
fullest, and the resource reservation would cover less of the path than it could, but this
seems to be sub-optimal rather than broken.

I also wonder whether this merits discussion in the security considerations... perhaps that will
become clear as we discuss the consequences of violating the topological constraints.

[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 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]
4.3.  Inspection-Triggered Proxy

[...]

  Note however, that in case of reservation failure, the inspection-
  triggered RSVP Proxy does not have a direct mechanism for notifying
  the application (since it is not participating itself actively in
  application signaling) so that the application is not in a position
  to take appropriate action (for example terminate the corresponding
  session).  To mitigate this problem, the inspection-triggered RSVP
  Proxy may mark differently the DSCP of flows for which an RSVP

The first use of the DSCP acronym should be expanded.


I am also agreeing with Adrian's comment, I was wondering about this myself.

[Ballot comment]
4.3.  Inspection-Triggered Proxy

[...]

  Note however, that in case of reservation failure, the inspection-
  triggered RSVP Proxy does not have a direct mechanism for notifying
  the application (since it is not participating itself actively in
  application signaling) so that the application is not in a position
  to take appropriate action (for example terminate the corresponding
  session).  To mitigate this problem, the inspection-triggered RSVP
  Proxy may mark differently the DSCP of flows for which an RSVP

The first use of the DSCP acronym should be expanded.

[Ballot comment]
Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor
misses them.

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?
---

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.