INTERNET-DRAFT
Internet Engineering Task Force (IETF)                      L. Fang, Ed.
Intended Status: Informational
Request for Comments: 6941                                         Cisco
Expires: August 25, 2013
Category: Informational                            B. Niven-Jenkins, Ed.
ISSN: 2070-1721                                                  Velocix
                                                       S. Mansfield, Ed.
                                                                Ericsson
                                                        R. Graveman, Ed.
                                                            RFG Security

                                                       February 25,
                                                              April 2013

                      MPLS-TP

          MPLS Transport Profile (MPLS-TP) Security Framework
                draft-ietf-mpls-tp-security-framework-09

Abstract

   This document provides a security framework for Multiprotocol Label
   Switching the MPLS Transport
   Profile (MPLS-TP).  MPLS-TP extends MPLS technologies and introduces
   new OAM Operations, Administration, and Maintenance (OAM) capabilities, a transport-
   oriented
   transport-oriented path protection mechanism, and strong emphasis on
   static provisioning supported by network management systems.  This
   document addresses the security aspects relevant in the context of
   MPLS-TP specifically.  It describes potential security threats, security
   requirements for MPLS-TP, and threats as
   well as mitigation procedures for related to MPLS-TP networks and to
   MPLS-TP interconnection to other MPLS and GMPLS networks.  This
   document is built on RFC5920 "MPLS RFC 5920 ("Security Framework for MPLS and GMPLS security
   framework"
   Networks") by providing additional security considerations which that are
   applicable to the MPLS-TP extensions.  All the security
   considerations from RFC5920 RFC 5920 are assumed to apply.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 Pseudowire Emulation Edge-to-Edge
   (PWE3) architectures to support the capabilities and functionality of
   a packet transport network.

Status of this This Memo

   This Internet-Draft document is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html
   http://www.rfc-editor.org/info/rfc6941.

Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................3
      1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3 ................................................3
   2. Security Reference Models . . . . . . . . . . . . . . . . . . .  4 .......................................4
      2.1. Security Reference Model 1  . . . . . . . . . . . . . . . .  4 .................................5
      2.2. Security Reference Model 2  . . . . . . . . . . . . . . . .  6 .................................6
   3. Security Threats  . . . . . . . . . . . . . . . . . . . . . . .  8 ................................................9
   4. Defensive Techniques  . . . . . . . . . . . . . . . . . . . . .  9 ...........................................10
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 ........................................12
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 11
   8. ...............................................13
   7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1. .....................................................13
      7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2. ......................................13
      7.2. Informative References  . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Contributors' Addresses  . . . . . . . . . . . . . . . . . . . . . 12 ....................................13
   Contributors ......................................................14

1.  Introduction

   This document provides a security framework for Multiprotocol Label
   Switching the MPLS Transport
   Profile (MPLS-TP).

   As defined in MPLS-TP Requirements "Requirements of an MPLS Transport Profile" [RFC5654]
   and MPLS-TP "A Framework for MPLS in Transport Networks" [RFC5921], MPLS-TP
   uses a subset of MPLS features and introduces extensions to reflect
   the characteristics of the transport technology.  The additional
   functionality include includes in-band OAM, transport-oriented path
   protection and recovery mechanisms, and new OAM capabilities that
   were developed for MPLS-TP but that also apply to general MPLS and GMPLS.
   There is strong emphasis in MPLS-TP on static provisioning support
   through network management systems (NMS) Network Management Systems (NMSs) or Operation Operational Support
   Systems (OSS). (OSSs).

   This document is built on RFC 5920 [RFC5920] by providing additional security
   considerations which that are applicable to the MPLS-TP extensions.  The
   security models, threats, requirements, and defense techniques previously defined
   in [RFC5920] are assumed to apply to general
   aspect aspects of MPLS-TP.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionality of a packet transport network.

   Readers can refer to [RFC5654] and [RFC5921] for MPLS-TP
   terminologies,
   terminologies and to [RFC5920] for security terminologies which that are
   relevant to MPLS and GMPLS.

