Subject: Re: L2vpn Digest, Vol 98, Issue 6

From: balaji venkat Venkataswami <[email-masked]>
Date: Sun, 08 Jul 2012 10:56:07 +0530

Dear Robert,

This scheme is primarily to protect against attacks from within a network
That intervenes the two providers that are participating in inter-provider
Model C.
While it is agreed that if the ISP itself sends packets then the whole
situation
Cannot be recovered from, we intend to use this scheme in places where the
Intervening network between the two providers is compromised. Also if one
or more
Routers of the ISP have been compromised within the ISP's network then an
intruder
Trying to gain access to the VPN traffic would have a hard time guessing
which
Traffic belongs to which VPN with our scheme. We have added more data on
why
We think Model C has a bad protection with respect to its data plane.

By increasing the label space to 40 bits the scheme we propose increases
Guessing the right labels for the right VPNs to non-polynomial time.

Also the following recommendation is usually advised for Model C.

Never connect ASBRs over a shared Layer 2 infrastructure such as an
Internet Exchange Point (IXP). Use a private connection, or at least a
private VLAN.

With our scheme this can be relaxed to a degree is what we feel.

More on Data Plane insecurity in Model C :
==========================================

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

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. 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
with a VPN label for VPN B, the packet will be forwarded into VPN B. At
the time of writing this draft there was no solution to 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.

Thanks and regards,
Balaji and shankar

On 08/07/12 12:30 AM, "[email-masked]" <[email-masked]>
wrote:

