Re: L2vpn Digest, Vol 98, Issue 6

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

Dear Josh, Robert,

We had considered the option of IPsec. With respect to encrypting and
decrypting at data rates that high we saw issues with respect to
computation and power and time as well. While this may be ok for today's
network speeds the higher speeds that would be achieved in future would
effectively create the above complexity issues if it was done on the PE
router (ingress and egress). While the CE based encryption might work,
spoofing attacks and other unidirectional attacks may send garbled packets
which will be sought to be decrypted thereby DOSing any decryptor. This
would be counterproductive.

Also the inner label of a Option-C inter-AS MPLS VPN packet cannot be
encrypted. If found to belong to a specific VPN that is of interest to the
tapper/eavesdropper he can still take the traffic based on that label and
decrypt it later on.

The proposed scheme in the internet draft makes it difficult to even
identify which label belongs to which VPN. Even if identified for a label
amongst the set of labels, in order for the tapper to get all the traffic
he / she has to guess all the labels, their respective time slices and in
addition the innermost label which is digest whose algorithm has to be
again guessed. So the proposed scheme provides several lines of defence
against spoofing, unidirectional attacks and even eavesdropping.

thanks and regards,
balaji, shankar and bhargav

On Mon, Jul 9, 2012 at 7:51 PM, Rogers, Josh <[e-mail]>wrote:

> While I don't necessarily agree with this draft's approach ("security
> through obscurity" comes to mind), I'd like to point out that I do see a
> need to assuage concerns about using Option C between operators.  In my
> part of the world, when I propose Option C to other operators, often the
> idea is met with concern/resistance, seemingly because the other operator
> has not done it before.  Even internally, many of my colleagues are
> concerned about security and the trust model in general.  It appears to
> me, to be no different than any other IP peering relationship, which
> requires some basic 'trust', albeit not implicit trust.
>
> I think Robert's suggestion of leveraging encryption is a more ironclad
> and reasonable solution to the problems presented here.  However, I'd
> still like to see an informative 'best practices' document at some point
> that covered some basic policies that should be followed when peering with
> another ISP for LxVPN exchange.
>
> -Josh
>
>
>
> On 7/8/12 1:46 AM, "balaji venkat Venkataswami"
> <[e-mail]> wrote:
>
> >Dear Robert,
> >
> >As mentioned in the earlier mail the following restriction is imposed on
> >the
> >Model C deploymentŠ
> >
> >The consequence of this is that in model C the service providers must
> >trust each other also in areas that are not shared. Therefore, model C is
> >most commonly used today where a single operator uses several ASs on the
> >backbone. In this case, implicit trust exists between the ASs because they
> >have the same operational control.
> >
> >
> >In order to stretch this scheme to other Ases under different admin
> >control this scheme helps out.
> >
> >Thanks and regards,
> >Balaji venkat
> >
> >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
> >>************************************
> >
> >
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>