Internet DRAFT - draft-bhargav-l3vpn-inter-provider-optcsec
draft-bhargav-l3vpn-inter-provider-optcsec
L3VPN Working Group Bhargav Bhikkaji
Internet-draft Balaji Venkat Venkataswami
Intended Status:Experimental RFC Dell-Force10
Expires: August 2012 March 2, 2012
Preventing spoofing attacks in BGP-MPLS-VPN Inter-Provider Model-C
draft-bhargav-l3vpn-inter-provider-optcsec-03
Abstract
In certain models of inter-provider Multi-Protocol-Label-Switching
based Virtual Private Networks (MPLS-VPNs), spoofing attacks against
VPN sites is a key concern. Unidirectional attacks towards VPN sites
can compromise servers at the VPN sites and cause Denial-of-Service
(DoS) situations. Currently, the inner labels associated with VPN
sites are not encrypted during transmission. The Provider Edge (PE)
router at the end to which the VPN customer is attached accepts any
data packet with a valid label. This enables a man-in-the-middle
attacker to spoof a packet to a specific site of a VPN. In this
paper, we propose some secure techniques which provide security
against such label-spoofing. These techniques ensure that an attacker
would not be able to spoof labeled data packets. In order to make the
proposed scheme robust, some additional steps are proposed over and
above the initial steps specified. This makes the attacker to spend
non-linear time to guess the right label for his unidirectional
attacks to succeed. Our proposed technique can be applied to a
specific type of inter-provider Border Gateway Protocol(BGP) based
MPLS VPN and other existing variant where Multi-Protocol exterior-
BGP (MP-eBGP) multi-hop is used. In future, if any other variant is
proposed to use MP-eBGP multi-hop, our scheme can be used to protect
against spoofing attacks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
Bhargav.B et.al Expires August 2012 [Page 1]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Security issue in model C . . . . . . . . . . . . . . . . . 5
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Methodology of the Proposal . . . . . . . . . . . . . . . . . 6
2.1 Solution:1 . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Control Plane operation . . . . . . . . . . . . . . . . 7
2.1.2 Data-Plane Operation . . . . . . . . . . . . . . . . . . 8
2.1.3 Mapping a hash to a 20 bit value . . . . . . . . . . . . 9
2.2 Solution:2 . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Control Plane operation . . . . . . . . . . . . . . . . 9
2.2.2 Data-Plane Operation . . . . . . . . . . . . . . . . . . 10
2.3 Use Case:1 . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Use Case:2 (RSVP can use this during tunnel setup) . . . . . 11
2.5 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 13
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
Bhargav.B et.al Expires August 2012 [Page 2]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Bhargav.B et.al Expires August 2012 [Page 3]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
1 Introduction
MPLS technology helps forward data packets in the Internet using
fixed-size labels [3]. By stacking labels (label-stacking technique),
specific customer services such as layer 3 VPNs based on BGP
extensions are widely deployed in the Internet. BGP based MPLS layer
3 VPN services are provided either on a single internet service
provider (ISP) core or across multiple ISP cores. The latter cases
are known as inter-provider MPLS VPNs which are broadly categorized
and referred to as models: A, B and C. Model A uses back-to-back VPN
Routing and Forwarding (VRF) connections between Autonomous System
Border Routers (ASBRs). Model B uses eBGP redistribution of labelled
VPN-IPv4 routes from AS to neighbouring AS. Model C uses multi-hop
eBGP redistribution of labelled VPNIPv4 routes and eBGP
redistribution of IPv4 routes from AS to neighbouring AS. Please
refer [1] for more details. A. Security issues in inter-provider VPN
models Model A is as secure a standard as the single-Autonomous
System (AS) standard proposed in [5]. Model B can be secured well on
the control plane, but on the data-plane the top-most label is not
checked for validity. This weakness could be exploited to inject
crafted packets from inside an MPLS core into the other. There is a
work-around discussed in [1] that solves the problem. Model C can
also be secured well on the control plane. But as the ASBRs do not
have any VPN information and the inner-most label cannot be
validated, the data-plane has architectural weakness with respect to
security. This enables unidirectional packets to be sent into the VPN
sites connected to the other AS, which cannot be protected against by
mere configuration. Model C can therefore only be deployed where
service providers trust each other. For more details refer to [1].
In [2] the authors propose encryption techniques, such as IPSec, for
securing the provider edge (PE) to PE legs of the network. However
the authors also highlight that the processing capacity could be
over-burdened. If an attacker is located at the core of the network,
or in the intermediate link or network between the providers that
constitute a inter-provider MPLS VPN solution, then spoofing attacks
are possible. In case an attacker spoofs the inner labels that
identify packets going towards a L3 VPN site, sensitive information
related to services available within the organizational servers can
be compromised. A denial-of-service (DoS) attack could also be
launched against these sensitive sites. As far as we know, there is
no scheme adopting encryption available for installing an anti-
spoofing mechanism for these VPN service labels. The proposed scheme
in this document provides an alternative in case other schemes that
dont adopt encryption are not suitable. The PEs at the end to which
the VPN customer is attached will accept any packet with a valid
label and will forward it to the VPN customer. There is no way to
Bhargav.B et.al Expires August 2012 [Page 4]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
ensure the veracity of a spoofed packet.
1.1 Security issue in model C
The deficiency discussed above is particularly true in the case of
inter-provider BGP based MPLS VPN model C. Even though model C is
highly scalable for carrying VRF routes, the vulnerability of the
data-plane has rendered it unusable and the current recommendation is
that model C must not be used. As discussed in [1] the insecurity for
model C stems from the fact that anybody within the core of the
network or at the peering points of the providers can cause DoS
attacks or worm attacks. It is possible to filter all IP traffic with
the exception of the required eBGP peering between the AS border
routers thereby preventing a large number of potential IP traffic
related attacks. Labelled packets, however, are much harder to
control. In model C, there are at least two labels for each packet:
the PE label, which defines the Label Switched Path (LSP) to the
egress PE, and the VPN label, which defines the VPN on the PE to
which the packet is associated.
1.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Bhargav.B et.al Expires August 2012 [Page 5]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
2. Methodology of the Proposal
Consider a setup as below
The reference MPLS-eBGP based VPN network for model-C / Option-C as
described in [11] is shown in Figure 1, which also shows the control
plane exchanges. The near-end PE (PE_ne) and far-end PE (PE_fa) are
connected through the inter-provider MPLS core. The VPN connectivity
is established through a set of routers from different Autonomous
Systems (AS) and their ASBRs. In the VPN, MP-eBGP updates are
exchanged for a set of Forward Equivalence Classes (FECs). These
FECs, which have to be protected, originate from the prefixes behind
PE_ne in a VPN site or a set of VPN sites.
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne )
( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]_________________[PE_fa]
|
172.18.10.0/24 NH:PE_ne 172.18.20.0/24 [CE2]
VPN Label: Inner Label IL1
For the example below we refer to PE_ne and PE_fa in the diagram as
PE-1 and PE-2.
1) PE-1 and PE-2 would establish a MPeBGP-VPNV4 session between them
2) PE-1 and PE-2 will exchange VPN-labels for the prefixes (FECs)
between them which are to be used during forwarding
3) This mechanism does not avoid an attacker who is trying to spoof a
packet from somewhere inside the core or from within the network
between the two ISP / provider networks.
There are 2 ways to solve this problem
Bhargav.B et.al Expires August 2012 [Page 6]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
2.1 Solution:1
2.1.1 Control Plane operation
1) PE-1 and PE-2 agree upon looking for a "Secure Label" in addition
to the VPN label
2) PE-1 and PE-2 use PKI and publish their respective public keys.
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne )
( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
^ ^
+-------------- MP-eBGP IPVPN-V4 session --------------+
Figure 2:PKI exchange to exchange their respective public keys.
3) PE-1 and PE-2 also agree upon a universal hashing algorithm to
use. It could be any of standard universal hashing algorithms which
minimize collisions to the maximum extent possible. They also agree
upon a bitmask that is to be used in step 5.1. These could be
exchanged using the MP-eBGP label exchange mechanism using suitable
fields which will be discussed in the appendix A.1 to be added later.
4) Unlike the VPN label that is exchanged as part of the MPBGP-VPNV4
exchange, the "Secure Label" is generated on the fly during forwarding.
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne )
( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
^ ^
+-------------- MP-eBGP IPVPN-V4 session --------+
172.18.10.0/24 (4) NH:PE_ne 172.18.20.0/24
VPN Label: Inner Label IL1
Universal hashing Algorithm: UA1,
Bitmask: B1
5) Secure labels are generated for prefixes reachable via PE-1 by PE-2
Bhargav.B et.al Expires August 2012 [Page 7]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
5.1) PE-2 takes a hash on the first 256 bytes of the packet's
payload received using the universal hashing algorithm agreed upon.
If the PEs are from the same vendor or from a different vendor the
algorithm to be used is expressed in a standard identifier which is
understood by both PEs.
5.2) Take any 20 bits from the hash using a bitmask that is also
shared amongst the two PEs.
5.3) Take this 20 bit value and encrypt with the private key of PE-2
if traffic is flowing from PE-2 to PE-1. The inner label, universal
hashing algorithm and the bitmask are sent from PE-1 to PE-2 for
prefixes reachable via PE-1. Steps 5.1 to 5.3 are done as part of data
plane operations which are explained below.
2.1.2 Data-Plane Operation
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
(IL1:SL:172.18.10.1 L1:IL1:SL:172.18.10.1 / \ )
( | L3:IL1:SL:172.18.10.1 <-+ L4:IL1:SL:172.18.10.1)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
172.18.10.0/24 L2:IL1:SL:172.18.10.1 172.18.20.0/24
1) Let us assume a customer connected to PE-2 is sending a packet to
PE-1
2) The packet could be any payload encapsulated in the MPLS header
having the usual stack of labels for MODEL-C
3) When the packet reaches PE-2, following operation is done
3.1) Generate a hash of the received packet using the universal
hashing algorithm chosen.
3.2) Take agreed 20 bits from the hash using the bitmask exchanged.
(Text below talks about what 20 bits to take)
3.3) Encrypt those 20 bits with PE-2's private key
3.4) Send the packet with VPN label on top of the secure label
4) When the packet reaches PE-1, following operation is done
4.1) Generate a hash on the 256 bytes of data after the secured
Bhargav.B et.al Expires August 2012 [Page 8]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
label
4.2) Take agreed 20 bits using the bitmask agreed upon after
hash calculation in #4.1, call it 'K'
4.3) Decrypt received secured-label using public key of PE-1
4.4) Check if decrypted secured label and K are same.
4.5) If both are same then forward the packet otherwise drop it
2.1.3 Mapping a hash to a 20 bit value
1) The universal hashing algorithm selected generates a 128 bit value
but a MPLS label is 20 bit value
2) A mechanism is necessary to map 128 bits to a 20 bit value
3) PE-1 and PE-2 would exchange a 128 bitmask which is used to convey
which 20 bits in that 128 bits is to be used for the purposes of
encryption
4) This bitmask / bitmap is generated randomly and exchanged at the
time of MP-eBGP NLRI exchanges and expires every t seconds.
5) Whenever a new bitmap is generated, this would be shared between
the PE's
2.2 Solution:2
2.2.1 Control Plane operation
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne )
( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
^ ^
+-------------- MP-eBGP IPVPN-V4 session --------------+
(1) PKI exchange to exchange their respective public keys.
1) PE-1 and PE-2 use PKI and publish their respective public keys.
2) PE-1 and PE-2 agree upon looking for a digital signature below
Bhargav.B et.al Expires August 2012 [Page 9]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
the EOS label.This would be done with an appropriate indicator in the
MP-eBGP update which would tell the other PE (far-end PE) that a
digital signature mechanism is to be used for purposes of protecting
the payload / stream between the two PEs.
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne )
( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
^ ^
+-------------- MP-eBGP IPVPN-V4 session --------+
172.18.10.0/24 (4) NH:PE_ne 172.18.20.0/24
VPN Label: Inner Label IL1
Universal hashing Algorithm: UA1,
Digital Signature mechanism
3) PE-1 and PE-2 also agree upon what universal hashing algorithm to
use.
4) Digital signature is generated as follows
4.1) First take a hash on the first 256 bytes of the packet received
4.2) Encrypt with private key available for the transaction.
2.2.2 Data-Plane Operation
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / \ )
( / +-----------+ ) ( / \ )
(IL1:DS:172.18.10.1 L1:IL1:DS:172.18.10.1 / \ )
( | L3:IL1:DS:172.18.10.1 <-+ L4:IL1:DS:172.18.10.1)
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
172.18.10.0/24 L2:IL1:DS:172.18.10.1 172.18.20.0/24
1) Let us assume a customer connected to PE-1 is sending a packet
to PE-2
2) The packet could be any payload encapsulated in the MPLS header
having a stack of labels for MODEL-C
Bhargav.B et.al Expires August 2012 [Page 10]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
3) When the packet reaches PE-1, following operation is done
3.1) Generate a hash of the received packet involving the first
256 bytes of the packet.
3.2) Encrypt the hash with private key of PE-1.
3.3) Add these encrypted 128 bits below EOS label
3.4) Send the packet with VPN label and with encrypted
digital signature below EOS label
4) When the packet reaches PE-2, following operation is done
4.1) Based on the VPN label, PE-2 knows that it needs to look for
a digital signature below EOS label
4.2) Remove 128 bit digital signature below EOS label
4.3) Calculate a hash after removing the digital signature,
call it 'J'
4.4) Decrypt the received digital signature with public key of
PE-1, Call it 'K'
4.5) compare the J and K. If they are equal, forward
the packet else drop it.
Note:
1) For both solutions, hash is calculated only before slapping VPN
label at PE-1, ie TTL update gets over by then
2) In case of Solution 2, to support ECMP case, we could add one
nibble extra in front of the digital signature based on IPV4 or IPV6
2.3 Use Case:1
1) The above case talks about usage of this mechanism in VPN case
2.4 Use Case:2 (RSVP can use this during tunnel setup)
1) Head-end during tunnel setup can inform tail-end about "Secured-
Label" during setup
2) We can use any of the above solutions for LSP setup as well.
2.5 Advantages
Bhargav.B et.al Expires August 2012 [Page 11]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
1) Any attacker's packet would have to guess a 40 bit label in the
case of Solution 1 and a 20 + 128-bit DS label in Solution 2.
2) Since we are using PKI, it is impossible for an attacker to create
a packet with same semantics(of PE) since he would have to guess the
Algorithm UA(x) and the bitmask pattern in Solution (1) and the PKI
key as well. In Solution (2) he would have to guess the PKI key and
the Algorithm UA(x).
3) Provides real security from attacker in the case of a man-in-the-
middle attack say from the intervening network between the two
providers.
5) The same mechanism could be used by RSVP for tunnel setup between
Head-end and tail-end. Head-end during RSVP set-up can inform tail-
end to use the "Secured-Label" mechanism or the DS mechanism in
Solution 1 and Solution 2 respectively.
2.6 Limitations
1) An additional decryption and hashing is necessary in PE for
secured labels in Solution 2 and in Solution 1 a bitmask lookup and
selection is required over and above the decryption and hashing.
2) This mechanism will not work if this packet is fragmented inside
the core. But given that fragmentation is not done as PMTUD may
be in vogue this is not really a serious limitation.
Bhargav.B et.al Expires August 2012 [Page 12]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
3 Security Considerations
PKI is a secure mechanism as established in common security
parlance. The control plane is secure in Option-C / Model-C in
Inter-provider VPNs. It would take more than polynomial time
complexity for an attacker to spoof the traffic when this
mechanism is in vogue. Thus spoofing attacks are obviated.
4 IANA Considerations
IANA needs to assign the Type value for exchanging the additional
details in the control plane as illustrated in the above two
solutions.
5 References
5.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
5.2 Informative References
[1] S. Alouneh, A. En-Nouaary and A. Agarwal, MPLS
security: an approach for unicast and multicast
environments, Annals of Telecommunications, Springer, vol.
64, no. 5, June 2009, pp. 391-400, doi:10.1007/s12243-009-
0089-y.
[2] M. H. Behringer and M. J. Morrow, MPLS VPN security,
Cisco Press, June 2005, ISBN-10: 1587051834.
[3] B. Daugherty and C. Metz, Multiprotocol Label
Switching and IP, Part 1, MPLS VPNS over IP Tunnels, IEEE
Internet Computing, May-June 2005, pp. 68-72, doi:
10.1109/MIC.2005.61.
[4] L. Fang, N. Bita, J. L. Le Roux and J. Miles,
Interprovider IP-MPLS services: requirements,
Bhargav.B et.al Expires August 2012 [Page 13]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
implementations, and challenges, IEEE Communications
Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi:
10.1109/MCOM.2005.1452840.
[5] C. Lin and W. Guowei, Security research of VPN
technology based on MPLS, Proceedings of the Third
International Symposium on Computer Science and
Computational Technology (ISCSCT 10), August 2010, pp.
168-170, ISBN- 13:9789525726107.
[6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D.
Farinacci and D. Katz, Tag switching architecture
overview, Proceedings of the IEEE, vol. 85, no. 12,
December 1997, pp. 1973-1983, doi:10.1109/5.650179.
[7] E. Rosen and Y. Rekhter, BGP/MPLS IP Virtual Private
Networks (VPNs), RFC 4364, Standard Track, February, 2006.
[8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C.
Stein, Introduction to algorithms, 3rd edition, MIT Press,
September 2009, ISBN-10:0262033844.
[9] C. Semeria, RFC 2547bis: BGP/MPLS VPN fundamentals,
Juniper Networks white paper, March 2001.
[10] Advance MPLS VPN Security Tutorials [Online],
Available:
http://etutorials.org/Networking/MPLS+VPN+security/
Part+II+Advanced+MPLS+VPN+Security+Issues, [Accessed: 10th
December 2011]
[11] Inter-provider MPLS VPN models [Online], Available:
http://mpls-configuration-on-cisco-
iossoftware.org.ua/1587051990/ ch07lev1sec4.html,
[Accessed 10th December 2011]
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
Bhargav.B et.al Expires August 2012 [Page 14]
INTERNET DRAFT Securing Inter-provider MPLS-VPN Model-C February 2012
Authors' Addresses
Bhargav Bhikkaji,
Dell-Force10,
350 Holger Way,
San Jose, CA 95134
U.S.A
EMail: BHARGAV_BHIKKAJI@dell.com
Balaji Venkat Venkataswami,
Dell-Force10,
Olympia Technology Park,
Fortius block, 7th & 8th Floor,
Plot No. 1, SIDCO Industrial Estate,
Guindy, Chennai - 600032.
EMail: BALAJI_VENKAT_VENKAT@dell.com
Bhargav.B et.al Expires August 2012 [Page 15]
