Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 5945


Resource Reservation Protocol (RSVP) Proxy Approaches

Part 3 of 3, p. 34 to 50
Prev RFC Part


prevText      Top      Up      ToC       Page 34 
5.  Security Considerations

   In the environments of concern for this document, RSVP messages are
   used to control resource reservations on a segment of the end-to-end
   path of flows.  The general security considerations associated with
   [RFC2205] apply.  To ensure the integrity of the associated
   reservation and admission control mechanisms, the RSVP cryptographic
   authentication mechanisms defined in [RFC2747] and [RFC3097] can be
   used.  Those protect RSVP messages integrity hop-by-hop and provide
   node authentication, thereby protecting against corruption, spoofing
   of RSVP messages, and replay.  [RSVP-SEC-KEY] discusses key types and
   key provisioning methods, as well as their respective applicability
   to RSVP authentication.

   [RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms
   ([RFC4302][RFC4303]) and associated key provisioning methods for
   security protection of RSVP.  This discussion applies to the
   protection of RSVP in the presence of RSVP proxies as defined in this

   A subset of RSVP messages are signaled with the IP router alert
   option ([RFC2113], [RFC2711]).  Based on the current security
   concerns associated with the use of the IP router alert option, the
   applicability of RSVP (and therefore of the RSVP proxy approaches
   discussed in this document) is limited to controlled environments
   (i.e., environments where the security risks associated with the use
   of the IP router alert option are understood and protected against).
   The security aspects and common practices around the use of the
   current IP router alert option, and consequences of using the IP
   router alert option by applications such as RSVP, are discussed in
   detail in [RTR-ALERT].

Top      Up      ToC       Page 35 
   A number of additional security considerations apply to the use of
   RSVP proxies and are discussed below.

   With some RSVP proxy approaches, the RSVP proxy operates autonomously
   inside an RSVP router.  This is the case for the Path-Triggered Proxy
   approaches defined in Section 4.1 and in Section 4.2, for the
   Inspection-Triggered Proxy approach defined in Section 4.3, for the
   STUN-Triggered Proxy approach defined in Section 4.4, and for the
   RSVP-Signaling-Triggered approach defined in Section 4.7.  Proper
   reservation operation assumes that the RSVP proxy can be trusted to
   behave correctly in order to control the RSVP reservation as required
   and expected by the end-systems.  Since the basic RSVP operation
   already assumes a trust model where end-systems trust RSVP nodes to
   appropriately perform RSVP reservations, the use of an RSVP proxy
   that behaves autonomously within an RSVP router is not seen as
   introducing any significant additional security threat or as
   fundamentally modifying the RSVP trust model.

   With some RSVP proxy approaches, the RSVP proxy operates under the
   control of another entity.  This is the case for the
   Application_Entity-Controlled Proxy approach defined in Section 4.5
   and for the Policy_Server-Controlled Proxy approach defined in
   Section 4.6.  This introduces additional security risks since the
   entity controlling the RSVP proxy needs to be trusted for proper
   reservation operation and also introduces additional authentication
   and confidentiality requirements.  The exact mechanisms to establish
   such trust, authentication, and confidentiality are beyond the scope
   of this document, but they may include security mechanisms inside the
   protocol used as the control interface between the RSVP proxy and the
   entity controlling it, as well as security mechanisms for all the
   interfaces involved in the reservation control chain (e.g., inside
   the application signaling protocol between the end-systems and the
   application entity, and, in the case of the Policy_Server-Controlled
   Proxy approach, in the protocol between the application entity and
   the policy server).

   In some situations, the use of RSVP proxy to control reservations on
   behalf of end-systems may actually reduce the security risk (at least
   from the network operator viewpoint).  This could be the case, for
   example, because the routers where the RSVP proxy functionality runs
   are less exposed to tampering than end-systems.  Such a case is
   further discussed in Section 4 of [RFC5946].  This could also be the
   case because the use of RSVP proxy allows localization of RSVP
   operation within the boundaries of a given administrative domain
   (thus easily operating as a controlled environment) while the end-to-
   end flow path spans multiple administrative domains.

Top      Up      ToC       Page 36 
6.  Acknowledgments

   This document benefited from earlier work on the concept of RSVP
   proxy including the one documented by Silvano Gai, Dinesh Dutt,
   Nitsan Elfassy, and Yoram Bernet.  It also benefited from discussions
   with Pratik Bose, Chris Christou, and Michael Davenport.  Tullio
   Loffredo and Massimo Sassi provided the base material for
   Section 4.6.  Thanks to James Polk, Magnus Westerlund, Dan Romascanu,
   Ross Callon, Cullen Jennings, and Jari Arkko for their thorough
   review and comments.

7.  References

7.1.  Normative References

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, September 1997.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [RFC3097]  Braden, R. and L. Zhang, "RSVP Cryptographic
              Authentication -- Updated Message Type Value", RFC 3097,
              April 2001.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

Top      Up      ToC       Page 37 
7.2.  Informative References

   [QOS-MOBILE]    Manner, J., "Provision of Quality of Service in IP-
                   based Mobile Access Networks", Doctoral
                   dissertation, University of Helsinki, 2003,

   [RFC1633]       Braden, B., Clark, D., and S. Shenker, "Integrated
                   Services in the Internet Architecture: an Overview",
                   RFC 1633, June 1994.

   [RFC2113]       Katz, D., "IP Router Alert Option", RFC 2113,
                   February 1997.

   [RFC2326]       Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
                   Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2474]       Nichols, K., Blake, S., Baker, F., and D. Black,
                   "Definition of the Differentiated Services Field (DS
                   Field) in the IPv4 and IPv6 Headers", RFC 2474,
                   December 1998.

   [RFC2711]       Partridge, C. and A. Jackson, "IPv6 Router Alert
                   Option", RFC 2711, October 1999.

   [RFC2872]       Bernet, Y. and R. Pabbati, "Application and Sub
                   Application Identity Policy Element for Use with
                   RSVP", RFC 2872, June 2000.

   [RFC2961]       Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
                   F., and S. Molendini, "RSVP Refresh Overhead
                   Reduction Extensions", RFC 2961, April 2001.

   [RFC3175]       Baker, F., Iturralde, C., Le Faucheur, F., and B.
                   Davie, "Aggregation of RSVP for IPv4 and IPv6
                   Reservations", RFC 3175, September 2001.

   [RFC3261]       Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                   Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                   and E. Schooler, "SIP: Session Initiation Protocol",
                   RFC 3261, June 2002.

   [RFC3312]       Camarillo, G., Marshall, W., and J. Rosenberg,
                   "Integration of Resource Management and Session
                   Initiation Protocol (SIP)", RFC 3312, October 2002.

