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.