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"<[email protected]>
To: "Joe Touch"<[email protected]>
Cc:<[email protected]>; "Paul Hoffman"<[email protected]>;
<[email protected]>
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<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
