Home > Articles > Security > Network Security

This chapter is from the book

This chapter is from the book

Specific Inter-AS Considerations

The drawback of RFC 2547 is that it requires a single autonomous system (AS) to provide VPNs across it. RFC 2547bis allows VPNs to be provided across several ASs and thus several service providers. The standard describes three basic models for Inter-AS connectivity (models A, B, and C) that have different security properties.

Model A: VRF-to-VRF Connections at the AS Border Routers

This model is the simplest one, as it uses interfaces or subinterfaces between autonomous system border routers (ASBRs) to keep the VPNs separate. Figure 3-7 shows this principle: the two ASBRs each hold a VRF for each VPN that is shared between the autonomous systems. The ASBRs are then connected, and subinterfaces are used to link the VRFs directly.

03fig07.gif

Figure 3-7 Inter-AS Model A

This model is equivalent in security to the standard RFC 2547 implementation because all external interfaces (seen from either AS) are IP interfaces.

In fact, an ASBR in this model behaves exactly like a normal PE router, and the configuration on an ASBR is also exactly the same as if it connected to a CE router in each VRF. Figure 3-8 shows how an ASBR in this model sees the other connections around it.

03fig08.gif

Figure 3-8 Inter-AS Model A: How an ASBR Sees Its Peers

Therefore, all the considerations from the previous sections apply also in this model: there is strict separation between VRFs, label spoofing is impossible because no labeled packets are accepted by the ASBR from the other ASBR, and the other AS cannot "see" the core.

A further advantage of Inter-AS model A is that existing provisioning systems require little or no changes to support this model because the ASBR is essentially a normal PE, with attachment circuits to untrusted routers. To the provisioning system, such an Inter-AS connection looks like a number of normal CE connections.

For the same reasons, this model is also the easiest in other aspects, such as quality of service (QoS): everything that is possible on a subinterface can be supported automatically in this model. Because consistent QoS is important, especially when several service providers are involved in the provisioning of a VPN, it is important to have clear interfaces.

A service provider can deploy this model without further security implications over the standard MPLS VPN model, just as it would deploy more CE connections.

A VPN user in a single-AS RFC 2547 network has to trust the service provider for correct implementation and operation of the core. In Inter-AS model A, the user must trust all service providers that provide parts of the user's MPLS VPN in this way, but there is no further risk of interference with third parties. The only potential risk is that a service provider connects the VPNs from the other service provider wrongly, but this problem also exists in standard single-AS MPLS networks and has to be controlled operationally.

Inter-AS model A is the most secure interconnection model, but it has scalability issues on the ASBR: the ASBR must be configured with all shared VPNs (VPNs spanning more than one AS) and thus hold all VPN routes of shared VPNs. VPNs that exist only on one AS do not need to be kept on the ASBR. Furthermore, the interface between the ASBRs is not very flexible: a new subinterface must be configured on both sides for each new shared VPN.

The limiting scalability factor in Inter-AS model A is the number of interfaces or subinterfaces required, the number of VRFs required, and the memory required to hold all the routes from the various shared VPNs. Only Inter-AS model A has VRFs configured, so VRF memory is a deciding factor between the different Inter-AS types.

Two more MPLS interconnection models are defined in RFC 2547bis, with the goal of making the interconnection between ASs more scalable. Model B removes the need for separate subinterfaces, and model C even removes the need for configuring VRFs on the ASBRs. Both models are more scalable than model A, but this scalability has security consequences.

Model B: EBGP Redistribution of Labeled VPN-IPv4 Routes from AS to Neighboring AS

Model B removes the need for separate (sub-) interfaces per shared VPN on the ASBR. Here, only a single interface is required between the ASBRs. To be able to still distinguish the data packets from each VPN, packets must now be labeled on the data plane. This essentially creates a type of "tunnel" for each VPN on the single connection, defined by the label. These labels could be configured manually, but for ease of use, the control plane controls the labels in use. The Multi-Protocol Exterior Border Gateway Protocol (MP-eBGP) is used to pass VPN routes between ASBRs, and it assigns the labels to be used for each VPN prefix.

How Model B Works

Figure 3-9 illustrates model B: On the control plane, a single instance of MP-eBGP is used, exchanging all VPN-IPv4 routes, together with the required parameters (RD, label, and so on). On the data plane, all VPN packets are labeled to distinguish the VPN they belong to. In model B, the ASBR still needs to keep all VPN routes of the exchanged VPNs, as in model A, but here there is only a single interconnection.