Top      Up      ToC       Page 38 
   [RFC3550]       Schulzrinne, H., Casner, S., Frederick, R., and V.
                   Jacobson, "RTP: A Transport Protocol for Real-Time
                   Applications", STD 64, RFC 3550, July 2003.

   [RFC3588]       Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                   J. Arkko, "Diameter Base Protocol", RFC 3588,
                   September 2003.

   [RFC3644]       Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and
                   B. Moore, "Policy Quality of Service (QoS)
                   Information Model", RFC 3644, November 2003.

   [RFC4032]       Camarillo, G. and P. Kyzivat, "Update to the Session
                   Initiation Protocol (SIP) Preconditions Framework",
                   RFC 4032, March 2005.

   [RFC4301]       Kent, S. and K. Seo, "Security Architecture for the
                   Internet Protocol", RFC 4301, December 2005.

   [RFC4302]       Kent, S., "IP Authentication Header", RFC 4302,
                   December 2005.

   [RFC4303]       Kent, S., "IP Encapsulating Security Payload (ESP)",
                   RFC 4303, December 2005.

   [RFC4566]       Handley, M., Jacobson, V., and C. Perkins, "SDP:
                   Session Description Protocol", RFC 4566, July 2006.

   [RFC4741]       Enns, R., "NETCONF Configuration Protocol", RFC 4741,
                   December 2006.

   [RFC4860]       Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
                   and M. Davenport, "Generic Aggregate Resource
                   ReSerVation Protocol (RSVP) Reservations", RFC 4860,
                   May 2007.

   [RFC4923]       Baker, F. and P. Bose, "Quality of Service (QoS)
                   Signaling in a Nested Virtual Private Network",
                   RFC 4923, August 2007.

   [RFC5277]       Chisholm, S. and H. Trevino, "NETCONF Event
                   Notifications", RFC 5277, July 2008.

   [RFC5432]       Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
                   Service (QoS) Mechanism Selection in the Session
                   Description Protocol (SDP)", RFC 5432, March 2009.

