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

John Scudder <jgs@juniper.net> Wed, 08 June 2011 18:31 UTC

Return-Path: <jgs@juniper.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 0E63521F8599 for <sidr@ietfa.amsl.com>; Wed, 8 Jun 2011 11:31:56 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yARZWa99yf3y for <sidr@ietfa.amsl.com>; Wed, 8 Jun 2011 11:31:55 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id CEE8521F8598 for <sidr@ietf.org>; Wed, 8 Jun 2011 11:31:54 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTe/AFZqAMXNQBnjzeDXL8weqX3MFxTxG@postini.com; Wed, 08 Jun 2011 11:31:54 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 8 Jun 2011 11:30:18 -0700
From: John Scudder <jgs@juniper.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Wed, 08 Jun 2011 11:30:16 -0700
Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
Thread-Index: AcwmCh4GwUUVgfSTTkSQpJ9Bzo3rsg==
Message-ID: <5B8DC276-52BF-4D33-852F-61CE520B3C74@juniper.net>
References: <4DAF44AC.8060408@isi.edu> <BANLkTikLi2p7UipJ!TRSQqVOL6GkLn=j9iA@mail.gmail.com> <F0FABE61-FC1D-45ED-A21D-ED7A1228A997@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <BANLkTikg18FV5H0bOdOfWMzpTcm_B__EVQ@mail.gmail.com> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <BANLkTink82qvhge6rRhqt5+h-2mEkKBMhA@mail.gmail.com> <m21uzwr3tw.wl%randy@psg.com> <BANLkTimPnMfE1ii=6uwAckoFY0yUU=w43g@mail.gmail.com> <BANLkTinu8pxxCj4cdJzbS3z5h=8=s+U3Gw@mail.gmail.com> <D1D8138DDF34B34B8BC68A11262D10790F6233E006@EUSAACMS0701.eamcs.ericsson.se> <Pine.WNT.4.64.1106031624560.2148@SMURPHY-LT.columbia.ads.sparta.com> <D1D8138DDF34B34B8BC68A11262D10790F6233E04A@EUSAACMS0701.eamcs.ericsson.se> <m2ei37gj4p.wl%randy@psg.com> <4DECDFA0.9080109@cs.tcd.ie>
In-Reply-To: <4DECDFA0.9080109@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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.12
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: Wed, 08 Jun 2011 18:31:56 -0000

On Jun 6, 2011, at 10:09 AM, Stephen Farrell wrote:
...
> That's why I suggested "MUST implement SSH; SHOULD implement
> TCP-AO; MUST prefer TCP-AO if both available"

The penny finally dropped and I realized there is a better reason why SSH isn't desirable, and neither is TLS or any other solution layered on top of TCP: they don't protect the transport.  Recall why TCP-MD5 was introduced (from RFC 2385):

   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets.

Any protocol layered over TCP can't address this concern.  

While authentication of peer identity and integrity of the transported data are even more important than transport protection per se for RPKI-RTR, it would seem prudent to assume that any threats that affect BGP may also affect RPKI-RTR.  That means protecting the transport from reset attacks, and that means AO, IPSec or MD5.  

--John