03fig09.gif

Figure 3-9 Inter-AS Model B

The standard for Multi-Protocol extensions for BGP (MP-BGP) is defined in RFC 2858. Although BGP only uses IPv4, MP-BGP uses the concept of an address family to enable BGP to carry VPN-IPv4 routes as a new address type. For this purpose, MP-BGP introduces two new attribute types, MP_REACH_NLRI and MP_UNREACH_NLRI, to announce and withdraw multiprotocol Network Layer Reachability Information (NLRI). The NLRI contains the VPN-IPv4 prefix (which in turn contains the RD) and the label. Example 3-3 shows how VPN label information can be seen on an ASBR.

Example 3-3. show ip bgp vpnv4 vrf A labels

PE#   sh ip bgp vpnv4 vrf A labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 100:1 (A)
   10.10.10.10/32   192.168.10.10   10/12

This model makes the security between the service providers somewhat more complex. For the VPN user, however, nothing changes in comparison to model A: The VPN user must still trust both service providers, but third parties still can not interfere with this solution.

Security of Model B

To analyze the security between service providers, we examine the data plane and control plane separately.

On the control plane, there is a single MP-eBGP session between ASBRs, nothing else. Specifically, there is no Tag Distribution Protocol (TDP) or Label Distribution Protocol (LDP) running between ASBRs. This session can be and should be secured as any other BGP session: peer authentication with message digest 5 (MD5), maximum route limits per peer and per VRF, dampening, and so on. In addition, prefix filters can be deployed to control which routes can be received from the other AS. Details on how to secure such BGP sessions are discussed in Chapter 5, "Security Recommendations."

With the Chapter 5 recommendations implemented on the two ASBRs, the MP-eBGP control plane does not increase the security exposure over model A and can be considered sufficiently secure for both service provider and VPN user.

On the data plane, labeled packets are exchanged. The label is derived from the MP-eBGP session; therefore, the ASBR announcing a VPN-IPv4 prefix controls and assigns the label for each prefix it announces. On the data plane, the incoming label is then checked to verify that this label on the data plane has really been assigned on the control plane. Therefore, it is impossible to introduce fake labels from one AS to another.

This control on the data plane means that packets with labels that were not assigned to the other ASBR will be dropped; however, it is not possible to check which of the correctly assigned labels is being used.

As an example, assume that an ASBR has announced two prefixes: one from VPN A with label 20, and another prefix from VPN B with label 21. On the data plane, packets with labels other than 20 or 21 can be dropped, but it is not possible to verify that a packet with label 21 really belongs to VRF B.

However, in reality, this does not add a new security exposure: each service provider involved in the provisioning of a VPN has the power to make each VPN insecure (which is not a specific MPLS problem). This does not change when VPNs are shared. As previously mentioned, the VPN user must trust all service providers involved in the provisioning of the VPN.

There is one more potential issue to look at: Layer 2 security. All the considerations so far have been exclusively on Layer 3 and above. However, for a Layer 3 service such as MPLS VPNs to be secure, the lower layers must be secure as well. We have already discussed one Layer 1 issue: a wiretap on core lines or CE-PE lines reveals VPN data, unless encryption is used on top of MPLS.

