draft-ietf-mpls-tp-security-framework-05.txt		draft-ietf-mpls-tp-security-framework-06.txt
	INTERNET-DRAFT L. Fang, Ed.		INTERNET-DRAFT L. Fang, Ed.
	Intended Status: Informational Cisco		Intended Status: Informational Cisco
	Expires: April 20, 2013 B. Niven-Jenkins, Ed.		Expires: June 17, 2013 B. Niven-Jenkins, Ed.
	Velocix		Velocix
	S. Mansfield, Ed.		S. Mansfield, Ed.
	Ericsson		Ericsson
	R. Graveman, Ed.		R. Graveman, Ed.
	RFG Security		RFG Security
	October 20, 2012		December 17, 2012
	MPLS-TP Security Framework		MPLS-TP Security Framework
	draft-ietf-mpls-tp-security-framework-05		draft-ietf-mpls-tp-security-framework-06
	Abstract		Abstract
	This document provides a security framework for Multiprotocol Label		This document provides a security framework for Multiprotocol Label
	Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS		Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS
	technologies and introduces new OAM capabilities, a transport-		technologies and introduces new OAM capabilities, a transport-
	oriented path protection mechanism, and strong emphasis on static		oriented path protection mechanism, and strong emphasis on static
	provisioning supported by network management systems. This document		provisioning supported by network management systems. This document
	addresses the security aspects relevant in the context of MPLS-TP		addresses the security aspects relevant in the context of MPLS-TP
	specifically. It describes potential security threats, security		specifically. It describes potential security threats, security
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	INTERNET DRAFT <Document Title> <Issue Date>
	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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	skipping to change at page 2, line 34		skipping to change at page 2, line 31
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Security Reference Models . . . . . . . . . . . . . . . . . . 4		2. Security Reference Models . . . . . . . . . . . . . . . . . . . 4
	2.1. Security Reference Model 1 . . . . . . . . . . . . . . . . 4		2.1. Security Reference Model 1 . . . . . . . . . . . . . . . . 4
	2.2. Security Reference Model 2 . . . . . . . . . . . . . . . . 6		2.2. Security Reference Model 2 . . . . . . . . . . . . . . . . 6
	3. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 8		3. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Defensive Techniques . . . . . . . . . . . . . . . . . . . . . 8		4. Defensive Techniques . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
	7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1 Normative References . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2 Informative References . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
			8.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 11		Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
	INTERNET DRAFT <Document Title> <Issue Date>		1. Introduction
	1 Introduction
	This document provides a security framework for Multiprotocol Label		This document provides a security framework for Multiprotocol Label
	Switching Transport Profile (MPLS-TP).		Switching Transport Profile (MPLS-TP).
	As defined in MPLS-TP Requirements [RFC5654] and MPLS-TP Framework		As defined in MPLS-TP Requirements [RFC5654] and MPLS-TP Framework
	[RFC5921], MPLS-TP uses a subset of MPLS features and introduces		[RFC5921], MPLS-TP uses a subset of MPLS features and introduces
	extensions to reflect the characteristics of the transport		extensions to reflect the characteristics of the transport
	technology. The additional functionalities include in-band OAM,		technology. The additional functionalities include in-band OAM,
	transport-oriented path protection and recovery mechanisms, and new		transport-oriented path protection and recovery mechanisms, and new
	OAM capabilities developed for MPLS-TP but apply to general MPLS and		OAM capabilities developed for MPLS-TP but apply to general MPLS and
	skipping to change at page 3, line 34		skipping to change at page 3, line 32
	security models, threats, requirements, and defense techniques		security models, threats, requirements, and defense techniques
	previously defined in [RFC5920] are assumed to apply to general		previously defined in [RFC5920] are assumed to apply to general
	aspect of MPLS-TP.		aspect of MPLS-TP.
	This document is a product of a joint Internet Engineering Task Force		This document is a product of a joint Internet Engineering Task Force
	(IETF) / International Telecommunication Union Telecommunication		(IETF) / International Telecommunication Union Telecommunication
	Standardization Sector (ITU-T) effort to include an MPLS Transport		Standardization Sector (ITU-T) effort to include an MPLS Transport
	Profile within the IETF MPLS and PWE3 architectures to support the		Profile within the IETF MPLS and PWE3 architectures to support the
	capabilities and functionality of a packet transport network.		capabilities and functionality of a packet transport network.
	1.1 Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Term Definition		Term Definition
	------ -----------------------------------------------		------ -----------------------------------------------
	AC Attachment Circuit		AC Attachment Circuit
	BFD Bidirectional Forwarding Detection		BFD Bidirectional Forwarding Detection
	CE Customer-Edge device		CE Customer-Edge device
	DoS Denial of Service		DoS Denial of Service
	DDoS Distributed Denial of Service		DDoS Distributed Denial of Service
	G-ACh Generic Associated Channel		G-ACh Generic Associated Channel
	GAL G-ACh Label		GAL G-ACh Label
	GMPLS Generalized Multi-Protocol Label Switching		GMPLS Generalized Multi-Protocol Label Switching
	LDP Label Distribution Protocol		LDP Label Distribution Protocol
	LSP Label Switched Path		LSP Label Switched Path
	MEP Maintenance End Point		MEP Maintenance End Point
	MIP Maintenance Intermediate Point		MIP Maintenance Intermediate Point
	MPLS MultiProtocol Label Switching		MPLS MultiProtocol Label Switching
	INTERNET DRAFT <Document Title> <Issue Date>
	OAM Operations, Administration, and Management		OAM Operations, Administration, and Management
	PE Provider-Edge device		PE Provider-Edge device
	PSN Packet-Switched Network		PSN Packet-Switched Network
	PW Pseudowire		PW Pseudowire
	S-PE Switching Provider Edge		S-PE Switching Provider Edge
	2. Security Reference Models		2. Security Reference Models
	This section defines reference models for security in MPLS-TP		This section defines reference models for security in MPLS-TP
	networks.		networks.
	The models are built on the architecture of MPLS-TP defined in		The models are built on the architecture of MPLS-TP defined in
	[RFC5921]. The placement of Service Provider (SP) boundaries plays		[RFC5921]. The placement of Service Provider (SP) boundaries plays
	important role in determining the security models for any particular		important role in determining the security models for any particular
	deployment.		deployment.
	This document defines a trusted zone as being where a single SP has		This document defines a trusted zone as being where a single SP has
	total operational control over that part of the network. A primary		total operational control over that part of the network. A primary
	concern is about security aspects that relate to breaches of security		concern is about security aspects that relate to breaches of security
	from the "outside" of a trusted zone to the "inside" of this zone.		from the "outside" of a trusted zone to the "inside" of this zone.
	2.1. Security Reference Model 1		2.1. Security Reference Model 1
	In reference model 1, a single SP has total control of the PE/T-PE to		In reference model 1, a single SP has total control of the PE/T-PE to
	PE/T-PE part of the MPLS-TP network.		PE/T-PE part of the MPLS-TP network.
	Security reference model 1(a) An MPLS-TP network with Single Segment		Security reference model 1(a) An MPLS-TP network with Single Segment
	Pseudowire (SS-PW) from PE to PE. The trusted zone is PE1 to PE2 as		Pseudowire (SS-PW) from PE to PE. The trusted zone is PE1 to PE2 as
	illustrated in Figure 1.		illustrated in Figure 1.
	INTERNET DRAFT <Document Title> <Issue Date>
	|<-------------- Emulated Service ---------------->|		|<-------------- Emulated Service ---------------->|
	| |		| |
	| |<------- Pseudo Wire ------>| |		| |<------- Pseudo Wire ------>| |
	| | | |		| | | |
	| | |<-- PSN Tunnel -->| | |		| | |<-- PSN Tunnel -->| | |
	| v v v v |		| v v v v |
	v AC +----+ +----+ AC v		v AC +----+ +----+ AC v
	+-----+ | | PE1|==================| PE2| | +-----+		+-----+ | | PE1|==================| PE2| | +-----+
	| |----------|............PW1.............|----------| |		| |----------|............PW1.............|----------| |
	| CE1 | | | | | | | | CE2 |		| CE1 | | | | | | | | CE2 |
	skipping to change at page 5, line 34		skipping to change at page 5, line 32
	| |		| |
	Native service Native service		Native service Native service
	---Untrusted--- >|<------- Trusted Zone ----->|<---Untrusted----		---Untrusted--- >|<------- Trusted Zone ----->|<---Untrusted----
	Figure 1. MPLS-TP Security Model 1(a)		Figure 1. MPLS-TP Security Model 1(a)
	Security reference model 1(b)		Security reference model 1(b)
	An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to		An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to
	T-PE. The trusted zone is T-PE1 to T-PE2 in this model as illustrated		T-PE. The trusted zone is T-PE1 to T-PE2 in Figure 2.
	in Figure 2.
	Native |<------------Pseudowire---------->| Native		Native |<------------Pseudowire---------->| Native
	Service | | Service		Service | | Service
	(AC) | |<- PSN ->| |<- PSN ->| | (AC)		(AC) | |<- PSN ->| |<- PSN ->| | (AC)
	| v v v v v v |		| v v v v v v |
	| +----+ +----+ +----+ |		| +----+ +----+ +----+ |
	+----+ | |TPE1|=========|SPE1|=========|TPE2| | +----+		+----+ | |TPE1|=========|SPE1|=========|TPE2| | +----+
	| |------|.....PW.Seg't1......PW.Seg't3.....|-------| |		| |------|.....PW.Seg't1......PW.Seg't3.....|-------| |
	| CE1| | | | | | | | | |CE2 |		| CE1| | | | | | | | | |CE2 |
	| |------|.....PW.Seg't2......PW.Seg't4.....|-------| |		| |------|.....PW.Seg't2......PW.Seg't4.....|-------| |
	+----+ | | |=========| |=========| | | +----+		+----+ | | |=========| |=========| | | +----+
	^ +----+ ^ +----+ ^ +----+ ^		^ +----+ ^ +----+ ^ +----+ ^
	| | | |		| | | |
	| TP LSP TP LSP |		| TP LSP TP LSP |
	| |		| |
	|<---------------- Emulated Service -------------->|		|<---------------- Emulated Service -------------->|
	-- Untrusted->|<--------- Trusted Zone --------->|<-Untrusted--		-- Untrusted->|<--------- Trusted Zone --------->|<-Untrusted--
	INTERNET DRAFT <Document Title> <Issue Date>
	Figure 2. MPLS-TP Security Model 1(b)		Figure 2. MPLS-TP Security Model 1(b)
	2.2. Security Reference Model 2		2.2. Security Reference Model 2
	In reference model 2, a single SP does not have total control of the		In reference model 2, a single SP does not have total control of the
	PE/T-PE to PE/T-PE part of the MPLS-TP network. S-PE and T-PE may be		PE/T-PE to PE/T-PE part of the MPLS-TP network. S-PE and T-PE may be
	under the control of different SPs, or their customers or may not be		under the control of different SPs, or their customers or may not be
	trusted for some other reason. The MPLS-TP network is not contained		trusted for some other reason. The MPLS-TP network is not contained
	within a single trusted zone.		within a single trusted zone.
	Security Reference Model 2(a)		Security Reference Model 2(a)
	An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to		An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to
	skipping to change at page 6, line 41		skipping to change at page 6, line 37
	+----+ | | |=========| |=========| | | +----+		+----+ | | |=========| |=========| | | +----+
	^ +----+ ^ +----+ ^ +----+ ^		^ +----+ ^ +----+ ^ +----+ ^
	| | | |		| | | |
	| TP LSP TP LSP |		| TP LSP TP LSP |
	| |		| |
	|<--------------- Emulated Service ------------->|		|<--------------- Emulated Service ------------->|
	-- Untrusted-->|<-- Trusted Zone-->|<---------Untrusted--------		-- Untrusted-->|<-- Trusted Zone-->|<---------Untrusted--------
	Figure 3. MPLS-TP Security Model 2(a)		Figure 3. MPLS-TP Security Model 2(a)
	Security Reference Model 2(b)		Security Reference Model 2(b)
	An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to		An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to
	T-PE. The trusted zone is the S-PE, as illustrated in Figure 4.		T-PE. The trusted zone is the S-PE, as illustrated in Figure 4.
	INTERNET DRAFT <Document Title> <Issue Date>
	Native |<------------Pseudowire---------->| Native		Native |<------------Pseudowire---------->| Native
	Service | | Service		Service | | Service
	(AC) | |<--PSN-->| |<--PSN-->| | (AC)		(AC) | |<--PSN-->| |<--PSN-->| | (AC)
	| V V V V V V |		| V V V V V V |
	| +----+ +----+ +----+ |		| +----+ +----+ +----+ |
	+----+ | |TPE1|=========|SPE1|=========|TPE2| | +----+		+----+ | |TPE1|=========|SPE1|=========|TPE2| | +----+
	| |------|.....PW.Seg't1......PW.Seg't3.....|------| |		| |------|.....PW.Seg't1......PW.Seg't3.....|------| |
	| CE1| | | | | | | | | |CE2 |		| CE1| | | | | | | | | |CE2 |
	| |------|.....PW.Seg't2......PW.Seg't4.....|------| |		| |------|.....PW.Seg't2......PW.Seg't4.....|------| |
	+----+ | | |=========| |=========| | | +----+		+----+ | | |=========| |=========| | | +----+
	skipping to change at page 8, line 4		skipping to change at page 8, line 4
	+----+ +-+ +----+ +----+ +-+ +----+		+----+ +-+ +----+ +----+ +-+ +----+
	|<- Subnetwork 123->| |<- Subnetwork XYZ->|		|<- Subnetwork 123->| |<- Subnetwork XYZ->|
	Untrusted>|<- Trusted Zone - >|<-------------Untrusted---------------		Untrusted>|<- Trusted Zone - >|<-------------Untrusted---------------
	Figure 5. MPLS-TP Security Model 2(c)		Figure 5. MPLS-TP Security Model 2(c)
	In general, the boundaries of a trusted zone must be carefully		In general, the boundaries of a trusted zone must be carefully
	defined when analyzing the security properties of each individual		defined when analyzing the security properties of each individual
	network. The security boundaries determine which reference model		network. The security boundaries determine which reference model
	INTERNET DRAFT <Document Title> <Issue Date>
	should be applied to given network topology.		should be applied to given network topology.
	3. Security Threats		3. Security Threats
	This section discuss various network security threats which are to		This section discuss various network security threats which are to
	MPLS-TP and may endanger MPLS-TP networks.		MPLS-TP and may endanger MPLS-TP networks.
	A successful attack on a particular MPLS-TP network or on a SP's		A successful attack on a particular MPLS-TP network or on a SP's
	MPLS-TP infrastructure may cause one or more adverse effects.		MPLS-TP infrastructure may cause one or more adverse effects.
	skipping to change at page 9, line 4		skipping to change at page 9, line 4
	4. Defensive Techniques		4. Defensive Techniques
	The defensive techniques presented in this document and in [RFC5920]		The defensive techniques presented in this document and in [RFC5920]
	are intended to describe methods by which some security threats can		are intended to describe methods by which some security threats can
	be addressed. They are not intended as requirements for all MPLS-TP		be addressed. They are not intended as requirements for all MPLS-TP
	deployments. The specific operational environment determines the		deployments. The specific operational environment determines the
	security requirements for any instance of MPLS-TP. Therefore,		security requirements for any instance of MPLS-TP. Therefore,
	protocol designers should provide a full set of security		protocol designers should provide a full set of security
	capabilities, which can be selected and used where appropriate. The		capabilities, which can be selected and used where appropriate. The
	INTERNET DRAFT <Document Title> <Issue Date>
	MPLS-TP provider should determine the applicability of these		MPLS-TP provider should determine the applicability of these
	techniques to the provider's specific service offerings, and the end		techniques to the provider's specific service offerings, and the end
	user may wish to assess the value of these techniques to the user's		user may wish to assess the value of these techniques to the user's
	service requirements.		service requirements.
	The techniques discussed here include entity authentication for		The techniques discussed here include entity authentication for
	identity verification, encryption for confidentiality, message		identity verification, encryption for confidentiality, message
	integrity and replay detection to ensure the validity of message		integrity and replay detection to ensure the validity of message
	streams, network- based access controls such as packet filtering and		streams, network- based access controls such as packet filtering and
	firewalls, host-based access controls, isolation, aggregation,		firewalls, host-based access controls, isolation, aggregation,
	skipping to change at page 9, line 49		skipping to change at page 9, line 46
	The defense techniques are apply generally to MPLS/GMPLS are not		The defense techniques are apply generally to MPLS/GMPLS are not
	detailed here, for example: 1) Authentication: including Management		detailed here, for example: 1) Authentication: including Management
	System Authentication, Peer-to-Peer Authentication, Cryptographic		System Authentication, Peer-to-Peer Authentication, Cryptographic
	Techniques for Authenticating Identity; 2) Access Control Techniques;		Techniques for Authenticating Identity; 2) Access Control Techniques;
	3) Use of Aggregated Infrastructure; 4) Use of Aggregated		3) Use of Aggregated Infrastructure; 4) Use of Aggregated
	Infrastructure; 5) Mitigation of Denial of Service Attacks; 6)		Infrastructure; 5) Mitigation of Denial of Service Attacks; 6)
	Monitoring, Detection, and Reporting of Security Attacks. Please		Monitoring, Detection, and Reporting of Security Attacks. Please
	refer to [RFC5920] for details.		refer to [RFC5920] for details.
	5. Security Considerations		5. Security Considerations
	Security considerations constitute the sole subject of this document		Security considerations constitute the sole subject of this document
	and hence are discussed throughout.		and hence are discussed throughout.
	This document evaluates MPLS-TP specific security risks and		This document evaluates MPLS-TP specific security risks and
	INTERNET DRAFT <Document Title> <Issue Date>
	mitigation mechanisms which may be used to counter the potential		mitigation mechanisms which may be used to counter the potential
	threats. All of the techniques presented involve mature and widely		threats. All of the techniques presented involve mature and widely
	implemented technologies that are practical to implement. It is meant		implemented technologies that are practical to implement. It is meant
	to assist equipment vendors and service providers, who must		to assist equipment vendors and service providers, who must
	ultimately decide what threats to protect against in any given		ultimately decide what threats to protect against in any given
	configuration or service offering from a customer's perspective as		configuration or service offering from a customer's perspective as
	well as from a service provider's perspective.		well as from a service provider's perspective.
	6. IANA Considerations		6. IANA Considerations
	This document contains no new IANA considerations.		This document contains no new IANA considerations.
	7 References		7. Acknowledgements
	7.1 Normative References		The authors wish to thank Joel Halpern and Gregory Mirsky for their
			review comments and contributions to this document, thank Adrian
			Farrel for his Routing AD review and detailed comments, and thank Loa
			Andersson for his continued support and guidance as the MPLS WG co-
			Chair.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		8. References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
			8.1. Normative References
	[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,		[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
	Sprecher, N., and S. Ueno, "Requirements of an MPLS		Sprecher, N., and S. Ueno, "Requirements of an MPLS
	Transport Profile", RFC 5654, September 2009.		Transport Profile", RFC 5654, September 2009.
	[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.		Networks", RFC 5920, July 2010.
	7.2 Informative References		8.2. Informative References
	[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,		[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
	L., and L. Berger, "A Framework for MPLS in Transport		L., and L. Berger, "A Framework for MPLS in Transport
	Networks", RFC 5921, July 2010.		Networks", RFC 5921, July 2010.
	Authors' Addresses		Authors' Addresses
	Luyuan Fang (editor)		Luyuan Fang (editor)
	Cisco Systems		Cisco Systems
	111 Wood Ave. South		111 Wood Ave. South
	Iselin, NJ 08830, US		Iselin, NJ 08830, US
	Email: lufang@cisco.com		Email: lufang@cisco.com
	Ben Niven-Jenkins (editor)		Ben Niven-Jenkins (editor)
	Velocix		Velocix
	326 Cambridge Science Park		326 Cambridge Science Park
	Milton Road		Milton Road
	Cambridge CB4 0WG, UK		Cambridge CB4 0WG, UK
	Email: ben@niven-jenkins.co.uk		Email: ben@niven-jenkins.co.uk
	INTERNET DRAFT <Document Title> <Issue Date>
	Scott Mansfield (editor)		Scott Mansfield (editor)
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134, US		San Jose, CA 95134, US
	Email: scott.mansfield@ericsson.com		Email: scott.mansfield@ericsson.com
	Richard F. Graveman (editor)		Richard F. Graveman (editor)
	RFG Security, LLC		RFG Security, LLC
	15 Park Avenue		15 Park Avenue
	Morristown, NJ 07960, US		Morristown, NJ 07960, US
	Email: rfg@acm.org		Email: rfg@acm.org
	Contributors' Addresses		Contributors' Addresses
	Raymond Zhang		Raymond Zhang
	Alcatel-Lucent		Alcatel-Lucent
	701 Middlefield Road		750D Chai Chee Road
	Mountain View, CA 94043, US		Singapore 469004
	Email: raymond.zhang@alcatel-lucent.com		Email: raymond.zhang@alcatel-lucent.com
	Nabil Bitar		Nabil Bitar
	Verizon		Verizon
	40 Sylvan Road		40 Sylvan Road
	Waltham, MA 02145, US		Waltham, MA 02145, US
	Email: nabil.bitar@verizon.com		Email: nabil.bitar@verizon.com
	Masahiro Daikoku		Masahiro Daikoku
	KDDI Corporation		KDDI Corporation
End of changes. 28 change blocks.
	58 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/