draft-ietf-mpls-ldp-dod-00.txt   draft-ietf-mpls-ldp-dod-01.txt 
Network Working Group T. Beckhaus Network Working Group T. Beckhaus
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational B. Decraene Intended status: Informational B. Decraene
Expires: July 7, 2012 France Telecom Expires: September 13, 2012 France Telecom
K. Tiruveedhula K. Tiruveedhula
M. Konstantynowicz
Juniper Networks Juniper Networks
M. Konstantynowicz
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
January 04, 2012 March 12, 2012
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-00 draft-ietf-mpls-ldp-dod-01
Abstract Abstract
Seamless MPLS design enables a single IP/MPLS network to scale over Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure core, metro and access parts of a large packet network infrastructure
using standardized IP/MPLS protocols. One of the key goals of using standardized IP/MPLS protocols. One of the key goals of
Seamless MPLS is to meet requirements specific to access, including Seamless MPLS is to meet requirements specific to access, including
high number of devices, their position in network topology and their high number of devices, their position in network topology and their
compute and memory constraints that limit the amount of state access compute and memory constraints that limit the amount of state access
devices can hold.This can be achieved with LDP Downstream-on-Demand devices can hold.This can be achieved with LDP Downstream-on-Demand
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 7, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22
4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22
4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23
4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24
4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27
4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1.1. Access to network packet flow direction . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 6.1.2. Network to access packet flow direction . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single
IP/MPLS network to scale over core, metro and access parts of a large IP/MPLS network to scale over core, metro and access parts of a large
packet network infrastructure using standardized IP/MPLS protocols. packet network infrastructure using standardized IP/MPLS protocols.
One of the key goals of Seamless MPLS is to meet requirements One of the key goals of Seamless MPLS is to meet requirements
specific to access, including high number of devices, their position specific to access, including high number of devices, their position
in network topology and their compute and memory constraints that in network topology and their compute and memory constraints that
limit the amount of state access devices can hold. limit the amount of state access devices can hold.
skipping to change at page 28, line 16 skipping to change at page 28, line 16
This document uses a new a new Optional Parameter Queue Request TLV This document uses a new a new Optional Parameter Queue Request TLV
in the Label Request message defined in Section 4.4.3. IANA already in the Label Request message defined in Section 4.4.3. IANA already
maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by
RFC5036. The following value is suggested for assignment: RFC5036. The following value is suggested for assignment:
TLV type Description TLV type Description
0x0971 Queue Request TLV 0x0971 Queue Request TLV
6. Security Considerations 6. Security Considerations
MPLS LDP Downstream on Demand deployment in the access network is
subject to similar security threats as any MPLS LDP deployment. It
is recommended that baseline security measures are considered as
described in the LDP specification [RFC5036] including ensuring
authenticity and integrity of LDP messages, as well as protection
against spoofing and Denial of Service attacks.
Some deployments may require increased measures of network security
if a subset of Access Nodes are placed in locations with lower levels
of physical security e.g. street cabinets (common practice for VDSL
access). In such cases it is the responsibility of the system
designer to take into account the physical security measures
(environmental design, mechanical or electronic access control,
intrusion detection), as well as monitoring and auditing measures
(configuration and Operating System changes, reloads, routes
advertisements).
But even with all this in mind, the designer still should consider
network security risks and adequate measures arising from the lower
level of physical security of those locations.
6.1. Security and LDP DoD
6.1.1. Access to network packet flow direction
An important property of MPLS LDP Downstream on Demand operation is
that the upstream LSR (requesting LSR) accepts only mappings it sent
a request for (in other words the ones it is interested in), and does
not accept any unsolicited label mappings by design.
This limits the potential of an unauthorized third party fiddling
with label mappings operations on the wire. It also enables ABR LSR
to monitor behaviour of any Access LSR in case the latter gets
compromised and attempts to get access to an unauthorized FEC or
remote LSR. Note that ABR LSR is effectively acting as a gateway to
the MPLS network, and any label mapping requests made by any Access
LSR are processed and can be monitored on this ABR LSR.
6.1.2. Network to access packet flow direction
Another important property of MPLS LDP DoD operation in the access is
that the number of access nodes and associated MPLS FECs per ABR LSR
is not large in number, and they are all known at the deployment
time. Hence any changes of the access MPLS FECs can be easily
controlled and monitored on the ABR LSR.
And then, even in the event when Access LSR manages to advertise a
FEC that belongs to another LSR (e.g. in order to 'steal' third party
data flows, or breach a privacy of VPN), such Access LSR will have to
influence the routing decision for affected FEC on the ABR LSR.
Following measures SHOULD be considered to prevent such event from
occurring:
a. ABR LSR - access side with static routes - this is not possible
for Access LSR. Access LSR has no way to influence ABR LSR
routing decisions due to static nature of routing configuration
here.
b. ABR LSR - access side with IGP - this is still not possible if
the compromised Access LSR is a leaf in the access topology (leaf
node in topologies I1, I, V, Y described earlier in this
document), due to the leaf metrics being configured on the ABR
LSR. If the compromised Access LSR is a transit LSR in the
access topology (transit node in topologies I, Y, U), it is
possible for this Access LSR to attract to itself traffic
destined to the nodes upstream from it. However elaborate such
'man in the middle attack' is possible, but can be quickly
detected by upstream Access LSRs not receiving traffic, and
legitimate traffic from them getting dropped.
c. ABR LSR - network side - designer SHOULD consider giving a higher
administrative preference to the labeled unicast BGP routes vs.
access IGP routes.
In summary MPLS in access design with LDP DoD has number of native
properties that prevent number of security attacks and make their
detection quick and straightforward.
Following two sections describe other security considerations
applicable to general MPLS deployments in the access.
6.2. Data Plane Security
Data plane security risks applicable to the access MPLS network are
listed below (a non-exhaustive list):
a. packets from a specific access node flow to an altered transport
layer or service layer destination.
b. packets belonging to undefined services flow to and from the
access network.
c. unlabelled packets destined to remote network nodes.
Following mechanisms should be considered to address listed data
plane security risks:
1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled
packets over a particular data link, unless from the Access or
ABR LSR perspective this data link is known to attach to a
trusted system based on employed authentication mechanism(s), and
the top label has been distributed to the upstream neighbour by
the receiving Access or ABR LSR.
2. addressing (a) - ABR LSR MAY restrict network reachability for
access devices to a subset of remote network LSR, based on
authentication or other network security technologies employed
towards Access LSRs. Restricted reachability can be enforced on
the ABR LSR using local routing policies, and can be distributed
towards the core MPLS network using routing policies associated
with access MPLS FECs.
3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP)
are not accepted from unreliable routing peers. Detection of
unreliable routing peers is achieved by engaging routing protocol
detection and alarm mechanisms, and is out of scope of this
document.
4. addressing (a) and (b) - no successful attacks have been mounted
on the control plane and has been detected.
5. addressing (c) - ABR LSR MAY restrict IP network reachability to
and from the access LSR.
6.3. Control Plane Security
Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the data plane
security depends on the security of the control plane.
To ensure control plane security access LDP DoD connections MUST only
be made with LDP peers that are considered trusted from the local LSR
perspective, meaning they are reachable over a data link that is
known to attach to a trusted system based on employed authentication
mechanism(s) on the local LSR.
The TCP/IP MD5 authentication option [RFC5925] should be used with
LDP as described in LDP specification [RFC5036]. If TCP/IP MD5
authentication is considered not secure enough, the designer may
consider using a more elaborate and advanced TCP Authentication
Option (TCP-AO RFC 5925) for LDP session authentication.
Access IGP (if used) and any routing protocols used in access network
for signalling service routes SHOULD also be secured in a similar
manner.
For increased level of authentication in the control plane security
for a subset of access locations with lower physical security,
designer could also consider using:
o different crypto keys for use in authentication procedures for
these locations.
o stricter network protection mechanisms including DoS protection,
interface and session flap dampening.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann and Ina Minei for their suggestions and review. Leymann and Ina Minei for their suggestions and review.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-ldp-ipv6]
Asati, R., Manral, V., Papneja, R., and C. Pignataro, Pignataro, C., Asati, R., Papneja, R., and V. Manral,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-05 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06
(work in progress), August 2011. (work in progress), January 2012.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", M., and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-00 (work in progress), draft-ietf-mpls-seamless-mpls-01 (work in progress),
May 2011. March 2012.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
skipping to change at page 29, line 22 skipping to change at page 32, line 35
Heron, "Pseudowire Setup and Maintenance Using the Label Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009. Synchronization", RFC 5443, March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
Authors' Addresses Authors' Addresses
Thomas Beckhaus Thomas Beckhaus
Deutsche Telekom AG Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307 Darmstadt, 64307
Germany Germany
Phone: +49 6151 58 12825 Phone: +49 6151 58 12825
Fax: Fax:
skipping to change at page 30, line 17 skipping to change at page 33, line 28
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
USA USA
Phone: 1-(978)-589-8861 Phone: 1-(978)-589-8861
Fax: Fax:
Email: kishoret@juniper.net Email: kishoret@juniper.net
URI: URI:
Maciek Konstantynowicz Maciek Konstantynowicz
Juniper Networks Cisco Systems, Inc.
Phone: Phone:
Fax: Fax:
Email: maciek@juniper.net Email: maciek@bgp.nu
URI: URI:
Luca Martini Luca Martini
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400 9155 East Nichols Avenue, Suite 400
Englewood, CO 80112 Englewood, CO 80112
USA USA
Phone: Phone:
Fax: Fax:
 End of changes. 13 change blocks. 
17 lines changed or deleted 180 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/