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.