RE: L2vpn Digest, Vol 98, Issue 6
"UTTARO, JAMES" <ju1738@att.com> Mon, 09 July 2012 17:56 UTC
Return-Path: <ju1738@att.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F1D11E81A9 for <l2vpn@ietfa.amsl.com>; Mon, 9 Jul 2012 10:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.319
X-Spam-Level:
X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBlcCJjXf3H2 for <l2vpn@ietfa.amsl.com>; Mon, 9 Jul 2012 10:56:45 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA011E8162 for <l2vpn@ietf.org>; Mon, 9 Jul 2012 10:56:45 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 67b1bff4.2aaafbe52940.1227980.00-510.3293136.nbfkord-smmo07.seg.att.com (envelope-from <ju1738@att.com>); Mon, 09 Jul 2012 17:57:10 +0000 (UTC)
X-MXL-Hash: 4ffb1b760ac9215d-58eb564dffee94f209dd2eb694252bfca908b83e
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 27b1bff4.0.1227961.00-399.3293076.nbfkord-smmo07.seg.att.com (envelope-from <ju1738@att.com>); Mon, 09 Jul 2012 17:57:07 +0000 (UTC)
X-MXL-Hash: 4ffb1b731a65550f-933fbefef1bac8114181e5e8cc54ccdc5394e9ef
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69Hv6VD009713; Mon, 9 Jul 2012 13:57:06 -0400
Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69Hv3a0009698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 13:57:03 -0400
Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 9 Jul 2012 13:56:52 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 13:56:51 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: "'Rogers, Josh'" <josh.rogers@twcable.com>, balaji venkat Venkataswami <balajivenkat299@gmail.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>, "robert@raszuk.net" <robert@raszuk.net>
Subject: RE: L2vpn Digest, Vol 98, Issue 6
Thread-Topic: L2vpn Digest, Vol 98, Issue 6
Thread-Index: Ac1d3iOdVst3wH8vN0uvsrGUCI9bogAAKKdgAAjeloAAAYQN8A==
Date: Mon, 09 Jul 2012 17:56:51 +0000
Message-ID: <B17A6910EEDD1F45980687268941550FB32B38@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <B17A6910EEDD1F45980687268941550FB32995@MISOUT7MSGUSR9I.ITServices.sbc.com> <CC2056D0.9463%josh.rogers@twcable.com>
In-Reply-To: <CC2056D0.9463%josh.rogers@twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.155.252]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <ju1738@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=gE9O8Arr410A:10 a=9xHMEmg6Re4A:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=-CRmgG0JhlAA:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=ahv8dbORAAAA:8 a=48vgC7mUAAAA:8 a=2clOPd4P]
X-AnalysisOut: [AAAA:8 a=zQP7CpKOAAAA:8 a=pGLkceISAAAA:8 a=bu-4PJRAI4fuBXv]
X-AnalysisOut: [7cYIA:9 a=jiObf9B0YAUA:10 a=BDsChg1p1CEA:10 a=lZB815dzVvQA]
X-AnalysisOut: [:10 a=bDUki_mJ7DgA:10 a=Hz7IrDYlS0cA:10 a=MSl-tDqOz04A:10 ]
X-AnalysisOut: [a=UIcTdWks-MRqePm4:21 a=UXk42QkqMWjFuIZr:21]
Cc: Shankar Raman M J <mjsraman@gmail.com>, Bhargav Bhikkaji <bharbhi@gmail.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 17:56:47 -0000
+1 -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, July 09, 2012 10:40 AM To: UTTARO, JAMES; balaji venkat Venkataswami; l2vpn@ietf.org; robert@raszuk.net Cc: Shankar Raman M J; Bhargav Bhikkaji Subject: Re: L2vpn Digest, Vol 98, Issue 6 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" <ju1738@att.com> 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: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Monday, July 09, 2012 10:22 AM >To: balaji venkat Venkataswami; l2vpn@ietf.org; robert@raszuk.net >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" ><balajivenkat299@gmail.com> 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, "l2vpn-request@ietf.org" <l2vpn-request@ietf.org> >>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 >>> l2vpn@ietf.org >>> >>>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 >>> l2vpn-request@ietf.org >>> >>>You can reach the person managing the list at >>> l2vpn-owner@ietf.org >>> >>>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 <robert@raszuk.net> >>>To: "l2vpn@ietf.org" <l2vpn@ietf.org> >>>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>>Message-ID: <4FF82E1C.6000009@raszuk.net> >>>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 >>>L2vpn@ietf.org >>>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.
- Re: L2vpn Digest, Vol 98, Issue 6 balaji venkat Venkataswami
- Re: L2vpn Digest, Vol 98, Issue 6 balaji venkat Venkataswami
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Robert Raszuk
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… balaji venkat Venkataswami
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Robert Raszuk
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Balaji venkat Venkataswami
- RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Tal Mizrahi
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Robert Raszuk
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Balaji venkat Venkataswami
- RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… UTTARO, JAMES
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Balaji venkat Venkataswami
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Robert Raszuk
- Re: L2vpn Digest, Vol 98, Issue 6 Rogers, Josh
- RE: L2vpn Digest, Vol 98, Issue 6 UTTARO, JAMES
- Re: L2vpn Digest, Vol 98, Issue 6 Rogers, Josh
- Re: L2vpn Digest, Vol 98, Issue 6 Balaji venkat Venkataswami
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Balaji venkat Venkataswami
- Re: L2vpn Digest, Vol 98, Issue 6 Robert Raszuk
- Re: L2vpn Digest, Vol 98, Issue 6 Balaji venkat Venkataswami
- Re: L2vpn Digest, Vol 98, Issue 6 Robert Raszuk
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Greg Mirsky
- RE: L2vpn Digest, Vol 98, Issue 6 UTTARO, JAMES
- RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Tal Mizrahi
- RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Bhargav Bhikkaji
- RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Gregory Mirsky
- RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Bhargav Bhikkaji
- Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00… Stewart Bryant