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

Hannes Gredler <hannes@juniper.net> Sat, 09 April 2011 20:42 UTC

Return-Path: <hannes@juniper.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 82EC13A6976 for <sidr@core3.amsl.com>; Sat, 9 Apr 2011 13:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 SJomTD5QyBdw for <sidr@core3.amsl.com>; Sat, 9 Apr 2011 13:42:36 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 669603A694F for <sidr@ietf.org>; Sat, 9 Apr 2011 13:42:33 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTaDFIr6cJQ1nsXjMCWtNC7P5IEj/u/NX@postini.com; Sat, 09 Apr 2011 13:44:23 PDT
Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Sat, 9 Apr 2011 13:41:31 -0700
Received: by hannes-755.juniper.net (Postfix, from userid 1000) id AD4B822545; Sat, 9 Apr 2011 22:43:34 +0200 (CEST)
Date: Sat, 09 Apr 2011 22:43:34 +0200
From: Hannes Gredler <hannes@juniper.net>
To: Geoff Huston <gih@apnic.net>
Message-ID: <20110409204334.GB16327@juniper.net>
References: <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> <E2C0D0FF-A02D-4DF3-80CE-2D6346E20EF5@apnic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E2C0D0FF-A02D-4DF3-80CE-2D6346E20EF5@apnic.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
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 20:42:37 -0000

On Sun, Apr 10, 2011 at 01:29:21AM +1000, Geoff Huston wrote:
| 
| 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.

the question is *what* is that we try to standardize ? - is it

1. the application level communication protocol between caches and routers
2. the application level communication protocol between caches and routers
   and the transport ?

i do not really buy the interop argument as early interop testing
has showed that there are already several transports available to carry
the rtr-cache protocol (BTW including vanilla TCP.) furthermore how should
one read the spec ? - is a rtr-cache protocol implementation doing IPSEC
*not* compliant and if so what are the technical arguments against it ?

in the spirit of good layering we should really focus on the application protocol
and not trying to crawl down the entire stack and securing each and every layer.
where does it stop ? i mean shall we include DoS mitigation schemes at L3 and L2 ?
clearly not - that is the operators choice and so is to take care of
transport level security.