RE: [Idr] draft-ymbk-l3vpn-origination-00.txt

"Pranav Mehta (pmehta)" <pmehta@cisco.com> Tue, 16 October 2012 21:02 UTC

Return-Path: <pmehta@cisco.com>
X-Original-To: l3vpn@ietfa.amsl.com
Delivered-To: l3vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC8D11E80E4; Tue, 16 Oct 2012 14:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKlBy67HfR7w; Tue, 16 Oct 2012 14:02:48 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 523EE11E80D5; Tue, 16 Oct 2012 14:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2387; q=dns/txt; s=iport; t=1350421368; x=1351630968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ryye2F9C8QFkHRangV/lS+04uSveCmDrXGWnkmpionY=; b=It3LNcX+0jBOy0frQcgyIkDKz9Y6QpQ4mpEnc2u8ssRsBbRQB5p0+tG+ 4RQWEbXUYutQHa3UvrD4k0gYPVDZoLE7QrCmvmlaK6wtEb3RiXl6mh45I hgbN1KeGgpGKTOKHrCsZH81nT0353tzko3pQcy59qgb/7L66Lkgf+Hic0 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALjKfVCtJV2Z/2dsb2JhbABFwA2BCIIgAQEBAwESASc/BQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIGodQAwkFAZsAj1yQRYpoZ4VdYAOkMoFrgm2BXCMY
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="132326985"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2012 21:02:48 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9GL2lQ1001898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 21:02:47 GMT
Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 16:02:47 -0500
From: "Pranav Mehta (pmehta)" <pmehta@cisco.com>
To: Randy Bush <randy@psg.com>, Robert Raszuk <robert@raszuk.net>
Subject: RE: [Idr] draft-ymbk-l3vpn-origination-00.txt
Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt
Thread-Index: AQHNqwAew0fd+6zQc0WX8IHgfJLNm5e7mp+AgAADjgCAAAYMgIAAAbKAgAC9qHA=
Date: Tue, 16 Oct 2012 21:02:46 +0000
Message-ID: <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com>
References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> <m2391flias.wl%randy@psg.com> <CA+b+ERk7dzBFLFN7BGEEg7aj0ymoh50GKbMB6CGxCXWqaCCuUg@mail.gmail.com> <m2y5j7gk1r.wl%randy@psg.com> <CA+b+ERkjmXv3pT7Jw_BbZ_f3hWy5rX6meW3sXGBnpmTu_FVwWA@mail.gmail.com> <m2obk3girk.wl%randy@psg.com>
In-Reply-To: <m2obk3girk.wl%randy@psg.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.71.138.228]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004
x-tm-as-result: No--34.879000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 18 Oct 2012 00:21:08 -0700
Cc: L3VPN <l3vpn@ietf.org>, "luay.jalil@verizon.com" <luay.jalil@verizon.com>, idr wg <idr@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Oct 2012 21:02:49 -0000

Robert,

As Randy already mentioned, Draft already covers an alternate approach where originating CE would sign the announcement and it will come all the way to destination CE to authenticate.  

Alternately this mechanism can also help in Inter-AS scenario.  In Inter-AS scenario, originating CE can sign the announcement and a "trusted" ASBR on the Inter-AS boundary can authenticate the announcement if customer trusts one of the two ISPs.    In such scenario, ISP may use the Key identifier to find the Key associated with the VPN and send unsigned NLRI in its own network once it is authenticated at ASBR boundary.

- Pranav

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com] 
Sent: Monday, October 15, 2012 9:10 PM
To: Robert Raszuk
Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asreekan); luay.jalil@verizon.com; idr wg; L3VPN
Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt

> I was not that much fishing here ... just trying to understand if you 
> are validating CE-CE or PE-PE. If the latter I unfortunately think 
> there is much less of the value.
> 
> When we originally started to roll out 2547 there was very clear 
> consensus that real protection must happen on the CE-CE boundary.
> Trusting SP where anyone who logs into PE can do anything for any VPN 
> there was never taken serious.
> 
> Note that the draft could also allow both, but this needs to be 
> clearly stated in the text.

it tries to make that pretty clear

   This document describes how the originating PE, West, may sign the
   announcement so that the destination PE, East, may authenticate the
   NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364]
   Section 4.3.1.  Alternatively, the originating CE router may sign the
   announcement so that the destination CE router may authenticate the
   NLRI.

>> if they want to use the rpki, then, just as other rpki publishers 
>> using 1918 space, they would have local trust anchors and certify the 
>> private space.  see draft-ietf-sidr-ltamgmt.
> 
> And what happens in the event of PE-PE validation where only one SP of 
> L3VPN subscribes to RPKI business ?

then they should not use rpki keying but rather their own key infrastructure using the Key Identifier to index their KI

randy