Network Working Group Michael Behringer
Internet Draft Cisco Systems, Inc.
Category: Informational
February 2001
Expires: August 2001
Analysis of the Security of the MPLS Architecture
draft-behringer-mpls-security-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document analyses the security of the MPLS architecture, especially in
comparison with other VPN technologies such as ATM and Frame Relay. The
target audience is service providers and VPN users. The document consists
of two main parts: First the requirements for security in VPN services are
defined, second MPLS is examined with respect to these requirements.
The analysis shows that MPLS networks can be equally secured as traditional
layer-2 networks such as ATM and Frame Relay.
Table of Contents
1. Scope and Introduction
2. Security Requirements of MPLS Networks
3. Analysis of MPLS Security
4. What MPLS Doesn't Provide
5. Summary and Conclusions
Author's Address
References
Full Copyright Statement
draft-behringer-mpls-security-00.txt page 1
Internet Draft draft-behringer-mpls-security-00.txt February 2001
1. Scope and Introduction
Many enterprises are thinking of replacing traditional layer-2 VPNs such as
ATM or Frame Relay (FR) with MPLS based services. As MPLS (multi protocol
label switching) is becoming a more wide-spread technology for providing
VPN (virtual private network) services, the security of the MPLS
architecture is of increasing concern to service providers and VPN
customers. This paper gives an overview of the security of the MPLS
architecture for both service providers and MPLS users, and compares it
with traditional layer-2 services from a security perspective. The focus is
specifically on the MPLS/BGP VPN architecture as described in [RFC2547].
This paper assumes that the MPLS core network is trusted and provided in a
secure manner. Thus it does not address basic security concerns such as
securing the network elements against unauthorised access,
misconfigurations of the core, internal (within the core) attacks and the
likes. Should a customer not wish to assume the service provider network as
trusted it becomes necessary to use additional security mechanisms such as
IPsec over the MPLS infrastructure.
Analysis of the security features of routing protocols is only covered to
the extend where it influences MPLS. IPsec technology is also not covered,
except to highlight the combination of MPLS with IPsec.
This paper is targeted at technical staff of service providers and
enterprises. Knowledge of the basic MPLS architecture is required to
understand this paper.
2. Security Requirements of MPLS Networks
Both service providers offering MPLS services and customers using them have
specific demands for the security of this special VPN solution. Mostly they
compare MPLS based solutions with traditional layer 2 based VPN solutions
such as Frame Relay and ATM, since these are widely deployed and accepted.
This section outlines the security requirements that are typically made in
MPLS networks. The following section discusses if and how MPLS addresses
these requirements, for both the MPLS core and the connected VPNs.
2.1 Address Space, Routing and Traffic Separation
Between two non-intersecting VPNs of an MPLS VPN service it is assumed that
the address space between different VPNs is entirely independent. This
means that for example two non-intersecting VPNs must be able to both use
the 10/8 network without any interference. In addition traffic from one VPN
must never enter another VPN. This includes routing protocols, so that also
routing is seperate per VPN. Specifically:
* Any VPN must be able to use the same address space as any other VPN.
* Any VPN must be able to use the same address space as the MPLS core.
* Traffic from one VPN must never flow to another VPN.
draft-behringer-mpls-security-00.txt page 2
Internet Draft draft-behringer-mpls-security-00.txt February 2001
* Routing between any two VPNs must be independent.
* Routing between any VPN and the core must be independent.
>From a security point of view the basic requirement is to avoid that
packets destined to a host a.b.c.d within a given VPN reach a host with the
same address in another VPN or the core.
2.2 Hiding of the MPLS Core Structure
The internal structure of the MPLS core network (PE and P elements) should
not be visible to outside networks (Internet or any connected VPN). Whilst
a breach of this requirement does not lead to a security problem itself,
many service providers feel that it is advantageous if the internal
addressing and network structure remains hidden to the outside world. A
strong argument is that DoS attacks against a core router for example are
much easier to carry out if an attacker knows the address. Where addresses
are not known, they can be guessed, but with this attacks become more
difficult. Ideally the MPLS core should be as invisible to the outside
world as a comparable layer 2 (e.g., frame relay, ATM) infrastructure.
Note that security should never rely on obscurity, i.e., the hiding of
information. On the contrary services should be equally secure if the
implementation is known. However, there is a strong market perception that
hiding of details is advantageous. This point addresses that market
perception.
2.3 Resistance to Attacks
There are two basic types of attacks: Denial-of-Service (DoS) attacks,
where resources become unavailable to authorised users, and intrusions,
where resources become available to un-authorised users.
For attacks that give unauthorised access to resources (intrusions) there
are two basic ways to protect the network: Firstly, to harden protocols
that could be abused (e.g., telnet to a router), secondly to make the
network as inaccessible as possible. The latter is achieved by a
combination of packet filtering or firewalling and address hiding, as
discussed above.
DoS attacks are easier to execute, since in the simplest case a known IP
address might be enough to attack a machine. This can be done using normal
"allowed" traffic, but higher than normal packet rates, so that other users
cannot access the targeted machine. The only way to be certain not be
vulnerable to this kind of attack is to make sure that machines are not
reachable, again by packet filtering and optionally address hiding.
MPLS networks must provide at least the same level of protection against
both forms as current layer 2 networks. Note that this paper concentrates
on protecting the core network against attacks from the "outside", i.e.,
the Internet and connected VPNs. Protection against attacks from the
"inside", i.e., if an attacker has logical or physical access to the core
draft-behringer-mpls-security-00.txt page 3
Internet Draft draft-behringer-mpls-security-00.txt February 2001
network is not considered here, since any network can be attacked with
access from the inside.
2.4 Impossibility of Label Spoofing
Assuming the address and traffic separation as discussed above, a potential
attacker might try to gain access to other VPNs by inserting packets with a
label that he doesn't "own". This could be done from the outside, i.e.,
another CE router or from the Internet, or from within the MPLS core. The
latter case (from within the core) will not be discussed, since the
assumption is that the core network is provided in a secure manner. Should
protection against an insecure core be required it is necessary to run
IPsec on top of the MPLS infrastructure.
It is required that VPNs cannot abuse the label mechanisms or protocols to
gain un-authorised access to other VPNs or the core.
3. Analysis of MPLS Security
In this section the MPLS architecture is analysed with respect to the
security requirements listed above.
3.1 Address Space, Routing and Traffic Separation
MPLS allows distinct VPNs to use the same address space, which can also be
private address space [RFC1918]. This is achieved by adding a 64 bit route
distinguisher (RD) to each IPv4 route, making VPN-unique addresses also
unique in the MPLS core. This "extended" address is also called a "VPN-IPv4
address". Thus customers of an MPLS service do not need to change current
addressing in their networks.
There is only one exception, which is the IP addresses of the PE routers
the CE routers are peering with, in the case of using routing protocols
between CE and PE routers (for static routing between PE and CE this is not
an issue). Routing protocols on the CE routers need to have configured the
address of the peer PE router in the core, to be able to "talk" to the PE
router. This address must be unique from the CE router's perspective. In an
environment where the service provider manages also the CE routers as CPE,
this can be made invisible to the customer. The address space on the CE-PE
link (including the peering PE address) must be considered as part of the
VPN address space.
Routing separation between the VPNs can also be achieved. Every PE router
maintains a separate Virtual Routing and Forwarding instance (VRF) for each
connected VPN. Each VRF on the PE router is populated with routes from one
VPN, through statically configured routes or through routing protocols that
run between the PE and the CE router. Since every VPN results in a separate
VRF there will be no interferences between the VPNs on the PE router.
Across the MPLS core to the other PE routers this separation is maintained
draft-behringer-mpls-security-00.txt page 4
Internet Draft draft-behringer-mpls-security-00.txt February 2001
by adding unique VPN identifiers in multi-protocol BGP, such as the route
distinguisher. VPN routes are exclusively exchanged by MP-BGP across the
core, and this BGP information is not re-distributed to the core network
but only to the other PE routers, where the information is kept again in
VPN specific VRFs. Thus routing across an MPLS network is separate per VPN.
Traffic separation is achieved by prepending VPN-specific labels to the
packets, so that a packet can also on the core be identified as belonging
to a specific VPN.
Given the addressing, routing and traffic separation across an MPLS core
network, it can be assumed that MPLS offers in this respect the same
security as comparable layer-2 VPNs such as ATM or Frame Relay. It is not
possible to intrude into other VPNs through the MPLS could, unless this has
been configured specifically.
3.2 Hiding of the MPLS Core Structure
For reasons of security service providers and end-customers do not normally
want their network topology revealed to the outside. This is done to make
attacks more difficult: If an attacker doesn't know the target he can only
guess the IP addresses to attack. Since most DoS attacks don't provide
direct feedback to the attacker it would be difficult to attack the
network. It has to be mentioned specifically that information hiding as
such does not provide security. However, in the market this is a perceived
requirement.
With a known IP address a potential attacker can launch a DoS attack more
easily against that device. So the ideal is to not reveal any information
of the internal network to the outside. This applies equally to the
customer networks as to the MPLS core. In practice a number of additional
security measures have to be taken, most of all extensive packet filtering.
MPLS does not reveal unnecessary information to the outside, not even to
customer VPNs. The addressing of the core can be done with private
addresses [RFC1918] or public addresses. Since the interface to the VPNs as
well as potentially to the Internet is BGP, there is no need to reveal any
internal information. The only information required in the case of a
routing protocol between PE and CE is the address of the PE router. If this
is not desired static routing on unnumbered interfaces can be configured
between the PE and CE. With this measure the MPLS core can be kept
completely hidden.
Customer VPNs will have to advertise their routes as a minimum to the MPLS
core (dynamically or statically), to ensure reachability across the MPLS
cloud. Whilst this could be seen too "open", the following has to be noted:
Firstly, the information known to the MPLS core is not about specific
hosts, but networks (routes); this offers some degree of abstraction.
Secondly, in a VPN-only MPLS network (i.e., no shared Internet access) this
is equal to existing layer-2 models, where the customer has to trust the
service provider to some degree. Also in a FR or ATM network routing
information about the VPNs can be seen on the core network.
draft-behringer-mpls-security-00.txt page 5
Internet Draft draft-behringer-mpls-security-00.txt February 2001
In a VPN service with shared Internet access the service provider will
typically announce the routes of customers that wish to use the Internet to
his upstream or peer providers. This can be done via a NAT function to
further obscure the addressing information of the customers' networks. In
this case the customer does not reveal more information to the general
Internet than with a general Internet service. Core information will still
not be revealed at all, except for the peering address(es) of the PE
router(s) that hold(s) the peering with the Internet.
In summary, in a pure MPLS-VPN service, where no Internet access is
provided, the information hiding is as good as on a comparable FR or ATM
network: No addressing information is revealed to third parties or the
Internet. If a customer chooses to access the Internet via the MPLS core he
will have to reveal the same addressing structure as for a normal Internet
service. NAT can be used for further address hiding.
If an MPLS network has no interconnections to the Internet, this is equal
to FR or ATM networks. With an Internet access from the MPLS cloud the
service provider has to reveal at least one IP address (of the peering PE
router) to the next provider, and thus the outside world.
3.3 Resistance to Attacks
Section 3.1 shows that it is not possible to directly intrude into other
VPNs. Another possibility is to attack the MPLS core, and try to attack
other VPNs from there. There are two basic ways the MPLS core can be
attacked:
1. By attacking the PE routers directly.
2. By attacking the signaling mechanisms of MPLS (mostly routing)
To attack an element of an MPLS network it is first necessary to know this
element, that is, its address. As discussed in section 3.2 it is possible
to hide the addressing structure of the MPLS core to the outside world.
Thus an attacker does not know the IP address of any router in the core
that he wants to attack. The attacker could now guess addresses and send
packets to these addresses. However, due to the address separation of MPLS
each incoming packet will be treated as belonging to the address space of
the customer. Thus it is impossible to reach an internal router, even
through IP address guessing. There is only one exception to this rule,
which is the peer interface of the PE router.
The routing between the VPN and the MPLS core can be configured two ways:
1. Static; in this case the PE routers are configured with static routes to
the networks behind each CE, and the CEs are configured to statically point
to the PE router for any network in other parts of the VPN (mostly a
default route). There are now two sub-cases: The static route can point to
the IP address of the PE router, or to an interface of the CE router (e.g.,
serial0).
draft-behringer-mpls-security-00.txt page 6
Internet Draft draft-behringer-mpls-security-00.txt February 2001
2. Dynamic; here a routing protocol (e.g., RIP, OSPF, BGP) is used exchange
the routing information between the CE and the PE at each peering point.
In the case of a static route from the CE router to the PE router, which
points to an interface, the CE router doesn't need to know any IP address
of the core network, not even of the PE router. This has the disadvantage
of a more extensive (static) configuration, but from a security point of
view is preferable to the other cases. It is now possible to configure
packet filters on the PE interface to deny any packet to the PE interface.
This way the router cannot be attacked.
In all other cases, each CE router needs to know at least the router ID
(RID; peer IP address) of the PE router in the MPLS core, and thus has a
potential destination for an attack. One could imagine various attacks on
various services running on a router. In practice access to the PE router
over the CE-PE interface can be limited to the required routing protocol by
using ACLs (access control lists). This limits the point of attack to one
routing protocol, for example BGP. A potential attack could be to send an
extensive number of routes, or to flood the PE router with routing updates.
Both could lead to a DoS, however, not to unauthorised access.
To restrict this risk it is necessary to configure the routing protocol on
the PE router as securely as possible. This can be done in various ways:
* By ACL, allow the routing protocol only from the CE router, not from
anywhere else. Furthermore, no access other than that should be allowed to
the PE router in the inbound ACL on each CE interface.
* Where available, configure MD-5 authentication for routing protocols.
This is available for BGP [RFC2385], OSPF [RFC2154] and RIP2 [RFC2082] for
example. It avoids that packets could be spoofed from other parts of the
customer network than the CE router. Note that this requires service
provider and customer to agree on a shared secret between all CE and PE
routers. Note that it is necessary to do this for all VPN customers, it is
not sufficient to do this for the customer with the highest security
requirements.
* To configure where available parameters of the routing protocol, to
further secure this communication. In BGP for example it is possible to
configure dampening, which limits the number of routing interactions. Also,
a maximum number of routes accepted per VRF should be configured where
possible.
In summary, it is not possible to intrude from one VPN into other VPNs, or
the core. However, it is theoretically possible to exploit the routing
protocol to execute a DoS attack against the PE router. This in turn might
have negative impact on other VPNs on this PE router. For this reason PE
routers must be extremely well secured, especially on their interfaces to
the CE routers. ACLs must be configured to limit access only to the port(s)
of the routing protocol, and only from the CE router. MD5 authentication in
routing protocols should be used on all PE-CE peerings. It is easily
possible to track the source of such a potential DoS attack. Without
draft-behringer-mpls-security-00.txt page 7
Internet Draft draft-behringer-mpls-security-00.txt February 2001
dynamic routing between CEs and PEs the security is equivalent to the
security of ATM or Frame Relay networks.
3.4 Label Spoofing
Within the MPLS network packets are not forwarded based on the IP
destination address, but based on labels that are pre-pended by the PE
routers. Similar to IP spoofing attacks, where an attacker replaces the
source or destination IP address of a packet, it is also theoretically
possible to spoof the label of an MPLS packet. In the first section the
assumption was made that the core network is trusted. If this assumption
cannot be made IPsec must be run over the MPLS cloud. Thus in this section
the emphasis is on whether it is possible to insert packets with (wrong)
labels into the MPLS network from the outside, i.e., from a VPN (CE router)
or from the Internet.
Principally the interface between any CE router and its peering PE router
is an IP interface, i.e., without labels. The CE router is unaware of the
MPLS core, and thinks it is sending IP packets to a simple router. The
"intelligence" is done in the PE device, where based on the configuration,
the label is chosen and pre-pended to the packet. This is the case for all
PE routers, towards CE routers as well as the upstream service provider.
All interfaces into the MPLS cloud only require IP packets, without labels.
For security reasons a PE router should never accept a packet with a label
from a CE router. [RFC3031] specifies: "Therefore, when a labeled packet is
received with an invalid incoming label, it MUST be discarded, UNLESS it is
determined by some means (not within the scope of the current document)
that forwarding it unlabeled cannot cause any harm." Since accepting labels
on the CE interface would allow passing packets to other VPNs it is not
permitted by the RFC.
There remains the possibility to spoof the IP address of a packet that is
being sent to the MPLS core. However, since there is strict addressing
separation within the PE router, and each VPN has its own VRF, this can
only do harm to the VPN the spoofed packet originated from, in other words,
a VPN customer can attack himself. MPLS doesn't add any security risk here.
3.5 Comparison with ATM/FR VPNs
ATM and FR VPN services often enjoy a very high reputation in terms of
security. Although ATM and FR VPNs can also be provided in a secure manner,
it has been reported that also these technologies can have severe security
vulnerabilities [DataComm]. Also in ATM/FR the security depends on the
configuration of the network being secure, and errors can also lead to
security problems.
draft-behringer-mpls-security-00.txt page 8
Internet Draft draft-behringer-mpls-security-00.txt February 2001
4. What MPLS Doesn't Provide
4.1 Protection against Misconfigurations of the Core and Attacks "within"
the Core
The security mechanisms discussed here assume correct configuration of the
involved network elements on the MPLS core network (PE and P routers).
Deliberate or inadvertent misconfigurations from SP staff may result in
undesired behaviour including severe security leaks.
Note that this paragraph specifically refers to the core network, i.e., the
PE and P elements. Misconfiguration of any of the customer side elements
such as the CE router are covered by the security mechanisms above. This
means that a potential attacker must have access to either PE or P routers
to gain advantage from misconfigurations. If an attacker has access to core
elements, or is able to insert into the core additional equipment, he will
be able to attack both the core network as well as the connected VPNs. Thus
the following is important:
* To avoid the risk of misconfigurations it is important that the equipment
is easy to configure, and that SP staff have the appropriate training and
experience when configuring the network.
* To avoid the risk of "internal" attacks the MPLS core network must be
properly secured. This includes network element security, management
security, physical security of the service provider infrastructure, access
control to service provider installations and other standard SP security
mechanisms.
MPLS can only provide a secure service if the core network is provided in a
secure fashion. This paper assumes this to be the case.
4.2 Data Encryption, Integrity and Origin Authentication
MPLS itself does not provide encryption, integrity or authentication
services. If these are required IPsec should be used over the MPLS
infrastructure. The same applies to ATM and Frame Relay: Also here IPsec
can provide these missing services.
4.3 Customer Network Security
MPLS can be secured so that it is comparable with other VPN services.
However, the security of the core network is only one factor for the
overall security of a customer's network. Threats in today's networks do
not only come from the "outside" connection, but also from the "inside" and
from other entry points (modems for example). To reach a good security
level for a customer network in an MPLS infrastructure, MPLS security is
necessary but not sufficient. See also [RFC2196] for more information on
how to secure a network.
draft-behringer-mpls-security-00.txt page 9
Internet Draft draft-behringer-mpls-security-00.txt February 2001
5. Summary and Conclusions
MPLS provides full address and traffic separation as in traditional layer-2
VPN services. It hides addressing structures of the core and other VPNs,
and it is in today's understanding not possible from the outside to intrude
into the core or other VPNs abusing the MPLS mechanisms. It is also not
possible to intrude into the MPLS core if this is properly secured.
However, there is a significant difference between MPLS based VPNs and for
example FR or ATM based VPNs: The control structure of the core is on layer
3 in the case of MPLS. This caused significant skepticism in the industry
towards MPLS, since this might open the architecture to DoS attacks from
other VPNs or the Internet (if connected).
As shown in this paper, it is possible to secure an MPLS infrastructure to
the same level of security than a comparable ATM or FR service. It is also
possible to offer Internet connectivity to MPLS VPNs in a secure manner,
and to interconnect different VPNs via firewalls. Although ATM and FR
services have a strong reputation with regard to security, it has been
shown that also in these networks security problems can exist [DataComm].
As far as attacks from within the MPLS core are concerned, all VPN classes
(MPLS, FR, ATM) have the same problem: If an attacker can install a
sniffer, he can read information in all VPNs, and if he has access to the
core devices, he can execute a large number of attacks, from packet
spoofing to introducing a new peer routers. There are a number of
precautions measures outlined above that a service provider can use to
tighten security of the core, but the security of the MPLS architecture
depends on the security of the service provider. If the service provider is
not trusted, the only way to fully secure a VPN against attacks from the
"inside" of the VPN service is to run IPsec on top, from the CE devices or
beyond.
This paper discussed many aspects of MPLS security. It has to be noted
explicitly that the overall security of an MPLS architecture depends on all
components, and is determined by the security of the weakest part of the
solution. For example a perfectly secured static MPLS network with secured
Internet access and secure management is still open to many attacks if
there is a weak remote access solution in place.
Author's Address
Michael H. Behringer
Avda de la Vega, 15
28100 Alcobendas, Madrid
Spain
E-mail: mbehring@cisco.com
draft-behringer-mpls-security-00.txt page 10
Internet Draft draft-behringer-mpls-security-00.txt February 2001
References
[DataComm] "Frame Relay and ATM: Are they really secure?". Data
Communications Report, Vol 15, No 4, February 2000.
(http://www.yankeegroup.com)
[RFC1918] "Address Allocation for Private Internets". Y. Rekhter et al;
February 1996. (http://search.ietf.org/rfc/rfc1918.txt)
[RFC2082] "RIP-2 MD5 Authentication". F. Baker, R. Atkinson. January 1997.
(http://search.ietf.org/rfc/rfc2082.txt)
[RFC2154] "OSPF with Digital Signatures". S. Murphy, M. Badger, B.
Wellington. June 1997. (http://search.ietf.org/rfc/rfc2154.txt)
[RFC2196] "Site Security Handbook". B. Fraser. September 1997.
(http://search.ietf.org/rfc/rfc2196.txt)
[RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature Option". A.
Heffernan. August 1998. (http://search.ietf.org/rfc/rfc2385.txt)
[RFC2547] "BGP/MPLS VPNs". E. Rosen, Y. Rekhter. March 1999.
(http://search.ietf.org/rfc/rfc2547.txt)
[RFC2827] "Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing". P. Ferguson, D. Senie. May 2000.
(http://search.ietf.org/rfc/rfc2827.txt)
[RFC2828] "Internet Security Glossary". R. Shirey. May 2000.
(http://search.ietf.org/rfc/rfc2828.txt)
[RFC3013] "Recommended Internet Service Provider Security Services and
Procedures". T. Killalea. November 2000.
(http://search.ietf.org/rfc/rfc3013.txt)
[RFC3031] "Multiprotocol Label Switching Architecture". E. Rosen, A.
Viswanathan, R. Callon. January
2001.(http://search.ietf.org/rfc/rfc3031.txt)
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
draft-behringer-mpls-security-00.txt page 11
Internet Draft draft-behringer-mpls-security-00.txt February 2001
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
draft-behringer-mpls-security-00.txt page 12