>If you have received this digest without all the individual message
>attachments you will need to update your digest options in your list
>subscription.  To do so, go to
>
>https://www.ietf.org/mailman/listinfo/l2vpn
>
>Click the 'Unsubscribe or edit options' button, log in, and set "Get
>MIME or Plain Text Digests?" to MIME.  You can set this option
>globally for all the list digests you receive at this point.
>
>
>
>Send L2vpn mailing list submissions to
>	[email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/l2vpn
>or, via email, send a message with subject or body 'help' to
>	[email-masked]
>
>You can reach the person managing the list at
>	[email-masked]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of L2vpn digest..."
>
>
>Today's Topics:
>
>   1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
>      (Robert Raszuk)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 07 Jul 2012 14:39:56 +0200
>From: Robert Raszuk <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt.
>
>It proposed an interesting solution to apply algorithmically computed
>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as
>option C is used.
>
>However I have a fundamental question .. from who the draft is
>protecting the inter-as service ?
>
>Who other then participating ISPs can spoof a value of VPN label ? If
>the solution is protecting from ISPs itself then I think it does not
>help at all as corresponding ISPs/SPs still have full access to their
>PEs and could inject packets to VPN sites at will.
>
>Moreover main issue with option C is not security (at least for the last
>10+ years). Main issue with option C and MPLS is that participating
>providers need to inject into each other's network all of their
>participating PE's /32 addresses so the end to end MPLS LSP can be
>build. Originally that was recommended to be done by mutual
>redistribution to the IGP .. now the general recommendation is to use
>labeled BGP (both IBGP and EBGP).
>
>So fundamental question to the authors ... who is the potential
>attacker/spoofer this draft is aiming to protect from ?
>
>Best regards,
>R.
>
>
>
>
>
>------------------------------
>
>_______________________________________________
>L2vpn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/l2vpn
>
>
>End of L2vpn Digest, Vol 98, Issue 6
>************************************

---

From: balaji venkat Venkataswami <[email-masked]>
Date: Sun, 08 Jul 2012 12:16:58 +0530

Dear Robert,

As mentioned in the earlier mail the following restriction is imposed on
the
Model C deploymentŠ

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.

In order to stretch this scheme to other Ases under different admin
control this scheme helps out.

Thanks and regards,
Balaji venkat

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 08 Jul 2012 13:02:00 +0200

Hi Balaji,

> Also if one or more Routers of the ISP have been compromised
> within the ISP's network then an intruder Trying to gain
 > access to the VPN traffic would have a hard time guessing
> which Traffic belongs to which VPN with our scheme.

You are effectively saying that if intruder compromises any router in 
the ISP or between ISPs it is quite likely that it may get access to VPN 
label information which are pretty static today. That is actually true 
for L3VPN and L2VPN. It is the same in basic non inter-as service as 
well as with inter-as service option A, B & C.

I do not see why in particular you are just focused on option C ?

Do you have this case in mind:

ISP1 -- ISP2 -- ISP3 where ISP2 is just an MPLS transit sitting with a 
sniffer and observing VPN labels in the data plane ?

I do agree that any LxVPN using BGP does not protect from this type of 
attacks. It is in fact well understood since the early days of MPLS-VPN 
deployments that sites which require security place hardware encryption 
devices between or next to their CEs.

In other words if your ISP network is so unsecure that it would allow to 
inject third party an MPLS encapsulated packets (not your trusted ISP 
option B or option C peer, but one of your customers or hackers) then I 
think all bet's are off as far as your services go.

That is also why for CSC one of the first feature which was added was 
label validation. CE can not inject any other label then the label 
already advertised to it. Some implementations do it also for option B.

While I like your solution in general I think it still needs to find a 
problem. For the problem presented IMHO ISP is much better to protect 
his PEs and his infrastructure rather then trying to make a VPN label a 
bit harder to guess.

Best,
R.

---

From: balaji venkat Venkataswami <[email-masked]>
Date: Sun, 08 Jul 2012 17:09:41 +0530

Dear Robert,

Comments inlineŠ.

>well as with inter-as service option A, B & C.

<balaji> We have another draft posted to the L3VPN group with regard
To Option C to protect against spoofing attacks and specifically
man-in-the-middle
Attacks for Option C in L3-VPNs. It is quite basic that all inter-AS
service
Options may suffer from this problem but at least A and B options have a
Capability to validate the inner label. Option C in the case of Inter-AS
doesn't. That's why we focussed on Option C. Some of the references we
Have quoted in the draft are testament to that. In the case of a
non-inter-AS
Case the service provider at least has control over the entire domain and
doesn't have an intervening network like the inter-AS cases.

>sniffer and observing VPN labels in the data plane ?

This is another case where our scheme can be used to protect the traffic
>From being eavesdropped or attacked from the middle ISP or the intervening
Networks between the ISPs.

>think all bet's are off as far as your services go.

Our draft never covers the case where the label injected packets are
injected
>From the CE. It covers the case where the trusted or not so trusted ISP
peer
Has been not so diligent as the first provider and allows compromise of
either
A PE router or a P router or the intervening network between the providers.
Attacks can range from spoofing attacks, unidirectional attacks causing
worms
To get in, or even DOS attacks that keep the router busy dropping these
errant
Packets. Our scheme takes care of the same. We do not bring into account or
Consider the case where the label injection is happening from the Ces if
hackers
Are behind such a CE.

To stress again Model C is relatively very easy to break if a
man-in-the-middle
Attack is undertaken as the Pes between the providers do not validate the
label
Hence the need for a solution here.

Thanks and regards,
Balaji venkat

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 08 Jul 2012 19:57:14 +0200

> We do not bring into account or
> hackers are behind such a CE.

If the hacker is not behind the CE where is it ?

Are you saying that peering ISP itself will attack his partner's ISP 
VPNs ? It can still do it at will if the PE which attaches the VPN sites 
are compromised.

Are you saying that your VPN label would not be see by any cli and show 
commands of the end to end participating PEs ? Then this is non starter 
IMHO.

r.

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 10:15:41 +0530

Dear Robert,

We talking about the ASBRs between the two or more ISP networks.

Consider the situation that the network / networks between the ASBRs is
compromised or the ASBR itself is compromised then this scheme would apply.

In the case of Model-C the ASBR bordering the ISP networks does not
validate the inner label as it would in the case of Option A and B.

(PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core
network 2)----(PE)

The above simple case shows that in the Model C the ASBR would not validate
the inner label and hence it is susceptible to spoofing attacks/
unidirectional attacks etc...

This is the situation that we are guarding against.

Hope this helps.

thanks and regards,
balaji venkat

On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <[email-masked]> wrote:

> Are you saying that peering ISP itself will attack his partner's ISP VPNs
> ? It can still do it at will if the PE which attaches the VPN sites are
> compromised.
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 9 Jul 2012 09:14:20 +0300

Hi Balaji,

A few clarification questions - I think it would be good to clarify these issues in the draft:
1.	Since the label hopping mechanism relies on PTP, I understand that PTP traffic itself does not use label hopping, right?
2.	Is there something preventing the attacker from attacking PTP, thus causing DoS to the data plane?
3.	Is the "additional label" similar to an Integrity Check Value (ICV) computed over part of the packet header? 
4.	Is there something in your approach that would prevent an attacker from a replay attack?
5.	Looking at "Algorithm 3" I was not sure: does the receiver check two consequent time slots? I could not see such a check. I am referring to a case where the sender transmits at the end of a time slot, and the packet is received at the beginning of the next time slot. That would mean the receiver has to be able to tolerate two concurrent time slots, right?
6.	The security parameters K, TS, A, I are exchanged over a secure link, which basically assumes there is a pre-shared key between the peer PEs. A naive question would be: how is your approach better than just using a standard ICV, based on the existing pre-shared key?

Tal.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Jul 2012 10:59:46 +0200

Balaji,

Many thx for clearly describing your target.

I am of the opinion that your scheme does not protect from compromised 
ASBR as once hacker has control of the ASBR he can instantiate any vrf 
locally and inject data from the ASBR itself into any VPN using your 
scheme.

For the link between ASBR yes you have a valid point. But note that over 
this link both ISPs exchange their precious infrastructure routes 
(addresses and labels to reach PEs) which if compromised can cause much 
more harm then injecting some packets into a VPN.

Therefor for the case of ASBR to ASBR link being compromized I would 
much more see local link level security (ex: encryption) for both data 
and control planes rather then change of the VPN label allocation scheme 
in both L3VPN networks.

Your scheme just makes the guess harder not that it eliminates the 
attacks. From the point of view of compromised inter-as link an attacker 
can sweep the VPN label range and still find the matching ones for some 
duration of time.

Also I have a different question ...

In each ISP there are 100s of PEs participating in given VPN and perhaps 
very few ASBRs with option C.

Each PE iBGP peers with RR and advertised the VPN label. RR is 
advertising this label to other PEs in a given ISP domain as well as 
over eBGP multihop other RRs in other option C domian.

Are you envisioning in your scheme direct BGP sessions between all 
participating in option C PEs ? Are you envisioning PTP full mesh 
between all PEs in all domains ? How PE if he has today a single IBGP 
session to vpnv4 RR is going to differentiate between VPN labels he want 
to advertise locally within his domain (as today) and those which would 
be used for Inter-AS option C ?

Thx,
R.

> The above simple case shows that in the Model C the ASBR would not
> validate the inner label and hence it is susceptible to spoofing
> attacks/ unidirectional attacks etc...
>
> On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     VPNs ? It can still do it at will if the PE which attaches the VPN
>     sites are compromised.
>
>     Are you saying that your VPN label would not be see by any cli and
>     show commands of the end to end participating PEs ? Then this is non
>     starter IMHO.
>
>     r.
>
>

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 15:51:59 +0530

Dear Robert,

Comments inline

On Mon, Jul 9, 2012 at 2:29 PM, Robert Raszuk <[email-masked]> wrote:

> locally and inject data from the ASBR itself into any VPN using your scheme.
>

I am of the opinion that an ASBR if it does not have peering relationships
with CEs would not have the feature for label-hopping enabled on it and
would have merely peering labels with PE loopback for the other ASBR. In
that case the ASBR cannot use the label hopping feature to inject packets
to the other ASBR into any VPN using the scheme.

> more harm then injecting some packets into a VPN.

At least the VPN that employs this scheme will not be affected though it
could harm the provider on the side to which such packets are injected.

>
> Therefor for the case of ASBR to ASBR link being compromized I would much
> more see local link level security (ex: encryption) for both data and
> control planes rather then change of the VPN label allocation scheme in
> both L3VPN networks.
>

Agreed. But if such a thing happens then the scheme would protect the VPN
deploying it to a higher level than it can be done right now with static
labels.

Guessing the right time to use the right label and distinguishing the right
VPN to attack would take a lot more time and effort if the scheme described
in the draft is deployed.

> can sweep the VPN label range and still find the matching ones for some
Sweeping the VPN label range with the Time varying label + the innermost
label which is a hash digest on the labelled packet would be much harder
since two factors have to be gotten right (a) The right label at the right
time for the right VPN and (b) the inner label digest on the payload. So it
would be pretty hard to break this scheme in the required time.

> Each PE iBGP peers with RR and advertised the VPN label. RR is advertising
> this label to other PEs in a given ISP domain as well as over eBGP multihop
> other RRs in other option C domian.
>
> participating in option C PEs ? Are you envisioning PTP full mesh between
> all PEs in all domains ? How PE if he has today a single IBGP session to
> vpnv4 RR is going to differentiate between VPN labels he want to advertise
> locally within his domain (as today) and those which would be used for
> Inter-AS option C ?
>
>
This scheme could be deployed selectively only for those that require
greater security. All VPN traffic need not be subjected to this scheme. So
you wouldnt need a full PTP mesh between all PEs in all domains. By the
fact that there are more than one labels and a time scheme to use them it
would be possible for the RR and PE to decipher that this is a
label-hopping scheme based on Tic-Toc (of course the Tic-Toc schedule also
would be provided to discriminate this specifically as a Tic-Toc scheme)
for option-C. If this were a distinguishing factor implied it would be
possible to deploy this scheme for option-C alone. Or a suitable community
attribute could specify this.

Hope this helps in explaining to your questions.

Your inputs would be most useful.

thanks and regards,
balaji and team

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 9 Jul 2012 11:34:15 +0000

Balaji,

                I understand that the VPN Label that has been assigned is opaque at the ASBRs in Option C or C-.. I still do not understand who is actually doing the attacking.. Can you describe the use case? How would the ASBR link be attacked and by whom..

Thanks,
                Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Balaji venkat Venkataswami
Sent: Monday, July 09, 2012 12:46 AM
To: [email-masked]
Cc: [email-masked]; Shankar Raman M J; Bhargav Bhikkaji
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Robert,

Consider the situation that the network / networks between the ASBRs is compromised or the ASBR itself is compromised then this scheme would apply.

In the case of Model-C the ASBR bordering the ISP networks does not validate the inner label as it would in the case of Option A and B.

(PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core network 2)----(PE)

The above simple case shows that in the Model C the ASBR would not validate the inner label and hence it is susceptible to spoofing attacks/ unidirectional attacks etc...

Hope this helps.

thanks and regards,
balaji venkat
On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Are you saying that peering ISP itself will attack his partner's ISP VPNs ? It can still do it at will if the PE which attaches the VPN sites are compromised.

Are you saying that your VPN label would not be see by any cli and show commands of the end to end participating PEs ? Then this is non starter IMHO.

r.

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 17:29:54 +0530

Dear James,

Consider the following situation.

Consider two or more providers connecting to each other at an IXP through a
high-end L2 switch that provides connectivity between providers. If the
switch is tapped through either mirroring or through other means, the inner
label can be easily deciphered by the tapper.

Consider another situation where the ASBR of one provider is compromised
and an interested eavesdropper is trying to look into the packets of a
specific VPN (say the defence department or ministry of interior) traffic
which is seeking services from the given  ISPs in the inter-AS setup.

In both these conditions the ASBR to ASBR link may be compromised if there
was not a dedicated link connecting the two providers. If more than two
providers are involved then the situation becomes more susceptible to
spoofing, eavesdropping or unidirectional attacks (DoS, worm etc...).

In such a case our scheme would help since it would confuse the tapper into
thinking that static labels are involved and hence only a subset of packets
of a flow which is using this scheme would be susceptible to such attacks.
By changing the label (inner VPN label) over time it is possible to confuse
the attacker and hence not give him the capability to eavesdrop, attack,
spoof the specific VPN he thinks he is attacking. It would take more time
and complexity for an algorithm to decipher this scheme, specifically the
labels, the time instances where such labels are valid and the inner digest
label that is payload dependent.

Hope this helps.

thanks and regards,
balaji venkat and team

On Mon, Jul 9, 2012 at 5:04 PM, UTTARO, JAMES <[email-masked]> wrote:

>  Balaji,****
>
> ** **
>
>                 I understand that the VPN Label that has been assigned is
> opaque at the ASBRs in Option C or C-.. I still do not understand who is
> actually doing the attacking.. Can you describe the use case? How would the
> ASBR link be attacked and by whom..****
>
> ** **
>
> Thanks,****
>
>                 Jim Uttaro****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Balaji venkat Venkataswami
> *Sent:* Monday, July 09, 2012 12:46 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; Shankar Raman M J; Bhargav Bhikkaji
> *Subject:* Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...****
>
> ** **
>
> Dear Robert,****
>
> ** **
>
> We talking about the ASBRs between the two or more ISP networks.****
>
> ** **
>
> ****
> ** **
> validate the inner label as it would in the case of Option A and B.****
>
> ** **
>
> network 2)----(PE)****
> ** **
> validate the inner label and hence it is susceptible to spoofing attacks/
> unidirectional attacks etc...****
>
> ** **
>
> This is the situation that we are guarding against.****
>
> ** **
>
> Hope this helps.****
>
> ** **
>
> thanks and regards,****
>
> balaji venkat****
>
> On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <[email-masked]> wrote:*
> ***
>
> ** **
>
> Consider the case where the label injection is happening from the Ces if**
> **
>
> hackers are behind such a CE.****
>
>
> r.****
> ** **

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Jul 2012 15:18:57 +0200

