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

Robert Raszuk <robert@raszuk.net> Wed, 17 October 2012 04:47 UTC

Return-Path: <rraszuk@gmail.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 515F221F8600; Tue, 16 Oct 2012 21:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level:
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 lUnLGpBqWmij; Tue, 16 Oct 2012 21:47:29 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB321F8562; Tue, 16 Oct 2012 21:47:29 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so12747957iec.31 for <multiple recipients>; Tue, 16 Oct 2012 21:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c8rIstKeMLmEBHmayDsLF800TFZQjStRTaEcm5Lth0k=; b=MOw4GwEPJ74N8ioGp0/HszCqkgCL1TumR0R+762ygTMbzJpWzYLwfvnb027xfw7jkH MdbzkyaK4zUKHPdHLduCbJvZJqTZpn2juRfse1mV068pLkaeiZUThm+LTFTLC+WJhex/ miQch2iq5S2gkkrXU/dT0SUDh/PImSS9IcwE94D+OWiPqQj2GHVaIRNzj7+4mJXvsDD0 yF1inc3SKfbB82OZS7P7NIRX6vHoqTLbq/CWWzN4/fulMeifG8s4Ey5cgHC1Li8CBnLe q+21zrtA4pk/TQE7Z0+dpixiZ6jh/xGDfwnwGU9SZmTJdWoajaUrm7c5nlII+zFHJETl SJjw==
MIME-Version: 1.0
Received: by 10.42.109.194 with SMTP id m2mr13300322icp.48.1350449248933; Tue, 16 Oct 2012 21:47:28 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.42.68.133 with HTTP; Tue, 16 Oct 2012 21:47:28 -0700 (PDT)
In-Reply-To: <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> <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com>
Date: Wed, 17 Oct 2012 06:47:28 +0200
X-Google-Sender-Auth: XxbdGgdqOlSLZQUWh3J1Z_nF4-M
Message-ID: <CA+b+ERm5cY0kk6HTUt2xLUbishPqcu=pO==O9rw=_B-GBY9efg@mail.gmail.com>
Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt
From: Robert Raszuk <robert@raszuk.net>
To: "Pranav Mehta (pmehta)" <pmehta@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: L3VPN <l3vpn@ietf.org>, idr wg <idr@ietf.org>, "luay.jalil@verizon.com" <luay.jalil@verizon.com>, Randy Bush <randy@psg.com>
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: Wed, 17 Oct 2012 04:47:30 -0000

Hey Pranav,

Do you really believe that each 7-11 or Walmart store will be
subscribing to global RPKI or building their own key infrastructure? I
do not. It seems few orders of magnitude easier to sign advertisements
at the src/spoke and validate signature at the hub site by the same
very network admin residing in the enterprise hub location. That is
something we should define in BGP for VPNs and not trying to reuse
origin validation concept which works well (for what it is designed to
do) in the Internet case.

Btw ,,, I do not buy any "trusted" ASBR business ;)

Best,
R.

On Tue, Oct 16, 2012 at 11:02 PM, Pranav Mehta (pmehta)
<pmehta@cisco.com> wrote:
> 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