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

[Robert Raszuk <[e-mail]>]

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.