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

[Robert Raszuk <[e-mail]>]

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.

> 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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>         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.
>
>
>     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.
>
>