[sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

Rob Austein <sra@hactrn.net> Thu, 06 March 2014 11:03 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9901A02BF for <sidr@ietfa.amsl.com>; Thu, 6 Mar 2014 03:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 HoG-sVGsXafJ for <sidr@ietfa.amsl.com>; Thu, 6 Mar 2014 03:03:22 -0800 (PST)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id E0CAE1A02BC for <sidr@ietf.org>; Thu, 6 Mar 2014 03:03:21 -0800 (PST)
Received: from minas-ithil.hactrn.net (dhcp-a117.meeting.ietf.org [31.133.161.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 079BB398A2 for <sidr@ietf.org>; Thu, 6 Mar 2014 11:03:18 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 2AF1BAFDF22 for <sidr@ietf.org>; Thu, 6 Mar 2014 11:03:17 +0000 (GMT)
Date: Thu, 06 Mar 2014 11:03:17 +0000
From: Rob Austein <sra@hactrn.net>
To: sidr@ietf.org
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140306110317.2AF1BAFDF22@minas-ithil.hactrn.net>
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Mrj98o9iUlkQ__Q_MhKPEEC5rNA
Subject: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 06 Mar 2014 11:03:23 -0000

I just posted draft-austein-sidr-rpki-rtr-rfc6810bis-00, which is
intended as an update to the RPKI-Router protocol (RFC 6810).  

An HTMLized rfcdiff against RFC 6810 is available at:

  http://subvert-ietf.hactrn.net/sidr-rpki-rtr-bis/draft-austein-sidr-rpki-rtr-rfc6810bis-00-from-rfc6810.diff.html

Summary of changes to date from RFC 6810:

1) New Router Certificate PDU, to support BGPSEC.  Those who remember
   the earlier (and now expired) draft-ymbk-rpki-rtr-keys may notice
   that the format of this PDU has changed slightly: per discussion at
   this week's face-to-face meeting in London, we need to support
   binding a single router key to multiple ASNs, so we changed the
   PDU format slightly to allow this.

2) We added a few timing parameters to the End Of Data PDU.  These,
   like the Serial Number mechanism, are lifted almost verbatim from
   the DNS zone transfer protocol.  We left them out of RFC 6810, but
   subsequent exploration of some of the corner cases of the RPKI
   Router protocol convinced us that leaving these timing parameters
   out of the protocol had been a mistake.

This draft bumps the protocol version number from 0 to 1.
Immediately after posting this I-D we received a gentle reminder that
we need to specify what a client and server are meant to do when they
support different versions of the protocol, so we'll say something
about that in the next revision.

We'd like to ask the WG to adopt this as a WG draft.  We hope this
will be a non-contentious request, as the WG is chartered to work on
BGPSEC and we're pretty sure that we need the Router Key PDU to
support this, but of course this is up to the chairs and the WG.