A potential Layer 2 issue relates to using a shared switch to interconnect various MPLS networks in the Inter-AS model: if the connection between the ASBRs is provided (for example, on an Ethernet switch), Layer 2 security must be taken into consideration. This type of security threat is detailed in Chapter 4, "Secure MPLS/VPN Designs." (A quick summary here: VLANs can usually be assumed to be separate from other traffic on the switch, but within a VLAN there are security issues such as a third party inserting labeled traffic.

In comparison with model A, model B is more scalable in that it requires only one connection between the ASBRs over which all VPNs are propagated. For this to work, MP-eBGP must be run between the ASBRs, and traffic is exchanged with labels. This can be secured adequately, but with more configuration the likelihood of error and a subsequent security breach increases.

Model B still requires each ASBR to hold the VPN routes for each shared VPN, and this is another scalability concern. To solve this issue, model C was invented.

Model C: Multihop eBGP Redistribution of Labeled VPN-IPv4 Routes Between Source and Destination ASs, with eBGP Redistribution of Labeled IPv4 Routes from AS to Neighboring AS

Model C was introduced in RFC 2547bis to remove the requirement to hold VPN-specific information on the ASBR. In this model, the VPN-specific information is propagated between the ingress PE on AS 1 and the egress PE on AS 2 directly. To improve scalability further, it allows the usage of route reflectors (RRs). [6]

How Model C Works

Figure 3-10 depicts model C without RRs. The PEs of both autonomous systems have visibility of each other through a multihop MP-BGP connection, and they exchange the VPN-specific information (VPN-IPv4 NLRIs, labels, and so on) end to end, using the loopback addresses of the PEs without involving the ASBRs. This means that the ASBRs do not need to hold VPN-specific information.

03fig10.gif

Figure 3-10 Inter-AS Model C, Without Route Reflectors

The ASBRs need only to exchange host routes (/32) to the PE routers involved in the VPN, with the labels needed to get there. In this way they facilitate the multihop BGP connection between the PE routers on both sides.

A Label Switch Path (LSP) is built from the ingress PE router in AS 1 to the egress PE in AS 2 (using loopback addresses). VPN traffic uses this LSP to reach the other AS. As far as the data plane is concerned, the ASBRs act as P routers, with no knowledge about the VPNs concerned. Also, between ASBRs the VPN traffic looks like traffic between P routers: each data packet is prepended with the VPN label and then with an egress-PE label.

Model C can be further scaled by using route reflectors in each AS. Figure 3-11 depicts this mode of operation. Because many networks require RRs internally, MPLS VPN model C also usually uses RRs.

03fig11.gif

Figure 3-11 Inter-AS Model C, with Route Reflectors

Here, the PEs in both autonomous systems maintain an MP-BGP peering only with the RRs in their own AS. The RRs in turn maintain an external MP-BGP peering. LSPs are established end to end from ingress PE to egress PE, as before.

Security of Model C

The security of this model is considerably more open than in models A and B.

On the control plane, model C has two interfaces between autonomous systems:

  • The ASBRs exchange IPv4 routes with labels via eBGP. The purpose is to propagate the PE loopback addresses to the other AS so that LSPs can be established end to end. This route exchange and the whole BGP session can be controlled as in standard BGP. On this connection, no VPN information is passed on—only information relevant to the two ASs. Details on how to secure this connection are explained in Chapter 5, "Security Recommendations."
  • The RRs exchange VPN-IPv4 routes with labels via multihop MP-eBGP. The prefixes exchanged can be controlled through route maps, equally the route targets. This makes it possible to ensure that only the required VPNs are exchanged, and within the VPNs, only specific prefixes.

On the data plane, the traffic exchanged between the ASBRs contains two labels:

  • VPN label— Is set by the ingress PE to identify the VPN
  • PE label— Specifies the LSP to the egress PE

Model C is considerably more open in terms of security than the previous models, for the following reasons:

  • To be able to establish end-to-end LSPs, the service provider must be able to reach all PEs of the other AS, which hold connections of shared VPNs. This can be a considerable number of PEs, exposing important parts of the normally internal infrastructure of an AS to the other AS. This also means that considerations that are usually local to an AS in terms of addressing need to be coordinated with the other AS. It also means that traffic can be sent to a number of internal addresses from the outside, making possible attacks from the outside. The recommendation is to filter IP packets into the core as tightly as possible to prevent these issues. Labeled packets cannot be filtered currently.
  • The ASBR does not hold any VPN information. This is a scalability advantage, but at the same time it prevents the ASBR from checking the VPN label for its validity. This means that it is impossible to verify the VPN label in the data path. (In model B, the ASBR holds this information and can therefore validate the VPN label.) The egress PE cannot verify the packet anymore because at this point the origin of the packet can no longer be determined.

Considering these reasons, a potential attack could be AS 1 sending labeled traffic into AS 2, where the top label represents the label to a valid egress PE in AS 2. AS 1 holds PE labels for all those PEs in AS 2, on which it has shared VPNs. However, because the VPN label cannot be checked by the ASBR, AS 1 could send packets with random VPN labels into AS 2 without AS 2 having a way to block this. Figure 3-12 illustrates this vulnerability. AS 1 has an LSP to the egress PE in AS 2. This PE has two VPNs configured: VPN A, which is shared with AS 1, and VPN B, which is not shared with AS 1. By sending the packet shown in Figure 3-12 with a VPN label for VPN B, the packet will be forwarded into VPN B. At the time of writing this book there was no solution to this issue.

03fig12.gif

Figure 3-12 Case C Security Issue

But how dangerous is this issue? First of all, AS 1 would need to know the VPN label for VPN B. The MPLS VPN network does not expose the label externally, so there are two ways of getting it: by espionage, or simply by trying the entire label space. A label has 20 bits, yielding 220 = 1,048,576 potential label values. Assuming a single packet attack with a 500-byte packet size, in the worst case an attacker would need to send 524 MB, which would take approximately 7 minutes on a 10 Mbps link, and 9 hours on a 128 k link. Note that in practice this number would be statistically smaller, and also, label numbering is not random, so intelligent guessing could reduce this number significantly.

Then, a malicious user in AS 1 could only send traffic into the VPN, but not receive a reply. However, there are a large number of examples in the history of security where a single unidirectional packet was enough to propagate a worm, for example. So while this limits the scope of an attack, it does not rule it out. In any case, the potential attacker would not receive feedback as to whether the attack was successful.

Therefore, it is not easy to carry out a sophisticated attack against a VPN from a given AS. But a single-packet unidirectional attack, as frequently used in the propagation of worms, is possible, even though statistically unlikely.

The consequence of this is that in model C the service providers must trust each other also in areas that are not shared. Therefore, model C is most commonly used today where a single operator uses several ASs on the backbone. In this case, implicit trust exists between the ASs because they have the same operational control.

As in model B, Layer 2 security between the ASBRs is extremely important. Therefore, here again is the recommendation from the previous section:

Since the various Inter-AS connectivity options are confusing and their differences often subtle, the next section puts all options in context for easy comparison.

Comparison of Inter-AS Security Considerations

Table 3-1 compares the three Inter-AS connectivity options in simple terms.

Table 3-1. Properties of Inter-AS Models

 

Model A

Model B

Model C

Required protocols between ASBRs

None (although intra-VRF routing is typically used)

MP-eBGP

eBGP

Complexity

Simple

More complex

Very complex

Scalability

Not very scalable

More scalable: one ASBR interconnection only

Very scalable: ASBRs don't carry VPN information

Visibility of other AS

None

ASBR only

All PEs, which carry shared VPNs and route reflectors

VPN user must trust

All service providers

All service providers

All service providers

Service provider must trust

Nobody

Nobody

The other service provider

So which Inter-AS option is the right one for you? Here are some decision guidelines, from a security perspective:

  • If the number of shared VPNs and prefixes is small, consider model A. ("Small" is a relative term, depending on your ASBR capabilities.) It is simple, most provisioning systems easily support it, and it is the most secure option because of its simplicity: the more complex a solution, the more risk for errors and security issues. Model A has almost nothing to configure and no global protocols running (only possibly inside the VRFs). In security, nothing can beat simplicity! If the number of VPNs and prefixes is too large for model A, consider one of the other models.
  • If you are peering with another operator, that is, the other AS is not under your direct control and you cannot fully trust it, use model B. If you cannot fully trust the other side, you need to control the interface. Model B has a clear-cut interface, which is relatively easy to control. Model C is not recommended here.
  • If you are a single operator controlling all involved ASs, feel free to use model C. In this case, all your ASs behave a bit like a single AS, where ingress and egress PEs are in direct contact. The boundaries between ASs are less clear, but if there is one operator for all ASs, this is controllable.

A number of risks exist in any environment and are independent of the Inter-AS model:

  • Service provider 1 sends faked or crafted IP packets into any shared VPN on AS 2: this cannot be prevented. The VPN user must trust both service providers.
  • Service provider 1 can bring a fake CE into any shared VPN, endangering the integrity of that VPN: this also cannot be prevented. Again, the service providers are trusted.
  • A service provider can sniff traffic on any trunk, endangering the confidentiality of the VPN data. Here, too, the VPN user must trust the provider.

This appears to be quite an insecure model, but in fact the same risks exist in any VPN technology, although sometimes these trust issues are not clear. The service provider must always be trusted. The only solution if the service provider cannot be trusted is to provide additional security on top of MPLS, such as through IPsec. Chapter 6, "How IPsec Complements MPLS," describes this option.

Another model involving several providers is the Carrier's Carrier model. It allows a hierarchical structure, where a service provider resells a service from an MPLS provider. The next section covers this case.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020