Network Working Group Y(J) Stein
Internet-Draft RAD Data Communications
Expires: August 30, 2006 Feb 26, 2006
Requirements for PW Security
draft-stein-pwe3-sec-req-00.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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document addresses security requirements for MPLS pseudowires.
We investigate security threats arising from the PWE3 architecture,
considering confidentiality, data integrity and authentication.
1. Introduction
The PWE3 architecture 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
Stein Expires August 30, 2006 [Page 1]
Internet-Draft pwe3-sec-req Feb 2006
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.
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 networks,
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:
accidental connection to untrusted network compromising user
traffic
maliciously setting up a PW to gain access to a customer network
forking of a PW to snoop PW packets
malicious rerouting of a PW to snoop or modify PW packets
unauthorized tearing down of a PW
unauthorized snooping of PW packets
traffic analysis of PW connectivity
unauthorized deletion of PW packets
unauthorized modification of PW packets
unauthorized insertion 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 Security Weaknesses and Strengths
The PW user plane suffers from the following security weaknesses:
the PW label is the only identifier in the packet (there is no
verifiable source address, cookies, etc.)
hence it is relatively easy to introduce seemingly valid foreign
packets
Stein Expires August 30, 2006 [Page 2]
Internet-Draft pwe3-sec-req Feb 2006
the control word sequence number processing algorithm can be used
for 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, autodiscovery mechanisms, and
multisegment PWs all introduce new problems.
Note that 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 is standardized
authentication is not mandated, so an intruder can potentially
impersonate a PE
then 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
a PW that is to be torn down may be left up.
Despite these weaknesses, PWs have the following advantages:
most 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
for MPLS PWs it is not possible to maliciously insert a properly
formatted packet from outside the service provider network (since
IP packets can not masquerade as PW packets).
3. Example Attacks
A PW man-in-the-middle occurs when an impostor causes two 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. Such an attack can 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
Stein Expires August 30, 2006 [Page 3]
Internet-Draft pwe3-sec-req Feb 2006
merging. The attacker can now insert a packet with the PW label
associated with any PW (as inner labels are not expected by provider
routers). By judicious choice of sequence number, the attacker may
be able to force massive packet loss, as discussed above.
4. 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.
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.
5. PW Packet Encryption
In order to secure PW traffic from interception we may encrypt it
below the PW level (link encryption)
at the PW level
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.
On the other hand, if only the payload is encrypted, how is PW level
encryption different from service encryption? The main difference
relates to the use of the sequence number. PW mechanisms do not
provide packet reliability, thus encryption must function on a
Stein Expires August 30, 2006 [Page 4]
Internet-Draft pwe3-sec-req Feb 2006
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.
6. Security Considerations
Since this entire document is about security considerations, a
security consideration section is superfluous.
7. IANA Considerations
This Internet Draft does not propose a protocol, nor a change to any
existing protocol, and thus no IANA considerations are raised.
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 August 30, 2006 [Page 5]
Internet-Draft pwe3-sec-req Feb 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stein Expires August 30, 2006 [Page 6]