Internet DRAFT - draft-mjsraman-l2vpn-vpls-tictoc-label-hop
draft-mjsraman-l2vpn-vpls-tictoc-label-hop
L2VPN Working Group Shankar Raman
Internet-Draft Balaji Venkat Venkataswami
Intended Status: Experimental RFC Gaurav Raina
Expires: October 10, 2013 IIT Madras
Bhargav Bhikkaji
Dell-Force10
April 8, 2013
Securing Model-C Inter-Provider L2 VPNs with Label Hopping and TicToc
draft-mjsraman-l2vpn-vpls-tictoc-label-hop-03
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" for VPLS, or any L2 VPN purpose 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-the-middle attacker can spoof packets to a specific L2 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 L2 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 hence calculating when it must have left that peer at the
Provider Edge Router in the near / receiving end.
This version of the document suggests a better method for gaining
more finely granular time slices. This is done by running the PTP LSP
between the ASBRs in the ASes that are providing the inter-AS L2VPN
service.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Shankar Raman et.al Expires October 10, 2013 [Page 1]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/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) 2013 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 L2 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 . . . . . . . . 8
2.2.2 Algorithm 2 Control-plane PEfa algorithm . . . . . . . . 10
2.2.3 Algorithm 3 Data-plane PEfa algorithm . . . . . . . . . 11
2.2.4 Algorithm 4 Data-plane PEne algorithm . . . . . . . . . 12
Shankar Raman et.al Expires October 10, 2013 [Page 2]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . 13
2.3 SIMULATION AND IMPLEMENTATION . . . . . . . . . . . . . . . 14
2.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Running the PTP LSP and label hopping at the ASBRs . . . 15
2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 16
2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 16
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 17
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Normative References . . . . . . . . . . . . . . . . . . . 17
5.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Shankar Raman et.al Expires October 10, 2013 [Page 3]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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 2 Virtual Private Networks
(L2-VPNs) such as VPLS (Virtual Private Lan Service) based on Border
Gateway Protocol (BGP) extensions are widely deployed in the
Internet. BGP-based MPLS L2-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 L2-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 L2 VPN routes from
Autonomous Systems (AS) to neighbouring AS. Model "C" uses multi-hop
MP-eBGP redistribution of labelled L2 VPN routes and eBGP
redistribution of L2 VPN 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) L2 VPN routes, the vulnerability of the data-plane
renders it unusable. The current recommendation is that model "C"
must not be used. 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 PE, and the VPN label, which
defines the VPN associated with the packet on the PE.
Shankar Raman et.al Expires October 10, 2013 [Page 4]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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 L2 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 L2 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 L2 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 L2 VPN model "C"
The reference MPLS-eBGP based L2 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 L2 VPN, MP-eBGP updates are
exchanged for a set of MAC based Forward Equivalence Classes (FECs).
These FECs, which have to be protected, originate from the MAC
addresses / FECs behind PEne in a L2 VPN site or a set of L2 VPN
Shankar Raman et.al Expires October 10, 2013 [Page 5]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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. In addition to these
data sets a random seed is also exchanged. This Random Seed which we
will henceforth as Rseed is used to generate the label for the next
time slot.
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
Shankar Raman et.al Expires October 10, 2013 [Page 6]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
label is valid at that time instant as will be seen in the Algorithms
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 L2 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 the random seed Rseed, 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.
Shankar Raman et.al Expires October 10, 2013 [Page 7]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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.
* Random seed "Rseed" which is used for generating the index into set
K (set of labels).
* PTP port and PTP LSP information
Begin
packet = makepacket(FEC,K, TS, A[i], I, Rseed);
CP-SendPacket(PEfa, MP-eBGP, packet);
End
Note: The values in K need not be contiguous and can be randomly
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.
Shankar Raman et.al Expires October 10, 2013 [Page 8]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
_______[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 L2-VPN 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),
(Rseed - A random seed to generate the next label to be used in set
K),
(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 | L2/+L3 | Payload |
| Header | | | | Header | |
+----------+---------+---------+---------+--------+---------+
S = 0 S = 0 S = 1
Figure 2: Label stack using scheme outlined for Model "C"
_______[AB1]________________ ___________[AB2]___________
( / | ) ( / )
( / +-----------+ ) ( / )
(IL1:SL:L2 FRAME L1:IL1:SL:L2 FRAME / )
( | L3:IL1:SL:L2 FRAME <-+ L4:IL1:SL:L2 FRAME )
( | | ) ( | | )
( | | ) ( | | )
[CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2]
| |
L2 VPN Site (1) L2:IL1:SL:172.18.10.1 L2 VPN Site (2)
Figure 3: Data-plane flow for model C [11]
Shankar Raman et.al Expires October 10, 2013 [Page 9]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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
Rseed = ExtractRandomSeed(packet); // extract the Rseed value.
selectHashAlgorithm(A[i]); // hash algorithm to use
RecordValues(FEC); // information for PEfa
RecordValues(K);
RecordValues(TS);
RecordValues(I); // bit-selection pattern to be used
RecordValue(Rseed);
End
Shankar Raman et.al Expires October 10, 2013 [Page 10]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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[GenerateRandom(Rseed) MOD n(K)];
end if
additional-label = process(hash-digest,I)
DP-SendPacket(PEne, first-label, additional-label, packet);
End
Shankar Raman et.al Expires October 10, 2013 [Page 11]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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++;
// Save the old RseedIndex into set K
OldRseedIndex = RseedIndex;
RseedIndex = (GenerateRandom(Rseed) MOD n(K));
NextRseedIndex =
LookAheadRseedIndex(GenerateRandom(Rseed) MOD n(K));
RollbackRseed(Rseed by 1);
if CurrentTimeSliceIndex == n then // check to wrap around
CurrentTimeSliceIndex = 0;
end if
CurrentTimeInstant = NextTimeInstant;
NextTimeInstant = CurrentTimeInstant + TS[CurrentTimeSliceIndex];
end if
// Check if label used before in the previous | current or future
// time slot can be used
// Check with OldRseedIndex, RseedIndex and NextRseedIndex
first-label-range = K[RseedIndex (+or- 1)];
additional-label = process(hash-digest,I)
if label-in-packet ! in first-label-range then
error(); return;
end if
Shankar Raman et.al Expires October 10, 2013 [Page 12]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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
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.
Note :
It is to be noted that the change in the algorithm to randomly pick
up a label for the next time slot will help in avoiding man-in-the-
middle attackers from synchronizing with the time slots and the
labels which in the previous version of the algorithm was predictable
if a large number of packets were observed. The Random seed agreed
upon will generate in lock step with the time slots at both the PEfa
and PEna, the correct label to be used and that will throw off the
attacker from synchronizing with such label changes. Thus even replay
attacks may be harder to attempt in such a case.
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
Shankar Raman et.al Expires October 10, 2013 [Page 13]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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
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
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
Shankar Raman et.al Expires October 10, 2013 [Page 14]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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.3.3 Running the PTP LSP and label hopping at the ASBRs
The ASes participating in the inter-AS L2VPN Option-C type service
connect with each other using ASBRs that connect one AS to another.
It would be prudent to run the PTP LSP and the label-hopping
algorithm between the ASBRs instead of between the PEs. Since these
ASBRs are usually one-hop away from each other or in the worst case a
couple of hops away, the granularity of the time slices can be a lot
more finer than when running between the PEs. At more granular time
slices it will be even harder for an attacker to pump in packets that
utilize the slack of + or - microseconds or milliseconds configured
in Algorithm 4.
Hence spoofing and replay attacks are less likely to succeed.
To make it clear the innermost label which is the hash digest
computed on the first 128 or 64 byte portion of the payload which is
binary anded with an arbitrary bit pattern known to both PEs in the
topology , serves as an added binary pattern which has to be guessed
by the intruder intending to spoof the packet into the VPN's PE onto
the CE.
Thus the effective label space that has to be guessed by the intruder
is the label for that time slice and the binary pattern computed on
the payload (result of the hash-digest ANDed with the arbitrary bit
pattern).
This makes it essentially a 40 bit label space. The hash-digest was
not intended to be a ICV. It could serve as an ICV as well.
Since the binary pattern exchanged through the control plane is not
known to the intruder, and the hash algorithm used is not known to
the intruder (unless of course both of them are compromised in the
control plane exchange which is of course secure) the resulting
innermost label extends the label space to 40 bits (including the
label for that time slice) that has to be guessed.
As to whether there might be a flood of replay packets with the + or
- 1 time slice being in place, the previous label used would be known
Shankar Raman et.al Expires October 10, 2013 [Page 15]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
but the one after the current time slice would be hard to guess owing
to the random number generation function being used to determine
which the next label should be. It should be possible to jam for that
time slice with the same packet with the 2 labels (previous and
current) for that time slice being repeated again and again. This is
solved by finely granularizing the time slices to microseconds or
milliseconds. This is especially the case if the scheme is run
between the ASBRs and not between the PEs.
2.4 CONCLUSION AND FUTURE WORK
In this paper, we proposed a label-hopping scheme for inter-provider
BGP-based MPLS L2 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
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. The authors would
also like to thank Chandrasekhar.R and Narayana Swamy for his review
and valuable comments during the writing of this draft.
Shankar Raman et.al Expires October 10, 2013 [Page 16]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
3 Security Considerations
The main objective of this proposal is to secure the Inter-Provider
MPLS L2 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
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,
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
Shankar Raman et.al Expires October 10, 2013 [Page 17]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
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.
Authors' Addresses
Shankar Raman
Department of Computer Science and Engineering
IIT Madras
Chennai - 600036
TamilNadu
India
Shankar Raman et.al Expires October 10, 2013 [Page 18]
INTERNET DRAFT L2 VPN using Label Hopping with TicToc April 8, 2013
EMail: mjsraman@cse.iitm.ac.in
Balaji Venkat Venkataswami
Department of Electrical Engineering
IIT Madras
Chennai - 600036
TamilNadu
India
EMail: balajivenkat299@gmail.com
Prof.Gaurav Raina
Department of Electrical Engineering
IIT Madras
Chennai - 600036
TamilNadu
India
EMail: gaurav@ee.iitm.ac.in
Bhargav Bhikkaji
Dell-Force10
350 Holger Way
San Jose, CA
USA
Email: Bhargav_Bhikkaji@dell.com
Shankar Raman et.al Expires October 10, 2013 [Page 19]