Top      Up      ToC       Page 39 
   [RFC5853]       Hautakorpi, J., Camarillo, G., Penfield, R.,
                   Hawrylyshen, A., and M. Bhatia, "Requirements from
                   Session Initiation Protocol (SIP) Session Border
                   Control (SBC) Deployments", RFC 5853, April 2010.

   [RFC5866]       Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria,
                   A., and G. Zorn, "Diameter Quality-of-Service
                   Application", RFC 5866, May 2010.

   [RFC5946]       Le Faucheur, F., Manner, J., Narayanan, A., Guillou,
                   A., and H. Malik, "Resource Reservation Protocol
                   (RSVP) Extensions for Path-Triggered RSVP Receiver
                   Proxy", RFC 5946, October 2010.

   [RFC5974]       Manner, J., Karagiannis, G., and A. McDonald, "NSIS
                   Signaling Layer Protocol (NSLP) for Quality-of-
                   Service Signaling", RFC 5974, October 2010.

   [RSVP-SEC-KEY]  Behringer, M. and F. Le Faucheur, "Applicability of
                   Keying Methods for RSVP Security", Work in Progress,
                   June 2009.

   [RTR-ALERT]     Le Faucheur, F., "IP Router Alert Considerations and
                   Usage", Work in Progress, October 2009.

   [W3C]           "World Wide Web Consortium (W3C) - Web Services
                   Architecture", <>.

Top      Up      ToC       Page 40 
Appendix A.  Use Cases for RSVP Proxies

A.1.  RSVP-Based VoD Admission Control in Broadband Aggregation Networks

   As broadband services for residential customers are becoming more and
   more prevalent, next-generation aggregation networks are being
   deployed in order to aggregate traffic from broadband users (whether
   attached via Digital Subscriber Line technology, aka DSL; Fiber To
   The Home/Curb, aka FTTx; Cable; or other broadband access
   technology).  Video on Demand (VoD) services, which may be offered to
   broadband users, present significant capacity planning challenges for
   the aggregation network for a number of reasons.  First, each VoD
   stream requires significant dedicated sustained bandwidth (typically
   2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition
   TV).  Secondly, the VoD codec algorithms are very sensitive to packet
   loss.  Finally, the load resulting from such services is very hard to
   predict (e.g., it can vary quite suddenly with blockbuster titles
   made available as well as with promotional offerings).  As a result,
   transport of VoD streams on the aggregation network usually translate
   into a strong requirement for admission control.  The admission
   control solution protects the quality of established VoD sessions by
   rejecting the additional excessive session attempts during
   unpredictable peaks, during link or node failures, or a combination
   of those factors.

   RSVP can be used in the aggregation network for admission control of
   the VoD sessions.  However, since customer premises equipment such as
   Set Top Boxes (STBs) (which behave as the receiver for VoD streams)
   often do not support RSVP, the last IP hop in the aggregation network
   can behave as an RSVP Receiver Proxy.  This way, RSVP can be used
   between VoD pumps and the last IP hop in the aggregation network to
   perform accurate admission control of VoD streams over the resources
   set aside for VoD in the aggregation network (typically a certain
   percentage of the bandwidth of any link).  As VoD streams are
   unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as
   described in Section 4.1) is all that is required in this use case.

   Figure 14 illustrates operation of RSVP-based admission control of
   VoD sessions in an aggregation network involving RSVP support on the
   VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop
   of the aggregation network.  All the customer premises equipment
   remains RSVP-unaware.

