Network Working Group Y(J). Stein
Internet-Draft RAD Data Communications
Intended status: Informational Feb 28, 2007
Expires: September 1, 2007
Requirements for PW Security
draft-stein-pwe3-sec-req-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents 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 of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
To date IETF's security suite has been entirely IP-centric, IPsec
only being applicable to IP packets. This document addresses
security requirements for MPLS pseudowires. We investigate security
considerations arising from the PWE3 architecture, and discuss
example threats, authentication, and confidentiality.
Stein Expires September 1, 2007 [Page 1]
Internet-Draft pwe3-sec-req Feb 2007
1. Introduction
Although the IP suite is obviously its main focus, the IETF has
standardized other protocols, notably MPLS [1] and MPLS pseudowires
(PWs) [3]. On the other hand, IETF's security suite is entirely IP-
centric, IPsec only being applicable to IP packets. Security aspects
of MPLS networks have been addressed in various RFCs, and PPVPN
security is been discussed in [4]; work is in progress on an MPLS/
GMPLS security framework [7]. Security considerations of the MPLS
control plane will most likely be applicable to the PWE3 control
protocol [5] as well. On the other hand security of the user plane
for non-IP traffic such as PWs has not yet been addressed in the
IETF.
The PWE3 architecture [3] defines a pseudowire (PW) connecting
customer networks over a provider network. The customer networks run
a native service, which may be Ethernet, ATM, frame relay, TDM, etc.
On both sides of the PW a customer edge (CE) connects to a provider
edge (PE) via an attachment circuit (AC). The PW itself is a tunnel
that transports the native service data across the provider network,
here assumed to be based on MPLS. PW tunnels are set up using the
PWE control protocol based on LDP [2].
PW packets contain at least one MPLS label (the PW label) and may
contain one or more MPLS tunnel labels. After the label stack there
is a four-byte control word (which is optional for some PW types),
followed by the native service payload. It must be stressed that
encapsulation of MPLS PW packets in IP for the purpose of enabling
use of IPsec mechanisms is not a valid option.
For the purpose of the present discussion, the customer networks will
be considered walled gardens, under the control of the customer. The
provider network is under the control of the provider, but accessible
to multiple customers. The customer expects the provider to ensure
that its data traversing the provider's network be afforded security
similar to that of a (virtual) connection of the native service.
The following will be considered explicitly out-of-scope of the
present treatment:
security considerations of the customer networks,
security considerations of the attachment circuits,
any security considerations that would exist were the customer
networks connected via native service links,
security considerations common to all MPLS networks.
The following is a nonexhaustive list of threats to be considered:
Stein Expires September 1, 2007 [Page 2]
Internet-Draft pwe3-sec-req Feb 2007
unauthorized setting up a PW (e.g. to gain access to a customer
network),
unauthorized tearing down of a PW (thus causing denial of
service),
malicious rerouting of a PW,
forking of a PW to snoop PW packets,
unauthorized on-route snooping of PW packets,
traffic analysis of PW connectivity,
unauthorized insertion of PW packets,
unauthorized modification of PW packets,
unauthorized deletion of PW packets,
replay of PW packets,
denial of service or significantly impacting PW service quality.
These threats are not mutually exclusive, for example, rerouting can
be used for snooping or insertion/deletion/replay, etc.
Special considerations arising for MS-PWs are for further study.
2. PW-specific Security Weaknesses and Strengths
The PW user plane suffers from the following inherent security
weaknesses:
the PW label is the only identifier in the packet (there is no
authenticatable source address, cookies, etc.),
hence it is relatively easy to introduce seemingly valid foreign
packets,
the control word sequence number processing algorithm is
susceptible to a DoS attack (the sequence number processing
algorithm can cause dropping of late packets, so inserting a
single future packet can cause a large number of legitimate
packets to be discarded).
VPLS services built on Ethernet PWs and multisegment PWs introduce
additional problems.
Even without the ability to observe PW packets, guessing a valid PW
label is not difficult. Many implementations start by assigning low
PW labels, and thus a small number will usually correspond to a valid
PW label. In any case there is no penalty to incorrect guessing, and
if one can inject one thousand PW packets per second, then one
exhausts the entire PW label space in about fifteen minutes.
The PWE control protocol introduces its own weaknesses:
no (secure) peer autodiscovery technique has been standardized,
PE authentication is not mandated, so an intruder can potentially
impersonate a PE,
Stein Expires September 1, 2007 [Page 3]
Internet-Draft pwe3-sec-req Feb 2007
after impersonating a PE, unauthorized PWs may be set up,
consuming resources and perhaps allowing access to user networks,
similarly, desired PWs may be torn down, giving rise to denial of
service.
Despite these weaknesses, PWs have the following advantages:
the most obvious attacks require compromising edge or core routers
(although not necessarily those along PW path),
adequate protection of the control plane messaging is sufficient
to rule out many attacks,
PEs are usually configured to reject MPLS packets from the outside
the service provider network, thus ruling out insertion of PW
packets from the outside (since IP packets can not masquerade as
PW packets).
3. Example Attacks
A PW man-in-the-middle occurs when an impostor causes two consecutive
PWs to be set up instead of one, and stitches them at a provider
router of which he has gained control. Such an impostor can then
snoop, delete, insert, and change, PW packets. This is different
from an MPLS man-in-the-middle attack, which results from an impostor
compromising a provider LSR somewhere along the PW path. This latter
attack can also compromise PW security, but must be dealt with as an
MPLS attack, and is out of scope here.
In another scenario the attack involves compromising a forwarding
device (router or Ethernet switch) that is not part of the PW path.
In this case the attack exploits the MPLS mechanism for tunnel
merging. The attacker can now insert a packet with the PW label
associated with any PW (as inner labels are not inspected by provider
routers). By judicious choice of sequence number, the attacker may
be able to force massive packet loss, as mentioned above.
4. Defensive Techniques
4.1. PW Packet Authentication
One way of ensuring that a packet is a valid PW packet, is to
authenticate it by inserting a cryptographically derived field
between the control word and the payload. It is envisaged that the
insertion of such a field will be agreed upon between the two PEs
using an extension to the PWE control protocol. This method will
only be useful when the desired PW packets emanate from a PE with
this capability, and when there is a secure key distribution
infrastructure.
Stein Expires September 1, 2007 [Page 4]
Internet-Draft pwe3-sec-req Feb 2007
In a light-weight version that may be sufficient for some
applications, and which could be implemented entirely in software, a
32-bit cookie is inserted that is derived entirely from the control
word, or (for SS-PWs), from the control word and PW label. The
mapping of control word to cookie may make use of symmetric or
public-key methods.
In a more heavy-weight version a 64-bit authentication cookie is
inserted which results from a cryptographic hash on the entire PW
payload. The authentication of this cookie should be hardware-
assisted in order to avoid a denial of service attack based on
sending invalid packets in order to overload computational resources.
4.2. PW Packet Encryption
In order to secure PW traffic from unauthorized observation we may
encrypt it
below the PW level (link encryption), or
at the PW level, or
above the PW level (service encryption).
Link encryption and service encryption are well understood, but PW
level encryption requires a new mechanism. The first question is
what is encrypted at this layer. Since the PW label is part of the
MPLS label stack, encrypting it would render the packet illegal from
an MPLS point of view. The first nibble of the control word enables
packet classification for ECMP, and thus encrypting it would disrupt
ECMP mechanisms [6].
On the other hand, if only the payload is encrypted, PW level
encryption becomes similar to service encryption. A universal
mechanism for securing PW packets of all types in proposed in [8] The
main difference relates to the use of the sequence number. PW
mechanisms do not provide packet reliability, thus encryption must
function on a packet-by-packet basis, and recover from occasional
lost packets. Hence service level encryptions based on stream
ciphers may not directly applicable. PW layer encryption may rely on
the sequence number (when the control word is used) but not directly
on the data stream, or even the number of bytes that have been
transmitted.
5. Security Considerations
Since this entire document is about security considerations, a
security consideration section would be superfluous.
Stein Expires September 1, 2007 [Page 5]
Internet-Draft pwe3-sec-req Feb 2007
6. IANA Considerations
This Internet Draft does not propose a protocol, nor change any
existing protocol, and thus no IANA considerations are raised.
7. Informative References
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[3] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[4] Fang, L., "Security Framework for Provider-Provisioned Virtual
Private Networks (PPVPNs)", RFC 4111, July 2005.
[5] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron,
"Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)", RFC 4447, April 2006.
[6] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost
Multipath Treatment in MPLS Networks",
draft-ietf-mpls-ecmp-bcp-03.txt (work in progress), August 2007.
[7] Fang, L., Behringer, M., Callon, R., Le Roux, JL., Zhang, R.,
and P. Knight, "Security Framework for MPLS and GMPLS Networks",
draft-fang-mpls-gmpls-security-framework-00.txt (work in
progress), August 2007.
[8] Stein, Y(J)S., "Pseudowire Security (PWsec)",
draft-draft-stein-pwe3-pwsec-00.txt (work in progress),
October 2006.
Stein Expires September 1, 2007 [Page 6]
Internet-Draft pwe3-sec-req Feb 2007
Author's Address
Yaakov (J) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5389
Email: yaakov_s@rad.com
Stein Expires September 1, 2007 [Page 7]
Internet-Draft pwe3-sec-req Feb 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Stein Expires September 1, 2007 [Page 8]