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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 24 August 2011 22:56 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 1C4FA21F8CF4; Wed, 24 Aug 2011 15:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.635
X-Spam-Level:
X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0xq0sSzjgwJ; Wed, 24 Aug 2011 15:56:13 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3116521F8CF0; Wed, 24 Aug 2011 15:56:13 -0700 (PDT)
Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OMvLUS081480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 15:57:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4E5570EF.4020202@isi.edu>
Date: Wed, 24 Aug 2011 15:57:20 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org>
References: <AANLkTimq3hcdK7-f_Pa9sWJJOTzF_GBLcYu36sB3WszN@mail.gmail.com> <CAL9jLaaVbmExEM2ZwBf5Ur6aRbBayxX13xGBL27r-svOmC3Wvg@mail.gmail.com> <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> <F350099E-1EEA-4478-BFC2-72A4622012E5@vpnc.org> <4E5570EF.4020202@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1244.3)
Cc: Christopher Morrow <christopher.morrow@gmail.com>, sidr-chairs@ietf.org, 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, 24 Aug 2011 22:56:14 -0000

On Aug 24, 2011, at 2:45 PM, Joe Touch wrote:

> On 8/24/2011 1:27 PM, Paul Hoffman wrote:
>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote:
>> 
>>> Is there ever a reason that this service should exist as a totally open and insecure port?
>> 
>> Given that it is explicitly listed in the draft, I find it worrisome that you even ask the question.
>> 
>>    Caches and routers MUST implement unprotected transport over TCP
>>    using a port, RPKI-Rtr, to be assigned, see Section 12.  Operators
>>    SHOULD use procedural means, ACLs, ... to reduce the exposure to
>>    authentication issues.
> 
> I saw a declaration that this was required, but no REASON that unprotected transport was necessary.

Three paragraphs earlier in the document:

   Unfortunately,
   there is no protocol to do so on all currently used platforms.
   Therefore, as of this document, there is no mandatory to implement
   transport which provides authentication and integrity protection.

This was discussed heavily in the WG.

>>> Also, is there a reason for not assuming that the out-of-band and
>> in-band services cannot exist on the same port (other than performance
>> of the connection establishment)?
>> 
>> Those aren't enough !?!?
> 
> "those"? I listed only one - performance.

Sorry, I misread your parenthetical as "other than performance and connection establishment". The idea that you can do TLS on the same port as not-TLS has been widely debated. It was finally agreed (maybe not by you) that the STARTTLS method for sharing a port may or may not be appropriate for each protocol. When I look at this protocol, I do not see a way to do it without completely rewriting the protocol interactions.

--Paul Hoffman