Requirements for PW Security
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv
69719
ISRAEL
+972 3 645-5389
yaakov_s@rad.com
Transport
pseudowire
security
Internet-Draft
This document addresses security requirements for MPLS pseudowires.
We investigate security threats arising from the PWE3 architecture,
considering confidentiality, data integrity and authentication.
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 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.
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
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).
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 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.
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.
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 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.
Since this entire document is about security considerations,
a security consideration section is superfluous.
This Internet Draft does not propose a protocol,
nor a change to any existing protocol,
and thus no IANA considerations are raised.