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

[Joe Touch <[e-mail]>]

Hi, Tom,

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