Re: [sidr] WGLC draft-sidr-rpki-rtr

Chris

Joe also made the point that the Service names as currently specified have an
invalid syntax in that there is a space in there, so that needs fixing, I think
before an IETF LC.

Tom Petch

----- Original Message -----
From: "Christopher Morrow" <christopher.morrow@gmail.com>
To: "Joe Touch" <touch@isi.edu>
Cc: <sidr-chairs@ietf.org>; "Paul Hoffman" <paul.hoffman@vpnc.org>;
<sidr@ietf.org>
Sent: Monday, September 26, 2011 3:44 PM
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 8/24/2011 3:57 PM, Paul Hoffman wrote:
>>
>> 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.
>
> I recall that discussion, but not the assertion that this would mean that
> you'd suggest using an insecure port.
>
> If that's the case, I strongly recommend NOT asking for a system port.
>
>> 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.
>
> Here I wasn't asking about TLS vs open, I was asking about TLS vs.
> IPsec/MD5/AO, and whether that has a different answer than TLS vs. open.
>
> Whether for this protocol or not, I would appreciate understanding that in
> more detail - even if off-list. I cannot see how the protocol matters if TLS
> is started or not on a per-connection basis since the TLS would wrap (or
> not) the data of the connect at the start. We can continue that off-list,
> though.

The doc in question hit version 16 on 8/13/2011... I think the authors
feel that the problems/issues/discussion-points here are addressed in
this version. Are we cycled down to acceptance of the language or no?
The -16 version asks for a 'well-known' port, which gets to the main
point of this discussion I think.

(and an IANA request would still need to be made when the doc goes
toward publishing)

-Chris
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr