< draft-ietf-l1vpn-applicability-basic-mode-04.txt   draft-ietf-l1vpn-applicability-basic-mode-05.txt >
Network Working Group Tomonori Takeda (Editor) Network Working Group Tomonori Takeda (Editor)
Internet Draft NTT Internet Draft NTT
Intended Status: Informational Intended Status: Informational
Created: February 21, 2008 Created: April 14, 2008
Expires: August 21, 2008 Expires: October 14, 2008
Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs)
Basic Mode Basic Mode
draft-ietf-l1vpn-applicability-basic-mode-04.txt draft-ietf-l1vpn-applicability-basic-mode-05.txt
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 2, line 29 skipping to change at page 2, line 29
5.2.3 Consideration of CE-PE Traffic Engineering Information......7 5.2.3 Consideration of CE-PE Traffic Engineering Information......7
5.3 Connectivity Restriction......................................8 5.3 Connectivity Restriction......................................8
6. Customer Control of its L1VPN..................................8 6. Customer Control of its L1VPN..................................8
6.1 Topology Control..............................................8 6.1 Topology Control..............................................8
6.2 Note on Routing...............................................8 6.2 Note on Routing...............................................8
7. Scalability and Resiliency.....................................9 7. Scalability and Resiliency.....................................9
7.1 Scalability...................................................9 7.1 Scalability...................................................9
7.2 Data Plane Resiliency........................................10 7.2 Data Plane Resiliency........................................10
7.3 Control Plane Resiliency.....................................11 7.3 Control Plane Resiliency.....................................11
8. Security......................................................11 8. Security......................................................11
8.1 Topology Confidentiality.....................................11 8.1 Topology Confidentiality.....................................12
8.2 External Control of the Provider Network.....................12 8.2 External Control of the Provider Network.....................12
8.3 Data Plane Security..........................................13 8.3 Data Plane Security..........................................13
8.4 Control Plane Security.......................................13 8.4 Control Plane Security.......................................13
9. Manageability Considerations..................................14 9. Manageability Considerations..................................14
10. IANA Considerations..........................................14 10. IANA Considerations..........................................15
11. References...................................................14 11. References...................................................15
11.1 Normative References........................................14 11.1 Normative References........................................15
11.2 Informative References......................................15 11.2 Informative References......................................16
12. Acknowledgments..............................................16 12. Acknowledgments..............................................17
13. Authors' Addresses...........................................16 13. Authors' Addresses...........................................17
14. Intellectual Property Consideration..........................17 14. Intellectual Property Consideration..........................18
15. Full Copyright Statement.....................................18 15. Full Copyright Statement.....................................18
1. Introduction 1. Introduction
This document provides an applicability statement on the use of This document provides an applicability statement on the use of
Generalized Multiprotocol Label Switching (GMPLS) protocols and Generalized Multiprotocol Label Switching (GMPLS) protocols and
mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as
specified in [RFC4847]. specified in [RFC4847].
The operation of L1VPNs is divided into the Basic Mode and the The operation of L1VPNs is divided into the Basic Mode and the
skipping to change at page 11, line 49 skipping to change at page 11, line 49
management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473] management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473]
and [RFC5063]) between a CE and a PE as well as within the provider and [RFC5063]) between a CE and a PE as well as within the provider
network. network.
8. Security 8. Security
Security considerations are described in [RFC4847], and this section Security considerations are described in [RFC4847], and this section
describes how these considerations are addressed in the L1VPN Basic describes how these considerations are addressed in the L1VPN Basic
Mode. Mode.
Additional discussion of GMPLS security an be found in [GMPLS-SEC].
8.1 Topology Confidentiality 8.1 Topology Confidentiality
As specified in [L1VPN-BM], a provider's topology confidentiality is As specified in [L1VPN-BM], a provider's topology confidentiality is
preserved by the Basic Mode. Since there is no routing exchange preserved by the Basic Mode. Since there is no routing exchange
between PE and CE, the customer network can gather no information between PE and CE, the customer network can gather no information
about the provider network. Further, as described in Section 4 of about the provider network. Further, as described in Section 4 of
[RFC4208], a PE may filter the information present in a Record Route [RFC4208], a PE may filter the information present in a Record Route
Object (RRO) that is signaled from the provider network to the Object (RRO) that is signaled from the provider network to the
customer network. In addition, as described in Section 5 of [RFC4208] customer network. In addition, as described in Section 5 of [RFC4208]
and Section 4.4 of [L1VPN-BM], when a Notify message is sent to a CE, and Section 4.4 of [L1VPN-BM], when a Notify message is sent to a CE,
skipping to change at page 13, line 9 skipping to change at page 13, line 14
At the same time, if a Path message from a CE contains an Explicit At the same time, if a Path message from a CE contains an Explicit
Route Object (ERO) specifying the route within provider network, it Route Object (ERO) specifying the route within provider network, it
is rejected by the PE. Thus, the customer network has no control over is rejected by the PE. Thus, the customer network has no control over
the resources in the provider network. the resources in the provider network.
8.3 Data Plane Security 8.3 Data Plane Security
As described in [RFC4847], at layer 1, data plane information is As described in [RFC4847], at layer 1, data plane information is
normally assumed to be secure once connections are established since normally assumed to be secure once connections are established since
those connections are dedicated to L1VPNs. That is, it is not the optical signals themselves are normally considered to be hard to
possible to communicate unless there is a connection. intercept or modify, and it is considered difficult to insert data
into an optical stream. This, the very use of an optical signal may
be considered to provide confidentiality and integrity to the payload
data. Furthemore, as indicated in [RFC4847], layer 1 VPN connections
are each dedicated to a specific L1VPN which provides an additional
element of security for the payload data.
In order to protect against mis-delivery, each L1VPN connection is Misconnection remains a security vulnerabilty for user data. If a
restricted to use only within a single L1VPN. That is, a L1VPN L1VPN connection were to be misconnected to the wrong destination,
connection does not connect CEs that are in different L1VPNs. In user data would be delivered to the wrong consumers. In order to
order to realize this, the identity of CEs is assured as part of the protect against mis-delivery, each L1VPN connection is restricted to
service contract. And upon receipt of a request for connection setup, use only within a single L1VPN. That is, a L1VPN connection does not
the provider network assures that the connection is requested between connect CEs that are in different L1VPNs. In order to realize this,
CEs belonging to the same L1VPN. This is achieved as described in the identity of CEs is assured as part of the service contract. And
Section 5.3. upon receipt of a request for connection setup, the provider network
assures that the connection is requested between CEs belonging to the
same L1VPN. This is achieved as described in Section 5.3.
Furthermore, customers can apply their own security mechanisms to Furthermore, users with greater sensitivity to the security of their
protect data plane information (CE-CE security). This includes IPsec payload data should apply appropriate security measures within their
for IP traffic. own network layer. For example, a customer exchanging IP traffic over
a L1VPN connection may choose to use IPsec to secure that traffic
(i.e., to operate IPsec on the CE-CE exchange of IP traffic).
8.4 Control Plane Security 8.4 Control Plane Security
There are two aspects for control plane security. There are two aspects for control plane security.
First, the entity connected over a CE-PE control channel must be First, the entity connected over a CE-PE control channel must be
identified. This is done when a new CE is added as part of the identified. This is done when a new CE is added as part of the
service contract and the necessary control channel is established. service contract and the necessary control channel is established.
This identification can use authentication procedures available in This identification can use authentication procedures available in
RSVP-TE [RFC3209]. RSVP-TE [RFC3209]. That is, control plane entities are identified
within the core protocols used for signaling, but are not
authenticated unless the authentication procedures of [RFC3209] are
used.
Second, it must be possible to secure communication over a CE-PE Second, it must be possible to secure communication over a CE-PE
control channel. If a communication channel between the customer and control channel. If a communication channel between the customer and
the provider (control channel, management interface) is physically the provider (control channel, management interface) is physically
separate per customer, the communication channel could be considered separate per customer, the communication channel could be considered
as secure. However, when the communication channel is physically as secure. However, when the communication channel is physically
shared among customers, security mechanisms need to be available and shared among customers, security mechanisms need to be available and
should be enforced. RSVP-TE [RFC3209] provides for tamper-protection should be enforced. RSVP-TE [RFC3209] provides for tamper-protection
of signaling message exchanges. IPsec tunnels can further be used for of signaling message exchanges through the optional Integrity object.
this purpose. IPsec tunnels can be used to carry the control plane messages to
further ensure the integrity of the signaling messages.
Note that even in the case of physically separate communication Note that even in the case of physically separate communication
channels, customers may wish to apply security mechanisms, such as channels, customers may wish to apply security mechanisms, such as
IPsec, to assure higher security, and such mechanisms must be IPsec, to assure higher security, and such mechanisms must be
available. available.
Furthermore, the provider network needs mechanisms to detect Denial Furthermore, the provider network needs mechanisms to detect Denial
of Service (DoS) attacks and to protect against them reactively and of Service (DoS) attacks and to protect against them reactively and
proactively. In the Basic Mode, this relies on management systems. proactively. In the Basic Mode, this relies on management systems.
For example, management systems collect and analyze statistics on For example, management systems collect and analyze statistics on
signaling requests from CEs, and protect against malicious behaviors signaling requests from CEs, and protect against malicious behaviors
where necessary. where necessary.
Lastly, it should be noted that customer control plane traffic Lastly, it should be noted that customer control plane traffic
carried over the provider network between CEs needs to be protected. carried over the provider network between CEs needs to be protected.
Such protection is normally the responsibility of the customer Such protection is normally the responsibility of the customer
network and can use the security mechanisms of the customer signaling network and can use the security mechanisms of the customer signaling
and routing protocols (for example, RSVP-TE [RFC3209]) or may use and routing protocols (for example, RSVP-TE [RFC3209]) or may use
IPsec tunnels between CEs. CE-CE control plane security may form part IPsec tunnels between CEs. CE-CE control plane security may form part
skipping to change at page 16, line 36 skipping to change at page 17, line 5
[BGP-TE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., [BGP-TE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y.,
"Traffic Engineering Attribute", draft-ietf- "Traffic Engineering Attribute", draft-ietf-
softwire-bgp-te-attribute, work in progress. softwire-bgp-te-attribute, work in progress.
[CONF-SEG] Bradford, R., Editor, "Preserving Topology [CONF-SEG] Bradford, R., Editor, "Preserving Topology
Confidentiality in Inter-Domain Path Computation Confidentiality in Inter-Domain Path Computation
and Signaling", draft-ietf-pce-path-key, work in and Signaling", draft-ietf-pce-path-key, work in
progress. progress.
[GMPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-
security-framework, work in progress.
12. Acknowledgments 12. Acknowledgments
Authors would like to thank Ichiro Inoue for valuable comments. In Authors would like to thank Ichiro Inoue for valuable comments. In
addition, authors would like to thank Marco Carugi and Takumi Ohba addition, authors would like to thank Marco Carugi and Takumi Ohba
for valuable comments in the early development of this document. for valuable comments in the early development of this document.
Thanks to Tim Polk and Mark Townsley for comments during IESG review.
13. Authors' Addresses 13. Authors' Addresses
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732 4201573 Phone: +1 732 4201573
Email: dbrungard@att.com Email: dbrungard@att.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
 End of changes. 13 change blocks. 
28 lines changed or deleted 48 lines changed or added

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