Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

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

Dear Robert,

Comments inlineŠ.

On 08/07/12 4:32 PM, "Robert Raszuk" <[e-mail]> wrote:

>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.

<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.

>
>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 ?

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.

>
>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.

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
>
>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.
>
>
>
>
>