draft-ietf-tsvwg-vpn-signaled-preemption-01.txt   draft-ietf-tsvwg-vpn-signaled-preemption-02.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational P. Bose Intended status: Informational P. Bose
Expires: March 30, 2007 Lockheed Martin Expires: August 6, 2007 Lockheed Martin
September 26, 2006 February 2, 2007
QoS Signaling in a Nested Virtual Private Network QoS Signaling in a Nested Virtual Private Network
draft-ietf-tsvwg-vpn-signaled-preemption-01 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 By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 30, 2007. This Internet-Draft will expire on August 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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, but have sensitivities about what information is portion of a VPN or through a concatenation of such networks
communicated across the boundary. This note seeks to outline the resulting in a nested VPN, but have sensitivities about what
issues and the nature of the proposed solutions. information is communicated across the boundary, especially while
providing quality of service to communications with different
precedence. This note seeks to outline the issues and the nature of
the proposed solutions based on the framework for Integrated Services
operation over DiffServ networks as described in RFC 2998 .
Table of Contents Table of Contents
1. QoS in a nested VPN . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Signaled QoS technology . . . . . . . . . . . . . . . . . 7 1.2. Background Information and Terminology . . . . . . . . . . 4
1.3. The Resource Reservation Protocol (RSVP) . . . . . . . . . 8 1.3. Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Logical structure of a VPN Router . . . . . . . . . . . . 10 1.4. Signaled QoS technology . . . . . . . . . . . . . . . . . 7
1.5. The Resource Reservation Protocol (RSVP) . . . . . . . . . 8
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 network 2.3.1. Initial routine reservations - generating network
state . . . . . . . . . . . . . . . . . . . . . . . . 18 state . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2. Initial routine reservations - request reservation . . 19 2.3.2. Initial routine reservations - request 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
skipping to change at page 2, line 42 skipping to change at page 2, line 38
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 . . . . . . . . . . 26 3.1.2. Ciphertext to Plaintext Data Flows . . . . . . . . . . 26
3.2. VPN Routers that use the Network Guard for signaling 3.2. VPN Routers that use the Network Guard for signaling
across the cryptographic boundary . . . . . . . . . . . . 27 across the cryptographic boundary . . . . . . . . . . . . 27
3.2.1. Signaling Flow . . . . . . . . . . . . . . . . . . . . 28 3.2.1. Signaling Flow . . . . . . . . . . . . . . . . . . . . 28
3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 36 7.2. Informative References . . . . . . . . . . . . . . . . . . 34
1. QoS in a nested VPN 1. Introduction
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, but have sensitivities about what and exterior portion of a VPN or through a concatenation of such
information is communicated across the boundary. This note seeks to networks resulting in a nested VPN, but have sensitivities about what
outline the issues and the nature of the proposed solutions. The information is communicated across the boundary, especially while
outline of the QoS solution for real-time traffic has been described providing quality of service to communications with different
at a high level in [RFC4542]. The key characteristics of this precedence. This note seeks to outline the issues and the nature of
proposal are that the proposed solutions. The outline of the QoS solution for real-
time traffic has been described at a high level in [RFC4542]. The
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
skipping to change at page 3, line 40 skipping to change at page 3, line 44
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 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. As a result, we will discuss the VPN Router form, such as IPsec and their subsequent nesting across multiple
supporting "plaintext" and "ciphertext" interfaces. However, the network domains. This specific type of VPNs is further clarified in
concept extends readily to any form of aggregation, including the Section 1.3 which describes the nested VPN as an example of an IPsec
concept proposed in [RFC3175] of the IP traffic entering and leaving or IPsec like VPN under the context of a 'customer provisioned' VPN.
a network at identified points, and the use of other kinds of tunnels As a result, we will discuss the VPN Router supporting "plaintext"
including GRE, IP/IP, MPLS, and so on. and "ciphertext" interfaces. However, the concept extends readily to
any form of aggregation, including the concept proposed in [RFC3175]
of the IP traffic entering and leaving a network at identified
points, and the use of other kinds of tunnels including GRE, IP/IP,
MPLS, and so on.
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
skipping to change at page 5, line 5 skipping to change at page 5, line 11
some cases, even though the traffic is absolutely critical to the some cases, even though the traffic is absolutely critical to the
network. Telephone call setup exchanges have this characteristic as network. Telephone call setup exchanges have this characteristic as
well: faced with a choice between loss and delay, protocols like SIP well: faced with a choice between loss and delay, protocols like SIP
and H.323 far prefer the latter, as the call setup time is far less and H.323 far prefer the latter, as the call setup time is far less
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.1. Nested VPNs 1.3. Nested VPNs
One could describe such a network in terms of three network diagrams. One could describe a nested VPN network in terms of three network
Figure 1 shows a simple network stretched across a VPN connection. diagrams. Figure 1 shows a simple network stretched across a VPN
The VPN Router (where, following [RFC2460] a "router" is "a node that connection. The VPN Router (where, following [RFC2460] a "router" is
forwards packets not explicitly addressed to itself"), performs the "a node that forwards packets not explicitly addressed to itself"),
following steps: it performs the following steps: it
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 [RFC2401] 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)
skipping to change at page 6, line 16 skipping to change at page 6, line 33
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.
VPN-Router | Router | VPN-Router Hosts Not Visible
/==================/
Router
|
VPN-Router
/---------------------/
Inner Domain
/---------------------/
VPN-Router
|
Router
/==================/
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- cipher text network which, for various reasons, is itself re-
encrypted and transmitted across a larger cipher text network. The encrypted and transmitted across a larger cipher text network. The
reasons for doing this vary, but they relate to information-hiding in reasons for doing this vary, but they relate to information-hiding in
the wider network, different levels of security required for the wider network, different levels of security required for
different enclosed enclaves, and so on. different enclosed enclaves, and so on.
skipping to change at page 7, line 35 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.2. 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 its own words,
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
skipping to change at page 8, line 43 skipping to change at page 8, line 48
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 RSVP and 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.3. 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
skipping to change at page 10, line 23 skipping to change at page 10, line 29
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] [I-D.ietf-tsvwg-rsvp-ipsec] or
[RFC2746]. [RFC2746].
1.4. 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 more
interfaces to the protected enclave(s) and one or more interfaces to interfaces to the protected enclave(s) and one or more interfaces to
the outside world. On the latter, it structures some number of the outside world. On the latter, it structures some number of
tunnels (in the case of an IPsec tunnel, having security 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.
skipping to change at page 15, line 22 skipping to change at page 15, line 22
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 or the same as the DSCP for the data o it will have a DSCP corollary to the DSCP for the data or the same
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:
skipping to change at page 16, line 23 skipping to change at page 16, line 23
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 higher precedence level call, the total reserved bandwidth
after admission may not exceed X+Y, and this may be achieved by after admission may not exceed X+Y, and this may be achieved by
preempting a lower precedence level call"), the bandwidth Y preempting a lower precedence level call"), the bandwidth Y
effectively comes from the bandwidth in use by elastic traffic rather effectively comes from the bandwidth in use by elastic traffic rather
than forcing a preemption event. than forcing a preemption event.
2.2. Preemption in a nested VPN 2.2. Preemption in a nested VPN
As discussed in Section 1.3 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
skipping to change at page 24, line 8 skipping to change at page 24, line 8
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 deliver 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. context of sessions as described in Section 2. It specifically
identifies the signaling flow at a given VPN boundary and
additionally elaborates the signaling mechanism with the aid of a
network guard. A use case describing the proposal in the context of
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 ||
skipping to change at page 27, line 8 skipping to change at page 27, line 8
are carried in the encrypted tunnel as data, and therefore arrive at are carried in the encrypted tunnel as data, and therefore arrive at
the plain text side with other data. As the plain text side the plain text side with other data. As the plain text side
participates in these reservations, some information is returned to participates in these reservations, some information is returned to
the cipher text size to parameterize the aggregate reservation as the cipher text size to parameterize the aggregate reservation as
described in Section 3.1.1 in the processing of the outbound described in 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.4 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 31, line 16 skipping to change at page 31, line 16
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 PIM routing, the
traffic is destined to the remote VPN Router. This means that the traffic is destined to the remote VPN Router. This means that the
Guard must somehow receive and respond to, on behalf of the VPN Guard must somehow receive and respond to, on behalf of the VPN
Router, messages that are not directed to it. There are several Router, messages that are not directed to it. There are several
possible solutions: possible solutions, which need to be carefully selected based on the
security and implementation needs of the environment:
o The two devices could use a common MAC and IP address, so that o In the simplest case, the network guard and encrypt/decrypt unit
traffic destined to one is also received by the other can be two independent functions which utilize a common network
and MAC layer. This can allow the two functions to share a common
MAC and IP address, so that traffic destined for one function is
also received by the other. In the case that these two functions
are physically separated on two devices, they can still share a
common MAC and IP address, however additional modifications may be
required on the Guard to to filter and not process IP traffic not
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. all but the few it is interested in. The security considerations
on putting a device in promiscuous mode at the VPN boundary needs
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. would use the same IP address. This mechanism puts the load of
all data and management traffic destined for the VPN router upon
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
skipping to change at page 33, line 15 skipping to change at page 32, line 26
5. Security Considerations 5. 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 which 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.1 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. are 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 which
can provide the highest security levels. If any VPN Router in the can provide the highest security levels. If any VPN Router in the
skipping to change at page 34, line 5 skipping to change at page 33, line 7
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. The prepended header, therefore, 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
[I-D.ietf-tsvwg-rsvp-ipsec] and [RFC3175]are also applicable in this
environment which include the integrity of RSVP messages can be
ensured via mechanisms described in [RFC2747] and [RFC3097] and
related key management (through manual configuration or a key
management protocol) at nodes between any aggregator and deaggregator
pair that process the messages. In addition confidentiality can be
provided between hops by employing IPsec. Further work in the IETF
MSEC Working Group may be applicable in these environments for key
management and confidentiality.
6. Acknowledgements 6. 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 [I-D.ietf-tsvwg-rsvp-ipsec], which clarified the
interaction of this approach with the DSCP. interaction of this approach with the DSCP.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate RSVP [I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate
Resource ReSerVation Protocol (RSVP)
Reservations", Reservations",
draft-ietf-tsvwg-rsvp-ipsec-01 (work in draft-ietf-tsvwg-rsvp-ipsec-04 (work in
progress), June 2006. progress), January 2007.
[RFC2205] Braden, B., Zhang, L., Berson, S., [RFC2205] Braden, B., Zhang, L., Berson, S.,
Herzog, S., and S. Jamin, "Resource Herzog, S., and S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 ReSerVation Protocol (RSVP) -- 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 IPSEC Data Flows", Extensions for IPSEC Data Flows",
RFC 2207, September 1997. RFC 2207, September 1997.
skipping to change at page 36, line 7 skipping to change at page 34, line 30
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 Telecommunications Service Emergency Telecommunications Service
(ETS) for Real-Time Services in the (ETS) for Real-Time Services in the
Internet Protocol Suite", RFC 4542, Internet Protocol Suite", RFC 4542,
May 2006. May 2006.
7.2. Informative References 7.2. Informative References
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel [ITU.MLPP.1990] International Telecommunications Union,
Precedence and Preemption Service", ITU- "Multilevel Precedence and Preemption
T Recommendation I.255.3, 1990. Service", ITU-T Recommendation I.255.3,
1990.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5,
September 1981. RFC 791, September 1981.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker,
Services in the Internet Architecture: an Overview", "Integrated Services in the Internet
RFC 1633, June 1994. Architecture: an Overview", RFC 1633,
June 1994.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation [RFC2209] Braden, B. and L. Zhang, "Resource
Protocol (RSVP) -- Version 1 Message Processing ReSerVation Protocol (RSVP) -- Version 1
Rules", RFC 2209, September 1997. Message Processing Rules", RFC 2209,
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF [RFC2210] Wroclawski, J., "The Use of RSVP with
Integrated Services", RFC 2210, September 1997. IETF Integrated Services", RFC 2210,
September 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for [RFC2401] Kent, S. and R. Atkinson, "Security
the Internet Protocol", RFC 2401, November 1998. Architecture for the Internet Protocol",
RFC 2401, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, [RFC2460] Deering, S. and R. Hinden, "Internet
Version 6 (IPv6) Specification", RFC 2460, Protocol, Version 6 (IPv6)
December 1998. Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and
"Definition of the Differentiated Services Field (DS D. Black, "Definition of the
Field) in the IPv4 and IPv6 Headers", RFC 2474, Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, [RFC2475] Blake, S., Black, D., Carlson, M.,
Z., and W. Weiss, "An Architecture for Davies, E., Wang, Z., and W. Weiss, "An
Differentiated Services", RFC 2475, December 1998. Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP [RFC2747] Baker, F., Lindell, B., and M. Talwar,
Cryptographic Authentication", RFC 2747, "RSVP Cryptographic Authentication",
January 2000. RFC 2747, January 2000.
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub [RFC2872] Bernet, Y. and R. Pabbati, "Application
Application Identity Policy Element for Use with and Sub Application Identity Policy
RSVP", RFC 2872, June 2000. Element for Use with RSVP", RFC 2872,
June 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP
Authentication -- Updated Message Type Value", Cryptographic Authentication -- Updated
RFC 3097, April 2001. Message Type Value", RFC 3097,
April 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy [RFC3181] Herzog, S., "Signaled Preemption
Element", RFC 3181, October 2001. Priority Policy Element", RFC 3181,
October 2001.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R.,
Moore, T., Herzog, S., and R. Hess, "Identity Ford, P., Moore, T., Herzog, S., and R.
Representation for RSVP", RFC 3182, October 2001. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le [RFC3246] Davie, B., Charny, A., Bennet, J.,
Boudec, J., Courtney, W., Davari, S., Firoiu, V., Benson, K., Le Boudec, J., Courtney, W.,
and D. Stiliadis, "An Expedited Forwarding PHB (Per- Davari, S., Firoiu, V., and D.
Hop Behavior)", RFC 3246, March 2002. Stiliadis, "An Expedited Forwarding PHB
(Per-Hop Behavior)", RFC 3246,
March 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., [RFC3261] Rosenberg, J., Schulzrinne, H.,
Johnston, A., Peterson, J., Sparks, R., Handley, M., Camarillo, G., Johnston, A., Peterson,
and E. Schooler, "SIP: Session Initiation Protocol", J., Sparks, R., Handley, M., and E.
RFC 3261, June 2002. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J.
"Integration of Resource Management and Session Rosenberg, "Integration of Resource
Initiation Protocol (SIP)", RFC 3312, October 2002. Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol
Switching (GMPLS) Signaling Resource ReserVation Label Switching (GMPLS) Signaling
Protocol-Traffic Engineering (RSVP-TE) Extensions", Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA [RFC3474] Lin, Z. and D. Pendarakis,
assignments for Generalized MultiProtocol Label "Documentation of IANA assignments for
Switching (GMPLS) Resource Reservation Protocol - Generalized MultiProtocol Label
Traffic Engineering (RSVP-TE) Usage and Extensions Switching (GMPLS) Resource Reservation
for Automatically Switched Optical Network (ASON)", Protocol - Traffic Engineering (RSVP-TE)
Usage and Extensions for Automatically
Switched Optical Network (ASON)",
RFC 3474, March 2003. RFC 3474, March 2003.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security
RFC 4303, December 2005. 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 39, line 7 skipping to change at page 38, line 7
700 North Frederick Ave 700 North Frederick Ave
Gaithersburg, Maryland 20871 Gaithersburg, Maryland 20871
USA USA
Phone: +1-301-240-7041 Phone: +1-301-240-7041
Fax: +1-301-240-5748 Fax: +1-301-240-5748
EMail: pratik.bose@lmco.com EMail: pratik.bose@lmco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 39, line 49 skipping to change at page 38, line 49
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 Acknowledgements
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.31 (of http://xml.resource.org/) from a source in using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
RFC-2629 XML format. RFC-2629 XML format.
 End of changes. 53 change blocks. 
120 lines changed or deleted 194 lines changed or added

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