Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

Randy Bush <randy@psg.com> Tue, 10 January 2017 05:43 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 11FA3129F47 for <sidr@ietfa.amsl.com>; Mon, 9 Jan 2017 21:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 Jbdv3GW55GHK for <sidr@ietfa.amsl.com>; Mon, 9 Jan 2017 21:43:41 -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 462AF1294CA for <sidr@ietf.org>; Mon, 9 Jan 2017 21:43:41 -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 1cQpDc-0005mH-Mr; Tue, 10 Jan 2017 05:43:36 +0000
Date: Tue, 10 Jan 2017 14:43:34 +0900
Message-ID: <m2inpncvw9.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <10822F92-5B04-41FD-9D19-5866D7EEACAE@psg.com>
References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <B659D894-672F-4059-A001-5C4D1D602470@vigilsec.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> <D492BBD6.6F422%dougm@nist.gov> <f306df7c-06a0-0662-93f4-5cb984a8eb0e@cs.tcd.ie> <D492D3B6.6F4BE%dougm@nist.gov> <f1c2f28f-c889-ee6d-e670-e8f977492946@cs.tcd.ie> <DM2PR09MB04468F57A38A20A58A33982584640@DM2PR09MB0446.namprd09.prod.outlook.com> <a092caaa-4c6d-e7c1-be3a-dd13c33fac10@cs.tcd.ie> <m24m18e1ph.wl-randy@psg.com> <6e8e235e-0d51-19ab-2651-c1ef1a05ea73@cs.tcd.ie> <m2vatnd96h.wl-randy@psg.com> <m2k2a3d5zd.wl-randy@psg.com> <10822F92-5B04-41FD-9D19-5866D7EEACAE@psg.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/GJDClHtCbNFrDfwLOBQY3T_Ag5M>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and 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: Tue, 10 Jan 2017 05:43:43 -0000

i had to do some ascii porn for rob to deal with a secdir reviewer for
draft-ietf-sidr-publication.  it may help here.  i added the routers for
this discussion.

       +------+    +------+    +------+
       |  CA  |    |  CA  |    |  CA  |
       +------+    +------+    +------+
           |           |           |      Publication Protocol
           |           |           |   draft-ietf-sidr-publication
           +-------+   |  +--------+ Business Relationship Set Up by
                   |   |  |          draft-ietf-sidr-rpki-oob-setup
              +----v---v--v-----+
              |                 |
              |   Publication   |
              |   Repository    |
              |                 |
              +-----------------+     Distribution Protocols
                       |           draft-ietf-sidr-delta-protocol
        +--------------+----------------+  and/or rcynic
        |              |                |
+-------v-----+ +------v------+  +------v------+
|   Relying   | |   Relying   |  |   Relying   |
|    Party    | |    Party    |  |    Party    |
+-+-----+----++ +---+-----+---+  +-+--------+--+
  |     |    |      |     |        |  |     |
  |     |    ++     |     |     +--+  |     |  RPKI to Router Protocol (RFC 6810)
  |     |     |     |     |     |     |     | draft-ietf-sidr-rpki-rtr-rfc6810-bis
  v     v     v     v     v     v     v     v
 / \   / \   / \   / \   / \   / \   / \   / \
|Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr|
 \ /   \ /   \ /   \ /   \ /   \ /   \ /   \ /
  V     V     V     V     V     V     V     V


we're talking about 6810-bis here, the rpki-rtr protocol which carries
the router keys and origin roas for bgpsec and origin validation.

it is a total database push from the RP cache to the router, not a
piecemeal router driven request protocol.  so a monkey in the middle
receives no clues as to what the router is using.  there is no side
channel leakage that i can see.  i would be happy to be educated
otherwise.

as 6810[-bis] has stripped the crypto of the rpki validataion chain to
the root TA, it no longer has object security; red alert.  so the two
ops drafts, 7115 for origin validation and draft-ietf-sidr-bgpsec-ops
for bgpsec, try to be very explicit about transport protection for these
data.

draft-ietf-sidr-bgpsec-ops points to rfc 7115 for RP cache advice.

  As RPKI-based origin validation relies on the availability of RPKI
  data, operators SHOULD locate RPKI caches close to routers that
  require these data and services in order to minimize the impact of
  likely failures in local routing, intermediate devices, long
  circuits, etc.  One should also consider trust boundaries, routing
  bootstrap reachability, etc.

  For example, a router should bootstrap from a cache that is reachable
  with minimal reliance on other infrastructure such as DNS or routing
  protocols.  If a router needs its BGP and/or IGP to converge for the
  router to reach a cache, once a cache is reachable, the router will
  then have to reevaluate prefixes already learned via BGP.  Such
  configurations should be avoided if reasonably possible.

  If insecure transports are used between an operator's cache and their
  router(s), the Transport Security recommendations in [RFC6810] SHOULD
  be followed.  In particular, operators MUST NOT use insecure
  transports between their routers and RPKI caches located in other
  Autonomous Systems.

so maybe the bgpsec-protocol document can remove, as opposed to add,
text just this once?

randy