Top      Up      ToC       Page 41 
                         | VoD  SRM    |
                         |             |
                 ////////|             |\\\\\\\\\\\\\\
                /        |-------------|              \
               /                                       \
              /                                         \
             /                                           \
            /                                             \
           /                                               \
      |****|   ***   ***   ***   |********|   |-----|    |---|
      |VoD |---*r*---*r*---*r*---|RSVP    |---|DSLAM|~~~~|STB|--TV
      |Pump|   ***   ***   ***   |Receiver|   |-----|    |---|
      |****|                     |Proxy   |

               <---Aggregation Net----------->



   SRM Session Resource Manager

   ***                       |---|
   *r* regular RSVP          |STB| Set Top Box
   *** router                |---|

   ***> VoD media flow

   ==>  segment of flow path protected by RSVP reservation

   /\   VoD Application-level signaling (e.g., RTSP)

                Figure 14: VoD Use Case with Receiver Proxy

   In the case where the VoD pumps are not RSVP-capable, an
   Application_Entity-Controlled Sender Proxy via the "RSVP over GRE"
   approach (as described in Section 4.5.1) can also be implemented on
   the VoD Controller or Session Resource Manager (SRM) devices
   typically involved in VoD deployments.  Figure 15 illustrates
   operation of RSVP-based admission control of VoD sessions in an
   aggregation network involving such an Application_Entity-Controlled
   Source Proxy combined with an RSVP Receiver Proxy on the last IP hop
   of the aggregation network.  All the customer premises equipment, as
   well as the VoD pumps, remain RSVP-unaware.

Top      Up      ToC       Page 42 
                     ////| VoD  SRM    |\\\\\\\\\\\
                    /    |             |           \
                   /     |     +       |            \
                  /      | RSVP Sender |             \
                 /       |Proxy Control|              \
                /        |-------------|               \
               /        /=/                             \
              /        /=/                               \
             /        /=/                                 \
            /        /=/                                   \
           /        /=/                                     \
      |----|  |******|    ***  ***  |********|  |-----|    |---|
      | VoD|--|RSVP  |----*r*--*r*--|RSVP    |--|DSLAM|~~~~|STB|--TV
      |Pump|  |Sender|    ***  ***  |Receiver|  |-----|    |---|
      |----|  |Proxy |              |Proxy   |
              |******|              |********|

               <---Aggregation Net------------->



   SRM Systems Resource Manager

   ***                       |---|
   *r* regular RSVP          |STB| Set Top Box
   *** router                |---|

   ***> VoD media flow

   ==>  segment of flow path protected by RSVP reservation

   /    VoD Application-level signaling (e.g., RTSP)

   /=/  GRE-tunneled RSVP (Path messages)

                Figure 15: VoD Use Case with Receiver Proxy
                        and SRM-Based Sender Proxy

   The RSVP proxy entities specified in this document play a significant
   role here since they allow immediate deployment of an RSVP-based
   admission control solution for VoD without requiring any upgrade to
   the huge installed base of non-RSVP-capable customer premises
   equipment.  In one mode described above, they also avoid upgrade of
   non-RSVP-capable VoD pumps.  In turn, this means that the benefits of

