[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4381

Network Working Group                                 Michael Behringer
Internet Draft                                      Cisco Systems, Inc.
<draft-behringer-mpls-security-03.txt>
Category: Informational
October 2002
Expires: April 2003



            Analysis of the Security of the MPLS Architecture


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 BGP/MPLS VPN architecture as
described in RFC 2547, 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 VPN networks can be equally secured as
traditional layer-2 VPN networks such as ATM and Frame Relay.







Internet Draft    Security of the MPLS Architecture      October 2002

Table of Contents

1. Scope and Introduction
2. Security Requirements of MPLS VPN Networks
3. Analysis of MPLS Security
4. What MPLS Doesn't Provide
5. Summary and Conclusions
Author's Address
References
Full Copyright Statement


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 document 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 document 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.

The overall security of a system depends on three parts: The
architecture, the implementation and the operation of the system.
Security issues can exist in either part. This document analyses the
architectural security of MPLS. It does not cover implementation issues
nor operational issues.

This document is targeted at technical staff of service providers and
enterprises. Knowledge of the basic MPLS architecture is required to
understand this document.



draft-behringer-mpls-security-03.txt                            page 2

Internet Draft    Security of the MPLS Architecture      October 2002


2. Security Requirements of MPLS VPN Networks

Both service providers offering VPN services on MPLS networks 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 layer 3 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 separation of routing protocol information, so that also
routing tables are 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.
*  Routing information, as well as distribution and processing of that
   information, for one VPN instance must be independent from any other
   VPN instance.
*  Routing information, as well as distribution and processing of that
   information, for one VPN instance must be independent from the core.

>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, or get routed to another
VPN even if this address does not exist there.

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


draft-behringer-mpls-security-03.txt                            page 3

Internet Draft    Security of the MPLS Architecture      October 2002

be as invisible to the outside world as a comparable layer 2 (e.g.,
frame relay, ATM) infrastructure. Core routers should also not be
accessible from a VPN.

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 of attack as current layer 2 networks. Note that
this document 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 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


draft-behringer-mpls-security-03.txt                            page 4

Internet Draft    Security of the MPLS Architecture      October 2002

a secure manner. Should protection against an insecure core be required
it is necessary to run IPsec on top of the MPLS infrastructure.

Depending on the way several CEs are connected to a PE router, it might
be technically possible to intrude into another VPN that is also
connected on that PE, based on layer 2 attack mechanisms. Examples are
802.1Q - label spoofing, or ATM VPI/VCI spoofing. These layer 2 attacks
are outside the scope of this document, since they are not MPLS/VPN
specific.

It is required that VPNs cannot abuse the MPLS 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. However,
since address space can overlap between VPNs, also the CE-PE link
addressing can overlap between VPNs.

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.



draft-behringer-mpls-security-03.txt                            page 5

Internet Draft    Security of the MPLS Architecture      October 2002

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 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



draft-behringer-mpls-security-03.txt                            page 6

Internet Draft    Security of the MPLS Architecture      October 2002

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 as "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.

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)



draft-behringer-mpls-security-03.txt                            page 7

Internet Draft    Security of the MPLS Architecture      October 2002

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).

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.





draft-behringer-mpls-security-03.txt                            page 8

Internet Draft    Security of the MPLS Architecture      October 2002

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. With all these security measures the only possible
attack is a DoS attack against the routing protocol itself. However, it
is easily possible to track the source of such a potential DoS attack.
Without 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 to the IP
packets by the inbound 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


draft-behringer-mpls-security-03.txt                            page 9

Internet Draft    Security of the MPLS Architecture      October 2002

is possible to insert packets with (spoofed) 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.


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.


draft-behringer-mpls-security-03.txt                           page 10

Internet Draft    Security of the MPLS Architecture      October 2002


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.
   Also, proper tools are required for configuring the core 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 document assumes this to be the case.

There are various approaches to control the security of an MPLS core if
the VPN customer cannot or does not want to trust the service provider.
IPsec from customer controlled devices is one of them. [Bonica]
proposes a CE based authentication scheme based on cookies, aimed at
detecting misconfigurations in the MPLS core. [Behringer] proposes a
similar scheme based on using the MD5 routing authentication. Both
schemes aim to detect and prevent misconfigurations in the MPLS core.

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,


draft-behringer-mpls-security-03.txt                           page 11

Internet Draft    Security of the MPLS Architecture      October 2002

MPLS security is necessary but not sufficient. The same applies to
other VPN technologies like ATM or frame relay. See also [RFC2196] for
more information on how to secure a network.


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 document, 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 document 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.



draft-behringer-mpls-security-03.txt                           page 12

Internet Draft    Security of the MPLS Architecture      October 2002


Acknowledgements

The author would like to thank everybody who has provided input to this
document. Specific thanks go to Yakov Rekhter for his continued strong
support, and Loa Andersson for his extended feedback and support.


Author's Address

Michael H. Behringer
Avda de la Vega, 15
28100 Alcobendas, Madrid
Spain
E-mail: mbehring@cisco.com


References

[Bonica] "CE-to-CE Authentication for Layer 3 VPNs". R. Bonica et al;
draft-ietf-ppvpn-l3vpn-auth-00.txt; work in progress

[Behringer] "MPLS VPN Authentication". M. Behringer, J. Guichard;
draft-behringer-mpls-vpn-auth-00.txt; work in progress

[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)


draft-behringer-mpls-security-03.txt                           page 13

Internet Draft    Security of the MPLS Architecture      October 2002


[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
   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-03.txt                           page 14


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/