Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT)

Rob Austein <sra@hactrn.net> Thu, 09 February 2017 21:38 UTC

Return-Path: <sra@hactrn.net>
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 DED9E129C9C; Thu, 9 Feb 2017 13:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 f5nXCwTKjW7i; Thu, 9 Feb 2017 13:38:45 -0800 (PST)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920BA1295C3; Thu, 9 Feb 2017 13:38:45 -0800 (PST)
Received: from minas-ithil.hactrn.net (dsl-207-183-187-238.freedom.wy.silverstar.com [207.183.187.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 300C7B868; Thu, 9 Feb 2017 21:38:45 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id C39584684B49; Thu, 9 Feb 2017 14:39:10 -0700 (MST)
Date: Thu, 09 Feb 2017 14:39:10 -0700
From: Rob Austein <sra@hactrn.net>
To: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <F95A3287-C1F6-4BE1-840F-683DDF045ECE@cooperw.in>
References: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com> <6549BAF8-95A7-42C6-A8E6-A80754DB2867@cisco.com> <F95A3287-C1F6-4BE1-840F-683DDF045ECE@cooperw.in>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-Id: <20170209213910.C39584684B49@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/r33phIQUcvXSKP-N8vwm9st6vkU>
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, IESG <iesg@ietf.org>, sidr@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org
Subject: Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (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: Thu, 09 Feb 2017 21:38:47 -0000

At Wed, 8 Feb 2017 10:03:32 -0500, Alissa Cooper wrote:
> > On Jan 19, 2017, at 9:34 AM, Alvaro Retana (aretana) <aretana@cisco.com>; wrote:
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>  
> >> (1) I agree with Mirja that this document seems to be missing the actual
> >> protocol specification, unless Section 6 is meant to provide the
> >> normative specification of how the messages are to be exchanged. Is it?
> >> If so, I would expect that to be explicit in the document.
> >>  
> >> (2) If there is in fact supposed to be a protocol specified here, I have
> >> the same question as I had on draft-ietf-sidr-publication, which is how
> >> do the entities migrate from one version to another and do version
> >> negotiation?
> >  
> > Picking up from Benoit?s comment ? the use of ?protocol? is
> > misleading.  What is described is a process that can be followed
> > and the necessary information exchanged ?to simplify
> > configuration?by setting up relationships and exchanging keying
> > material used to authenticate those relationships.?
> 
> Is this going to be clarified in the document?

[Mostly offline this week, including a multi-day power outage, whee!]

With respect, I don't concede the point that this is not a protocol.

UUCP (RFC 976) and Batch SMTP (RFC 2442) were protocols, so is this.
It has senders and receivers, rules for who initiates the conversation
and what each party is allowed to say, and so forth.  The only things
it doesn't have are a required underlying transport protocol and
corresponding channel security mechanism.  These omissions are
deliberate, as stated in the introduction (last two paragraphs).  As
Stephen observe, it's a sneakernet protocol.

Sections 5 and 6 are intended to be read together.  The explicit rules
for what goes into each PDU are in section 5.2, but it's easier to see
how the protocol operates with the worked examples in section 6.

The only thing I can see in re-reading this that looks unclear (to me)
is that section 5.2.3 ought to state explicitly that it comes after
the <child_request/> / <parent_response/> exchange.  This is sort of
there already in implicit form (the <referral/> sub-element of the
<publisher_request/> message requires an <authorization/> from the
<parent_response/> message), but it probably ought to be explicit.