Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)
Randy Bush <randy@psg.com> Mon, 02 January 2017 13:45 UTC
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCD129463; Mon, 2 Jan 2017 05:45:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmTlSqaHbSBs; Mon, 2 Jan 2017 05:45:26 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E26124281; Mon, 2 Jan 2017 05:45:26 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cO2vP-0007Gf-Td; Mon, 02 Jan 2017 13:45:20 +0000
Date: Mon, 02 Jan 2017 22:45:16 +0900
Message-ID: <m2vatxmv83.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com>
References: <148336377615.21819.15119186800162780376.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/rcxnbXK1r4JsB8PtDd-Up21De-U>
Cc: draft-ietf-sidr-bgpsec-ops@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, The IESG <iesg@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jan 2017 13:45:28 -0000
> Quick question: I'm by far not an expert here, but I remember that > there used to be some concerns that it is practical not possible to > disable BGPsec once enabled. If that's (still) true, should this be > mentioned here? i am not sure what you mean, so let me guess. an established bgp session has negotiated simplex or duplex bgpsec via bgp capability exchange. one can not change the agreement without tearing down and restarting the session. a router which is bgpsec enabled, receives a signed path from the left, but on the right it had a non-sec session, strips the bgpsec info from the path. these are discussed in the bgpsec protocol document. section 6, appended to save dumster diving, shows some of the operational uses of this. do you have suggestions for other examples worth enumerating? randy 6. Considerations for Edge Sites An edge site which does not provide transit and trusts its upstream(s) SHOULD only originate a signed prefix announcement and need not validate received announcements. An Operator might need to use hardware with limited resources. In such cases, BGPsec protocol capability negotiation allows for a resource constrained edge router to hold only its own signing key(s) and sign its announcements, but not receive signed announcements. Therefore, the router would not have to deal with the majority of the RPKI, potentially saving the need for additional hardware. As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and less expensive incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec.
- [sidr] Mirja Kühlewind's No Objection on draft-ie… Mirja Kuehlewind
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Randy Bush
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Randy Bush
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Chris Morrow
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Randy Bush
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Peter Hessler
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Chris Morrow
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Alvaro Retana (aretana)
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Sriram, Kotikalapudi (Fed)
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Sriram, Kotikalapudi (Fed)
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Randy Bush
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Randy Bush
- Re: [sidr] Mirja Kühlewind's No Objection on draf… Christopher Morrow