Top      Up      ToC       Page 43 
   on-path admission control can be offered to VoD services over
   broadband aggregation networks without network or VoD pump upgrade.
   Those include accurate bandwidth accounting regardless of topology
   (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic
   adjustment to any change in topology (such as failure, routing
   change, additional links, etc.).

A.2.  RSVP-Based Voice/Video Connection Admission Control (CAC) in
      Enterprise WAN

   More and more enterprises are migrating their telephony and
   videoconferencing applications onto IP.  When doing so, there is a
   need for retaining admission control capabilities of existing TDM-
   based (Time-Division Multiplexing) systems to ensure the QoS of these
   applications is maintained even when transiting through the
   enterprise's Wide Area Network (WAN).  Since many of the endpoints
   already deployed (such as IP phones or videoconferencing terminals)
   are not RSVP-capable, RSVP proxy approaches are very useful: they
   allow deployment of an RSVP-based admission control solution over the
   WAN without requiring upgrade of the existing terminals.

   A common deployment architecture for such environments relies on the
   Application_Entity-Controlled Proxy approach as defined in
   Section 4.5.  Routers sitting at the edges of the WAN are naturally
   "on-path" for all inter-campus calls (or sessions) and behave as RSVP
   proxies.  The RSVP proxies establish, maintain, and tear down RSVP
   reservations over the WAN segment for the calls (or sessions) under
   the control of the SIP server/proxy.  The SIP server/proxy
   synchronizes the RSVP reservation status with the status of end-to-
   end calls.  For example, the called IP phone will only be instructed
   to play a ring tone if the RSVP reservation over the corresponding
   WAN segment has been successfully established.

   This architecture allowing RSVP-based admission control of voice and
   video on the enterprise WAN is illustrated in Figure 16.

Top      Up      ToC       Page 44 
                   //////////////| SIP     |\\\\\\\\\\\\
                  /              | Server/ |            \
                 /               | Proxy   |             \
                /                |---------|              \
               /                //       \\                \
              /                //         \\                \
             /                //           \\                \
            /                //             \\                \
           /                //               \\                \
      |-----|      |********|   ***   ***   |********|       |-----|
      | IP  |------| Media  |---*r*---*r*---| Media  |-------|IP   |
      |Phone|      | Relay  |   ***   ***   | Relay  |       |Phone|
      |-----|      |  +     |               |    +   |       |-----|
                   | RSVP   |               | RSVP   |
                   | Proxy  |               | Proxy  |
                   |********|               |********|

        <--campus-->                                <--campus-->
           network                                     network


        <*************> <***********************> <**************>


   *r*   Regular RSVP router

   <***> media flow

   <==>  segment of flow path protected by RSVP reservation

   /\    SIP signaling

   //   control interface between the SIP server/proxy and
        RSVP proxy

                 Figure 16: CAC on Enterprise WAN Use Case

A.3.  RSVP Proxies for Mobile Access Networks

   Mobile access networks are increasingly based on IP technology.  This
   implies that, on the network layer, all traffic, both traditional
   data and streamed data like audio or video, is transmitted as

Top      Up      ToC       Page 45 
   packets.  Increasingly popular multimedia applications would benefit
   from better than best-effort service from the network, a forwarding
   service with strict Quality of Service (QoS) with guaranteed minimum
   bandwidth and bounded delay.  Other applications, such as electronic
   commerce, network control and management, and remote-login
   applications, would also benefit from a differentiated treatment.

   The IETF has two main models for providing differentiated treatment
   of packets in routers.  The Integrated Services (IntServ) model
   [RFC1633], together with the Resource Reservation Protocol (RSVP)
   [RFC2205], [RFC2210], [RFC2961] provides per-flow guaranteed end-to-
   end transmission service.  The Differentiated Services (Diffserv)
   framework [RFC2475] provides non-signaled flow differentiation that
   usually provides, but does not guarantee, proper transmission

   However, these architectures have potential weaknesses for deployment
   in Mobile Access Networks.  For example, RSVP requires support from
   both communication endpoints, and the protocol may have potential
   performance issues in mobile environments.  Diffserv can only provide
   statistical guarantees and is not well suited for dynamic

   Let us consider a scenario, where a fixed network correspondent node
   (CN) would be sending a multimedia stream to an end host behind a
   wireless link.  If the correspondent node does not support RSVP, it
   cannot signal its traffic characteristics to the network and request
   specific forwarding services.  Likewise, if the correspondent node is
   not able to mark its traffic with a proper Differentiated Services
   codepoint (DSCP) to trigger service differentiation, the multimedia
   stream will get only best-effort service, which may result in poor
   visual and audio quality in the receiving application.  Even if the
   connecting wired network is over-provisioned, an end host would still
   benefit from local resource reservations, especially in wireless
   access networks, where the bottleneck resource is most probably the
   wireless link.

   RSVP proxies would be a very beneficial solution to this problem.  It
   would allow distinguishing local network reservations from the end-
   to-end reservations.  The end host does not need to know the access
   network topology or the nodes that will reserve the local resources.
   The access network would do resource reservations for both incoming
   and outgoing flows based on certain criteria, e.g., filters based on
   application protocols.  Another option is that the mobile end host
   makes an explicit reservation that identifies the intention, and the
   access network will find the correct local access network node(s) to
   respond to the reservation.  RSVP proxies would, thus, allow resource
   reservation over the segment that is the most likely bottleneck, the

Top      Up      ToC       Page 46 
   wireless link.  If the wireless access network uses a local mobility
   management mechanism, where the IP address of the mobile node does
   not change during handover, RSVP reservations would follow the mobile
   node movement.

A.4.  RSVP Proxies for Reservations in the Presence of IPsec Gateways

   [RFC4923] discusses how resource reservation can be supported end-to-
   end in a nested VPN environment.  At each VPN level, VPN routers
   behave as [RFC4301] security gateways between a plaintext domain and
   a ciphertext domain.  To achieve end-to-end resource reservation, the
   VPN routers process RSVP signaling on the plaintext side, perform
   aggregation of plaintext reservations, and maintain the corresponding
   aggregate RSVP reservations on the ciphertext side.  Each aggregate
   reservation is established on behalf of multiple encrypted end-to-end
   sessions sharing the same ingress and egress VPN routers.  These
   aggregate reservations can be as specified in [RFC3175] or [RFC4860].

   Section 3 of [RFC4923] discusses the necessary data flows within a
   VPN router to achieve the behavior described in the previous
   paragraph.  Two mechanisms are described to achieve such data flows.
   Section 3.1 presents the case where the VPN router carries data
   across the cryptographic boundary.  Section 3.2 discusses the case
   where the VPN router uses a Network Guard.

   Where such mechanisms are not supported by the VPN routers, the
   approach for end-to-end reservations presented in [RFC4923] cannot be
   deployed.  An alternative approach to support resource reservations
   within the ciphertext core is to use the Application_Entity-
   Controlled Proxy approach (as defined in Section 4.5) in the
   following way:

   o  the RSVP proxies are located inside the ciphertext domain and use
      aggregate RSVP reservations.

   o  the application entity exchange application-level signaling with
      the end-systems in the plaintext domain.

   o  the application entity controls the RSVP proxies in the ciphertext
      domain via an RSVP proxy control interface.

   This is illustrated in Figure 17 in the case where the application is
   SIP-based multimedia communications.

Top      Up      ToC       Page 47 
         |-------|                                    |-------|
         |SIP    |///////////////////\\\\\\\\\\\\\\\\\|SIP    |
        /|Server/|                                    |Server/|\
       / |Proxy  |                                    |Proxy  | \
      /  |-------|                                    |-------|  \
     /      ^    \\                                  //   ^       \
    /       ^     \\                                //    ^        \
   /        ^      \\                              //     ^         \
 |***|   |------|  |********|   ***   ***   |********|  |------|   |***|
 | S |---|IPsec |--|  ARSVP |---*r*---*r*---| ARSVP  |--|IPsec |---| R |
 |***|   | GW   |  | Sender |   ***   ***   |Receiver|  | GW   |   |***|
         |------|  |  Proxy |               | Proxy  |  |------|
                   |********|               |********|

     ***PT*****> **********************CT****************> ****PT***>

     =====>                                                   =====>

 |****| RSVP-capable      |****| RSVP-capable         ***
 | S  | Sender            | R  | Receiver             *r* regular RSVP
 |****|                   |****|                      *** router

 |IPsec | IPsec security gateway
 | GW   |

 ARSVP Aggregate RSVP

 ***>  media flow

 ==>   segment of flow path protected by RSVP reservation

 / \   SIP signaling

  ^    Network management interface between SIP server/proxy
       and IPsec security gateway

 //    control interface between SIP server/proxy and ARSVP proxy

 PT    Plaintext network

 CT    Ciphertext network

        Figure 17: RSVP Proxies for Reservations in the Presence of
                              IPsec Gateways

Top      Up      ToC       Page 48 
   Where the sender and receiver are RSVP-capable, they may also use
   RSVP signaling.  This achieves resource reservation on the plaintext
   segments of the end-to-end, i.e.,

   o  from the sender to the ingress IPsec gateway, and

   o  from the egress IPsec gateway to the receiver.

   In this use case, because the VPN routers do not support any RSVP-
   specific mechanism, the end-to-end RSVP signaling is effectively
   hidden by the IPsec gateways on the ciphertext segment of the end-to-
   end path.

   As with the Application_Entity-Controlled Proxy approach (defined in
   Section 4.5), the solution here for synchronizing RSVP signaling with
   application-level signaling is to rely on an application-level
   signaling device that controls an on-path RSVP proxy function.
   However, in this use case, the RSVP proxies are a component of a
   ciphertext network where all user (bearer) traffic is IPsec
   encrypted.  This has a number of implications, including the

   1.  encrypted flows cannot be identified in the ciphertext domain so
       that network nodes can only classify traffic based on IP address
       and Differentiated Services codepoints (DSCPs).  As a result,
       only aggregate RSVP reservations (such as those specified in
       [RFC3175] or [RFC4860]) can be used.  This is similar to

   2.  Determining the RSVP Sender Proxy and RSVP Receiver Proxy to be
       used for aggregation of a given flow from sender to receiver
       creates a number of challenges.  Details on how this may be
       achieved are beyond the scope of this document.  We observe that,
       as illustrated in Figure 17, this may be facilitated by a network
       management interface between the application entity and the IPsec
       gateways.  For example, this interface may be used by the
       application entity to obtain information about which IPsec
       gateway is on the path of a given end-to-end flow.  Then, the
       application entity may maintain awareness of which RSVP proxy is
       on the ciphertext path between a given pair of IPsec gateways.
       How such awareness is achieved is beyond the scope of this
       document.  We simply observe that such awareness can be easily
       achieved through simple configuration in the particular case
       where a single (physical or logical) RSVP proxy is fronting a
       given IPsec gateway.  We also observe that when awareness of the
       RSVP Receiver Proxy for a particular egress IPsec gateway (or

Top      Up      ToC       Page 49 
       end-to-end flow) is not available, the aggregate reservation may
       be signaled by the RSVP Sender Proxy to the destination address
       of the egress IPsec gateway and then proxied by the RSVP Receiver

   Different flavors of operations are possible in terms of aggregate
   reservation sizing.  For example, the application entity can initiate
   an aggregate reservation of fixed size a priori and then simply keep
   count of the bandwidth used by sessions and reject sessions that
   would result in excess usage of an aggregate reservation.  The
   application entity could also re-size the aggregate reservations on a
   session-by-session basis.  Alternatively, the application entity
   could re-size the aggregate reservations in step increments typically
   corresponding to the bandwidth requirement of multiple sessions.

Top      Up      ToC       Page 50 
Authors' Addresses

   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410

   Phone: +33 4 97 23 26 19

   Jukka Manner
   Aalto University
   Department of Communications and Networking (Comnet)
   P.O. Box 13000
   FIN-00076 Aalto

   Phone: +358 9 470 22481

   Dan Wing
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   United States


   Allan Guillou
   40-42 Quai du Point du Jour
   Boulogne-Billancourt  92659