Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

Geoff Huston <gih@apnic.net> Sat, 09 April 2011 15:27 UTC

Return-Path: <gih@apnic.net>
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53193A6876 for <sidr@core3.amsl.com>; Sat, 9 Apr 2011 08:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.704
X-Spam-Level:
X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UX5+ovefEbc for <sidr@core3.amsl.com>; Sat, 9 Apr 2011 08:27:42 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8E1793A6835 for <sidr@ietf.org>; Sat, 9 Apr 2011 08:27:41 -0700 (PDT)
Received: from 4.75.240.10.in-addr.arpa (m1f0436d0.tmodns.net [208.54.4.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3BCFAB6826; Sun, 10 Apr 2011 01:29:24 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com>
Date: Sun, 10 Apr 2011 01:29:21 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2C0D0FF-A02D-4DF3-80CE-2D6346E20EF5@apnic.net>
References: <BANLkTi=eZ=pQ2gJfiPBfeb4frH8Tncempw@mail.gmail.com> <m21v1i9ha8.wl%randy@psg.com> <BF88D659-1BE5-4DD2-AB24-7A113360DF37@cisco.com> <m2tyea7urr.wl%randy@psg.com> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <BANLkTikTqCD4_=-Sjs7ng2qSLn3vYw5qLw@mail.gmail.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <m2ipupsmuy.wl%randy@psg.com> <BANLkTinoJRu=hkoiCS=Xj000r3W+n5KnZQ@mail.gmail.com> <F05F2600-9E6C-410B-9EC5-F4245E6F5B88@cisco.com> <20110408170400.GC11350@juniper.net> <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com>
To: Hannes Gredler <hannes@juniper.net>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 09 Apr 2011 15:27:42 -0000

On 09/04/2011, at 3:49 AM, Pradosh Mohapatra wrote:

>> not sure if mandating a single transport is needed at all.
>> 
>> since the pros and cons of the various transport protocols
>> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply
>> enumerating the choices and leave it to the operator's local security policy
>> which one to deploy ?
>> 
>> IMO you cannot dictate local security policy as they are different between
>> operators. also if the level of containment is sufficiently enough (e.g.
>> local-cache only reachable through vrf, not accessible through internet
>> it is perfectly reasonable even to load your cache records using vanilla TCP.)
> 
> I have no problem listing various transports. I thought there was a suggestion to
> keep one of them mandatory to encourage better interoperability. That makes
> some sense.

Frankly the interoperability argument is a very strong one for me. Yes, at every
step and with every component of this design we could enumerate a laundry list
of possible technologies, but, frankly, it seems like a less than useful exercise
of constructing complexity and threatening interoperability of the resultant
system. If the intention is to produce robust specifications that allow cleanly
interoperable implementations then it makes sense for me to produce a 
specification that makes specific selections from the choice set.

 Geoff