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/