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

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

Dear Robert,

Comments inline

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

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

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.

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

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.

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

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

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