Tài liệu Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) ppt

LINK DOWNLOAD MIỄN PHÍ TÀI LIỆU "Tài liệu Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) ppt": http://123doc.vn/document/1036193-tai-lieu-analysis-of-the-security-of-bgp-mpls-ip-virtual-private-networks-vpns-ppt.htm

RFC 4381 Security of BGP/MPLS IP VPNs February 2006
2.2. Hiding the Core Infrastructure
The internal structure of the core network (MPLS PE and P elements)
should not be externally visible. Whilst breaking this requirement
is not a security problem in itself, many service providers believe
it is advantageous if the internal addresses and network structure
are hidden from the outside world. An argument is that denial-of-
service (DoS) attacks against a core router are much easier to carry
out if an attacker knows the router addresses. Addresses can always
be guessed, but attacks are more difficult if addresses are not
known. The core should be as invisible to the outside world as a
comparable layer 2 infrastructure (e.g., Frame Relay, ATM). Core
network elements should also not be accessible from within a VPN.
Security should never rely entirely on obscurity, i.e., the hiding of
information. 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: DoS attacks, where resources
become unavailable to authorised users, and intrusions, where
resources become available to unauthorised users. BGP/MPLS IP VPN
networks must provide at least the same level of protection against
both forms of attack as current layer 2 networks.
For intrusions, there are two fundamental ways to protect the
network: first, to harden protocols that could be abused (e.g.,
Telnet into a router), and second, to make the network as
inaccessible as possible. This is achieved by a combination of
packet filtering / firewalling and address hiding, as discussed
above.
DoS attacks are easier to execute, since a single known IP address
might be enough information to attack a machine. This can be done
using normal "permitted" traffic, but using higher than normal packet
rates, so that other users cannot access the targeted machine. The
only way to be invulnerable to this kind of attack is to make sure
that machines are not reachable, again by packet filtering and
optionally by address hiding.
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., an attacker who
has logical or physical access to the core network, is not discussed
here.
Behringer Informational [Page 5]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
2.4. Impossibility of Label Spoofing
Assuming the address and traffic separation discussed above, an
attacker might try to access other VPNs by inserting packets with a
label that he does not "own". This could be done from the outside,
i.e., another Customer Edge (CE) router or from the Internet, or from
within the MPLS core. The latter case (from within the core) will
not be discussed, since we assume that the core network is provided
securely. Should protection against an insecure core be required, it
is necessary to use security protocols such as IPsec across the MPLS
infrastructure, at least from CE to CE, since the PEs belong to the
core.
Depending on the way that CE routers are connected to PE routers, it
might be possible to intrude into a VPN that is connected to the same
PE, using layer 2 attack mechanisms such as 802.1Q-label spoofing or
ATM VPI/VCI spoofing. Layer 2 security issues will be discussed in
section 6.
It is required that VPNs cannot abuse the MPLS label mechanisms or
protocols to gain unauthorised access to other VPNs or the core.
3. Analysis of BGP/MPLS IP VPN Security
In this section, the BGP/MPLS IP VPN architecture is analysed with
respect to the security requirements listed above.
3.1. Address Space, Routing, and Traffic Separation
BGP/MPLS allows distinct IP VPNs to use the same address space, which
can also be private address space (RFC 1918 [2]). 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 a BGP/MPLS IP VPN service do not need to change their
current addressing plan.
Each PE router maintains a separate Virtual Routing and Forwarding
instance (VRF) for each connected VPN. A VRF includes the addresses
of that VPN as well as the addresses of the PE routers with which the
CE routers are peering. All addresses of a VRF, including these PE
addresses, belong logically to the VPN and are accessible from the
VPN. The fact that PE addresses are accessible to the VPN is not an
issue if static routing is used between the PE and CE routers, since
packet filters can be deployed to block access to all addresses of
the VRF on the PE router. If dynamic routing protocols are used, the
CE routers need to have the address of the peer PE router in the core
configured. In an environment where the service provider manages the
Behringer Informational [Page 6]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
CE routers as CPE, this can be invisible to the customer. The
address space on the CE-PE link (including the peering PE address) is
considered part of the VPN address space. Since address space can
overlap between VPNs, the CE-PE link addresses can overlap between
VPNs. For practical management considerations, SPs typically address
CE-PE links from a global pool, maintaining uniqueness across the
core.
Routing separation between VPNs can also be achieved. Each VRF is
populated with routes from one VPN through statically configured
routes or through routing protocols that run between the PE and CE
router. Since each VPN is associated with a separate VRF there is no
interference between VPNs on the PE router.
Across the core to the other PE routers separation is maintained with
unique VPN identifiers in multiprotocol BGP, the Route Distinguishers
(RDs). VPN routes including the RD are exclusively exchanged between
PE routers by Multi-Protocol BGP (MP-BGP, RFC 2858 [8]) across the
core. These BGP routing updates are not re-distributed into the
core, but only to the other PE routers, where the information is kept
again in VPN-specific VRFs. Thus, routing across a BGP/MPLS network
is separate per VPN.
On the data plane, traffic separation is achieved by the ingress PE
pre-pending a VPN-specific label to the packets. The packets with
the VPN labels are sent through the core to the egress PE, where the
VPN label is used to select the egress VRF.
Given the addressing, routing, and traffic separation across an BGP/
MPLS IP VPN core network, it can be assumed that this architecture
offers in this respect the same security as a layer-2 VPN. It is not
possible to intrude from a VPN or the core into another VPN unless
this has been explicitly configured.
If and when confidentiality is required, it can be achieved in BGP/
MPLS IP VPNs by overlaying encryption services over the network.
However, encryption is not a standard service on BGP/MPLS IP VPNs.
See also section 5.2.
3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure
Service providers and end-customers do not normally want their
network topology revealed to the outside. This makes attacks more
difficult to execute: If an attacker doesn’t know the address of a
victim, 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
Behringer Informational [Page 7]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
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. Therefore, the ideal is to not
reveal any information about the internal network to the outside
world. This applies to the customer network and the core. A number
of additional security measures also have to be taken: most of all,
extensive packet filtering.
For security reasons, it is recommended for any core network to
filter packets from the "outside" (Internet or connected VPNs)
destined to the core infrastructure. This makes it very hard to
attack the core, although some functionality such as pinging core
routers will be lost. Traceroute across the core will still work,
since it addresses a destination outside the core.
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 (RFC 1918 [2]) or public addresses. Since the
interface to the VPNs as well as 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 no dynamic routing is required, static
routing on unnumbered interfaces can be configured between the PE and
CE. With this measure, the BGP/MPLS IP VPN core can be kept
completely hidden.
Customer VPNs must advertise their routes to the BGP/MPLS IP VPN core
(dynamically or statically), to ensure reachability across their VPN.
In some cases, VPN users prefer that the service provider have no
visibility of the addressing plan of the VPN. The following has to
be noted: First, the information known to the core is not about
specific hosts, but networks (routes); this offers a degree of
abstraction. Second, in a VPN-only BGP/MPLS IP VPN network (no
Internet access) this is equal to existing layer-2 models, where the
customer has to trust the service provider. Also, in a Frame Relay
or ATM network, routing and addressing 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 who wish to use the
Internet to his upstream or peer providers. This can be done
directly if the VPN customer uses public address space, or via
Network Address Translation (NAT) to obscure the addressing
information of the customers’ networks. In either case, the customer
does not reveal more information than would be revealed by a general
Internet service. Core information will not be revealed, except for
Behringer Informational [Page 8]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
the peering address(es) of the PE router(s) that hold(s) the peering
with the Internet. These addresses must be secured as in a
traditional IP backbone.
In summary, in a pure MPLS-VPN service, where no Internet access is
provided, 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
BGP/MPLS IP VPN core, he will have to reveal the same information as
required for a normal Internet service. NAT can be used for further
obscurity. Being reachable from the Internet automatically exposes a
customer network to additional security threats. Appropriate
security mechanisms have to be deployed such as firewalls and
intrusion detection systems. This is true for any Internet access,
over MPLS or direct.
A BGP/MPLS IP VPN network with no interconnections to the Internet
has security equal to that of FR or ATM VPN 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 to the outside world.
3.3. Resistance to Attacks
Section 3.1 shows that it is impossible to directly intrude into
other VPNs. Another possibility is to attack the MPLS core and try
to attack other VPNs from there. As shown above, it is impossible to
address a P router directly. The only addresses reachable from a VPN
or the Internet are the peering addresses of the PE routers. Thus,
there are two basic ways that the BGP/MPLS IP VPN 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 a BGP/MPLS IP VPN network, it is first
necessary to know the address of the element. As discussed in
section 3.2, the addressing structure of the BGP/MPLS IP VPN core is
hidden from the outside world. Thus, an attacker cannot know the IP
address of any router in the core to attack. The attacker could
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 by guessing IP
addresses. There is only one exception to this rule, which is the
peer interface of the PE router. This address of the PE is the only
attack point from the outside (a VPN or Internet).
Behringer Informational [Page 9]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
The routing between a VPN and the BGP/MPLS IP VPN 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 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: A routing protocol (e.g., Routing Information Protocol
(RIP), OSPF, BGP) is used to exchange routing information between
the CE and PE at each peering point.
In the case of a static route that points to an interface, the CE
router doesn’t need to know any IP addresses of the core network or
even of the PE router. This has the disadvantage of needing a more
extensive (static) configuration, but is the most secure option. In
this case, it is also possible to configure packet filters on the PE
interface to deny any packet to the PE interface. This protects the
router and the whole core from attack.
In all other cases, each CE router needs to know at least the router
ID (RID, i.e., peer IP address) of the PE router in the 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 access control
lists (ACLs). 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 reduce this risk, it is necessary to configure the routing
protocol on the PE router to operate as securely as possible. This
can be done in various ways:
o By accepting only routing protocol packets, and only from the CE
router. The inbound ACL on each CE interface of the PE router
should allow only routing protocol packets from the CE to the PE.
o By configuring MD5 authentication for routing protocols. This is
available for BGP (RFC 2385 [6]), OSPF (RFC 2154 [4]), and RIP2
(RFC 2082 [3]), for example. This avoids packets being spoofed
from other parts of the customer network than the CE router. It
requires the service provider and customer to agree on a shared
secret between all CE and PE routers. It is necessary to do this
for all VPN customers. It is not sufficient to do this only for
the customer with the highest security requirements.
Behringer Informational [Page 10]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
o By configuring parameters of the routing protocol to further
secure this communication. For example, the rate of routing
updates should be restricted where possible (in BGP through
damping); a maximum number of routes accepted per VRF and per
routing neighbor should be configured where possible; and the
Generalized TTL Security Mechanism (GTSM; RFC 3682 [10]) should be
used for all supported protocols.
In summary, it is not possible to intrude from one VPN into other
VPNs, or the core. However, it is theoretically possible to attack
the routing protocol port to execute a DoS attack against the PE
router. This in turn might have a negative impact on other VPNs on
this PE router. For this reason, PE routers must be extremely well
secured, especially on their interfaces to CE routers. ACLs must be
configured to limit access only to the port(s) of the routing
protocol, and only from the CE router. Further routing protocols’
security mechanisms such as MD5 authentication, maximum prefix
limits, and Time to Live (TTL) security mechanisms 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.
BGP has a number of countermeasures such as prefix filtering and
damping built into the protocol, to assist with stability. It is
also easy 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
Similar to IP spoofing attacks, where an attacker fakes the source 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
spoofed labels into the MPLS network from the outside, i.e., from a
VPN (CE router) or from the Internet.
The interface between a 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 another 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.
Behringer Informational [Page 11]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
For security reasons, a PE router should never accept a packet with a
label from a CE router. RFC 3031 [9] 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
potentially allow passing packets to other VPNs it is not permitted
by the RFC.
Thus, it is impossible for an outside attacker to send labeled
packets into the BGP/MPLS IP VPN core.
There remains the possibility to spoof the IP address of a packet
being sent to the MPLS core. Since there is strict address
separation within the PE router, and each VPN has its own VRF, this
can only harm the VPN the spoofed packet originated from; that is, a
VPN customer can attack only himself. MPLS doesn’t add any security
risk here.
The Inter-AS and Carrier’s Carrier cases are special cases, since on
the interfaces between providers typically packets with labels are
exchanged. See section 4 for an analysis of these architectures.
3.5. Comparison with ATM/FR VPNs
ATM and FR VPN services enjoy a very high reputation in terms of
security. Although ATM and FR VPNs can be provided in a secure
manner, it has been reported that these technologies also can have
security vulnerabilities [14]. In ATM/FR as in any other networking
technology, the security depends on the configuration of the network
being secure, and errors can also lead to security problems.
4. Security of Advanced BGP/MPLS IP VPN Architectures
The BGP/MPLS IP VPN architecture described in RFC 2547 [7] defines
the PE-CE interface as the only external interface seen from the
service provider network. In this case, the PE treats the CE as
untrusted and only accepts IP packets from the CE. The IP address
range is treated as belonging to the VPN of the CE, so the PE
maintains full control over VPN separation.
RFC 4364 [1] has subsequently defined a more complex architecture,
with more open interfaces. These interfaces allow the exchange of
label information and labeled packets to and from devices outside the
control of the service provider. This section discusses the security
implications of this advanced architecture.
Behringer Informational [Page 12]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
4.1. Carriers’ Carrier
In the Carriers’ Carrier (CsC) architecture, the CE is linked to a
VRF on the PE. The CE may send labeled packets to the PE. The label
has been previously assigned by the PE to the CE, and represents the
label switched path (LSP) from this CE to the remote CE via the
carrier’s network.
RFC 4364 [1] specifies for this case: "When the PE receives a labeled
packet from a CE, it must verify that the top label is one that was
distributed to that CE." This ensures that the CE can only use
labels that the PE correctly associates with the corresponding VPN.
Packets with incorrect labels will be discarded, and thus label
spoofing is impossible.
The use of label maps on the PE leaves the control of the label
information entirely with the PE, so that this has no impact on the
security of the solution.
The packet underneath the top label will as in standard RFC 2547
[7] networks remain local to the customer carrier’s VPN and not be
inspected in the carriers’ carrier core. Potential spoofing of
subsequent labels or IP addresses remains local to the carrier’s VPN;
it has no implication on the carriers’ carrier core nor on other VPNs
in that core. This is specifically stated in section 6 of RFC 4364
[1].
Note that if the PE and CE are interconnected using a shared layer 2
infrastructure such as a switch, attacks are possible on layer 2,
which might enable a third party on the shared layer 2 network to
intrude into a VPN on that PE router. RFC 4364 [1] specifies
therefore that either all devices on a shared layer 2 network have to
be part of the same VPN, or the layer 2 network must be split
logically to avoid this issue. This will be discussed in more detail
in section 6.
In the CsC architecture, the customer carrier needs to trust the
carriers’ carrier for correct configuration and operation. The
customer of the carrier thus implicitly needs to trust both his
carrier and the carriers’ carrier.
In summary, a correctly configured carriers’ carrier network provides
the same level of security as comparable layer 2 networks or
traditional RFC 2547 [7] networks.
Behringer Informational [Page 13]
RFC 4381 Security of BGP/MPLS IP VPNs February 2006
4.2. Inter-Provider Backbones
RFC 4364 [1] specifies three sub-cases for the inter-provider
backbone (Inter-AS) case.
a) VRF-to-VRF connections at the autonomous system border routers
(ASBRs).
In this case, each PE sees and treats the other PE as a CE; each will
not accept labeled packets, and there is no signaling between the PEs
other than inside the VRFs on both sides. Thus, the separation of
the VPNs on both sides and the security of those are the same as on a
single AS RFC 2547 [7] network. This has already been shown to have
the same security properties as traditional layer 2 VPNs.
This solution has potential scalability issues in that the ASBRs need
to maintain a VRF per VPN, and all of the VRFs need to hold all
routes of the specific VPNs. Thus, an ASBR can run into memory
problems affecting all VPNs if one single VRF contains too many
routes. Thus, the service providers needs to ensure that the ASBRs
are properly dimensioned and apply appropriate security measures such
as limiting the number of prefixes per VRF.
The two service providers connecting their VPNs in this way must
trust each other. Since the VPNs are separated on different
(sub-)interfaces, all signaling between ASBRs remains within a given
VPN. This means that dynamic cross-VPN security breaches are
impossible. It is conceivable that a service provider connects a
specific VPN to the wrong interface, thus interconnecting two VPNs
that should not be connected. This must be controlled operationally.
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to
neighboring AS.
In this case, ASBRs on both sides hold full routing information for
all shared VPNs on both sides. This is not held in separate VRFs,
but in the BGP database. (This is typically limited to the Inter-AS
VPNs through filtering.) The separation inside the PE is maintained
through the use of VPN-IPv4 addresses. The control plane between the
ASBRs uses Multi-Protocol BGP (MP-BGP, RFC 2858 [8]). It exchanges
VPN routes as VPN-IPv4 addresses, the ASBR addresses as BGP next-hop
IPv4 addresses, and labels to be used in the data plane.
The data plane is separated through the use of a single label,
representing a VRF or a subset thereof. RFC 4364 [1] states that an
ASBR should only accept packets with a label that it has assigned to
this router. This prevents the insertion of packets with unknown
labels, but it is possible for a service provider to use any label
Behringer Informational [Page 14]