Hi Balaji,

> I am of the opinion that an ASBR if it does not have peering
> relationships with CEs would not have the feature for label-hopping
> enabled on it

And based number of projects I have seen ASBR pretty much always is also 
acting as PE and have customers attached. ASBRs are just too expensive 
to place them in the network with just two interfaces hanging there.

> Agreed. But if such a thing happens then the scheme would protect the
> VPN deploying it to a higher level than it can be done right now with
> static labels.

Do you see any value of your proposal if one could do IPSec between PEs 
in hardware with any rate which is required by inter-AS option C 
customers ?

Yes you compare this in the draft using one x86 generic compute 
platform. But if we assume that PEs used are capable of IPSec would you 
still deploy your scheme ?

Note that there is another significant advantage of using IPSec between 
option C PEs .. it runs over IP. So no need to build hierarchy of MPLS 
labels for transport nor exchange all of those /32s loopbacks between 
any domains for constructing transport level LSP.

Thx,
R.

---

From: "Rogers, Josh" <[email-masked]>
Date: Mon, 9 Jul 2012 10:21:34 -0400

While I don't necessarily agree with this draft's approach ("security
through obscurity" comes to mind), I'd like to point out that I do see a
need to assuage concerns about using Option C between operators.  In my
part of the world, when I propose Option C to other operators, often the
idea is met with concern/resistance, seemingly because the other operator
has not done it before.  Even internally, many of my colleagues are
concerned about security and the trust model in general.  It appears to
me, to be no different than any other IP peering relationship, which
requires some basic 'trust', albeit not implicit trust.

I think Robert's suggestion of leveraging encryption is a more ironclad
and reasonable solution to the problems presented here.  However, I'd
still like to see an informative 'best practices' document at some point
that covered some basic policies that should be followed when peering with
another ISP for LxVPN exchange.

-Josh

>>   1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 9 Jul 2012 14:35:31 +0000

Josh,

	Yes quite leery of building an Option C solution to other providers for a number of reasons including trust, security but also others i.e RT Mapping, Scale, Protected Infrastructure available to others, IGP Scale ( # of LBs ), Pri/Back Selection of ASBR, attack on the PEs, etc... Actually the more sophisticated the Option C solution the more alignment and possible risk. 

I understand the ask that this draft is attempting to meet, but does it make sense to do this without addressing the other facets of building an Option C solution between different ISPs..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rogers, Josh
Sent: Monday, July 09, 2012 10:22 AM
To: balaji venkat Venkataswami; [email-masked]; [email-masked]
Cc: Shankar Raman M J; Bhargav Bhikkaji
Subject: Re: L2vpn Digest, Vol 98, Issue 6

-Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Mon, 9 Jul 2012 10:40:03 -0400

I would propose tabling this draft, and attempting to create a document
outlining 1) how best to establish option C peering with other SP's, and
2) outstanding caveats/exposures that are not addressed with available
technology/standards.