1.1.  Terminology

   Term       Definition
   ------     -----------------------------------------------
   AC         Attachment Circuit
   BFD        Bidirectional Forwarding Detection
   CE       Customer-Edge device         Customer Edge
   DoS        Denial of Service
   G-ACh      Generic Associated Channel
   GAL        G-ACh Label
   GMPLS      Generalized Multi-Protocol Multiprotocol Label Switching
   IP         Internet Protocol
   LDP        Label Distribution Protocol
   LSP        Label Switched Path
   NMS        Network Management System
   MPLS     MultiProtocol       Multiprotocol Label Switching
   MPLS-TP  MultiProtocol Label Switching    MPLS Transport Profile
   MS-PW      Multi-Segment Pseudowire
   OAM        Operations, Administration, and Maintenance
   PE       Provider-Edge device         Provider Edge
   PSN        Packet-Switched Network
   PW         Pseudowire
   S-PE       PW Switching Provider Edge
   SP         Service Provider
   SS-PW      Single-Segment Pseudowire
   T-PE       PW Terminating Provider Edge

2.  Security Reference Models

   This section defines reference models for security in MPLS-TP
   networks.

   The models are built on the architecture of MPLS-TP MPLS-TP, as defined in
   [RFC5921].  The placement of Service Provider (SP) SP boundaries plays an important role in
   determining the security models for any particular deployment.

   This document defines a trusted zone as being where a single SP has
   total operational control over that part of the network.  A primary
   concern is about security aspects that relate to breaches of security
   from the "outside" of a trusted zone to the "inside" of this zone.

2.1.  Security Reference Model 1

   In reference model 1, a single SP has total control of the PE/T-PE "PE/T-PE
   to
   PE/T-PE PE/T-PE" part of the MPLS-TP network.

   Security reference model 1(a)

   An shows an MPLS-TP network with Single Segment
   Single-Segment Pseudowire (SS-PW) from PE1 to PE2.  The trusted zone
   is PE1 to PE2 PE2, as illustrated in Figure 1.

           |<-------------- Emulated Service ---------------->|
           |                                                  |
           |          |<------- Pseudo Wire ------>| Pseudowire ------->|          |
           |          |                            |          |
           |          |    |<-- PSN Tunnel -->|    |          |
           |          v    v                  v    v          |
           v    AC    +----+                  +----+     AC   v
     +-----+    |     | PE1|==================| PE2|     |    +-----+
     |     |----------|............PW1.............|----------|     |
     | CE1 |    |     |    |                  |    |     |    | CE2 |
     |     |----------|............PW2.............|----------|     |
     +-----+  ^ |     |    |==================|    |     | ^  +-----+
           ^  |       +----+                  +----+     | |  ^
           |  |   Provider Edge 1         Provider Edge 2  |  |
           |  |                                            |  |
     Customer |                                            |Customer
     Edge 1   |                                            |Edge 2
              |                                            |
        Native service                               Native service

     ---Untrusted--- >|<------- Trusted Zone ----->|<---Untrusted----

                  Figure 1.  MPLS-TP Security Model 1(a)
   Security reference model 1(b)

   An shows an MPLS-TP network with
   Multi-Segment Pseudowire (MS-PW) from T-PE1 to T-PE2.  The trusted
   zone is T-PE1 to T-PE2 T-PE2, as illustrated in Figure 2.

         Native  |<-------------Pseudowire------------>|  Native
         Service |                                     |  Service
          (AC)   |     |<- PSN ->|     |<- PSN ->|     |   (AC)
            |    v     v         v     v         v     v     |
            |    +-----+         +-----+         +-----+     |
     +----+ |    |T-PE1|=========|S-PE1|=========|T-PE2|     | +----+
     |    |------|......PW.Seg't1.......PW.Seg't3......|-------|    |
     | CE1| |    |     |         |     |         |     |     | |CE2 |
     |    |------|......PW.Seg't2.......PW.Seg't4......|-------|    |
     +----+ |    |     |=========|     |=========|     |     | +----+
          ^      +-----+    ^    +-----+     ^   +-----+        ^
          |                 |                |                  |
          |               TP LSP            TP LSP              |
          |                                                     |
          |<----------------- Emulated Service ---------------->|

     -Untrusted->|<---------- Trusted Zone ----------->|<-Untrusted--

                  Figure 2.  MPLS-TP Security Model 1(b)

2.2.  Security Reference Model 2

   In reference model 2, a single SP does not have the end-to-end
   control of the segment from PE/T-PE to PE/T-PE. Some S-PE(s), T-PE(s)  A given S-PE or T-PE
   may be under the control of other SPs, or the another SP, that SP's customers, or its
   partners.  In this case, the MPLS-TP network is not contained within
   a single trusted zone.

   Security Reference Model reference model 2(a)

   An shows an MPLS-TP network with
   Multi-Segment Pseudowire (MS-PW) from T-PE1 to T-PE2.  The trusted
   zone is T-PE1 to S-PE1, as illustrated in Figure 3.

         Native  |<-------------Pseudowire------------>| Native
         Service |                                     | Service
          (AC)   |     |<--PSN-->|     |<--PSN-->|     |  (AC)
            |    V     V         V     V         V     V    |
            |    +-----+         +-----+         +-----+    |
     +----+ |    |T-PE1|=========|S-PE1|=========|T-PE2|    | +----+
     |    |------|......PW.Seg't1.......PW.Seg't3......|------|    |
     | CE1| |    |     |         |     |         |     |    | |CE2 |
     |    |------|......PW.Seg't2.......PW.Seg't4......|------|    |
     +----+ |    |     |=========|     |=========|     |    | +----+
          ^      +-----+    ^    +-----+     ^   +-----+      ^
          |                 |                |                |
          |               TP LSP            TP LSP            |
          |                                                   |
          |<---------------- Emulated Service --------------->|

     Untrusted-->|<-- Trusted Zone---->|<---------Untrusted--------

                  Figure 3.  MPLS-TP Security Model 2(a)
   Security Reference Model reference model 2(b)

   An shows an MPLS-TP network with
   Multi-Segment Pseudowire (MS-PW) from T-PE1 to T-PE2.  The trusted
   zone is the S-PE1 only, as illustrated in Figure 4.

         Native  |<-------------Pseudowire------------>| Native
         Service |                                     | Service
          (AC)   |     |<--PSN-->|     |<--PSN-->|     |  (AC)
            |    V     V         V     V         V     V    |
            |    +-----+         +-----+         +-----+    |
     +----+ |    |T-PE1|=========|S-PE1|=========|T-PE2|    | +----+
     |    |------|......PW.Seg't1.......PW.Seg't3......|------|    |
     | CE1| |    |     |         |     |         |     |    | |CE2 |
     |    |------|......PW.Seg't2.......PW.Seg't4......|------|    |
     +----+ |    |     |=========|     |=========|     |    | +----+
          ^      +-----+    ^    +-----+     ^   +-----+      ^
          |                 |                |                |
          |               TP LSP            TP LSP            |
          |                                                   |
          |<---------------- Emulated Service --------------->|

     --------Untrusted---------->|<--->|<-------Untrusted----------
                                 Trusted
                                  Zone

                  Figure 4.  MPLS-TP Security Model 2(b)

   Security Reference Model reference model 2(c)

   An shows an MPLS-TP network with
   Multi-Segment Pseudowire (MS-PW) from different Service Providers SPs with
   inter-provider PW connections.  The trusted zone is T-PE1 to S-PE3,
   as illustrated in Figure 5.

     Native  |<--------------------- PW15 ------------------>| Native
      Layer  |                                               | Layer
    Service  |     |<PSN13>|     |<PSN3X>|     |<PSNXZ>|     | Service
      (AC1)  V     V  LSP  V     V  LSP  V     V  LSP  V     V (AC2)
          |  +-----+  +-+  +-----+       +-----+  +-+  +-----+ |
    +---+ |  |T-PE1|  | |  |S-PE3|       |S-PEX|  | |  |T-PEZ| | +---+
    |   | |  |     |=======|     |=======|     |=======|     | | |   |
    |CE1|----|........PW1........|..PW3..|........PW5........|---|CE2|
    |   | |  |     |=======|     |=======|     |=======|     | | |   |
    +---+    |  1  |  |2|  |  3  |       |  X  |  |Y|  |  Z  |   +---+
             +-----+  +-+  +-----+       +-----+  +-+  +-----+
             |<--Subnetwork 123->|       |<--Subnetwork XYZ->|

   Untrusted>|<-- Trusted Zone-->|<-------------Untrusted-------------

                  Figure 5.  MPLS-TP Security Model 2(c)
   In general, the boundaries of a trusted zone must be carefully
   defined when analyzing the security properties of each individual
   network.  The security boundaries determine which reference model
   should be applied to a given network topology.

