Re: L2vpn Digest, Vol 98, Issue 6

[balaji venkat Venkataswami <[e-mail]>]

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, "[e-mail]" <[e-mail]>
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
>	[e-mail]
>
>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
>	[e-mail]
>
>You can reach the person managing the list at
>	[e-mail]
>
>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 <[e-mail]>
>To: "[e-mail]" <[e-mail]>
>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
>Message-ID: <[e-mail]>
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/l2vpn
>
>
>End of L2vpn Digest, Vol 98, Issue 6
>************************************