Having such a document would better frame any subsequent 'solution' drafts
that address concerns not currently addressable with good policy/practice.

-josh

On 7/9/12 9:35 AM, "UTTARO, JAMES" <[email-masked]> wrote:

>Josh,
>
>       Yes quite leery of building an Option C solution to other providers for
>a number of reasons including trust, security but also others i.e RT
>Mapping, Scale, Protected Infrastructure available to others, IGP Scale (
># of LBs ), Pri/Back Selection of ASBR, attack on the PEs, etc...
>Actually the more sophisticated the Option C solution the more alignment
>and possible risk.
>
>I understand the ask that this draft is attempting to meet, but does it
>make sense to do this without addressing the other facets of building an
>Option C solution between different ISPs..
>
>Jim Uttaro
>
>
>
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 20:40:20 +0530

Dear Josh, Robert,

We had considered the option of IPsec. With respect to encrypting and
decrypting at data rates that high we saw issues with respect to
computation and power and time as well. While this may be ok for today's
network speeds the higher speeds that would be achieved in future would
effectively create the above complexity issues if it was done on the PE
router (ingress and egress). While the CE based encryption might work,
spoofing attacks and other unidirectional attacks may send garbled packets
which will be sought to be decrypted thereby DOSing any decryptor. This
would be counterproductive.

Also the inner label of a Option-C inter-AS MPLS VPN packet cannot be
encrypted. If found to belong to a specific VPN that is of interest to the
tapper/eavesdropper he can still take the traffic based on that label and
decrypt it later on.

The proposed scheme in the internet draft makes it difficult to even
identify which label belongs to which VPN. Even if identified for a label
amongst the set of labels, in order for the tapper to get all the traffic
he / she has to guess all the labels, their respective time slices and in
addition the innermost label which is digest whose algorithm has to be
again guessed. So the proposed scheme provides several lines of defence
against spoofing, unidirectional attacks and even eavesdropping.

thanks and regards,
balaji, shankar and bhargav

On Mon, Jul 9, 2012 at 7:51 PM, Rogers, Josh <[email-masked]>wrote:

> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 21:17:06 +0530

Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <[email-masked]> wrote:

> 1.      Since the label hopping mechanism relies on PTP, I understand that
> PTP traffic itself does not use label hopping, right?
>

The PTP traffic itself does not use label hopping.

> thus causing DoS to the data plane?

It would be difficult for the attacker to identify which LSP is the PTP LSP
for a specific VPN traffic (flow / set of flows) that is protected by this
scheme. There is no information except on the ingress and egress PEs that
identifies which is the PTP LSP for a particular VPN traffic protected by
this scheme.

3.      Is the "additional label" similar to an Integrity Check Value (ICV)
> computed over part of the packet header?
>

It serves as a digest from which certain specific bits are chosen to become
the innermost label. Which bits are chosen depends upon the bitmask
exchanged during the control plane.

> 4.      Is there something in your approach that would prevent an attacker

For a reply attack to succeed, the replay should time the labels correctly
otherwise the traffic gets rejected.

5.      Looking at "Algorithm 3" I was not sure: does the receiver check
> two consequent time slots? I could not see such a check. I am referring to
> a case where the sender transmits at the end of a time slot, and the packet
> is received at the beginning of the next time slot. That would mean the
> receiver has to be able to tolerate two concurrent time slots, right?
>

Yes. It is available as +or- 1 unit (usually seconds) in the algorithm.
Maybe a little more fine tuning is required on this.

> 6.      The security parameters K, TS, A, I are exchanged over a secure
> link, which basically assumes there is a pre-shared key between the peer
> PEs. A naive question would be: how is your approach better than just using
> a standard ICV, based on the existing pre-shared key?
>

While the ICV may protect against modification of the inner payload one
cannot prevent spoofing attacks if the algorithm for the ICV is deduced.
Our scheme provides facility to change the labels from time slice to time
slice so that guessing what packet belongs to which VPN traffic itself
becomes difficult. This is the first line of defense. If we provide ICV
alone we protect against modification but not with replay attacks. The
proposed scheme protects against VPN traffic identification (so replay
attacks cannot be made) and modification as well through the ICV which is
the innermost label.

thanks and regards,
balaji , shankar and bhargav

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Jul 2012 17:47:23 +0200

Hi Balaji,

> spoofing attacks and other unidirectional attacks may send garbled
> packets which will be sought to be decrypted thereby DOSing any
> decryptor. This would be counterproductive.

The ASBR - ASBR local link encryption does not suffer from any of the 
above.

> encrypted. If found to belong to a specific VPN that is of interest to
> the tapper/eavesdropper he can still take the traffic based on that
> label and decrypt it later on.
>
> identify which label belongs to which VPN. Even if identified for a
> label amongst the set of labels, in order for the tapper to get all the
> traffic he / she has to guess all the labels, their respective time
> slices and in addition the innermost label which is digest whose
> algorithm has to be again guessed. So the proposed scheme provides
> several lines of defence against spoofing, unidirectional attacks and
> even eavesdropping.

In the same time the proposed scheme makes the troubleshooting 
impossible. How ISPs would decode that for some option C VPNs their 
customer packets go via ASBR to ASBR link or not ?

Same for billing. To the best of my knowledge ISPs charge differently 
for the portion of inter-as service. There is need to provide on a per 
VPN stats from ASBR router. How in this scheme per VPN granularity of 
traffic statistics will be accomplished for billing purposes ? That's 
actually one of the key reasons for option B popularity today.

Thx,
R.

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 9 Jul 2012 21:30:29 +0530

Dear Robert,

Comments inline

> The ASBR - ASBR local link encryption does not suffer from any of the

If specific set of VPNs alone are to be subject to the scheme then the ASBR
which encrypts on the local link between ASBR and ASBR will not know which
VPN inner label whose traffic is to be subjected to encryption. Otherwise
it would have to encrypt all traffic since it finds that some of the VPNs
are subject to this scheme. This would be an overkill.

> In the same time the proposed scheme makes the troubleshooting impossible.
> How ISPs would decode that for some option C VPNs their customer packets go
> via ASBR to ASBR link or not ?
>

Could you please explain a bit more on this. We assume that all Option-C
traffic has to go through ASBR to ASBR link.

>
> Same for billing. To the best of my knowledge ISPs charge differently for
> the portion of inter-as service. There is need to provide on a per VPN
> stats from ASBR router. How in this scheme per VPN granularity of traffic
> statistics will be accomplished for billing purposes ? That's actually one
> of the key reasons for option B popularity today.
>
>
The billing can be done as follows. Collect the traffic statistics for all
VPN labels as if they were separate VPN labels each for a specific VPN. At
the egress PE collate statistics coming towards it based on a set of labels
instead of a single label in the regular case. Collate this data with the
ASBR statistics (identifying the egress PE by the outer label) and do the
billing.

Hope this helps.

thanks and regards,
balaji venkat

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Jul 2012 18:14:07 +0200

> If specific set of VPNs alone are to be subject to the scheme

I don't think this is for specific VPNs. It would be applicable for all 
VPNs using option C on a given link between pair of peering ASBRs.

> encryption. Otherwise it would have to encrypt all traffic since it
> finds that some of the VPNs are subject to this scheme. This would be an
> overkill.

I do not think so. If there is any risk that my link is insecure between 
trusted parties it seems wise to make it secure for all control plane 
and data plane traffic which traverses such link.

> traffic has to go through ASBR to ASBR link.

So do I.

Let's assume customer X reports that he can not ping his remote sites.

Today NOC does:

- Logs into PE and see what VPN label his remote PE peer advertised
- Enabled filter on the ASBR and issues a vrf ping on the PE or CE
- Has ability to see or not his customer packets

With your scheme such filtering becomes impossible. So does the 
troubleshooting.

>     Same for billing. To the best of my knowledge ISPs charge
>     differently for the portion of inter-as service. There is need to
>     provide on a per VPN stats from ASBR router. How in this scheme per
>     VPN granularity of traffic statistics will be accomplished for
>     billing purposes ? That's actually one of the key reasons for option
>     B popularity today.
>
>
> The billing can be done as follows. Collect the traffic statistics for
> all VPN labels as if they were separate VPN labels each for a specific
> VPN. At the egress PE collate statistics coming towards it based on a
> set of labels instead of a single label in the regular case. Collate
> this data with the ASBR statistics (identifying the egress PE by the
> outer label) and do the billing.

If there are many PEs and their labels restart that is a lot of 
additional complexity and data correlation as compared with today.

Many thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 9 Jul 2012 10:45:35 -0700

Dear Balaji,
you've said " There is no information except on the ingress and egress PEs
that identifies which is the PTP LSP for a particular VPN traffic protected
by this scheme."
AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP
updates. Would that compromise your method?

Regards,
Greg

On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkataswami <
[email-masked]> wrote:

>> 1.      Since the label hopping mechanism relies on PTP, I understand
>> that PTP traffic itself does not use label hopping, right?
>>
>
> It would be difficult for the attacker to identify which LSP is the PTP
> LSP for a specific VPN traffic (flow / set of flows) that is protected by
> this scheme. There is no information except on the ingress and egress PEs
> that identifies which is the PTP LSP for a particular VPN traffic protected
> by this scheme.
>
> 3.      Is the "additional label" similar to an Integrity Check Value
>> (ICV) computed over part of the packet header?
>>
>
> It serves as a digest from which certain specific bits are chosen to
> become the innermost label. Which bits are chosen depends upon the bitmask

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 9 Jul 2012 17:56:51 +0000

+1

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 10:40 AM
To: UTTARO, JAMES; balaji venkat Venkataswami; [email-masked]; [email-masked]
Cc: Shankar Raman M J; Bhargav Bhikkaji
Subject: Re: L2vpn Digest, Vol 98, Issue 6

-josh

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 9 Jul 2012 22:06:29 +0300

Hi Balaji,

Thanks for the prompt and detailed response.
Please see inline.

Regards,
Tal.

From: Balaji venkat Venkataswami [mailto:[email-masked]]
Sent: Monday, July 09, 2012 6:47 PM
To: Tal Mizrahi
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Tal,

Comments inline
On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Balaji,

It would be difficult for the attacker to identify which LSP is the PTP LSP for a specific VPN traffic (flow / set of flows) that is protected by this scheme. There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffic protected by this scheme.

It serves as a digest from which certain specific bits are chosen to become the innermost label. Which bits are chosen depends upon the bitmask exchanged during the control plane.
[TM] Right. Unless I am missing something, that sounds like a variant of an ICV: it basically produces a label which is a function(packet payload, pre-shared secret). That is essentially what an ICV does, unless I am missing something?

For a reply attack to succeed, the replay should time the labels correctly otherwise the traffic gets rejected.
[TM] Right, so assuming the attacker is "fast enough", the attacker can replay during the time slice (which is ~seconds)?

Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. Maybe a little more fine tuning is required on this.

While the ICV may protect against modification of the inner payload one cannot prevent spoofing attacks if the algorithm for the ICV is deduced. Our scheme provides facility to change the labels from time slice to time slice so that guessing what packet belongs to which VPN traffic itself becomes difficult. This is the first line of defense. If we provide ICV alone we protect against modification but not with replay attacks. The proposed scheme protects against VPN traffic identification (so replay attacks cannot be made) and modification as well through the ICV which is the innermost label.
[TM] Since an ICV uses a pre-shared key, even if the algorithm is well-known to the attacker, the attacker cannot forge/spoof it, assuming that the attacker is not exposed to the key. ICV mechanisms typically support anti replay, e.g., the IPsec AH.

thanks and regards,

Tal.

---

From: Bhargav Bhikkaji <[email-masked]>
Date: Mon, 9 Jul 2012 15:45:04 -0700

Dear Greg,

As per the PTP over MPLS draft, all intervening LSRs need not be 1588-aware.

If we use the EF-PHB with green as drop probability all P routers need not know about the PTP LSP. This has been stated in the PTP over MPLS draft.

Even if we were to use the 1588 aware LSRs the actual binding between a PTP LSP and the VPN which is protected by it is known only to the ingress and egress PE and not anywhere else. The PTP LSP would have to be tied into the labels only at the ingress and egress PE and this binding / tying up is known only to them. Hence even if the PTP LSP timing is elicited the time slices when the labels have to be used is known only to the ingress  and egress PEs.

Thanks

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, July 09, 2012 10:46 AM
To: Balaji venkat Venkataswami
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Balaji,
you've said " There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffic protected by this scheme."
AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP updates. Would that compromise your method?

Regards,
Greg
On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkataswami <[email-masked]<mailto:[email-masked]>> wrote:
Dear Tal,

Comments inline

thanks and regards,

Tal.

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 9 Jul 2012 19:09:45 -0400

Dear Bhargav,
thank you for your expedient reply to my question.
Yes, technically, PTP LSP can run through LSRs that are not 1588-aware. But that is very unlikely IMHO.
Then I need to note that the http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02 had expired last April.

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhargav Bhikkaji
Sent: Monday, July 09, 2012 3:45 PM
To: Greg Mirsky; Balaji venkat Venkataswami
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Greg,

Thanks

Dear Balaji,

Regards,
Greg

Comments inline

thanks and regards,

Tal.

---

From: Bhargav Bhikkaji <[email-masked]>
Date: Mon, 9 Jul 2012 19:59:12 -0700

Hi Tal,

Thanks for your comments. Pls see inline [BB] for response

-Bhargav

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, July 09, 2012 12:06 PM
To: Balaji venkat Venkataswami
Cc: [email-masked]; Shankar Raman M J; [email-masked]; [email-masked]
Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Hi Balaji,

Regards,
Tal.

Dear Tal,

Comments inline

[BB]: Agreed, the scheme we proposed is a of ICV scheme.

[BB]: We had submitted a draft where certain bits of IPSec digital signature is used as "additional label". This would help to identify forged/spoofed packet.

http://tools.ietf.org/html/draft-bhargav-l3vpn-inter-provider-optcsec-01

thanks and regards,

Tal.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jul 2012 09:07:35 +0100

> If we use the EF-PHB with green as drop probability all P routers need 
> not know about the PTP LSP. This has been stated in the PTP over MPLS 
> draft.
>
Given that forwarders are work conserving, a packet that has already 
started will go to completion, so a high priority  packet arriving after 
the transmit decision has been taken by the forwarder waits. The now 
devalued timing packet goes ahead of all other packets, some of which 
are less devalued by the delay. I am worried that giving timing packet 
priority degrades the network without achieving anything for the timing 
system.

Do we have any measured evidence that sending timing packets with a high 
priority is actually beneficial? If so can someone please point me at it.

Thanks

Stewart