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
