Re: L2vpn Digest, Vol 98, Issue 6

["Rogers, Josh" <[e-mail]>]

I would propose tabling this draft, and attempting to create a document
outlining 1) how best to establish option C peering with other SP's, and
2) outstanding caveats/exposures that are not addressed with available
technology/standards.

Having such a document would better frame any subsequent 'solution' drafts
that address concerns not currently addressable with good policy/practice.

-josh


On 7/9/12 9:35 AM, "UTTARO, JAMES" <[e-mail]> wrote:

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


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.