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

["t.petch" <[e-mail]>]

Joe

Thanks for the information.  I had missed the IESG update to the guidelines on
Port allocation, which relaxes the constraints on a separate port for security a
little.

Also, from experience with requests to IANA for the specification of URI and
such like schemes, where there is a pro forma which I always see in the
requesting RFC, I had imagined that something similar would now be needed for
Port number requests but perhaps not; and if there is, then you have provided it
for us.

Tom Petch


----- Original Message -----
From: "Joe Touch" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: "Christopher Morrow" <[e-mail]>; <[e-mail]>;
<[e-mail]>; "Randy Bush" <[e-mail]>
Sent: Monday, August 22, 2011 6:01 PM
> On 8/22/2011 4:03 AM, t.petch wrote:
> > Chris
> >
> > I don't know if your training included
> > draft-ietf-tsvwg-iana-ports-10
> > currently in AUTH48 but it does say, as some on this list know well,
> >
> > "    A service name or port number assignment request contains the
> >     following information.  The service name is the unique identifier of
> >     a given service:
> >
> >        Service Name (REQUIRED)
> >        Transport Protocol(s) (REQUIRED)
> >        Assignee (REQUIRED)
> >        Contact (REQUIRED)
> >        Description (REQUIRED)
> >        Reference (REQUIRED)
> >        Port Number (OPTIONAL)
> >        Service Code (REQUIRED for DCCP only)
> >        Known Unauthorized Uses (OPTIONAL)
> >        Assignment Notes (OPTIONAL)"
> >
> > which suggests a fairly rapid rejection of our I-D.
>
> Sure, but on trivial grounds (the service names you provide have spaces).
>
> To assist with your application, here's a suggestion (this need not be
> in the RFC, but the RFC should conform to the following information
> where it differs, e.g., the list of requested service names - note that
> this isn't guaranteed to fly, though, as per below):
>
>          Service Name (REQUIRED) RPKI-Rtr
>          Transport Protocol(s) (REQUIRED) TCP
>          Assignee (REQUIRED) IESG <[e-mail]> (as per sec 8.1.1.)
>          Contact (REQUIRED) IETF Chair <[e-mail]>
>          Description (REQUIRED) request/response exchange, including
> an initial message indicating version number; data transferred
> as native records with in-band record separators and
> transaction terminators; transport connection is
> persistent across multiple request/response exchanges;
> exchanges MUST be protected by access control, and MAY
> use TCP MD5, TCP-AO, or IPsec
>          Reference (REQUIRED) See RFC (TBD)
>          Port Number (OPTIONAL) any in the well-known range
>          Service Code (REQUIRED for DCCP only) N/A
>          Known Unauthorized Uses (OPTIONAL) N/A
>          Assignment Notes (OPTIONAL)
>
>          Service Name (REQUIRED) RPKI-Rtr-TLS
>          Transport Protocol(s) (REQUIRED) TCP
>          Assignee (REQUIRED) (as per sec 8.1.1.)
>          Contact (REQUIRED) IETF Chair <[e-mail]>
>          Description (REQUIRED) request/response exchange, including
> an initial message indicating version number; data transferred
> as native records with in-band record separators and
> transaction terminators; transport connection is
> persistent across multiple request/response exchanges;
> exchanges MUST be protected by access control and TLS
>          Reference (REQUIRED)See RFC (TBD)
>          Port Number (OPTIONAL) any in the well-known range
>          Service Code (REQUIRED for DCCP only) N/A
>          Known Unauthorized Uses (OPTIONAL) N/A
>          Assignment Notes (OPTIONAL)
>
> Regarding Chris's question:
> On 8/22/2011 6:17 AM, Christopher Morrow wrote:
>  > Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems
>  > non-scalable in a number of dimensions.
>
> Again see Sec 8.1.1. It's a person (usually the person who issues the
> request) in all cases except IETF document stream assignments.
>
> > The section on two ports or
> > one, which I alluded to earlier, is section 7.2 which starts with
> > "   o  IANA strives to assign only one assigned port number per service
> >        or application"\
>
> This was updated as a result of IETF last call and IESG review. The
> current text (pending final typo corrections) reads as follows (the
> tracker here shows this:)
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/writeup/
>
> --
> o  IANA strives to assign only one assigned port number per service
>        or application
>
> Note: At the time of writing of this document there is no IETF consensus
> on when it is appropriate to use a second port for an insecure version
> of a protocol.
> --
>
> This is a bit of a sticky example, mostly because you're asking for a
> well-known port. It'd help to have IESG consensus on the use of an
> insecure protocol in that range.
>
> The current doc is a bit confusing on this point - do you ever intend to
> allow both insecure and TCP MD5/TCP-AO/IPsec on the same port?
>
> AFAICT, you actually want (need) three ports:
>
> RPKI-Rtr-open - insecure
> RPKI-Rtr-tnsec - transport/network security
> RPKI-Rtr-apsec - application-layer security (TLS)
>
> Then you need to explain clearly why you *cannot* determine which
> category a connection falls from the packets that arrive -- and
> performance alone is not a sufficient reason (that could then be used to
> argue, e.g., for dozens of ports for various services, and the port
> space is too limited to support that just for performance reasons).
>
> It seems like -open is an uphill issue if you ask for a well-known port,
> IMO.
>
> Joe