3.  Security Threats

   This section discusses various network security threats that are
   unique to MPLS-TP and may endanger MPLS-TP networks.

   Attacks to against a GAL or G-ACh may include: include the following:

   - GAL or BFD label manipulation, which includes insertion of false
     labels and modification, deletion, or replay of messages.

   - DoS attack attacks through in-band OAM by generating excessive G-ACh/GAL
     and BFD messages which that consume significant bandwidth and potentially
     cause congestion.

   These attacks can cause unauthorized protection switchover, inability
   to restore, restore one or more LSPs, or loss of network connectivity.

   When a an NMS is used for LSP setup, the attacks to on the NMS can cause the
   above effect effects as well.  Although this is not unique to MPLS-TP,
   MPLS-TP
   network networks can be particularly vulnerable to NMS attack attacks, due
   to the fact that static provisioning through NMS NMSs is a commonly used
   model.  In the static provisioning model, a compromised NMS can
   potentially be comparable to a comprised compromised control plane plus a comprised
   compromised management plane in the dynamic controlled network model.

   Attacks to NMS on NMSs may come from either external attackers, attackers or insiders.
   Outside attacks are initiated outside of the trusted zone by
   unauthorized
   user users of the MPLS-TP network management systems. NMSs.  Insider attack is attacks are
   initiated from inside of the trusted zone by an entity with that has
   authorized access to the management systems, systems but that performs
   unapproved
   harmful functions that are harmful to the MPLS-TP networks.  These
   attacks may be directly targeted to target the NMS, or NMS; they may also take place via the
   compromised communication channels between the NMS and the network
   devices that are being provisioned, or through the user access of the users to the
   provisioning tools. The  This type of security threat may include
   disclosure of information, generating false OAM messages, taking down
   MPLS-TP LSPs, connecting to the wrong MPLS-TP tunnel end points, endpoints, and
   DoS attacks to on the MPLS-
   TP MPLS-TP networks.

   There are other more generic security threat, threats, such as: Unauthorized as unauthorized
   observation of data traffic (including traffic pattern analysis),
   modification,
   modification or deletion of a provider's or user's data, as well as and replay
   or insertion of inauthentic data into a provider's or user's data
   stream.  These types of attacks apply to MPLS-TP traffic regardless
   of how the LSP or PW is set up up, in a similar way that is similar to how they
   apply to MPLS traffic regardless of how the LSP is set up.  More
   details on the above mentioned threat above-mentioned threats are documented in [RFC5920].

   The

   Such threats may be resulting result from malicious behavior or accidental
   errors. errors:

   Example 1: Attack Attacks from users: Users of the MPLS-TP network may
      attack the network infrastructure or attack other users.

   Example 2: Attack Attacks from insiders: Employees of the operators may
      attack the MPLS-TP network, especially through NMS. NMSs.

   Example 3: Attack Attacks from inter-connecting interconnecting SPs or other partners: Other
      SPs may attack the MPLS-TP network, particularly through the inter-
   provider
      inter-provider connections.

   Example 4: Attack Attacks as the result of operation operational errors: Operation Operations
      staff may fail to follow the operational procedures or may make
      operational mistakes.

