draft-ietf-tsvwg-vpn-signaled-preemption-02.txt   rfc4923.txt 
Transport Working Group F. Baker Network Working Group F. Baker
Internet-Draft Cisco Systems Request for Comments: 4923 Cisco Systems
Intended status: Informational P. Bose Category: Informational P. Bose
Expires: August 6, 2007 Lockheed Martin Lockheed Martin
February 2, 2007 August 2007
QoS Signaling in a Nested Virtual Private Network Quality of Service (QoS) Signaling in a Nested Virtual Private Network
draft-ietf-tsvwg-vpn-signaled-preemption-02
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This memo provides information for the Internet community. It does
applicable patent or other IPR claims of which he or she is aware not specify an Internet standard of any kind. Distribution of this
have been or will be disclosed, and any of which he or she becomes memo is unlimited.
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Some networks require communication between an interior and exterior Some networks require communication between an interior and exterior
portion of a VPN or through a concatenation of such networks portion of a Virtual Private Network (VPN) or through a concatenation
resulting in a nested VPN, but have sensitivities about what of such networks resulting in a nested VPN, but have sensitivities
information is communicated across the boundary, especially while about what information is communicated across the boundary,
providing quality of service to communications with different especially while providing quality of service to communications with
precedence. This note seeks to outline the issues and the nature of different precedence. This note seeks to outline the issues and the
the proposed solutions based on the framework for Integrated Services nature of the proposed solutions based on the framework for
operation over DiffServ networks as described in RFC 2998 . Integrated Services operation over Diffserv networks as described in
RFC 2998.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement ..........................................3
1.2. Background Information and Terminology . . . . . . . . . . 4 1.2. Background Information and Terminology .....................4
1.3. Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Nested VPNs ................................................5
1.4. Signaled QoS technology . . . . . . . . . . . . . . . . . 7 1.4. Signaled QoS Technology ....................................7
1.5. The Resource Reservation Protocol (RSVP) . . . . . . . . . 8 1.5. The Resource Reservation Protocol (RSVP) ...................9
1.6. Logical structure of a VPN Router . . . . . . . . . . . . 10 1.6. Logical Structure of a VPN Router .........................10
2. Reservation and Preemption in a Nested VPN .....................13
2. Reservation and Preemption in a nested VPN . . . . . . . . . . 13 2.1. Reservation in a Nested VPN ...............................14
2.1. Reservation in a nested VPN . . . . . . . . . . . . . . . 14 2.2. Preemption in a Nested VPN ................................16
2.2. Preemption in a nested VPN . . . . . . . . . . . . . . . . 16 2.3. Working through an Example ................................17
2.3. Working through an example . . . . . . . . . . . . . . . . 17 2.3.1. Initial Routine Reservations - Generating
2.3.1. Initial routine reservations - generating network Network State ......................................18
state . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.2. Initial Routine Reservations - Request
2.3.2. Initial routine reservations - request reservation . . 19 Reservation ........................................19
2.3.3. Installation of a reservation using precedence . . . . 20 2.3.3. Installation of a Reservation Using Precedence .....20
2.3.4. Installation of a reservation using preemption . . . . 21 2.3.4. Installation of a Reservation Using Preemption .....21
3. Data Flows within a VPN Router .................................24
3. Data flows within a VPN Router . . . . . . . . . . . . . . . . 24 3.1. VPN Routers That Carry Data across the
3.1. VPN Routers that carry data across the cryptographic Cryptographic Boundary ....................................24
boundary . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.1. Plaintext to Ciphertext Data Flows .................24
3.1.1. Plaintext to Ciphertext Data Flows . . . . . . . . . . 24 3.1.2. Ciphertext to Plaintext Data Flows .................27
3.1.2. Ciphertext to Plaintext Data Flows . . . . . . . . . . 26 3.2. VPN Routers That Use the Network Guard for
3.2. VPN Routers that use the Network Guard for signaling Signaling across the Cryptographic Boundary ...............28
across the cryptographic boundary . . . . . . . . . . . . 27 3.2.1. Signaling Flow .....................................29
3.2.1. Signaling Flow . . . . . . . . . . . . . . . . . . . . 28 3.2.2. Use Case with Network Guard ........................30
3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 4. Security Considerations ........................................33
5. Acknowledgements ...............................................34
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 6. References .....................................................34
6.1. Normative References ......................................34
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6.2. Informative References ....................................35
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
1.1. Problem Statement 1.1. Problem Statement
More and more networks wish to guarantee secure transmission of IP More and more networks wish to guarantee secure transmission of IP
traffic across public LANs or WANs and therefore use Virtual Private traffic across public LANs or WANs and therefore use Virtual Private
Networks. Some networks require communication between an interior Networks. Some networks require communication between an interior
and exterior portion of a VPN or through a concatenation of such and exterior portion of a VPN or through a concatenation of such
networks resulting in a nested VPN, but have sensitivities about what networks resulting in a nested VPN, but have sensitivities about what
information is communicated across the boundary, especially while information is communicated across the boundary, especially while
providing quality of service to communications with different providing quality of service to communications with different
precedence. This note seeks to outline the issues and the nature of precedence. This note seeks to outline the issues and the nature of
the proposed solutions. The outline of the QoS solution for real- the proposed solutions. The outline of the QoS solution for real-
time traffic has been described at a high level in [RFC4542]. The time traffic has been described at a high level in [RFC4542]. The
key characteristics of this proposal are that key characteristics of this proposal are that
o it uses standardized protocols, o it uses standardized protocols,
o It includes reservation setup and teardown for guaranteed and o it includes reservation setup and teardown for guaranteed and
controlled load services using the standardized protocols, controlled load services using the standardized protocols,
o it is independent of link delay, and therefore consistent with o it is independent of link delay, and therefore consistent with
high delay*bandwidth networks as well as the more common variety, high delay*bandwidth networks as well as the more common variety,
o it has no single point of failure, such as a central reservation o it has no single point of failure, such as a central reservation
manager, manager,
o It provides for the preemption of established data flows, o it provides for the preemption of established data flows,
o In that preemption, it not only permits a policy-admitted data o in that preemption, it not only permits a policy-admitted data
flow in, but selects a specific data flow to exclude based upon flow in, but selects a specific data flow to exclude based upon
control input rather than simply accepting a loss of service control input rather than simply accepting a loss of service
dictated at the discretion of the network control function, and dictated at the discretion of the network control function, and
o interoperates directly with SIP Proxies, H.323 Gatekeepers, or o it interoperates directly with SIP Proxies, H.323 Gatekeepers, or
other call management subsystems to present the other services other call management subsystems to present the other services
required in a preemptive or preferential telephone network. required in a preemptive or preferential telephone network.
The thrust of the memo surrounds VPNs that use encryption in some The thrust of the memo surrounds VPNs that use encryption in some
form, such as IPsec and their subsequent nesting across multiple form, such as IPsec and their subsequent nesting across multiple
network domains. This specific type of VPNs is further clarified in network domains. This specific type of VPNs is further clarified in
Section 1.3 which describes the nested VPN as an example of an IPsec Section 1.3, which describes the nested VPN as an example of an IPsec
or IPsec like VPN under the context of a 'customer provisioned' VPN. or IPsec like VPN under the context of a 'customer provisioned' VPN.
As a result, we will discuss the VPN Router supporting "plaintext" As a result, we will discuss the VPN router supporting "plaintext"
and "ciphertext" interfaces. However, the concept extends readily to and "ciphertext" interfaces. However, the concept extends readily to
any form of aggregation, including the concept proposed in [RFC3175] any form of aggregation, including the concept proposed in [RFC3175]
of the IP traffic entering and leaving a network at identified of the IP traffic entering and leaving a network at identified
points, and the use of other kinds of tunnels including GRE, IP/IP, points, and the use of other kinds of tunnels including Generic
MPLS, and so on. Routing Encapsulation (GRE), IP/IP, MPLS, and so on.
1.2. Background Information and Terminology 1.2. Background Information and Terminology
A note on the use of the words "priority" and "precedence" in this A note on the use of the words "priority" and "precedence" in this
document is in order. The term "priority" has been used in this document is in order. The term "priority" has been used in this
context with a variety of meanings, resulting in a great deal of context with a variety of meanings, resulting in a great deal of
confusion. The term "priority" is used in this document to identify confusion. The term "priority" is used in this document to identify
one of several possible datagram scheduling algorithms. A scheduler one of several possible datagram scheduling algorithms. A scheduler
is used when deciding which datagram will be sent next on a computer is used when deciding which datagram will be sent next on a computer
interface; a priority scheduler always chooses a datagram from the interface; a priority scheduler always chooses a datagram from the
highest priority class (queue) that is occupied, shielding one class highest priority class (queue) that is occupied, shielding one class
of traffic from most of the jitter by passing jitter it would of traffic from most of the jitter by passing jitter it would
otherwise have experienced to another class. [RFC3181] applies the otherwise have experienced to another class. [RFC3181] applies the
term to a reservation, in a sense that this document will refer to as term to a reservation, in a sense that this document will refer to as
"precedence". The term "precedence" is used in the sense implied in "precedence". The term "precedence" is used in the sense implied in
the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ; the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ;
some classes of sessions take precedence over others, which may some classes of sessions take precedence over others, which may
result in bandwidth being admitted that might not otherwise have been result in bandwidth being admitted that might not otherwise have been
or may result in the prejudicial termination of a lower precedence or may result in the prejudicial termination of a lower-precedence
session under a stated set of circumstances. For the purposes of the session under a stated set of circumstances. For the purposes of the
present discussion, "priority" is a set of algorithms applied to present discussion, "priority" is a set of algorithms applied to
datagrams, where "precedence" is a policy attribute of sessions. The datagrams, where "precedence" is a policy attribute of sessions. The
techniques of priority comparisons are used in a router or a policy techniques of priority comparisons are used in a router or a policy
decision point to implement precedence, but they are not the same decision point to implement precedence, but they are not the same
thing. thing.
Along the same lines, it is important for the reader to understand Along the same lines, it is important for the reader to understand
the difference between QoS policies and policies based on the the difference between QoS policies and policies based on the
"precedence" or "importance" of data to the person or function using "precedence" or "importance" of data to the person or function using
skipping to change at page 5, line 15 skipping to change at page 5, line 16
than it would be if datagrams had to be retransmitted, and this is than it would be if datagrams had to be retransmitted, and this is
true regardless of whether the call is routine or of high precedence. true regardless of whether the call is routine or of high precedence.
As such, QoS markings tell us how to provide good service to an As such, QoS markings tell us how to provide good service to an
application independent of how "important" it may be at the current application independent of how "important" it may be at the current
time, while "importance" can be conveyed separately in many cases. time, while "importance" can be conveyed separately in many cases.
1.3. Nested VPNs 1.3. Nested VPNs
One could describe a nested VPN network in terms of three network One could describe a nested VPN network in terms of three network
diagrams. Figure 1 shows a simple network stretched across a VPN diagrams. Figure 1 shows a simple network stretched across a VPN
connection. The VPN Router (where, following [RFC2460] a "router" is connection. The VPN router (where, following [RFC2460], a "router"
"a node that forwards packets not explicitly addressed to itself"), is "a node that forwards packets not explicitly addressed to
performs the following steps: it itself"), performs the following steps:
o receives an IP datagram from a plain text interface, o receives an IP datagram from a plain text interface,
o determines what remote enclave and therefore other VPN Router to o determines what remote enclave and therefore other VPN router to
forward it to, forward it to,
o ensures that it has a tunnel mode security association (as o ensures that it has a tunnel mode security association (as
generally defined in [RFC2401] section 4) with that router, generally defined in [RFC4301], Section 4) with that router,
o encloses the encrypted datagram within another VPN (e.g. IPsec) o encloses the encrypted datagram within another VPN (e.g., IPsec)
and IP header, and and IP header, and
o forwards the encapsulated datagram toward the remote VPN Router. o forwards the encapsulated datagram toward the remote VPN router.
The receiving VPN Router reverses the steps: it The receiving VPN router reverses the steps:
o determines what security association the datagram was received o determines what security association the datagram was received
from, from,
o decrypts the interior datagram, o decrypts the interior datagram,
o forwards the now-decapsulated datagram on a plain text interface. o forwards the now-decapsulated datagram on a plain text interface.
The use of IPsec in this manner is described as the tunnel mode of The use of IPsec in this manner is described as the tunnel mode of
[RFC2401] and [RFC4303]. [RFC4301] and [RFC4303].
Host Host Host Host Host Host Host Host Host Host Host Host
/------------------/ /------------------/ /------------------/ /------------------/
Router -------Router Router -------Router
| |
VPN-Router VPN-Router
|| ||
|| IPsec Tunnel through routed network || IPsec Tunnel through routed network
|| ||
VPN-Router VPN-Router
| |
Router -------Router Router -------Router
/------------------/ /------------------/ /------------------/ /------------------/
Host Host Host Host Host Host Host Host Host Host Host Host
Figure 1: VPN-connected enclave Figure 1: VPN-Connected Enclave
An important point to understand is that the VPN tunnel, like other An important point to understand is that the VPN tunnel, like other
features of the routed network, are invisible to the host. The host features of the routed network, are invisible to the host. The host
can infer that "something out there" is affecting the Path MTU, can infer that "something out there" is affecting the Path MTU,
introducing delay, or otherwise affecting its data stream, but if introducing delay, or otherwise affecting its data stream, but if
properly implemented it should be able to adapt to these. The words properly implemented, it should be able to adapt to these. The words
"if properly implemented" are the bane of every network manager, "if properly implemented" are the bane of every network manager,
however; substandard implementations do demonstrably exist. however; substandard implementations do demonstrably exist.
Outside of the enclave, the hosts are essentially invisible. The Outside of the enclave, the hosts are essentially invisible. The
communicating enclaves look like a simple data exchange between peer communicating enclaves look like a simple data exchange between peer
hosts across a routed network, as shown in Figure 2. hosts across a routed network, as shown in Figure 2.
Hosts Not Visible Hosts Not Visible
/==================/ /==================/
Router Router
skipping to change at page 6, line 47 skipping to change at page 6, line 47
VPN-Router VPN-Router
/---------------------/ /---------------------/
Inner Domain Inner Domain
/---------------------/ /---------------------/
VPN-Router VPN-Router
| |
Router Router
/==================/ /==================/
Hosts Not Visible Hosts Not Visible
Figure 2: VPN-connected enclave from exterior perspective Figure 2: VPN-Connected Enclave from Exterior Perspective
Such networks can be nested and re-used in a complex manner. As Such networks can be nested and re-used in a complex manner. As
shown in Figure 3 a pair of enclaves might communicate across a shown in Figure 3, a pair of enclaves might communicate across a
cipher text network which, for various reasons, is itself re- ciphertext network that, for various reasons, is itself re-encrypted
encrypted and transmitted across a larger cipher text network. The and transmitted across a larger ciphertext network. The reasons for
reasons for doing this vary, but they relate to information-hiding in doing this vary, but they relate to information-hiding in the wider
the wider network, different levels of security required for network, different levels of security required for different enclosed
different enclosed enclaves, and so on. enclaves, and so on.
Host Host Host Host Host Host Host Host Host Host Host Host
/------------------/ /------------------/ /------------------/ /------------------/
Router -------Router Router -------Router
| |
VPN-Router VPN-Router VPN-Router VPN-Router VPN-Router VPN-Router
/---------------------/ /----------/ /---------------------/ /----------/
Router -------------Router Router -------------Router
| |
VPN-Router VPN-Router VPN-Router VPN-Router
skipping to change at page 7, line 38 skipping to change at page 7, line 38
| |
Router -------Router Router -------Router
/------------------/ /------------------/ /------------------/ /------------------/
Host Host Host Host Host Host Host Host Host Host Host Host
Figure 3: Nested VPN Figure 3: Nested VPN
The key question this document explores is "how do reservations, and The key question this document explores is "how do reservations, and
preemption of reservations, work in such an environment?" preemption of reservations, work in such an environment?"
1.4. Signaled QoS technology 1.4. Signaled QoS Technology
The Integrated Services model for networking was originally proposed The Integrated Services model for networking was originally proposed
in [RFC1633]. In short, it divides all applications into two broad in [RFC1633]. In short, it divides all applications into two broad
classes: those that will adapt themselves to any available bandwidth, classes: those that will adapt themselves to any available bandwidth,
and those that will not or cannot. In its own words, and those that will not or cannot. In the words of [RFC1633]:
One class of applications needs the data in each packet by a One class of applications needs the data in each packet by a
certain time and, if the data has not arrived by then, the data certain time and, if the data has not arrived by then, the data
is essentially worthless; we call these "real-time" is essentially worthless; we call these "real-time"
applications. Another class of applications will always wait applications. Another class of applications will always wait
for data to arrive; we call these "elastic" applications. for data to arrive; we call these "elastic" applications.
The Integrated Services model defines data flows supporting The Integrated Services model defines data flows supporting
applications as either "real-time" or "elastic". It should be noted applications as either "real-time" or "elastic". It should be noted
that "real-time" traffic is also referred to as "inelastic" traffic, that "real-time" traffic is also referred to as "inelastic" traffic,
and that elastic traffic is occasionally referred to as "non-real- and that elastic traffic is occasionally referred to as "non-real-
time." time".
In this view, the key issue is the so-called "playback point": a In this view, the key issue is the so-called "playback point": a
real-time application is considered to have a certain point in time real-time application is considered to have a certain point in time
at which data describing the next sound, picture, or whatever to be at which data describing the next sound, picture, or whatever to be
delivered to a display device or forfeit its utility, while an delivered to a display device or forfeit its utility, while an
elastic application has no such boundary. Another way to look at the elastic application has no such boundary. Another way to look at the
difference is that real-time applications have an irreducible lower difference is that real-time applications have an irreducible lower
bound on their bandwidth requirements. For example, the typical bound on their bandwidth requirements. For example, the typical
G.711 payload is delivered in 160 byte samples (plus 40 bytes of IP/ G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/
UDP/RTP headers) at 20 millisecond intervals. This will yield 80 UDP/RTP headers) at 20 millisecond intervals. This will yield 80
KBPS of bandwidth, without silence suppression, and not accounting kbps of bandwidth, without silence suppression, and not accounting
for the layer 2 overhead. To operate in real-time, a G.711 codec for the layer 2 overhead. To operate in real-time, a G.711 codec
requires the network over which its data will be delivered to support requires the network over which its data will be delivered to support
communications at 80 KBPS at the IP layer with roughly constant end communications at 80 kbps at the IP layer with roughly constant end-
to end delay and nominal or no loss. If this is not possible (if to-end delay and nominal or no loss. If this is not possible (if
there is significant loss or wide variations in delay), voice quality there is significant loss or wide variations in delay), voice quality
will suffer. On the other hand, if many megabits of capacity are will suffer. On the other hand, if many megabits of capacity are
available, the G.711 codec will not increase its bandwidth available, the G.711 codec will not increase its bandwidth
requirements either. Although adaptive codecs exist, (e.g., G.722.2 requirements either. Although adaptive codecs exist (e.g., G.722.2
or G.726), the adaptive mechanism can either require greater or or G.726), the adaptive mechanism can either require greater or
lesser bandwidth and can adapt only within a certain range of lesser bandwidth and can adapt only within a certain range of
bandwidth requirements beyond which the quality of the data flow bandwidth requirements beyond which the quality of the data flow
required is not met. Elastic applications, however, will generally required is not met. Elastic applications, however, will generally
adapt themselves to any network: if the bottleneck provides 9600 bits adapt themselves to any network: if the bottleneck provides 9600 bits
per second, a web transfer or electronic mail exchange will happen at per second, a Web transfer or electronic mail exchange will happen at
9600 bits per second, and if hundreds of megabits are available, the 9600 bits per second, and if hundreds of megabits are available, the
TCP (or SCTP) transport will increase their transfer rate in an TCP (or SCTP) transport will increase their transfer rate in an
attempt to reduce the time required to accomplish the transfer. attempt to reduce the time required to accomplish the transfer.
For real-time applications, those that require data to be delivered For real-time applications, those that require data to be delivered
end to end with at least a certain rate and with delays varying end to end with at least a certain rate and with delays varying
between stated bounds, the Integrated Services architecture proposes between stated bounds, the Integrated Services architecture proposes
the use of a signaling protocol that allows the communicating the use of a signaling protocol that allows the communicating
applications and the network to communicate about the application applications and the network to communicate about the application
requirements and the network's capability to deliver them. Several requirements and the network's capability to deliver them. Several
such protocols have been developed or are under development, notably such protocols have been developed or are under development, notably
including RSVP and NSIS. The present discussion is limited to RSVP, including the Resource Reservation Protocol (RSVP) and Next Steps in
Signaling (NSIS). The present discussion is limited to RSVP,
although any protocol that delivers a similar set of capabilities although any protocol that delivers a similar set of capabilities
could be considered. could be considered.
1.5. The Resource Reservation Protocol (RSVP) 1.5. The Resource Reservation Protocol (RSVP)
RSVP is initially defined in [RFC2205] with a set of datagram RSVP is initially defined in [RFC2205] with a set of datagram
processing rules defined in [RFC2209] and datagram details for processing rules defined in [RFC2209] and datagram details for
Integrated Services [RFC2210]. Conceptually, this protocol specifies Integrated Services [RFC2210]. Conceptually, this protocol specifies
a way to identify data flows from a source application to a a way to identify data flows from a source application to a
destination application and request specific resources for them. The destination application and request specific resources for them. The
source may be a single machine or a set of machines listed explicitly source may be a single machine or a set of machines listed explicitly
or implied, whereas the destination may be a single machine or a or implied, whereas the destination may be a single machine or a
multicast group (and therefore all of the machines in it). Each multicast group (and therefore all of the machines in it). Each
application is specified by a transport protocol number in the IP application is specified by a transport protocol number in the IP
protocol field, or may additionally include destination and perhaps protocol field, or may additionally include destination and perhaps
source port numbers. The protocol is defined for both IPv4 [RFC0791] source port numbers. The protocol is defined for both IPv4 [RFC0791]
and IPv6 [RFC2460]. It was recognized immediately that it was also and IPv6 [RFC2460]. It was recognized immediately that it was also
necessary to provide a means to perform the same function for various necessary to provide a means to perform the same function for various
kinds of tunnels, which implies a relationship between what is inside kinds of tunnels, which implies a relationship between what is inside
and what is outside the tunnel. Definitions were therefore developed and what is outside the tunnel. Definitions were therefore developed
for IPsec [RFC2207] and [I-D.ietf-tsvwg-rsvp-ipsec] and for more for IPsec [RFC2207] and [RFC4860] and for more generic forms of
generic forms of tunnels [RFC2746]. With the later development of tunnels [RFC2746]. With the later development of the Differentiated
the Differentiated Services Architecture [RFC2475], definitions were Services Architecture [RFC2475], definitions were added to specify
added to specify the DSCP [RFC2474] to be used by a standard RSVP the Differentiated Services Code Point (DSCP) [RFC2474] to be used by
data flow in [RFC2996] and to use a pair of IP addresses and a DSCP a standard RSVP data flow in [RFC2996] and to use a pair of IP
as the identifying information for a data flow [RFC3175]. addresses and a DSCP as the identifying information for a data flow
[RFC3175].
In addition, the initial definition of the protocol included a In addition, the initial definition of the protocol included a
placeholder for policy information, and for preemption of placeholder for policy information, and for preemption of
reservations. This placeholder was later specified in detail in reservations. This placeholder was later specified in detail in
[RFC2750] with a view to associating a policy [RFC2872] with an [RFC2750] with a view to associating a policy [RFC2872] with an
identity [RFC3182] and thereby enabling the network to provide a identity [RFC3182] and thereby enabling the network to provide a
contracted service to an authenticated and authorized user. This was contracted service to an authenticated and authorized user. This was
integrated with the Session Initiation Protocol [RFC3261] in integrated with the Session Initiation Protocol [RFC3261] in
[RFC3312]. Preemption of a reservation is specified in the context, [RFC3312]. Preemption of a reservation is specified as in [RFC3181]
in [RFC3181] which in essence specifies that a reservation installed -- a reservation that is installed in the network using an Preemption
in the network using an Preemption Priority and retained using a Priority and retained using a separate Defending Priority may be
separate Defending Priority may be removed by the network via an RESV removed by the network via an RESV Error signal that removes the
Error signal that removes the entire reservation. This has issues, entire reservation. This has issues, however, in that the matter is
however, in that the matter is often not quite so black and white. often not quite so black and white. If the issue is that an existing
If the issue is that an existing reservation for 80 KBPS can no reservation for 80 kbps can no longer be sustained but a 60 kbps
longer be sustained but a 60 KBPS reservation could, it is possible reservation could, it is possible that a VoIP sender could change
that a VoIP sender could change from a G.711 codec to a G.729 codec from a G.711 codec to a G.729 codec and achieve that. Or, if there
and achieve that. Or, if there are multiple sessions in a tunnel or are multiple sessions in a tunnel or other aggregate, one of the
other aggregate, one of the calls could be eliminated leaving calls could be eliminated leaving capacity for the others. [RFC4495]
capacity for the others. [RFC4495] seeks to address this issue. seeks to address this issue.
In a similar way, a capability was added to limit the possibility of In a similar way, a capability was added to limit the possibility of
control signals being spoofed or otherwise attacked [RFC2747] control signals being spoofed or otherwise attacked [RFC2747]
[RFC3097]. [RFC3097].
[RFC3175] describes several features that are unusual in RSVP, being [RFC3175] describes several features that are unusual in RSVP, being
specifically set up to handle aggregates in a service provider specifically set up to handle aggregates in a service provider
network. It describes three key components: network. It describes three key components:
o The RFC 3175 session object, which identifies not the IP addresses o The RFC 3175 session object, which identifies not the IP addresses
of the packets that are identified, but the IP addresses of the of the packets that are identified, but the IP addresses of the
ingress and egress devices in the network, and the DSCP that the ingress and egress devices in the network, and the DSCP that the
traffic will use, traffic will use.
o The function of a reservation "aggregator", which operates in the o The function of a reservation "aggregator", which operates in the
ingress router and accepts individual reservations from the ingress router and accepts individual reservations from the
"customer" network which it aggregates into the ISP core in a "customer" network. It aggregates the reservations into the ISP
tunnel, an MPLS LSP, or as a traffic stream that it known to leave core in a tunnel or an MPLS LSP, or as a traffic stream that is
at the deaggregator, known to leave at the deaggregator.
o The function of a reservation "deaggregator", which operates in o The function of a reservation "deaggregator", which operates in
the egress router and breaks the aggregate reservation and data the egress router and breaks the aggregate reservation and data
streams back out into individual data streams that may be passed streams back out into individual data streams that may be passed
to other networks. to other networks.
In retrospect, the Session Object specified by RFC 3175 is useful but In retrospect, the Session Object specified by RFC 3175 is useful but
not intrinsically necessary. If the ISP network uses tunnels, such not intrinsically necessary. If the ISP network uses tunnels, such
as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security
Associations, the concepts of an aggregator and a deaggregator work Associations, the concepts of an aggregator and a deaggregator work
in the same manner, although the reservation mechanism would be that in the same manner, although the reservation mechanism would be that
of [RFC3473] and [RFC3474] [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746].
[RFC2746].
1.6. Logical structure of a VPN Router 1.6. Logical Structure of a VPN Router
The conceptual structure of a VPN Router is similar to that of any The conceptual structure of a VPN router is similar to that of any
other router. In its simplest form, it is physically a two or more other router. In its simplest form, it is physically a two or more
port device, similar to that shown in Figure 4 which has one or more port device (similar to that shown in Figure 4), which has one or
interfaces to the protected enclave(s) and one or more interfaces to more interfaces to the protected enclave(s) and one or more
the outside world. On the latter, it structures some number of interfaces to the outside world. On the latter, it structures some
tunnels (in the case of an IPsec tunnel, having security number of tunnels (in the case of an IPsec tunnel, having security
associations) that it can treat as point to point interfaces from a associations) that it can treat as point-to-point interfaces from a
routing perspective. routing perspective.
+---------+ +-------+ +----+----+ +---------+ +---------+ +-------+ +----+----+ +---------+
| RSVP | |Routing| |Net Guard| |IPsec Mgr| | RSVP | |Routing| |Net Guard| |IPsec Mgr|
+----+----+ +---+---+ +----+----+ +----+----+ +----+----+ +---+---+ +----+----+ +----+----+
| | | | | | | |
+----+-----------+------------+-----------------+----+ +----+-----------+------------+-----------------+----+
| IP | | IP |
+-----------+--------------------+------------+------+ +-----------+--------------------+------------+------+
| | | | | |
skipping to change at page 11, line 25 skipping to change at page 11, line 25
| |Decrypt for| |Decrypt for| | |Decrypt for| |Decrypt for|
| | Security | | Security | | | Security | | Security |
| |Association| |Association| | |Association| |Association|
| +-----+-----+ +----+------+ | +-----+-----+ +----+------+
| | | | | |
+-----------+------------+ +-----+------------+------+ +-----------+------------+ +-----+------------+------+
| Plain text | | Cipher text | | Plain text | | Cipher text |
| Interface | | Interface | | Interface | | Interface |
+------------------------+ +-------------------------+ +------------------------+ +-------------------------+
Figure 4: Logical structure of a VPN Router Figure 4: Logical Structure of a VPN Router
The encrypt/decrypt unit may be implemented as a function of the The encrypt/decrypt unit may be implemented as a function of the
plain text router, as a function on its interface card, or as a plain text router, as a function on its interface card, or as a
function of an external device with a private interface to the IP function of an external device with a private interface to the IP
routing functionality of the plain text router. These are routing functionality of the plain text router. These are
conceptually equivalent, although there are practical differences in conceptually equivalent, although there are practical differences in
implementation. The key issue is that when IP routing presents a implementation. The key issue is that when IP routing presents a
message to the encrypt/decrypt unit for transmission, it must also be message to the encrypt/decrypt unit for transmission, it must also be
presented with the IP address of the plain text routing peer, whether presented with the IP address of the plain text routing peer, whether
host or router, to which the security association must be host or router, to which the security association must be
established. This IP Address is used to select (and perhaps create) established. This IP Address is used to select (and perhaps create)
the security association, and in turn select the appropriate set of the security association, and in turn select the appropriate set of
security parameters. This could also be implemented by presenting security parameters. This could also be implemented by presenting
the local Security Parameter Index (SPI) for the data, if it has been the local Security Parameter Index (SPI) for the data, if it has been
created out of band by the Network Management Process. created out of band by the Network Management Process.
In addition, it is necessary for aggregated signaling to be generated In addition, it is necessary for aggregated signaling to be generated
for the cipher text domain. This may be accomplished in several for the ciphertext domain. This may be accomplished in several ways:
ways:
o by having the RSVP process on the plain text router generate the o by having the RSVP process on the plain text router generate the
messages and having the encrypt/decrypt unit bypass them into the messages and having the encrypt/decrypt unit bypass them into the
cipher text network cipher text network
o by having the plain text RSVP Process advise a process in the o by having the plaintext RSVP process advise a process in the
encrypt/decrypt implementation of what needs to be generated using encrypt/decrypt implementation of what needs to be generated using
some local exchange, and having it generate such messages, or some local exchange, and having it generate such messages, or
o by having a separate parallel network management system o by having a separate parallel network management system
intermediate between the plain text and cipher text routers, in intermediate between the plain text and cipher text routers, in
which case the encrypt/decrypt unit and the parallel network which case, the encrypt/decrypt unit and the parallel network
system must use the same address and the cipher text router must system must use the same address, and the ciphertext router must
distinguish between traffic for them based on SPI or the presence distinguish between traffic for them based on SPI or the presence
of encryption. of encryption.
Control plane signaling using this additional path is described in Control plane signaling using this additional path is described in
Section 3.2. The information flow between the plain text and cipher Section 3.2. The information flow between the plaintext and
text domains includes ciphertext domains includes
o IP datagrams via the encrypt/decrypt unit, o IP datagrams via the encrypt/decrypt unit,
o RSVP signaling via the bypass path, o RSVP signaling via the bypass path,
o Control information coordinating security associations, and o Control information coordinating security associations, and
o precious little else. o precious little else.
2. Reservation and Preemption in a nested VPN 2. Reservation and Preemption in a Nested VPN
/ \ / \
( +--+ +--+ enclave ) ,---------. ( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' ` .----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ +--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3| |H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ +--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ | | / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| , --------|VPN1|' | ``|VPN3| ,
skipping to change at page 13, line 48 skipping to change at page 13, line 48
+----+.`----. +----+ _.--'' ,+----+ +----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / | | \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ +--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4| |H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+ +--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \ // |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. , `. ,' \ enclave / '-. ,
`-------' \ / `-------' `-------' \ / `-------'
Figure 5: Reservations in a nested VPN Figure 5: Reservations in a Nested VPN
Let us discuss how a resource reservation protocol, and specifically Let us discuss how a resource reservation protocol, and specifically
RSVP, might be used in a nested virtual private network. RSVP, might be used in a nested virtual private network.
2.1. Reservation in a nested VPN 2.1. Reservation in a Nested VPN
A reservation in a nest VPN is very much like a reservation in any A reservation in a nested VPN is very much like a reservation in any
other network, with one exception: it is composed of multiple other network, with one exception: it is composed of multiple
reservations that must be coordinated. These include a reservation reservations that must be coordinated. These include a reservation
within the originating and receiving enclaves and a reservation at within the originating and receiving enclaves and a reservation at
each layer of the VPN, as shown in Figure 5. each layer of the VPN, as shown in Figure 5.
Thus, when a host in one enclave opens a reservation to a host in Thus, when a host in one enclave opens a reservation to a host in
another enclave, a reservation of the appropriate type and size is another enclave, a reservation of the appropriate type and size is
created end to end. As it traverses the VPN Router leaving its created end to end. As it traverses the VPN router leaving its
enclave, the reservation information and the data are placed within enclave, the reservation information and the data are placed within
the appropriate tunnel (e. g., the IPsec Security Association for its the appropriate tunnel (e. g., the IPsec Security Association for its
precedence level to the appropriate remote VPN Router). At the precedence level to the appropriate remote VPN router). At the
remote VPN Router, it is extracted from the tunnel and passed on its remote VPN router, it is extracted from the tunnel and passed on its
way to the target system. The data in the enclave will be marked way to the target system. The data in the enclave will be marked
with a DSCP appropriate to its application and (if there is a with a DSCP appropriate to its application and (if there is a
difference) precedence level, and the signaling datagrams (PATH and difference) precedence level, and the signaling datagrams (PATH and
RESV) are marked with a DCLASS object indicating that value. RSVP RESV) are marked with a DCLASS object indicating that value. RSVP
signaling datagrams (PATH and RESV) are marked with a DCLASS object signaling datagrams (PATH and RESV) are marked with a DCLASS object
indicating the value used for the corresponding data. The DSCP on indicating the value used for the corresponding data. The DSCP on
the signaling datagrams, however, is a DSCP for signaling, and has the signaling datagrams, however, is a DSCP for signaling, and has
the one provision that if routing varies by DSCP then it must be a the one provision that if routing varies by DSCP, then it must be a
DSCP that is routed the same way as the relevant data. The [RFC2872] DSCP that is routed the same way as the relevant data. The [RFC2872]
policy object specifies the applicable policy (e. g., "routine policy object specifies the applicable policy (e.g., "routine service
service for voice traffic") and asserts a [RFC3182] credential for voice traffic") and asserts a [RFC3182] credential indicating its
indicating its user (which may be a person or a class of persons). user (which may be a person or a class of persons). As specified in
As specified in [RFC3181] it also specifies its Preemption Priority [RFC3181], it also specifies its Preemption Priority and its
and its Defending Priority; these enable the Preemption Priority of a Defending Priority; these enable the Preemption Priority of a new
new session to be compared with the Defending Priority of previously session to be compared with the Defending Priority of previously
admitted sessions. admitted sessions.
On the cipher text side of the VPN Router, no guarantees result On the ciphertext side of the VPN router, no guarantees result unless
unless the VPN Router likewise sets up a reservation to the peer VPN the VPN router likewise sets up a reservation to the peer VPN Router
Router across the cipher text domain. Thus, the VPN Router sets up across the ciphertext domain. Thus, the VPN router sets up an
an [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC3175] reservation to [RFC2207], [RFC4860], or [RFC3175] reservation to its peer.
its peer.
The Session Object defined by [RFC2207] or The Session Object defined by [RFC2207] or [RFC4860] contains a field
[I-D.ietf-tsvwg-rsvp-ipsec] contains a field called a "virtual called a "virtual destination port", which allows the multiplexing of
destination port", which allows the multiplexing of many reservations many reservations over a common security association and, in the
over a common security association, and in the latter case, a common latter case, a common DSCP value. Thus, the voice traffic at every
DSCP value. Thus, the voice traffic at every precedence level might precedence level might use the Expedited Forwarding (EF) DSCP and
use the EF DSCP and service as described in [RFC3246], but the service as described in [RFC3246], but the reservations would be for
reservations would be for "the aggregate of voice sessions at "the aggregate of voice sessions at precedence Pn between these VPN
precedence Pn between these VPN Routers". This would allow the routers". This would allow the network administration to describe
network administration to describe policies with multiple thresholds, policies with multiple thresholds, such as "a new session at
such as "a new session at precedence Pn may be accepted if the total precedence Pn may be accepted if the total reserved bandwidth does
reserved bandwidth does not exceed threshold Qn; if it is necessary not exceed threshold Qn; if it is necessary and sufficient to accept
and sufficient to accept the reservation, existing reservations at the reservation, existing reservations at lower precedences may be
lower precedences may be preemptively reduced to make acceptance of preemptively reduced to make acceptance of the new session possible".
the new session possible."
In the [RFC3175] case, since the DSCP must be used to identify both In the [RFC3175] case, since the DSCP must be used to identify both
the reservation and the corresponding data stream, the aggregate the reservation and the corresponding data stream, the aggregate
reservations for different precedence levels require different DSCP reservations for different precedence levels require different DSCP
values. values.
In either case, the fundamental necessity is for one VPN Router to In either case, the fundamental necessity is for one VPN router to
act as what [RFC3175] calls the "aggregator" and another to act as act as what [RFC3175] calls the "aggregator" and another to act as
the "deaggregator", and extend a VPN tunnel between them. If the VPN the "deaggregator", and extend a VPN tunnel between them. If the VPN
Tunnel is an IPsec Security Association between the VPN Routers and Tunnel is an IPsec Security Association between the VPN routers and
the IP packet is entirely contained within (such as is used to cross the IP packet is entirely contained within (such as is used to cross
a firewall), then the behavior of [RFC2746] is required of the a firewall), then the behavior of [RFC2746] is required of the
tunnel. That bearer will have the following characteristics: tunnel. That bearer will have the following characteristics:
o it will have a DSCP corollary to the DSCP for the data or the same o it will have a DSCP corollary to the DSCP for the data or the same
DSCP as the data it carries, DSCP as the data it carries,
o the reservations and data will be carried in security associations o the reservations and data will be carried in security associations
between the VPN Routers, and between the VPN routers, and
o the specification for the reservation for the tunnel itself will o the specification for the reservation for the tunnel itself will
not be less than the sum of the requirements of the aggregated not be less than the sum of the requirements of the aggregated
reservations. reservations.
The following requirements relationships apply between the set of The following requirements relationships apply between the set of
enclosed reservations and the tunnel reservation: enclosed reservations and the tunnel reservation:
o The sum of the average rates of the contained reservations, having o The sum of the average rates of the contained reservations, having
been adjusted for the additional IP headers, will be less than or been adjusted for the additional IP headers, will be less than or
skipping to change at page 16, line 15 skipping to change at page 16, line 15
This would differ only in the case that measurement-based admission This would differ only in the case that measurement-based admission
is in use in the tunnel but not in the end system. In that case, the is in use in the tunnel but not in the end system. In that case, the
tunnel's average bandwidth specification would be greater than or tunnel's average bandwidth specification would be greater than or
equal to the actual average offered traffic. Such systems are beyond equal to the actual average offered traffic. Such systems are beyond
the scope of this specification. the scope of this specification.
As a policy matter, it may be useful to note a quirk in the way As a policy matter, it may be useful to note a quirk in the way
Internet QoS works. If the policies for various precedence levels Internet QoS works. If the policies for various precedence levels
specify different thresholds (e. g., "to accept a new routine call, specify different thresholds (e. g., "to accept a new routine call,
the total reserved bandwidth after admission may not exceed X; to the total reserved bandwidth after admission may not exceed X; to
accept a higher precedence level call, the total reserved bandwidth accept a call with a higher precedence level, the total reserved
after admission may not exceed X+Y, and this may be achieved by bandwidth after admission may not exceed X+Y, and this may be
preempting a lower precedence level call"), the bandwidth Y achieved by preempting a call with a lower precedence level"), the
effectively comes from the bandwidth in use by elastic traffic rather bandwidth Y effectively comes from the bandwidth in use by elastic
than forcing a preemption event. traffic rather than forcing a preemption event.
2.2. Preemption in a nested VPN 2.2. Preemption in a Nested VPN
As discussed in Section 1.5 preemption is specified in [RFC3181] and As discussed in Section 1.5, preemption is specified in [RFC3181] and
further addressed in [RFC4495]. The issue is that in many cases the further addressed in [RFC4495]. The issue is that in many cases the
need is to reduce the bandwidth of a reservation due to a change in need is to reduce the bandwidth of a reservation due to a change in
the network, not simply to remove the reservation. In the case of an the network, not simply to remove the reservation. In the case of an
end system originated reservation, the end system might be able to end-system-originated reservation, the end system might be able to
accommodate the need through a change of codec; in the case of an accommodate the need through a change of codec; in the case of an
aggregate of some kind, it could reduce the bandwidth it is sending aggregate of some kind, it could reduce the bandwidth it is sending
by dropping one or more reservations entirely. by dropping one or more reservations entirely.
In a nested VPN or other kind of aggregated reservation, this means In a nested VPN or other kind of aggregated reservation, this means
that the deaggregator (the VPN Router initiating the RESV signal for that the deaggregator (the VPN router initiating the RESV signal for
the tunnel) must the tunnel) must
o receive the RESV Error signaling it to reduce its bandwidth, o receive the RESV Error signaling it to reduce its bandwidth,
o re-issue its RESV accordingly, o re-issue its RESV accordingly,
o identify one or more of its aggregated reservations, enough to do o identify one or more of its aggregated reservations, enough to do
the job, and the job, and
o signal them to reduce their bandwidth accordingly. o signal them to reduce their bandwidth accordingly.
It is possible, of course, that it is signaling them to reduce their It is possible, of course, that it is signaling them to reduce their
bandwidth to zero, which is functionally equivalent to removing the bandwidth to zero, which is functionally equivalent to removing the
reservation as described in [RFC3181]. reservation as described in [RFC3181].
In the routers in the core, an additional case arises. One could In the routers in the core, an additional case arises. One could
imagine that some enclave presents the VPN with a single session, and imagine that some enclave presents the VPN with a single session, and
that session has a higher precedence level. If some interior link is that session has a higher precedence level. If some interior link is
congested (e. g., the reserved bandwidth will exceed policy if the congested (e. g., the reserved bandwidth will exceed policy if the
call is admitted), a session between a different pair of VPN Routers call is admitted), a session between a different pair of VPN routers
must be preempted. More generally, in selecting a reservation to must be preempted. More generally, in selecting a reservation to
preempt, the core router must always select a reservation at the preempt, the core router must always select a reservation at the
lowest available Defending Priority. This is the reason that various lowest available Defending Priority. This is the reason that various
precedence levels must be kept separate in the core. precedence levels must be kept separate in the core.
2.3. Working through an example 2.3. Working through an Example
The network in Figure 5 shows three security layers: six plain text The network in Figure 5 shows three security layers: six plain text
enclaves around the periphery, two cipher text domains connecting enclaves around the periphery, two ciphertext domains connecting them
them at one layer (referred to in the diagram as an "interface at one layer (referred to in the diagram as an "interface domain"),
domain"), and a third cipher text domain connecting the first two and a third ciphertext domain connecting the first two (referred to
(referred to in the diagram as an "inner domain"). The following in the diagram as an "inner domain"). The following distribution of
distribution of information exists: information exists:
o Each enclave has access to general routing information concerning o Each enclave has access to general routing information concerning
other enclaves it is authorized to communicate with: systems in it other enclaves it is authorized to communicate with: systems in it
can translate a DNS name for a remote host or domain and obtain can translate a DNS name for a remote host or domain and obtain
the corresponding address or prefix. the corresponding address or prefix.
o Each enclave router also has specific routing information o Each enclave router also has specific routing information
regarding its own enclave. regarding its own enclave.
o A default route is distributed within the enclave, pointing to its o A default route is distributed within the enclave, pointing to its
VPN Router. VPN router.
o VPN Routers 1-6 are able to translate remote enclave prefixes to o VPN Routers 1-6 are able to translate remote enclave prefixes to
the appropriate remote enclave's VPN Router addresses. the appropriate remote enclave's VPN router addresses.
o Each interface domain has access to general routing information o Each interface domain has access to general routing information
concerning the other interface domains, but not the enclaves. concerning the other interface domains, but not the enclaves.
Systems in an interface domain can translate a DNS name for a Systems in an interface domain can translate a DNS name for a
remote interface domain and obtain the corresponding address or remote interface domain and obtain the corresponding address or
prefix. prefix.
o Each interface domain router also has specific routing information o Each interface domain router also has specific routing information
regarding its own interface domain. regarding its own interface domain.
o A default route is distributed within the interface domain, o A default route is distributed within the interface domain,
pointing to the "inner" VPN Router. pointing to the "inner" VPN router.
o VPN Routers 7 and 8 are able to translate remote interface domain o VPN Routers 7 and 8 are able to translate remote interface domain
prefixes to remote VPN Router addresses. prefixes to remote VPN router addresses.
o Routers in the inner domain have routing information for that o Routers in the inner domain have routing information for that
domain only. domain only.
While the example shows three levels, there is nothing magic about While the example shows three levels, there is nothing magic about
the number three. The model can be extended to any number of the number three. The model can be extended to any number of
concentric layers. concentric layers.
Note that this example places unidirectional reservations in the Note that this example places unidirectional reservations in the
forward direction. In voice and video applications, one generally forward direction. In voice and video applications, one generally
has a reservation in each direction. The reverse direction is not has a reservation in each direction. The reverse direction is not
discussed, for the sake of clarity, but operates in the same way in discussed, for the sake of clarity, but operates in the same way in
the reverse direction and uses the same security associations. the reverse direction and uses the same security associations.
2.3.1. Initial routine reservations - generating network state 2.3.1. Initial Routine Reservations - Generating Network State
Now let us install a set of reservations from H1 to H4, H2 to H5, and Now let us install a set of reservations from H1 to H4, H2 to H5, and
H3 to H6, and for the sake of argument let us presume that these are H3 to H6, and for the sake of argument, let us presume that these are
at the "routine" precedence. H1, H2, and H3 each initiate an PATH at the "routine" precedence. H1, H2, and H3 each initiate a PATH
signal describing their traffic. For the sake of argument, let us signal describing their traffic. For the sake of argument, let us
presume that H1's reservation is for an [RFC2205] session, H2's presume that H1's reservation is for an [RFC2205] session, H2's
reservation is for a session encrypted using IPsec, and therefore reservation is for a session encrypted using IPsec, and therefore
depends on [RFC2207] and H3 (which is a PSTN Gateway) sends an depends on [RFC2207], and H3 (which is a Public Switched Telephone
[RFC3175] reservation comprising a number of distinct sessions. Network (PSTN) gateway) sends an [RFC3175] reservation comprising a
Since these are going to H4, H5, and H6 respectively, the default number of distinct sessions. Since these are going to H4, H5, and
route leads them to VPN1, VPN2, and VPN3 respectively. H6, respectively, the default route leads them to VPN1, VPN2, and
VPN3, respectively.
The VPN Routers each ensure that they have an appropriate security The VPN routers each ensure that they have an appropriate security
association or tunnel open to the indicated remote VPN Router (VPN4, association or tunnel open to the indicated remote VPN router (VPN4,
VPN5, or VPN6). This will be a security association or tunnel for VPN5, or VPN6). This will be a security association or tunnel for
the indicated application at the indicated precedence level. Having the indicated application at the indicated precedence level. Having
accomplished that, it will place the PATH signal into the security accomplished that, it will place the PATH signal into the security
association and forward it. If such does not already exist, association and forward it. If such does not already exist,
following [RFC3175] 's aggregation model, it will now open a following [RFC3175] 's aggregation model, it will now open a
reservation (send a PATH signal) for the tunnel/SA within the reservation (send a PATH signal) for the tunnel/SA within the
interface domain; if the reservation does exist, the VPN Router will interface domain; if the reservation does exist, the VPN router will
increase the bandwidth indicated in the ADSPEC appropriately. In increase the bandwidth indicated in the ADSPEC appropriately. In
this example, these tunnel/SA reservations will follow the default this example, these tunnel/SA reservations will follow the default
route to VPN7. route to VPN7.
VPN7 ensures that it has an appropriate security association or VPN7 ensures that it has an appropriate security association or
tunnel open to VPN8. This will be a security association or tunnel tunnel open to VPN8. This will be a security association or tunnel
for the indicated application at the indicated precedence level. for the indicated application at the indicated precedence level.
Having accomplished that, it will place the PATH signal into the Having accomplished that, it will place the PATH signal into the
security association and forward it. If such does not already exist, security association and forward it. If such does not already exist,
following [RFC3175] 's aggregation model, it will now open a following [RFC3175] 's aggregation model, it will now open a
reservation (send a PATH signal) for the tunnel/SA within the reservation (send a PATH signal) for the tunnel/SA within the
interface domain; if the reservation does exist, the VPN Router will interface domain; if the reservation does exist, the VPN router will
increase the bandwidth indicated in the ADSPEC appropriately. In increase the bandwidth indicated in the ADSPEC appropriately. In
this example, this tunnel/SA reservation is forwarded to VPN8. this example, this tunnel/SA reservation is forwarded to VPN8.
VPN8 acts as an [RFC3175] deaggregator for the inner domain. This VPN8 acts as an [RFC3175] deaggregator for the inner domain. This
means that it receives the PATH signal for the inner domain means that it receives the PATH signal for the inner domain
reservation and stores state, decrypts the data stream from VPN7, reservation and stores state, decrypts the data stream from VPN7,
operates on the RSVP signals as an RSVP-configured router, and operates on the RSVP signals as an RSVP-configured router, and
forwards the received IP datagrams (including the updated PATH forwards the received IP datagrams (including the updated PATH
signals) into its interface domain. The PATH signals originated by signals) into its interface domain. The PATH signals originated by
VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and
skipping to change at page 19, line 23 skipping to change at page 19, line 26
the interface domain reservation and stores state, decrypts the data the interface domain reservation and stores state, decrypts the data
stream from its peer, operates on the RSVP signals as an RSVP- stream from its peer, operates on the RSVP signals as an RSVP-
configured router, and forwards the received IP datagrams (including configured router, and forwards the received IP datagrams (including
the updated PATH signals) into its enclave. The PATH signals the updated PATH signals) into its enclave. The PATH signals
originated by H1, H2, and H3 are therefore forwarded towards H4, H5, originated by H1, H2, and H3 are therefore forwarded towards H4, H5,
and H6 according to the routing of the enclave. and H6 according to the routing of the enclave.
H4, H5, and H6 now receive the original PATH signals and deliver them H4, H5, and H6 now receive the original PATH signals and deliver them
to their application. to their application.
2.3.2. Initial routine reservations - request reservation 2.3.2. Initial Routine Reservations - Request Reservation
The application in H4, H5, and H6 decides to install the indicated The application in H4, H5, and H6 decides to install the indicated
reservations, meaning that they now reply with RESV signals. These reservations, meaning that they now reply with RESV signals. These
signals request the bandwidth reservation. Following the trail left signals request the bandwidth reservation. Following the trail left
by the PATH signals, the RESV signals traipse back to their by the PATH signals, the RESV signals traipse back to their
respective sources. The state left by the PATH signals leads them to respective sources. The state left by the PATH signals leads them to
VPN4, VPN5, and VPN6 respectively. If the routers in the enclaves VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves
are configured for RSVP, this will be explicitly via R4, R5, or R6; are configured for RSVP, this will be explicitly via R4, R5, or R6;
if they are not, routing will lead them through those routers. if they are not, routing will lead them through those routers.
The various RSVP-configured routers en route in the enclave The various RSVP-configured routers en route in the enclave
(including the VPN Router on the "enclave" side) will verify that (including the VPN router on the "enclave" side) will verify that
there is sufficient bandwidth on their links and that any other there is sufficient bandwidth on their links and that any other
stated policy is also met. Having accomplished that, each will stated policy is also met. Having accomplished that, each will
update its reservation state and forward the RESV signal to the next. update its reservation state and forward the RESV signal to the next.
The VPN Routers will also each generate an RESV for the reservation The VPN routers will also each generate an RESV for the reservation
within the interface domain, attempting to set or increase the within the interface domain, attempting to set or increase the
bandwidth of the reservation appropriately. bandwidth of the reservation appropriately.
The various RSVP-configured routers en route in the interface domain The various RSVP-configured routers en route in the interface domain
(including VPN8) will verify that there is sufficient bandwidth on (including VPN8) will verify that there is sufficient bandwidth on
their links and that any other stated policy is also met. Having their links and that any other stated policy is also met. Having
accomplished that, each will update its reservation state and forward accomplished that, each will update its reservation state and forward
the RESV signal to the next. VPN8 will also generate an RESV for the the RESV signal to the next. VPN8 will also generate an RESV for the
reservation within the inner domain, attempting to set or increase reservation within the inner domain, attempting to set or increase
the bandwidth of the reservation appropriately. This gets the the bandwidth of the reservation appropriately. This gets the
skipping to change at page 20, line 32 skipping to change at page 20, line 35
the interface domain reservation and stores state, decrypts the data the interface domain reservation and stores state, decrypts the data
stream from its peer, operates on the RSVP signals as an RSVP- stream from its peer, operates on the RSVP signals as an RSVP-
configured router, and forwards the received IP datagrams (including configured router, and forwards the received IP datagrams (including
the updated RESV signals) into its enclave. The RESV signals the updated RESV signals) into its enclave. The RESV signals
originated by H4, H5, and H6 are therefore forwarded towards H1, H2, originated by H4, H5, and H6 are therefore forwarded towards H1, H2,
and H3 according to the routing of the enclave. and H3 according to the routing of the enclave.
H1, H2, and H3 now receive the original RESV signals and deliver them H1, H2, and H3 now receive the original RESV signals and deliver them
to their application. to their application.
2.3.3. Installation of a reservation using precedence 2.3.3. Installation of a Reservation Using Precedence
Without going through the details called out in Section 2.3.1 and Without going through the details called out in Sections 2.3.1 and
Section 2.3.2 if sufficient bandwidth exists to support them, 2.3.2, if sufficient bandwidth exists to support them, reservations
reservations of other precedence levels or other applications may of other precedence levels or other applications may also be
also be installed across this network. If the "routine" reservations installed across this network. If the "routine" reservations already
already described are for voice, for example, and sufficient described are for voice, for example, and sufficient bandwidth is
bandwidth is available under the relevant policy, a reservation for available under the relevant policy, a reservation for voice at the
voice at the "priority" precedence level might be installed. Due to "priority" precedence level might be installed. Due to the mechanics
the mechanics of preemption, however, this would not expand the of preemption, however, this would not expand the existing "routine"
existing "routine" reservations in the interface and inner domains, reservations in the interface and inner domains, as doing this causes
as doing this causes loss of information - how much of the loss of information - how much of the reservation is now "routine"
reservation is now "routine" and how much is "priority"? Rather, and how much is "priority"? Rather, this new reservation will open
this new reservation will open up a separate set of tunnels or up a separate set of tunnels or security associations for traffic of
security associations for traffic of its application class at its its application class at its precedence between that aggregator and
precedence between that aggregator and deaggregator. deaggregator.
As a side note, there is an opportunity here that does not exist in As a side note, there is an opportunity here that does not exist in
the PSTN. In the PSTN, all circuits are potentially usable by any the PSTN. In the PSTN, all circuits are potentially usable by any
PSTN application under a certain set of rules (H channels, such as PSTN application under a certain set of rules (H channels, such as
are used by video streams, must be contiguous and ordered). As such, those used by video streams, must be contiguous and ordered). As
if a channel is not made available to routine traffic but is made such, if a channel is not made available to routine traffic but is
available to priority traffic, the operator is potentially losing made available to priority traffic, the operator is potentially
revenue on the reserved bandwidth and deserves remuneration. losing revenue on the reserved bandwidth and deserves remuneration.
However, in the IP Internet, some bandwidth must be kept for basic However, in the IP Internet, some bandwidth must be kept for basic
functions such as routing, and in general policies will not permit functions such as routing, and, in general, policies will not permit
100% of the bandwidth on an interface to be allocated to one 100% of the bandwidth on an interface to be allocated to one
application at one precedence. As a result, it may be acceptable to application at one precedence. As a result, it may be acceptable to
permit a certain portion (e. g. 50%) to be used by routine voice and permit a certain portion (e.g., 50%) to be used by routine voice and
a larger amount (e. g. 60%) to be used by voice at a higher a larger amount (e.g., 60%) to be used by voice at a higher
precedence level. Under such a policy, a higher precedence precedence level. Under such a policy, a higher precedence
reservation for voice might not result in the preemption of a routine reservation for voice might not result in the preemption of a routine
call, but rather impact elastic traffic, and might be accepted at a call, but rather impact elastic traffic, and might be accepted at a
time that a new reservation of lower precedence might be denied. time that a new reservation of lower precedence might be denied.
In microwave networks, such as satellite or mobile ad hoc, one could In microwave networks, such as satellite or mobile ad hoc, one could
also imagine network management intervention that could change the also imagine network management intervention that could change the
characteristics of the radio signal to increase the bandwidth under characteristics of the radio signal to increase the bandwidth under
some appropriate policy. some appropriate policy.
2.3.4. Installation of a reservation using preemption 2.3.4. Installation of a Reservation Using Preemption
So we now have a number of reservations across the network described So we now have a number of reservations across the network described
in Figure 5 including several reservations at "routine" precedence in Figure 5 including several reservations at "routine" precedence
and one at "priority" precedence. For sake of argument, let us and one at "priority" precedence. For sake of argument, let us
presume that the link from VPN7 to R9 is now fully utilized - all of presume that the link from VPN7 to R9 is now fully utilized - all of
the bandwidth allocated by policy to voice at the routine or priority the bandwidth allocated by policy to voice at the routine or priority
level has been reserved. Let us further imagine that a new level has been reserved. Let us further imagine that a new
"priority" reservation is now placed from H3 to H6. "priority" reservation is now placed from H3 to H6.
The process described in Section 2.3.1 is followed, resulting in PATH The process described in Section 2.3.1 is followed, resulting in PATH
state across the network for the new reservation. This is installed state across the network for the new reservation. This is installed
even though it is not possible to install a new reservation on even though it is not possible to install a new reservation on VPN7-
VPN7-R9, as it does not install any reservation and the network does R9, as it does not install any reservation and the network does not
not know whether H6 will ultimately require a reservation. know whether H6 will ultimately require a reservation.
The process described in Section 2.3.2 is also followed. The The process described in Section 2.3.2 is also followed. The
application in H6 decides to install the indicated reservation, application in H6 decides to install the indicated reservation,
meaning that it now replies with an RESV signal. Following the trail meaning that it now replies with an RESV signal. Following the trail
left by the PATH signal, the RESV signal traipses back towards H3. left by the PATH signal, the RESV signal traipses back towards H3.
VPN6 and (if RSVP was configured) R6 verify that there is sufficient VPN6 and (if RSVP was configured) R6 verify that there is sufficient
bandwidth on their links and that any other stated policy is also bandwidth on their links and that any other stated policy is also
met. Having accomplished that, each will update its reservation met. Having accomplished that, each will update its reservation
state and forward the RESV signal to the next. VPN6 also generates state and forward the RESV signal to the next. VPN6 also generates
an RESV for the reservation within the interface domain, attempting an RESV for the reservation within the interface domain, attempting
to set or increase the bandwidth of the reservation appropriately. to set or increase the bandwidth of the reservation appropriately.
VPN6, R8, and VPN8's "interface domain" side now verify that there is VPN6, R8, and VPN8's "interface domain" sides now verify that there
sufficient bandwidth on their links and that any other stated policy is sufficient bandwidth on their links and that any other stated
is also met. Having accomplished that, each will update its policy is also met. Having accomplished that, each will update its
reservation state and forward the RESV signal to the next. VPN8 will reservation state and forward the RESV signal to the next. VPN8 will
also generate an RESV for the reservation within the inner domain, also generate an RESV for the reservation within the inner domain,
attempting to set or increase the bandwidth of the reservation attempting to set or increase the bandwidth of the reservation
appropriately. This gets the reservation to the inner deaggregator, appropriately. This gets the reservation to the inner deaggregator,
VPN8. VPN8.
VPN8's "inner domain" side and R9 now verify that there is sufficient VPN8's "inner domain" side and R9 now verify that there is sufficient
bandwidth on their links and that any other stated policy is also bandwidth on their links and that any other stated policy is also
met. At R9, a problem is detected - there is not sufficient met. At R9, a problem is detected - there is not sufficient
bandwidth under the relevant policy. In the absence of precedence, bandwidth under the relevant policy. In the absence of precedence,
R9 would now return an RESV Error indicating that the reservation R9 would now return an RESV Error indicating that the reservation
could not be increased or installed. In such a case, if a pre- could not be increased or installed. In such a case, if a
existing reservation of lower bandwidth already existed, the previous preexisting reservation of lower bandwidth already existed, the
reservation would remain in place but the new bandwidth would not be previous reservation would remain in place but the new bandwidth
granted, and the originator (H6) would be informed. Let us clarify would not be granted, and the originator (H6) would be informed. Let
what it means to be at a stated precedence: it means that the us clarify what it means to be at a stated precedence: it means that
POLICY_DATA object in the RESV contains a Preemption Priority and a the POLICY_DATA object in the RESV contains a Preemption Priority and
Defending Priority with values specified in some memo. With a Defending Priority with values specified in some memo. With
precedence, [RFC4495]'s algorithm would have the Preemption Priority precedence, [RFC4495]'s algorithm would have the Preemption Priority
of the new reservation compared to the Defending Priority of extant of the new reservation compared to the Defending Priority of extant
reservations in the router, of which there are two: one VPN7->VPN8 at reservations in the router, of which there are two: one VPN7->VPN8 at
"routine" precedence and one VPN7->VPN8 at "priority" precedence. "routine" precedence and one VPN7->VPN8 at "priority" precedence.
Since the Defending Priority of routine reservation is less than the Since the Defending Priority of routine reservation is less than the
Preemption Priority of a "priority" reservation, the "routine" Preemption Priority of a "priority" reservation, the "routine"
reservation is selected. R9 determines that it will accept the reservation is selected. R9 determines that it will accept the
increase in its "priority" reservation VPN7->VPN8 and reduce the increase in its "priority" reservation VPN7->VPN8 and reduce the
corresponding "routine" reservation. Two processes now occur in corresponding "routine" reservation. Two processes now occur in
parallel: parallel:
o The routine reservation is reduced following the algorithms in o The routine reservation is reduced following the algorithms in
[RFC4495] and [RFC4495] and
o The priority reservation continues according to the usual rules. o The priority reservation continues according to the usual rules.
R9 reduces its "routine" reservation by sending an RESV Error R9 reduces its "routine" reservation by sending an RESV Error
updating its internal state to reflect the reduced reservation and updating its internal state to reflect the reduced reservation and
sending an RESV Error to VPN8 requesting that it reduce its sending an RESV Error to VPN8 requesting that it reduce its
reservation to a number less than or equal to the relevant threshold reservation to a number less than or equal to the relevant threshold
less the sum of the competing reservations. VPN8, acting as a de- less the sum of the competing reservations. VPN8, acting as a
aggregator, makes two changes. On the "inner domain" side, it marks deaggregator, makes two changes. On the "inner domain" side, it
its reservation down to the indicated rate (the most it is now marks its reservation down to the indicated rate (the most it is now
permitted to reserve), so that if an RESV Refresh event happens it permitted to reserve), so that if an RESV Refresh event happens, it
will request the specified rate. On the "interface domain" side it will request the specified rate. On the "interface domain" side, it
selects one or more of the relevant reservations by an algorithm of selects one or more of the relevant reservations by an algorithm of
its choosing and requests that it likewise reduce its rate. For sake its choosing and requests that it likewise reduce its rate. For the
of argument, let us imagine that the selected reservation is the one sake of argument, let us imagine that the selected reservation is the
to VPN5. The RESV Error now makes its way through R8 to VPN5, which one to VPN5. The RESV Error now makes its way through R8 to VPN5,
similarly reduces its bandwidth request to the stated amount and which similarly reduces its bandwidth request to the stated amount
passes a RESV Error signal on the "enclave" side requesting that the and passes a RESV Error signal on the "enclave" side requesting that
reservation be appropriately reduced. the reservation be appropriately reduced.
H5 is now faced with a decision. If the request is to reduce its H5 is now faced with a decision. If the request is to reduce its
reservation to zero, that is equivalent to tearing down the reservation to zero, that is equivalent to tearing down the
reservation. In this simple case, it sends an RESV Tear to tear down reservation. In this simple case, it sends an RESV Tear to tear down
the reservation entirely and advises its application to adjust its the reservation entirely and advises its application to adjust its
expectations of the session accordingly, which may mean shutting down expectations of the session accordingly, which may mean shutting down
the session. If the request is to reduce it below a certain value, the session. If the request is to reduce it below a certain value,
however, it may be possible for the application to do so and remain however, it may be possible for the application to do so and remain
viable. For example, if a VoIP application using a G. 711 codec (80 viable. For example, if a VoIP application using a G. 711 codec (80
KBPS) is asked to reduce its bandwidth below 70 KBPS, it may be kbps) is asked to reduce its bandwidth below 70 kbps, it may be
possible to renegotiate the codec in use to G. 729 or some other possible to renegotiate the codec in use to G. 729 or some other
codec. In such a case, the originating application should re-reserve codec. In such a case, the originating application should re-reserve
at the stated bandwidth (in this case, 70 KBPS), initiate the at the stated bandwidth (in this case, 70 kbps), initiate the
application level change, and let the application change the application level change, and let the application change the
reservation again (perhaps to 60 KBPS) when it has completed that reservation again (perhaps to 60 kbps) when it has completed that
process. process.
For the "priority" reservation, at the same time, R9 believes that it At the time the reservation is being processed at R9, for the
has sufficient bandwidth and that any other stated policy is also "priority" reservation, R9 believes that it has sufficient bandwidth
met, it forwards the RESV to VPN7. Each will update its reservation and that any other stated policy is also met, and it forwards the
state and forward the RESV signal to the next. VPN7 now acts as an RESV to VPN7. Each will update its reservation state and forward the
[RFC3175] aggregator for the inner domain. This means that it RESV signal to the next. VPN7 now acts as an [RFC3175] aggregator
receives the RESV signal for the inner domain reservation and stores for the inner domain. This means that it receives the RESV signal
state, decrypts the data stream from VPN8, operates on the RSVP for the inner domain reservation and stores state, decrypts the data
signals as an RSVP-configured router, and forwards the received IP stream from VPN8, operates on the RSVP signals as an RSVP-configured
datagrams (including the updated RESV signals) into its interface router, and forwards the received IP datagrams (including the updated
domain. The RESV signals originated by VPN4, VPN5, and VPN6 are RESV signals) into its interface domain. The RESV signals originated
therefore forwarded towards VPN1, VPN2, and VPN3 through the by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2,
interface domain. and VPN3 through the interface domain.
VPN3 now acts as an [RFC3175] aggregator for the interface domain. VPN3 now acts as an [RFC3175] aggregator for the interface domain.
This means that it receives the RESV signal for the interface domain This means that it receives the RESV signal for the interface domain
reservation and stores state, decrypts the data stream from its peer, reservation and stores state, decrypts the data stream from its peer,
operates on the RSVP signals as an RSVP-configured router, and operates on the RSVP signals as an RSVP-configured router, and
forwards the received IP datagrams (including the updated RESV forwards the received IP datagrams (including the updated RESV
signals) into its enclave. The RESV signal originated by H6 is signals) into its enclave. The RESV signal originated by H6 is
therefore forwarded towards H3 according to the routing of the therefore forwarded towards H3 according to the routing of the
enclave. enclave.
H3 now receives the original RESV signals and deliver it to the H3 now receives the original RESV signals and delivers it to the
relevant application. relevant application.
3. Data flows within a VPN Router 3. Data Flows within a VPN Router
This section details the data flows within a VPN Router, in the This section details the data flows within a VPN router, in the
context of sessions as described in Section 2. It specifically context of sessions as described in Section 2. It specifically
identifies the signaling flow at a given VPN boundary and identifies the signaling flow at a given VPN boundary and
additionally elaborates the signaling mechanism with the aid of a additionally elaborates the signaling mechanism with the aid of a
network guard. A use case describing the proposal in the context of Network Guard. A use case describing the proposal in the context of
an operational scenario is presented herein. an operational scenario is presented herein.
3.1. VPN Routers that carry data across the cryptographic boundary 3.1. VPN Routers That Carry Data across the Cryptographic Boundary
3.1.1. Plaintext to Ciphertext Data Flows 3.1.1. Plaintext to Ciphertext Data Flows
+-----------------------+ +----------------------+ +-----------------------+ +----------------------+
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP || | |RSVP || ||Aggregate RSVP ||
| | || || || | | || || ||
| |Per session: || ID ||Agg. Session || | |Per session: || ID ||Agg. Session ||
| | Destination ||--->|| Agg. Destination || | | Destination ||--->|| Agg. Destination ||
| | Source || || Agg. Source= self || | | Source || || Agg. Source= self ||
| | potential SPI || || Agg. SPI generated|| | | potential SPI || || Agg. SPI generated||
| | DSCP ---------> DSCP || | | DSCP ---------> DSCP ||
| | vPort or protocol---------> vPort || | | vPort or protocol---------> vPort ||
skipping to change at page 24, line 42 skipping to change at page 25, line 4
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| | IP || || IP || | | IP || || IP ||
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| | Plain text Interface|| ||Cipher text Interface|| | | Plain text Interface|| ||Cipher text Interface||
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+ +-----------------------+ +----------------------+
Figure 6: Data Flows in a VPN Router Outbound Figure 6: Data Flows in a VPN Router Outbound
Parameters on a reservation include: Parameters on a reservation include:
Destination Address: On the plain text side, the VPN Router Destination Address: On the plaintext side, the VPN router
participates in the end to end reservations being installed for participates in the end-to-end reservations being installed for
plain text sessions. These may include individual flows as plain text sessions. These may include individual flows as
described in [RFC2205] IPsec data flows [RFC2207] aggregate described in [RFC2205], IPsec data flows [RFC2207], aggregate
reservations [RFC3175] or other types. It passes an identifier reservations [RFC3175], or other types. It passes an identifier
for the cipher text side of the deaggregator to its cipher text for the cipher text side of the deaggregator to its cipher text
unit. unit.
DSCP: The DSCP of the plain text data flow is provided to the cipher DSCP: The DSCP of the plain text data flow is provided to the cipher
text side. text side.
Virtual Port: The virtual destination port is provided to the cipher Virtual Port: The virtual destination port is provided to the cipher
text side. This may be derived from an [RFC2207] session object text side. This may be derived from an [RFC2207] session object
or from policy information. or from policy information.
Mean Rate: The sum of the plain text mean rates is provided to the Mean Rate: The sum of the plain text mean rates is provided to the
cipher text unit. cipher text unit.
Peak Rate: A function of the plain text peak rates is provided to Peak Rate: A function of the plaintext peak rates is provided to the
the cipher text unit. This function is less than or equal to the ciphertext unit. This function is less than or equal to the sum
sum of the peak rates. of the peak rates.
Burst Size: The sum of the burst sizes is provided to the cipher Burst Size: The sum of the burst sizes is provided to the cipher
text unit. text unit.
Messages include: Messages include:
Path: The Plain text PATH message is sent as encrypted data to the Path: The plaintext PATH message is sent as encrypted data to the
cipher text unit. In parallel, a trigger needs to be sent to the cipher text unit. In parallel, a trigger needs to be sent to the
cipher text unit that results in it generating the corresponding cipher text unit that results in it generating the corresponding
aggregated PATH message for the cipher text side. aggregated PATH message for the cipher text side.
Path Error: This indicates that a PATH message sent to the remote Path Error: This indicates that a PATH message sent to the remote
enclave was in error. In the error case, the message itself is enclave was in error. In the error case, the message itself is
sent on as encrypted data, but a signal is sent to the cipher text sent on as encrypted data, but a signal is sent to the cipher text
side in case the error affects the cipher text reservation (such side in case the error affects the ciphertext reservation (such as
as removing or changing state). removing or changing state).
Path Tear: The PATH Tear message is sent as encrypted data to the Path Tear: The PATH Tear message is sent as encrypted data to the
cipher text unit. In parallel, a signal is sent to the cipher ciphertext unit. In parallel, a signal is sent to the cipher text
text side which will trigger a Path Tear on its reservation in the side; it will trigger a Path Tear on its reservation in the event
event that this is the last aggregated session, or change the that this is the last aggregated session, or change the
SENDER_TSPEC of the aggregated session. SENDER_TSPEC of the aggregated session.
RESV: The Plain text RESV message is sent as encrypted data to the RESV: The plaintext RESV message is sent as encrypted data to the
cipher text unit. In parallel, a trigger needs to be sent to the cipher text unit. In parallel, a trigger needs to be sent to the
cipher text unit that results in it generating the corresponding cipher text unit that results in it generating the corresponding
aggregated RESV message for the cipher text side. aggregated RESV message for the cipher text side.
RESV Error: This indicates that a RESV message received as data and RESV Error: This indicates that a RESV message that was received as
forwarded into the enclave was in error or needed to be preempted data and forwarded into the enclave was in error or needed to be
as described in [RFC3181] or [RFC4495]. In the error case, the preempted as described in [RFC3181] or [RFC4495]. In the error
message itself is sent on as encrypted data, but a signal is sent case, the message itself is sent on as encrypted data, but a
to the cipher text side in case the error affects the cipher text signal is sent to the ciphertext side in case the error affects
reservation (such as removing or changing state). the ciphertext reservation (such as removing or changing state).
RESV Tear: The RESV Tear message is sent as encrypted data to the RESV Tear: The RESV Tear message is sent as encrypted data to the
cipher text unit. In parallel, a signal is sent to the cipher ciphertext unit. In parallel, a signal is sent to the cipher text
text side which will trigger a RESV Tear on its reservation in the side; it will trigger a RESV Tear on its reservation in the event
event that this is the last aggregated session, or reduce the that this is the last aggregated session, or reduce the bandwidth
bandwidth of an existing reservation. of an existing reservation.
RESV Confirm: This indicates that a RESV message received as data RESV Confirm: This indicates that a RESV message received as data
and forwarded into the enclave, and is now being confirmed. This and forwarded into the enclave, and is now being confirmed. This
message is sent as encrypted data to the cipher text side, and in message is sent as encrypted data to the ciphertext side, and, in
parallel a signal is sent to potentially trigger an RESV Confirm parallel, a signal is sent to potentially trigger an RESV Confirm
on the aggregate reservation. on the aggregate reservation.
3.1.2. Ciphertext to Plaintext Data Flows 3.1.2. Ciphertext to Plaintext Data Flows
+-----------------------+ +----------------------+ +-----------------------+ +----------------------+
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP || | |RSVP || ||Aggregate RSVP ||
| | || || terminated || | | || || terminated ||
| |Per session: |+ || || | |Per session: |+ || ||
| | Destination || || || | | Destination || || ||
| | Source <---------Decrypted RSVP || | | Source <---------Decrypted RSVP ||
| | potential SPI || || message sent to || | | potential SPI || || message sent to ||
| | DSCP || || Plain text unit || | | DSCP || || Plain text unit ||
| | vPort or protocol || || *as data* for || | | vPort or protocol || || *as data* for ||
skipping to change at page 26, line 44 skipping to change at page 27, line 33
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| | IP || || IP || | | IP || || IP ||
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
| |Plain text Interface|| ||Cipher text Interface|| | |Plain text Interface|| ||Cipher text Interface||
| +--------------------+| |+--------------------+| | +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+ +-----------------------+ +----------------------+
Figure 7: Data Flows in a VPN Router Inbound Figure 7: Data Flows in a VPN Router Inbound
The aggregate reservation is terminated by the cipher text side of The aggregate reservation is terminated by the ciphertext side of the
the VPN Router. The RSVP messages related to the subsidiary sessions VPN router. The RSVP messages related to the subsidiary sessions are
are carried in the encrypted tunnel as data, and therefore arrive at carried in the encrypted tunnel as data, and therefore arrive at the
the plain text side with other data. As the plain text side plaintext side with other data. As the plaintext side participates
participates in these reservations, some information is returned to in these reservations, some information is returned to the ciphertext
the cipher text size to parameterize the aggregate reservation as size to parameterize the aggregate reservation as described in
described in Section 3.1.1 in the processing of the outbound Section 3.1.1 in the processing of the outbound messages.
messages.
3.2. VPN Routers that use the Network Guard for signaling across the 3.2. VPN Routers That Use the Network Guard for Signaling across the
cryptographic boundary Cryptographic Boundary
As described in Section 1.6 the Network Guard provides an additional As described in Section 1.6 the Network Guard provides an additional
path for the reservation signaling between the plain text and cipher path for the reservation signaling between the plain text and cipher
text domains. text domains.
_.------------. _.------------.
,--'' Plain text Domain--. ,--'' Plain text Domain--.
,-' +--------+ +--------+ `-. ,-' +--------+ +--------+ `-.
,' | Host | | Host | `. ,' | Host | | Host | `.
,' +--------+ +--------+ `. ,' +--------+ +--------+ `.
skipping to change at page 27, line 34 skipping to change at page 28, line 34
|----|E/D |--|Net Grd| | VPN Router |----|E/D |--|Net Grd| | VPN Router
,-'| +-+--+ +-+--+--+ |\ ,-'| +-+--+ +-+--+--+ |\
, | +----------+ | \ , | +----------+ | \
,' | +---+----+ | `. ,' | +---+----+ | `.
,' | | Router | | | ,' | | Router | | |
/ | +--------+ | \ / | +--------+ | \
; +----------------------+ : ; +----------------------+ :
| | | |
: Cipher text Domain ; : Cipher text Domain ;
Figure 8: RSVP passage via Network Guard Figure 8: RSVP Passage via Network Guard
In this context, the VPN Router is composed of a plaintext router, a In this context, the VPN router is composed of a plaintext router, a
ciphertext router, an encrypt/decrypt implementation (such as a line ciphertext router, an encrypt/decrypt implementation (such as a line
card or interface device) and a network management process that card or interface device), and a network management process that
manages the encrypt/decrypt implementation and potentially passes manages the encrypt/decrypt implementation and potentially passes
defined information flows between the plaintext and ciphertext defined information flows between the plaintext and ciphertext
domains. If the Network Guard is implemented as software process domains. If the Network Guard is implemented as a software process
that exchanges configuration instructions between the routers, this that exchanges configuration instructions between the routers, this
is simple to understand. If it is built as separate systems is simple to understand. If it is built as a separate systems
exchanging datagrams, it is somewhat more complex, but conceptually exchanging datagrams, it is somewhat more complex, but conceptually
equivalent. For example, the ciphertext router would consider an IP equivalent. For example, the ciphertext router would consider an IP
datagram received via the Network Guard (control plane) as having datagram received via the Network Guard (control plane) as having
been received from and concerning the interface used in the data been received from and concerning the interface used in the data
plane to the encrypt/decrypt unit. plane to the encrypt/decrypt unit.
3.2.1. Signaling Flow 3.2.1. Signaling Flow
Encrypt/Decrypt units may not be capable of terminating and Encrypt/decrypt units may not be capable of terminating and
originating flows as described in Section 3.1, and policy may prevent originating flows as described in Section 3.1, and policy may prevent
knowledge of the cipher text network addresses in the plain text knowledge of the cipher text network addresses in the plain text
router. In such a case the plain text and cipher text routers may router. In such a case, the plaintext and ciphertext routers may use
use the Network Guard as the path for the signaling flows. The the Network Guard as the path for the signaling flows. The Network
Network Guard performs the following functions to enable the flow of Guard performs the following functions to enable the flow of
reservation signaling across the cryptographic domain reservation signaling across the cryptographic domain
o Transform plain text session identifiers into cipher text session o transforms plaintext session identifiers into ciphertext session
identifiers and vice-versa in IP datagrams and RSVP objects (e.g. identifiers and vice-versa in IP datagrams and RSVP objects (e.g.
IP addresses) IP addresses)
o Resource management of aggregated reservations (e.g. including o performs resource management of aggregated reservations (e.g.,
cipher text encapsulation overhead to resources requested) including ciphertext encapsulation overhead to resources
requested)
o Read and write configuration on the Encrypt/Decrypt units as o reads and writes configuration on the encrypt/decrypt units as
necessary (e.g. read plain text to cipher text IP address mapping) necessary (e.g., reads plaintext to ciphertext IP address mapping)
In addition the plain text and cipher text routers must support a In addition, the plaintext and ciphertext routers must support a
routing function or local interface which ensures that aggregated routing function or local interface that ensures that aggregated RSVP
RSVP messages flow via the Network Guard. The signaling flow across messages flow via the Network Guard. However, the signaling flow
the entire VPN Router at cryptographic boundary however remains across the entire VPN router at a cryptographic boundary remains
identical to the description in Section 3.1. identical to the description in Section 3.1.
A reader may note that the VPN Router described in Figure 8 can be A reader may note that the VPN router described in Figure 8 can be
collapsed into a single router with two halves or the Network Guard collapsed into a single router with two halves, or the Network Guard
and the Encrypt/Decrypt units can be part of the plain text router. and the encrypt/decrypt units can be part of the plaintext router.
The details of alternate logical and physical architectures for the The details of alternate logical and physical architectures for the
VPN router are beyond the scope of this document. VPN router are beyond the scope of this document.
3.2.2. Use case with Network Guard 3.2.2. Use Case with Network Guard
........................................ ........................................
: VPN Router A : : VPN Router A :
: : : :
:+-----------++----------++-----------+: :+-----------++----------++-----------+:
+------+ RSVP :| || NetGrd-A || |: +------+ RSVP :| || NetGrd-A || |:
|Host-A|<---->:|PT-Router-A|+----------+|CT-Router-A|:::::::: |Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|::::::::
+------+ :| || E/D-A || |: :: +------+ :| || E/D-A || |: ::
:+-----------++----------++-----------+: :: :+-----------++----------++-----------+: ::
: A-RSVP : :: : A-RSVP : ::
: <:::::::::::::> : :: : <:::::::::::::> : ::
:......................................: :: :......................................: ::
A-RSVP :: A-RSVP ::
,---. ,---.
,' `. ,' `.
/ \ / \
; Interface : ; Interface :
skipping to change at page 29, line 34 skipping to change at page 30, line 34
: ; : ;
\ / \ /
`. ,' `. ,'
'---' '---'
A-RSVP :: A-RSVP ::
........................................ :: ........................................ ::
: VPN Router B : :: : VPN Router B : ::
: : :: : : ::
:+-----------++----------++-----------+: :: :+-----------++----------++-----------+: ::
+------+ RSVP :| || NetGrd-B || |: :: +------+ RSVP :| || NetGrd-B || |: ::
|Host-B|<---->:|PT-Router-B|+----------+|CT-Router-B|:::::::: |Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|::::::::
+------+ :| || E/D-B || |: +------+ :| || E/D-B || |:
:+-----------++----------++-----------+: :+-----------++----------++-----------+:
: A-RSVP : : A-RSVP :
: <:::::::::::::> : : <:::::::::::::> :
:......................................: :......................................:
Figure 9: Aggregated RSVP via Network Guard Figure 9: Aggregated RSVP via Network Guard
The above figure depicts a simple use case for aggregated signaling The above figure depicts a simple use case for aggregated signaling
with the Network Guard. In this scenario, Host A initiates RSVP with the Network Guard. In this scenario, Host A initiates RSVP
signaling to Host B for a reservation. The RSVP signaling between signaling to Host B for a reservation. The RSVP signaling between
the hosts is encapsulated by the VPN Router Instances into encrypted the hosts is encapsulated by the VPN routers into encrypted tunnels.
tunnels. Aggregated RSVP signaling is triggered by VPN Router Aggregated RSVP signaling is triggered by VPN routers, and flows into
Instances, and flows into the CT-Routers as well as the interface the CT-Routers, as well as the interface domains, to reserve
domains to reserve resources at RSVP capable routers on the path. resources at RSVP-capable routers on the path. The aggregation/
The aggregation/deaggregation point for RSVP reservations in this use deaggregation point for RSVP reservations in this use case are the
case are the PT-Routers. The signaling aggregation of RSVP into PT-Routers. The signaling aggregation of RSVP into A-RSVP at the
A-RSVP at the PT-Router is similar to the data flow described in PT-Router is similar to the data flow described in Section 3.1. The
Section 3.1. The Network Guard performs the additional functions Network Guard performs the additional functions described in Section
described in Section 3.2.1 to transform plaintext A-RSVP messages 3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext
into suitable ciphertext A-RSVP messages. A typical reservation set A-RSVP messages. A typical reservation set up in this case would
up in this case would follow these steps follow these steps.
o Host-A sends RSVP PATH message to Host B o Host A sends RSVP PATH message to Host B.
o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to
VPN Router Instance B VPN Router B.
o CT Routers and Interface domain carry encrypted RSVP PATH message o CT Routers and Interface domain carry encrypted RSVP PATH message
(like any other encrypted data message) (like any other encrypted data message).
o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr
message to PT-Router-A in the encrypted tunnel. message to PT-Router-A in the encrypted tunnel.
o PT-Router-B forwards decrypted plaintext RSVP PATH message to o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host
Host-B. B.
o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH
message towards PT-Router-B via the Network Guard. message towards PT-Router-B via the Network Guard.
o The NetGrd-A transforms the plaintext aggregate RSVP into the o The NetGrd-A transforms the plaintext aggregate RSVP into the
ciphertext aggregate RSVP message as described in Section 3.2.1 ciphertext aggregate RSVP message as described in Section 3.2.1
and sends it to the CT-Router-A. and sends it to the CT-Router-A.
o The ciphertext aggregated RSVP message travels through ciphertext o The ciphertext aggregated RSVP message travels through ciphertext
routers in the interface domain. routers in the interface domain.
o CT-Router-B receives the ciphertext aggregate RSVP message and o CT-Router-B receives the ciphertext aggregate RSVP message and
sends it to the NetGrd-B. sends it to the NetGrd-B.
o The NetGrd-B transforms the ciphertext aggregate RSVP into the o The NetGrd-B transforms the ciphertext aggregate RSVP into the
plaintext aggregate RSVP message as described in Section 3.2.1 and plaintext aggregate RSVP message as described in Section 3.2.1 and
sends it to the PT-Router-B. sends it to the PT-Router-B.
The subsequent RSVP and Aggregate RSVP signaling follows a similar The subsequent RSVP and Aggregate RSVP signaling follows a similar
flow, as described in detail in [RFC3175] and flow, as described in detail in [RFC3175] and [RFC4860]to aggregate
[I-D.ietf-tsvwg-rsvp-ipsec]to aggregate each plaintext reservation each plaintext reservation into a corresponding ciphertext
into a corresponding ciphertext reservation. This ensures that RSVP reservation. This ensures that RSVP-capable ciphertext routers
capable ciphertext routers reserve the required resources for a reserve the required resources for a plaintext end-to-end
plaintext end to end reservation. Subsequent mechanisms such as reservation. Subsequent mechanisms, such as preemption or the
preemption or the increase and decrease of resources reserved may be increase and decrease of resources reserved, may be applied to these
applied to these reservations as described before in this document. reservations as described before in this document. The RSVP data
The RSVP data flow as described in Section 3.1 within the VPN router flow as described in Section 3.1 within the VPN router (from the
(from the plaintext router to the ciphertext router via the Guard) plaintext router to the ciphertext router via the Guard) provides
provides necessary and sufficient information to routers in the necessary and sufficient information to routers in the ciphertext
ciphertext domain to implement the QoS solution presented in the domain to implement the QoS solution presented in the document.
document.
In this description, we have described the Network Guard as being In this description, we have described the Network Guard as being
separate from the Encrypt/Decrypt unit. This separation exists separate from the encrypt/decrypt unit. This separation exists
because in certain implementations it is mandated by those who because in certain implementations, it is mandated by those who
specify the devices. The separation does not come for free, however; specify the devices. The separation does not come for free, however;
the separation of the devices for system engineering purposes is the separation of the devices for system-engineering purposes is
expensive, and it imposes architectural problems. For example, when expensive, and it imposes architectural problems. For example, when
the Guard is used to aggregate RSVP messages or PIM routing, the the Guard is used to aggregate RSVP messages or Protocol Independent
traffic is destined to the remote VPN Router. This means that the Multicast (PIM) routing, the traffic is destined to the remote VPN
Guard must somehow receive and respond to, on behalf of the VPN router. This means that the Guard must somehow receive and respond
Router, messages that are not directed to it. There are several to, on behalf of the VPN Router, messages that are not directed to
possible solutions, which need to be carefully selected based on the it. Several possible solutions exist; they should be selected
security and implementation needs of the environment: carefully based on the security and implementation needs of the
environment. They are as follows:
o In the simplest case, the network guard and encrypt/decrypt unit o In the simplest case, the Network Guard and encrypt/decrypt unit
can be two independent functions which utilize a common network can be two independent functions that utilize a common network and
and MAC layer. This can allow the two functions to share a common MAC layer. This can allow the two functions to share a common MAC
MAC and IP address, so that traffic destined for one function is and IP address, so that traffic destined for one function is also
also received by the other. In the case that these two functions received by the other. In the case that these two functions are
are physically separated on two devices, they can still share a physically separated on two devices, they can still share a common
common MAC and IP address, however additional modifications may be MAC and IP address; however, additional modifications may be
required on the Guard to to filter and not process IP traffic not required on the Guard to filter and not process IP traffic not
destined for itself. destined for itself.
o The ciphertext interface of the Guard could be placed into o The ciphertext interface of the Guard could be placed into
promiscuous mode, allowing it to receive all messages and discard promiscuous mode, allowing it to receive all messages and discard
all but the few it is interested in. The security considerations all but the few it is interested in. The security considerations
on putting a device in promiscuous mode at the VPN boundary needs on putting a device in promiscuous mode at the VPN boundary needs
to be taken into account in this method. to be taken into account in this method.
o The Guard could be engineered to receive all from the ciphertext o The Guard could be engineered to receive all from the ciphertext
router and pass the bulk of it on to the VPN Router through router and pass the bulk of it on to the VPN router through
another interface. In this case, the Guard and the VPN Router another interface. In this case, the Guard and the VPN router
would use the same IP address. This mechanism puts the load of would use the same IP address. This mechanism puts the load of
all data and management traffic destined for the VPN router upon all data and management traffic destined for the VPN router upon
the Guard. the Guard.
o The VPN Router could be engineered to receive all traffic from the o The VPN router could be engineered to receive all traffic from the
ciphertext router and pass any unencrypted traffic it receives to ciphertext router and pass any unencrypted traffic it receives to
the Guard through another interface. In this case, the Guard and the Guard through another interface. In this case, the Guard and
the VPN Router would use the same IP address. the VPN router would use the same IP address.
o All the VPN router functions as shown in Figure 9 could be o All the VPN router functions, as shown in Figure 9, could be
incorporated into a single chassis, with appropriate internal incorporated into a single chassis, with appropriate internal
traffic management to send some traffic into the plaintext enclave traffic management to send some traffic into the plaintext enclave
and some to the Guard. In this case, the Guard and the VPN Router and some to the Guard. In this case, the Guard and the VPN router
would at least functionally be the same system. would be -- at least, functionally -- the same system.
Of these, clearly the last is the simplest architecturally and the Of these, clearly the last is the simplest architecturally and the
one which most minimizes the attendant risk. one that most minimizes the attendant risk.
4. IANA Considerations
This document makes no request of the IANA.
Note to RFC Editor: in the process assigning numbers and building
IANA registries prior to publication, this section will have served
its purpose. It may therefore be removed upon publication as an RFC.
5. Security Considerations 4. Security Considerations
The typical security concerns of datagram integrity, node and user The typical security concerns of datagram integrity, node and user
authentication are implicitly met by the security association that authentication are implicitly met by the security association that
exists between the VPN Routers. The secure data stream which flows exists between the VPN routers. The secure data stream that flows
between the VPN Routers is also used for the reservation signaling between the VPN routers is also used for the reservation signaling
datagrams flowing between VPN Routers. Information that is contained datagrams flowing between VPN routers. Information that is contained
in these signaling datagrams receives the same level of encryption in these signaling datagrams receives the same level of encryption
that is received by the data streams. that is received by the data streams.
One of the reasons cited for the nesting of VPN routes in Section 1.3 One of the reasons cited for the nesting of VPN routes in Section 1.3
are the different levels of security across the nested VPN Routers. is the different levels of security across the nested VPN routers.
If the security level decreases from one VPN Router to the next VPN If the security level decreases from one VPN router to the next VPN
Router in the nested path, the reservation signaling datagrams will Router in the nested path, the reservation signaling datagrams will,
by default receive the lower security level treatment. For most by default, receive the lower security-level treatment. For most
cases, the lower security treatment is acceptable. In certain cases, the lower security treatment is acceptable. In certain
networks, however, the reservation signaling across the entire nested networks, however, the reservation signaling across the entire nested
path must receive the highest security level treatment (e. g. path must receive the highest security-level treatment (e.g.,
encryption, authentication of signaling nodes). For example the encryption, authentication of signaling nodes). For example, the
highest precedence level may only be signaled to VPN Routers which highest precedence level may only be signaled to VPN routers that can
can provide the highest security levels. If any VPN Router in the provide the highest security levels. If any VPN router in the nested
nested path is incapable of providing the highest security level, it path is incapable of providing the highest security level, it cannot
cannot participate in the reservation mechanism. participate in the reservation mechanism.
In the general case, the nested path may contain routers which are In the general case, the nested path may contain routers that are
either incapable of participating in VPNs or providing required either incapable of participating in VPNs or providing required
security levels. These routers can participate in the reservation security levels. These routers can participate in the reservation
only if the lower security level is acceptable (as configured by only if the lower security level is acceptable (as configured by
policy) for the signaling of reservation datagrams. policy) for the signaling of reservation datagrams.
VPN Routers encapsulate encrypted IP packets and prepend an extra VPN routers encapsulate encrypted IP packets and prepend an extra
header on each packet. These packets, whether used for signaling or header on each packet. These packets, whether used for signaling or
data, should be identifiable, at a minimum by the IP addresses and data, should be identifiable, at a minimum by the IP addresses and
DSCP value. The prepended header, therefore, should contain at a DSCP value. Therefore, the prepended header should contain, at a
minimum the DSCP value corresponding to the signaled reservation in minimum, the DSCP value corresponding to the signaled reservation in
each packet. This may literally be the same DSCP as is used for the each packet. This may literally be the same DSCP as is used for the
data (forcing control plane traffic to receive the same QoS treatment data (forcing control plane traffic to receive the same QoS treatment
as its data), or a different DSCP that is routed identically as its data), or a different DSCP that is routed identically
(separating control and data plane traffic QoS but not routing). (separating control and data-plane traffic QoS but not routing).
Additionally security considerations as described in Additionally security considerations as described in [RFC4860] and
[I-D.ietf-tsvwg-rsvp-ipsec] and [RFC3175]are also applicable in this [RFC3175] are also applicable in this environment; they include the
environment which include the integrity of RSVP messages can be integrity of RSVP messages can be ensured via mechanisms described in
ensured via mechanisms described in [RFC2747] and [RFC3097] and [RFC2747] and [RFC3097] and related key management (through manual
related key management (through manual configuration or a key configuration or a key management protocol) at nodes between any
management protocol) at nodes between any aggregator and deaggregator aggregator and deaggregator pair that processes the messages. In
pair that process the messages. In addition confidentiality can be addition, confidentiality can be provided between hops by employing
provided between hops by employing IPsec. Further work in the IETF IPsec. Further work in the IETF MSEC Working Group may be applicable
MSEC Working Group may be applicable in these environments for key in these environments for key management and confidentiality.
management and confidentiality.
6. Acknowledgements 5. Acknowledgements
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger
Levesque, and Subha Dhesikan gave early review comments. Levesque, and Subha Dhesikan gave early review comments.
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou,
and their associates resulted in Section 3.2. and their associates resulted in Section 3.2.
Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik
Bose) added [I-D.ietf-tsvwg-rsvp-ipsec], which clarified the Bose) added [RFC4860], which clarified the interaction of this
interaction of this approach with the DSCP. approach with the DSCP.
7. References
7.1. Normative References 6. References
[I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate 6.1. Normative References
Resource ReSerVation Protocol (RSVP)
Reservations",
draft-ietf-tsvwg-rsvp-ipsec-04 (work in
progress), January 2007.
[RFC2205] Braden, B., Zhang, L., Berson, S., [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Herzog, S., and S. Jamin, "Resource Jamin, "Resource ReSerVation Protocol (RSVP) --
ReSerVation Protocol (RSVP) -- Version 1 Version 1 Functional Specification", RFC 2205,
Functional Specification", RFC 2205,
September 1997. September 1997.
[RFC2207] Berger, L. and T. O'Malley, "RSVP [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for
Extensions for IPSEC Data Flows", IPSEC Data Flows", RFC 2207, September 1997.
RFC 2207, September 1997.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
J., and L. Zhang, "RSVP Operation Over Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
IP Tunnels", RFC 2746, January 2000. January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
Control", RFC 2750, January 2000. 2750, January 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
Object", RFC 2996, November 2000. 2996, November 2000.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
F., and B. Davie, "Aggregation of RSVP Davie, "Aggregation of RSVP for IPv4 and IPv6
for IPv4 and IPv6 Reservations", Reservations", RFC 3175, September 2001.
RFC 3175, September 2001.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation
Reservation Protocol (RSVP) Extension Protocol (RSVP) Extension for the Reduction of
for the Reduction of Bandwidth of a Bandwidth of a Reservation Flow", RFC 4495, May 2006.
Reservation Flow", RFC 4495, May 2006.
[RFC4542] Baker, F. and J. Polk, "Implementing an [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Emergency Telecommunications Service Telecommunications Service (ETS) for Real-Time
(ETS) for Real-Time Services in the Services in the Internet Protocol Suite", RFC 4542,
Internet Protocol Suite", RFC 4542,
May 2006. May 2006.
7.2. Informative References [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
and M. Davenport, "Generic Aggregate Resource
ReSerVation Protocol (RSVP) Reservations", RFC 4860,
May 2007.
[ITU.MLPP.1990] International Telecommunications Union, 6.2. Informative References
"Multilevel Precedence and Preemption
Service", ITU-T Recommendation I.255.3,
1990.
[RFC0791] Postel, J., "Internet Protocol", STD 5, [ITU.MLPP.1990] International Telecommunications Union, "Multilevel
RFC 791, September 1981. Precedence and Preemption Service", ITU-T
Recommendation I.255.3, 1990.
[RFC1633] Braden, B., Clark, D., and S. Shenker, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
"Integrated Services in the Internet September 1981.
Architecture: an Overview", RFC 1633,
June 1994.
[RFC2209] Braden, B. and L. Zhang, "Resource [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
ReSerVation Protocol (RSVP) -- Version 1 Services in the Internet Architecture: an Overview",
Message Processing Rules", RFC 2209, RFC 1633, June 1994.
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
IETF Integrated Services", RFC 2210, Protocol (RSVP) -- Version 1 Message Processing
September 1997. Rules", RFC 2209, September 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Architecture for the Internet Protocol", Services", RFC 2210, September 1997.
RFC 2401, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Protocol, Version 6 (IPv6) Version 6 (IPv6) Specification", RFC 2460, December
Specification", RFC 2460, December 1998. 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
D. Black, "Definition of the "Definition of the Differentiated Services Field (DS
Differentiated Services Field (DS Field) Field) in the IPv4 and IPv6 Headers", RFC 2474,
in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Davies, E., Wang, Z., and W. Weiss, "An Z., and W. Weiss, "An Architecture for Differentiated
Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
"RSVP Cryptographic Authentication", Cryptographic Authentication", RFC 2747, January
RFC 2747, January 2000. 2000.
[RFC2872] Bernet, Y. and R. Pabbati, "Application [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
and Sub Application Identity Policy Application Identity Policy Element for Use with
Element for Use with RSVP", RFC 2872, RSVP", RFC 2872, June 2000.
June 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Cryptographic Authentication -- Updated Authentication -- Updated Message Type Value", RFC
Message Type Value", RFC 3097, 3097, April 2001.
April 2001.
[RFC3181] Herzog, S., "Signaled Preemption [RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Priority Policy Element", RFC 3181, Element", RFC 3181, October 2001.
October 2001.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
Ford, P., Moore, T., Herzog, S., and R. Moore, T., Herzog, S., and R. Hess, "Identity
Hess, "Identity Representation for Representation for RSVP", RFC 3182, October 2001.
RSVP", RFC 3182, October 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J., [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Benson, K., Le Boudec, J., Courtney, W., Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
Davari, S., Firoiu, V., and D. D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Stiliadis, "An Expedited Forwarding PHB Behavior)", RFC 3246, March 2002.
(Per-Hop Behavior)", RFC 3246,
March 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Camarillo, G., Johnston, A., Peterson, Johnston, A., Peterson, J., Sparks, R., Handley, M.,
J., Sparks, R., Handley, M., and E. and E. Schooler, "SIP: Session Initiation Protocol",
Schooler, "SIP: Session Initiation RFC 3261, June 2002.
Protocol", RFC 3261, June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
Rosenberg, "Integration of Resource "Integration of Resource Management and Session
Management and Session Initiation Initiation Protocol (SIP)", RFC 3312, October 2002.
Protocol (SIP)", RFC 3312, October 2002.
[RFC3473] Berger, L., "Generalized Multi-Protocol [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Label Switching (GMPLS) Signaling Switching (GMPLS) Signaling Resource ReserVation
Resource ReserVation Protocol-Traffic Protocol-Traffic Engineering (RSVP-TE) Extensions",
Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3474] Lin, Z. and D. Pendarakis, [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
"Documentation of IANA assignments for assignments for Generalized MultiProtocol Label
Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol -
Switching (GMPLS) Resource Reservation Traffic Engineering (RSVP-TE) Usage and Extensions
Protocol - Traffic Engineering (RSVP-TE) for Automatically Switched Optical Network (ASON)",
Usage and Extensions for Automatically
Switched Optical Network (ASON)",
RFC 3474, March 2003. RFC 3474, March 2003.
[RFC4303] Kent, S., "IP Encapsulating Security [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Payload (ESP)", RFC 4303, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Phone: +1-408-526-4257 Phone: +1-408-526-4257
skipping to change at page 38, line 45 skipping to change at page 38, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). This document was produced Internet Society.
using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
RFC-2629 XML format.
 End of changes. 192 change blocks. 
554 lines changed or deleted 496 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/