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

Right - for those on this list:

-16 says:

    This document requests the IANA to assign 'well known' TCP Port
    Numbers to the RPKI-Router Protocol for the following, see Section 7:

            RPKI-Rtr
            RPKI-Rtr TLS

It should say:

    This document requests the IANA to assign 'well known' TCP Port
    Numbers to the RPKI-Router Protocol for the following, see Section 7:

            RPKI-Rtr	TCP
            RPKI-Rtr-s	TCP

(with corresponding changes to section 7).

Joe

On 9/27/2011 12:51 AM, t.petch wrote:
> 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