4.  Defensive Techniques

   The defensive techniques presented in this document and in [RFC5920]
   are intended to describe methods by which some security threats can
   be addressed.  They are not intended as requirements for all MPLS-TP
   deployments.  The specific operational environment determines the
   security requirements for any instance of MPLS-TP.  Therefore,
   protocol designers should provide a full set of security
   capabilities, which capabilities
   that can be selected and used where appropriate.  The MPLS-TP
   provider should determine the applicability of these 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 service
   requirements.

   Authentication is the primary defense technique to mitigate the risk
   of the MPLS-TP security threat "GAL threats discussed in Section 3 (GAL or BFD
   label manipulation", manipulation, and
   "DoS attack DoS attacks through in-band OAM" discussed in Section 3. OAM).
   Authentication refers to methods to ensure that message sources are
   properly identified by the MPLS-TP devices with which they
   communicate.  Authentication includes the following:

   - entity authentication for identity verification, verification

   - management system authentication, authentication

   - peer-to-peer
   authentication, authentication
   - message integrity and replay detection to ensure the validity of
     message streams, streams

   - network-based access controls such as packet filtering and firewalls,
     firewalls

   - host-based access controls,
   isolation, aggregation, controls

   - isolation

   - aggregation

   - protection against denial of service, and service

   - event logging. Where logging

   Section 5.2 of [RFC5920] describes these techniques where they apply
   to MPLS and GMPLS in
   general, they are described in Section 5.2 of [RFC5920]. general.

   In addition to authentication, the following defense should also be
   considered in order to protect MPLS-TP networks. networks:

   - Use of Isolated Infrastructure isolated infrastructure for MPLS-TP

   One way to protect the MPLS-TP infrastructure network is to use dedicated
   network resources to provide MPLS-TP transport services.  For
   example, in security model 2 (Section 2.2), the potential risk of
   attacks on the S-PE1 or T-PE1 in the trusted zone may be reduced by
   using non-IP-based communication paths, so that the paths in the
   trusted zone cannot be reached from the outside via IP.

   - Verification of Connectivity connectivity

   To protect against deliberate or accidental misconnection, mechanisms
   can be put in place to verify both end-to-end connectivity and
   segment-by-segment resources.  These mechanisms can trace the routes
   of LSPs in both the control plane and the data plane.  Note that the
   connectivity verification tools are now developed for general MPLS
   networks as well.

   The defense techniques are that apply generally to MPLS/GMPLS are not
   detailed here, here; see [RFC5920] for details regarding these techniques.
   For example:

   1) Authentication: including Management System Authentication,
      Peer-to-Peer Authentication, Cryptographic Techniques including management system authentication,
      peer-to-peer authentication, and cryptographic techniques for
      Authenticating Identity;
      authenticating identity

   2) Access Control Techniques; control techniques

   3) Use of Aggregated Infrastructure; aggregated infrastructure

   4) Mitigation of Denial of Service Attacks; denial-of-service attacks

   5) Monitoring, Detection, detection, and Reporting reporting of Security Attacks.

   Readers can refer to [RFC5920] for details. security attacks

   It is important to point out the following security defense
   techniques which
   techniques, as they are particularly critical for NMS NMSs, due to the
   strong emphasis on static provisioning supported by NMS NMSs in MPLS-TP
   deployment.
   deployments.  These techniques include: Entity include the following:

   - entity authentication for identity verification, verification

   - encryption for confidentiality, confidentiality

   - message integrity and replay detection to ensure the validity of
     message
   streams, as well as users streams

   - user access control and events logging event logging, which must be applied for NMS
     NMSs and provisioning applications. applications

5.  Security Considerations

   Security considerations constitute the sole subject of this document
   and hence are discussed throughout.

   This document evaluates MPLS-TP specific security risks and specific to MPLS-TP, as well
   as mitigation mechanisms which that may be used to counter the potential
   threats.  All of the techniques presented here involve mature and
   widely implemented technologies that are practical to implement.  It
   is meant to assist equipment vendors and service providers, providers who must
   ultimately decide what threats to protect against in any given
   configuration or service offering offering, from a customer's perspective as
   well as from a service provider's perspective.

6. IANA Considerations

      This document contains no new IANA considerations.

7.  Acknowledgements

   The authors wish to thank the following people: Joel Halpern and
   Gregory Mirsky for their review comments and contributions to this
   document, thank Mach Chen for his review and suggestions, thank Adrian Farrel for
   his Routing
   AD Area Director review and detailed comments, thank Loa Andersson
   for his continued support and guidance as the MPLS WG co-Chair, co-chair, and thank
   Dan Romascanu and Barry Leiba for their helpful comments during IESG
   review.

8.

7.  References

8.1.

7.1.  Normative References

   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, September 2009.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

8.2.

7.2.  Informative References

   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
              L., and L. Berger, "A Framework for MPLS in Transport
              Networks", RFC 5921, July 2010.

Contributors

   Raymond Zhang
   Alcatel-Lucent
   750D Chai Chee Road
   Singapore  469004

   EMail: raymond.zhang@alcatel-lucent.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145
   US

   EMail: nabil.bitar@verizon.com

   Masahiro Daikoku
   KDDI Corporation
   3-11-11 Iidabashi, Chiyodaku, Tokyo
   Japan

   EMail: ms-daikoku@kddi.com

   Lei Wang
   Lime Networks
   Strandveien 30, 1366 Lysaker
   Norway

   EMail: lei.wang@limenetworks.no

   Henry Yu
   TW Telecom
   10475 Park Meadow Drive
   Littleton, CO  80124
   US

   EMail: henry.yu@twtelecom.com

Authors' Addresses

   Luyuan Fang (editor)
   Cisco Systems
   111 Wood Ave. South
   Iselin, NJ 08830,  08830
   US
   Email:

   EMail: lufang@cisco.com

   Ben Niven-Jenkins (editor)
   Velocix
   326 Cambridge Science Park
   Milton Road
   Cambridge  CB4 0WG, 0WG
   UK
   Email:

   EMail: ben@niven-jenkins.co.uk

   Scott Mansfield (editor)
   Ericsson
   300 Holger Way
   San Jose, CA 95134,  95134
   US
   Email:

   EMail: scott.mansfield@ericsson.com

   Richard F. Graveman (editor)
   RFG Security, LLC
   15 Park Avenue
   Morristown, NJ 07960,  07960
   US
   Email:

   EMail: rfg@acm.org

Contributors' Addresses

   Raymond Zhang
   Alcatel-Lucent
   750D Chai Chee Road
   Singapore 469004
   Email: raymond.zhang@alcatel-lucent.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145, US
   Email: nabil.bitar@verizon.com

   Masahiro Daikoku
   KDDI Corporation
   3-11-11 Iidabashi, Chiyodaku, Tokyo, Japan
   Email: ms-daikoku@kddi.com

   Lei Wang
   Lime Networks
   Strandveien 30, 1366 Lysaker, Norway
   Email: lei.wang@limenetworks.no

   Henry Yu
   TW Telecom
   10475 Park Meadow Drive
   Littleton, CO 80124, US
   Email: henry.yu@twtelecom.com