RE: L2vpn Digest, Vol 98, Issue 6

["UTTARO, JAMES" <[e-mail]>]

Josh,

	Yes quite leery of building an Option C solution to other providers for a number of reasons including trust, security but also others i.e RT Mapping, Scale, Protected Infrastructure available to others, IGP Scale ( # of LBs ), Pri/Back Selection of ASBR, attack on the PEs, etc... Actually the more sophisticated the Option C solution the more alignment and possible risk. 

I understand the ask that this draft is attempting to meet, but does it make sense to do this without addressing the other facets of building an Option C solution between different ISPs..

Jim Uttaro




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Rogers, Josh
Sent: Monday, July 09, 2012 10:22 AM
To: balaji venkat Venkataswami; [e-mail]; [e-mail]
Cc: Shankar Raman M J; Bhargav Bhikkaji
Subject: Re: L2vpn Digest, Vol 98, Issue 6

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.