Subject: Re: [Tsvwg] RSVP proxy approaches

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 5 Jul 2007 15:02:23 +0200

Chris, Fred, Pratik and all,

Please see below:

On 19 Jun 2007, at 20:40, Christou, Christos wrote:

> Francois,
>
> Yes, I do think this works.
>
> Thanks,
>
> Chris
>
> From: Francois Le Faucheur IMAP [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2007 11:22 AM
> To: Christou, Christos
> Cc: Francois Le Faucheur IMAP; [email-masked]
> Subject: Re: [Tsvwg] RSVP proxy approaches
>
> Chris and all,
>
> I'm started editing rsvp-proxy-approaches to reflect all discussed  
> changes.
>
> Regarding the input below, I would propose that we incorporate it  
> as a new section under Appendix A (eg "A.5 RSVP-based Voice/Video  
> CAC in IPsec environments"). This seems reasonable since:
> * Appendix A is dedicated to describing use cases for the RSVP  
> Proxy approaches described in the main sections of the I-D .
> * the fundamental approach used in this scenario is already  
> described in the main sections of the I-D. The text below focuses  
> on some details specific to when the approach is used in the  
> presence of IPsec.
>

Below is the text I put together for the new Appendix A.5.
I added material to explain how this relates to [I-D.ietf-tsvwg-vpn- 
signaled-preemption].
If you want to send comments/suggestions by the end of today I could  
address those before posting.
Francois

A.5.  RSVP Proxies for Reservations in the presence of IPsec Gateways

    [I-D.ietf-tsvwg-vpn-signaled-preemption] 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 cyphertext 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
    cyphertext 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 [I-D.ietf-tsvwg-vpn-signaled-preemption] 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 reservation presented in
    [I-D.ietf-tsvwg-vpn-signaled-preemption] cannot be deployed.  An
    alternative approach to support resource reservations within the
    cyphertext 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 cyphertext 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  
cyphertext
       domain via an RSVP Proxy control interface

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

          |-------|                                    |-------|
          |SIP    |///////////////////\\\\\\\\\\\\\\\\\|SIP    |
         /|Server/|                                    |Server/|\
        / |Proxy  |                                    |Proxy  | \
       /  |-------|                                    |-------|  \
      /      ^    \\                                  //   ^       \
     /       ^     \\                                //    ^        \
    /        ^      \\                              //     ^         \
|---|   |------|  |--------|   ***   ***   |--------|  |------|   |---|
| S |---|IPsec |--|  ARSVP |---*r*---*r*---| ARSVP  |--|IPsec |---| R |
|---|   | GW   |  | Sender |   ***   ***   |Receiver|  | GW   |   |---|
         |------|  |  Proxy |               | Proxy  |  |------|
                   |--------|               |--------|

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

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

                             =====ARSVP======>

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

|------|
|IPsec | IPsec 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 device

//    control interface between SIP Server/Proxy and ARSVP Proxy

PT    Plaintext network

CT    Cyphertext network

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

    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 cyphertext 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 the present use case, the RSVP Proxies are a  
component of
    a cyphertext network where all user (bearer) traffic is IPsec
    encrypted.  This has a number of implications including the
    following:

    1.  encrypted flows can not be identified in the cyphertext  
domain so
        that network nodes can only classify traffic based on IP address
        and DiffServ Code Points (DSCPs).  As a result, only aggregate
        RSVP reservations (such as those specified in [RFC3175] or
        [RFC4860] ) can be used.  This is similar to
        [I-D.ietf-tsvwg-vpn-signaled-preemption].

    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 cyphertext 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) Proxy device is fronting a
        given IPsec gateway.  We also observe that when awareness of the
        RSVP Receiver Proxy for a particular egress IPsec gateway (or
        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
        Proxy.

    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.