Securing Model-C Inter-Provider VPNs with Label Hopping and TicToc
draft-mjsraman-l3vpn-tictoc-label-hop-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Shankar Raman , Balaji Venkat Venkataswami , Gaurav Raina | ||
| Last updated | 2012-03-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mjsraman-l3vpn-tictoc-label-hop-00
L3VPN Working Group Shankar Raman
Internet-Draft Balaji Venkat Venkataswami
Intended Status: Experimental RFC Gaurav Raina
Expires: September 2012 I.I.T, Madras
March 26, 2012
Securing Model-C Inter-Provider VPNs with Label Hopping and TicToc
draft-mjsraman-l3vpn-tictoc-label-hop-00
Abstract
In certain models of inter-provider Multi- Protocol Label Switching
(MPLS) based Virtual Private Networks (VPNs) spoofing attack against
VPN sites is a key concern. For example, MPLS-based VPN inter-
provider model "C" is not favoured, owing to security concerns in the
dataplane, even though it can scale with respect to maintenance of
routing state. Since the inner labels associated with VPN sites are
not encrypted during transmission, a man-in-themiddle attacker can
spoof packets to a specific VPN site. In this paper, we propose a
label-hopping technique which uses a set of randomized labels and a
method for hopping amongst these labels using the time instant the
packet leaves the port from a sending Provider Edge Router. To
prevent the attacker from identifying the labels in polynomial time,
we also use an additional label. The proposed technique can be
applied to other variants of inter-provider MPLS based VPNs where
Multi-Protocol exterior-BGP (MP-eBGP) multi-hop is used. As we
address a key security concern, we can make a case for the deployment
of MPLS based VPN inter-provider model "C". Specifically we use the
TicToc based Precision Time Protocol LSP to provide the timing for
determining the time instant at which the packet is sent from the
remote end Provider Edge Router and for calculating when it must have
left the that peer at the Provider Edge Router at the near end /
receiving end.
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Shankar Raman et.al Expires September 2012 [Page 1]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Methodology of the proposal . . . . . . . . . . . . . . . . . 5
2.1 PRE-REQUISITES FOR THE LABEL-HOPPING SCHEME . . . . . . . . 5
2.1.1 MPLS VPN model "C" . . . . . . . . . . . . . . . . . . . 5
2.1.2 PE configuration . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 6
2.2 LABEL-HOPPING TECHNIQUE . . . . . . . . . . . . . . . . . . 7
2.2.1 Algorithm 1 Control-plane PEne algorithm . . . . . . . . 7
2.2.2 Algorithm 2 Control-plane PEfa algorithm . . . . . . . . 9
2.2.3 Algorithm 3 Data-plane PEfa algorithm . . . . . . . . . 10
2.2.4 Algorithm 4 Data-plane PEne algorithm . . . . . . . . . 11
2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . 12
2.3 SIMULATION AND IMPLEMENTATION . . . . . . . . . . . . . . . 12
2.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . 13
2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 13
2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 14
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 15
Shankar Raman et.al Expires September 2012 [Page 2]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Normative References . . . . . . . . . . . . . . . . . . . 15
5.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Shankar Raman et.al Expires September 2012 [Page 3]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
1 Introduction
Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size
labels to forward data packets between routers. By stacking labels,
specific customer services such as Layer 3 Virtual Private Networks
(L3-VPNs) based on Border Gateway Protocol (BGP) extensions are
widely deployed in the Internet. BGP-based MPLS L3-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" [10].
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
Autonomous Systems (AS) to neighbouring AS. Model "C" uses multi-hop
MP-eBGP redistribution of labelled VPN-IPv4 routes and eBGP
redistribution of IPv4 routes from an AS to a neighbouring AS. Model
"C" is more scalable for maintaining routing states and hence
preferred for deployment in the Internet; refer to [2] for more
details. Security issues in MPLS, especially MPLS-based VPNs has
attracted attention [1]. The security of model "A" matches the
single-AS standard proposed in [9]. Model "B" can be secured well on
the control-plane, but on the data-plane the validity of the outer-
most label (Label Distribution or Resource Reservation Protocol
label) is not checked. This weakness could be exploited to inject
crafted packets from inside an MPLS network core. A solution for this
problem is proposed in [2]. Model "C" can be secured on the control-
plane but has a security weakness on the data-plane. The Autonomous
System Border Routers (ASBRs) do not have any VPN information and
hence the inner-most label cannot be validated. In this case, the
solution used for Model "B" cannot be applied. An attacker can
exploit this weakness to send unidirectional packets into the VPN
sites connected to the other AS. Therefore, ISPs using model "C" must
either trust each other or not deploy it [4].
Control plane security issue in model "C" can be resolved by using
IPSec. If IPSec is used in the data-plane then configuring and
maintaining key associations could be extremely cumbersome. Even
though model "C" is highly scalable for carrying VPN Routing and
Forwarding (VRF) routes, the vulnerability of the data-plane renders
it unusable. The current recommendation is that model "C" must not be
used. A simple solution to this problem is to filter all IP traffic
with the exception of the required eBGP peering between the ASBRs,
thereby preventing a large number of potential IP traffic-related
attacks. However, controlling labelled packets is difficult. In model
"C", there are at least two labels for each packet: the Provider Edge
(PE) label, which defines the Label Switched Path (LSP) to the egress
Shankar Raman et.al Expires September 2012 [Page 4]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
PE, and the VPN label, which defines the VPN associated with the
packet on the PE.
In [5], the authors propose encryption techniques, such as IPSec, for
securing the provider edge (PE) of the network. The authors also
highlight that the processing capacity could be over-burdened.
Further, if an attacker is located at the core of the network, or in
the network between the providers that constitute an inter-provider
MPLS VPN, then spoofing attacks are possible. The vulnerability of
MPLS against spoofing attacks and performance impact of IPSec has
been discussed in [3]. If the inner labels that identify packets
going towards a L3 VPN site are spoofed, then sensitive information
related to services available within the organizational servers can
be compromised. As far as we know, there is no scheme available for
installing an antispoofing mechanism for these VPN service labels.
This paper outlines a label-hopping technique that helps to alleviate
the data-plane security problem in model "C". We propose a scheme
that changes the inner VPN labels dynamically based on the time
instant the packet is sent from the remote-end PE router. By using a
mix of algorithms and randomized labels, we can guard against
spoofing and related attacks. The advantage of our scheme is that it
can be used wherever Multiprotocol-external BGP (MP-eBGP) multi-hop
scenarios arise.
1.1 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].
2. Methodology of the proposal
2.1 PRE-REQUISITES FOR THE LABEL-HOPPING SCHEME
In this section, we briefly review the network topology for model
"C", the PE configuration and the control-plane exchanges needed for
our proposed scheme.
2.1.1 MPLS VPN model "C"
The reference MPLS-eBGP based VPN network for model "C" as described
in [11] is shown in Figure 1, which also shows the control plane
exchanges. The near-end PE (PEne) and far-end PE (PEfa) 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
Shankar Raman et.al Expires September 2012 [Page 5]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
exchanged for a set of Forward Equivalence Classes (FECs). These
FECs, which have to be protected, originate from the prefixes behind
PEne in a VPN site or a set of VPN sites.
2.1.2 PE configuration
Various configurations are needed on the PEs to implement the label
hopping scheme. A set of "m" algorithms that generate collision-free
labels (universal hashing algorithms) are initially implemented in
the PEs. Each algorithm is mapped to an index A = (a1; a2; . . . am)
where m >= 1. The bit-selection pattern used by the PEs for
generating the additional label is also configured. PEne must be
configured for a FEC or a set of FECs represented by an aggregate
label (per VRF label) which will use the label-hopping scheme. For
each FEC or a set of FECs, a set of valid labels used for hopping, K
= (k1; k2; k3; . . . kn) where n >= 1 and, ki != kj if i != j, is
configured in PEne. For the set of labels K time slices TS = (TS1;
TS2; TS3 . . . TSn) are also exchanged. These time slices can be
periodically changed and a new set of TS ranging from TS1 to TSn can
be exchanged after a time duration TS_Exchange_Interval which itself
can be randomized from time to time.In the case of bi-directional
security, the roles of the PEs can be reversed.
2.1.3 Control and data-plane flow
Initially, set K, set TS and the bit-selection pattern used by the
PEs are exchanged securely over the control-plane. Optionally an
index from A, representing a hash-algorithm, could also be exchanged.
We propose that only the index is exchanged between the PEs, as it
enhances the security, for two reasons. First, the algorithm itself
is masked from the attacker. Second, the algorithm can be changed
frequently, and it would be difficult for the attacker to identify
the final mapping that generates the label to be used for a packet.
Figure 1 depicts this unidirectional exchange from PEne to PEfa.
The control plane exchanges also involve a-priori constructing a
Precision Time Protocol (PTP) LSP for deriving the clock at the PEne
and PEfa for a forwarding direction. For the reverse direction
another PTP LSP can be constructed as well. In the example that we
illustrate we discuss about only a single forwarding direction. The
PTP LSP port assigned for a forwarding direction is tied in with the
configuration that goes into the inter-PEne-PEfa exchanges to setup
the labelling control plane. So each pair of PEne and PEfa knows
which PTP port and corresponding PTP LSP as per [12] to be used for
the traffic. The PTP LSP is intended for providing the clocking
between a pair of PEne and PEfa. The clock / timestamp derived from
this PTP LSP is used in the data plane operation to determine which
label is valid at that time instant as will be seen in the Algorithms
Shankar Raman et.al Expires September 2012 [Page 6]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
provided below.
Once the secure control-plane exchanges are completed, we apply the
label-hopping technique, and PEfa forwards the labelled traffic
towards PEne through the intermediate routers using the label-
stacking technique (Figure 2). The stacked labels along with the
payload are transferred between the AS and ASBRs before they reach
PEne. Using the label-hopping algorithm PEne verifies the integrity
of labels. Upon validation, PEne uses the label information to
forward the packets to the appropriate VPN service instance or site.
This data-plane exchange from PEfa and PEne is depicted in Figure 3.
We now present the label-hopping scheme.
2.2 LABEL-HOPPING TECHNIQUE
In this section, we describe the label-hopping technique and discuss
some implementation aspects. Once a data packet destined to the PEne
arrives at the PEfa (a) a first-label is chosen using set K and set
TS. and a first-label selected. Next (b) a selected number of bytes
from the payload is chosen as input to the hashing algorithm. The
hash-digest obtained as a result is used to obtain the additional
label for the packet. The agreed bit-selection pattern is then
applied on the hash-digest to obtain an additional label, which is
then concatenated with the first label. Once PEne receives these
packets it verifies both the labels.
The implementation steps for the control-plane at the PEne and PEfa
are given by Algorithms 1 and 2. The implementation steps for the
data-plane at the PEfa and PEne are given by Algorithms 3 and 4.
2.2.1 Algorithm 1 Control-plane PEne algorithm
Require:
* FEC[] Forward Equivalence Classes,
* K[] valid labels,
* TS[] valid time slices,
* A[i] hash algorithm instance,
* I[] the bit-selection pattern chosen for the inner label.
* PTP port and PTP LSP information
Begin
packet = makepacket(FEC,K, TS, A[i], I);
CP-SendPacket(PEfa, MP-eBGP, packet);
End
Note: The values in K need not be contiguous and can be randomly
Shankar Raman et.al Expires September 2012 [Page 7]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
chosen from a pool of labels to remove coherence in the label space.
Also the algorithms used could be either vendor dependent or a set of
standard algorithms mapped the same way by the PEne and PEfa. If the
two PEs involved are from different vendors we assume that a set of
standard algorithms are used.
Note: Also the values in set TS should be of a coarse granularity of
seconds recommended to be higher than 2 seconds.
_______[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 IP-VPNV4 session --------------+ |
| |
172.18.10.0/24 172.18.20.0/24
NH: PE_ne
<(FEC[] Forward Equivalence Classes), (K[] valid labels),
(TS[] valid time slices), (A[i] hash algorithm instance),
(I[] the bit-selection pattern chosen for the inner label),
(PTP port and PTP LSP information)>.
Exchange all details as per Algorithm 1.
Figure 1: Control-plane exchanges for model C [11]
<------- Label Stack ------>
+----------+---------+---------+---------+--------+---------+
| Frame L2 | Label 1 | Label 2 | Label 3 | L3 | Payload |
| Header | | | | Header | |
+----------+---------+---------+---------+--------+---------+
S = 0 S = 0 S = 1
Figure 2: Label stack using scheme outlined for Model "C"
Shankar Raman et.al Expires September 2012 [Page 8]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
_______[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
Figure 3: Data-plane flow for model C [11]
2.2.2 Algorithm 2 Control-plane PEfa algorithm
Require: None
Begin
packet = CP-ReceivePacket(PEne); // from PEne
FEC[] = ExtractFEC(packet); // extract FECs
K[] = ExtractLabels(packet); // extract the labels
TS[] = ExtractTimeSlices(packet); // extract the time slices
selectHashAlgorithm(A[i]); // hash algorithm to use
RecordValues(FEC); // information for PEfa
RecordValues(K);
RecordValues(TS);
RecordValues(I); // bit-selection pattern to be used
End
Shankar Raman et.al Expires September 2012 [Page 9]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
2.2.3 Algorithm 3 Data-plane PEfa algorithm
Require: None
Begin
Initialization :
One Time Init :
BeginInit
CurrentTimeSliceIndex = 0;
CurrentMasterClock = PTP LSP Master Clock Timestamp;
CurrentTimeInstant = CurrentMasterClock;
NextTimeInstant = CurrentMasterClock + TS[CurrentTimeSliceIndex];
EndInit
packet = DP-ReceivePacket(Interface);
match = CheckFEC(packet); // Is the algorithm enabled?
if match == 0 then
return; // no match
end if
hash-digest = calculateHash(A[i],packet);
if (CurrentTimeInstant <= NextTimeInstant ((+ or -) configured
seconds)) then
// do nothing;
else
CurrentTimeSliceIndex++;
if CurrentTimeSliceIndex == n then // check to wrap around
CurrentTimeSliceIndex = 0;
end if
CurrentTimeInstant = NextTimeInstant;
NextTimeInstant = CurrentTimeInstant + TS[CurrentTimeSliceIndex];
end if
first-label = K[CurrentTimeSliceIndex];
end if
additional-label = process(hash-digest,I)
DP-SendPacket(PEne, first-label, additional-label, packet);
End
Shankar Raman et.al Expires September 2012 [Page 10]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
2.2.4 Algorithm 4 Data-plane PEne algorithm
Require: None
Initialization :
One Time Init :
BeginInit
CurrentTimeSliceIndex = 0;
CurrentMasterClock = PTP LSP Clock Timestamp;
CurrentTimeInstant = CurrentMasterClock;
NextTimeInstant = CurrentMasterClock + TS[CurrentTimeSliceIndex];
EndInit
Begin
packet = DP-ReceivePacket(Interface);
match = CheckFEC(packet);
if match == 0 then
return; //no match
end if
label-in-packet=extractPacket(packet, LABEL);
inner-label=extractPacket(packet, INNER-LABEL);
hash-digest=calculateHash(A[i],packet);
if (CurrentTimeInstant <= NextTimeInstant ((+ or -) configured
seconds)) then
// do nothing;
else
CurrentTimeSliceIndex++;
if CurrentTimeSliceIndex == n then // check to wrap around
CurrentTimeSliceIndex = 0;
end if
CurrentTimeInstant = NextTimeInstant;
NextTimeInstant = CurrentTimeInstant + TS[CurrentTimeSliceIndex];
end if
first-label-range = K[CurrentTimeSliceIndex (+or- 1)];
additional-label = process(hash-digest,I)
if label-in-packet ! in first-label-range then
error(); return;
end if
if inner-label != additional-label then
error(); return;
end if
DP-SendPacket(CE1, NULL, NULL, packet);
End
Here configured seconds could be a fraction as well.
In order to avoid too many processing cycles in the line cards of
Shankar Raman et.al Expires September 2012 [Page 11]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
PEne and PEfa, the hash- digest is calculated over a predefined size
of the payload. An additional inner label is further added to enhance
protection against spoofing attacks. With an increased label size, an
attacker spends more than polynomial time to guess the VPN instance
label for the site behind PEne. There could be two hash-digests that
generate the same label. In this case, the two hash-digests is
differentiated using the additional label. Collisions can be avoided
by re-hashing or any other suitable techniques that are proposed in
the literature [8]. If collisions exceed a certain number, then
Algorithms 1 and 2 can be executed with a set of new labels.
2.2.1 Illustration
We now briefly illustrate the label-hopping scheme. In Figure 1,
using Algorithms 1 and 2, a set of labels are forwarded from PEne to
PEfa. The roles of PEne and PEfa are interchanged for reverse
traffic. Figure 2 shows a packet from the data-plane for model "C",
with the proposed scheme. In the figure, "Label 1" refers to the
outermost label, while "Label 2" refers to the label generated from
the set K and set TS and "Label 3" refers to an additional label
generated as in Algorithm 3. This additional label has bottom of
stack bit (denoted by S in Figure 2) set. These labels are stacked
immediately onto the packet and the path labels for routing the
packets to appropriate intermediary PEs are added. Figure 3 also
shows these path labels used by the data packet to reach PEne. When
the packet passes through the core of an intermediary AS involved in
model "C", or through the network connecting the intermediary AS, the
intruder or the attacker has the capability to inspect the labels and
the payload. However, the proposed scheme prevents the attacker from
guessing the right combination of the labels. We can increase the
size of the additional inner-labels thereby reducing threats from
polynomial time attacks.
2.3 SIMULATION AND IMPLEMENTATION
In this section, we present the preliminary simulation results on
performance, comparing the label-hopping technique with deep packet
inspection where we encrypt and decrypt the complete packet. We also
briefly highlight some implementation issues.
2.3.1 Simulation
Implementing the label-hopping scheme for all set of FECs belonging
to any or all VPN service instances may cause throughput degradation.
This is because the hashdigest computation and derivation of the
inner-label / additional inner label calculation can be computation
intensive. We therefore compared our technique by choosing a part of
the payload as input to our hashing algorithm. We simulated our
Shankar Raman et.al Expires September 2012 [Page 12]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
algorithm on a 2.5 GHz processor Intel dual processor quad core
machine. We compared the performance of the label-hopping technique
with a deep packet inspection technique where the complete packet was
encrypted before transmission and decrypted on reception. These
simulation figures indicate that we were able to process 10 million
packets per second when we used 64-byte for hashing on a payload of
size 1024 bytes. For a hash using 128-byte, we were able to process
about 6.3 million packets per second. However with a deep packet
inspection where we encrypted and decrypted the complete packet, we
were able to process only about 1 million packets per second. In
cases where performance becomes a bottleneck, this label-hopping
scheme can be applied to specific traffic which are mission-critical,
sensitive and most likely need to be protected as they travel from
the PEfa to the PEne. Selective application of this service which
could be offered as a premium for a selected set of FECs is a
suitable option, there by protecting the traffic of organizations
that are paranoid about the integrity of the switched traffic into
their VPN sites.
2.3.2 Implementation
We are modifying the open source Quagga router software on Linux to
implement our scheme. One of the concerns in the scheme is the use of
payload for generating the random inner label / additonal label. If
the payload does not vary between two packets then the control-plane
exchanges have to be renegotiated with a different algorithm to be
used for the hashing for the subsequent packets. The other concern in
the scheme is to tackle the problem of fragmentation that can occur
along the path from PEfa to PEne. We can fragment the packet at PEfa
and ensure that the size of the packet is fixed before transmission.
We could also employ the Path Maximum Transfer Unit (Path-MTU)
discovery process so that packets do not get split into multiple
fragments. If packets are fragmented this scheme fails. However,
networks usually employ the Path-MTU discovery process to prevent
fragmentation and hence this problem may not occur.
2.4 CONCLUSION AND FUTURE WORK
In this paper, we proposed a label-hopping scheme for inter-provider
BGP-based MPLS VPNs that employ MPe-BGP multi-hop control-plane
exchanges. In such an environment, without label-hopping, the data-
plane is subject to spoofing attacks.
The technique proposed uses a time-based label hopping scheme in
addition to the use of the payload to generate an inner label to
prevent attackers from easily deciphering labels and their respective
VPNs. The scheme is less computationally intensive than encryption-
based methods. It prevents the spoofed packets from getting into a
Shankar Raman et.al Expires September 2012 [Page 13]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
VPN site even if the attacker is in the core or at an intervening
link between ISPs. In our scheme, we chose the time instant that the
packet leaves the first Provider Edge on the far end and this time
instant serves as the variable component that the attacker cannot
decipher. This requires the use of time synchronization mechanism.
This is provided by the PTP LSP constructed for this purpose.
2.5 ACKNOWLEDGEMENTS
The authors would like to acknowledge the UK EP-SRC Digital Economy
Programme and the Government of India Department of Science and
Technology (DST) for funding given to the IU-ATC.
Shankar Raman et.al Expires September 2012 [Page 14]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
3 Security Considerations
The main objective of this proposal is to secure the Inter-Provider
MPLS VPN Model-C data plane by preventing spoofing attacks and other
unidirectional attacks against the customer site in this model. The
suggestions and algorithms provided will mitigate these attacks to a
large extent. The attacker will have many barriers to break through
before he/she can successfully mount an attack against the customer
site in this model with these algorithms implemented. The
availability of TicToc as a method of clocking helps a great deal in
this direction.
4 IANA Considerations
Appropriate IANA indicators would have to be provided to exchange the
set of values that Algorithm 1 outlines in order to implement this
scheme.
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:
Shankar Raman et.al Expires September 2012 [Page 15]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
10.1109/MIC.2005.61.
[4] L. Fang, N. Bita, J. L. Le Roux and J. Miles,
"Interprovider IP-MPLS services: requirements,
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]
[12] Davari.S et.al, Transporting PTP messages (1588) over
MPLS networks, "http://datatracker.ietf.org/doc/draft-
ietf-tictoc-1588overmpls/?include_text=1", Work in
Progress, October 2011.
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
Shankar Raman et.al Expires September 2012 [Page 16]
INTERNET DRAFT MPLS-VPNs using Label Hopping with TicToc March 2012
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.
Authors' Addresses
Shankar Raman
Department of Computer Science and Engineering
I.I.T Madras,
Chennai - 600036
TamilNadu,
India.
EMail: mjsraman@cse.iitm.ac.in
Balaji Venkat Venkataswami
Department of Electrical Engineering,
I.I.T Madras,
Chennai - 600036,
TamilNadu,
India.
EMail: balajivenkat299@gmail.com
Prof.Gaurav Raina
Department of Electrical Engineering,
I.I.T Madras,
Chennai - 600036,
TamilNadu,
India.
EMail: gaurav@ee.iitm.ac.in
Shankar Raman et.al Expires September 2012 [Page 17]