On 8/24/2011 3:51 AM, t.petch wrote:
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.
There's an online form at IANA, but they're in the process of updating
it based on the I-D below. The info below answers the questions that
apply for this protocol.
Note, however, that there still remains an interesting question here -
whether 1, 2, or 3 ports are really needed.
1 = insecure, out-of-band security (IPsec, TCP MD5, TCP-AO), in-band-sec
(TLS) all on one port
2 = as per the current doc:
- insecure and out-of-band (IPsec, TCP MD5, TCP-AO) (rpki-rtr)
- TLS (rpki-rtr-tls)
3 = all three on separate ports
Is there ever a reason that this service should exist as a totally open
and insecure port?
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)?
(IMO, this might be more of a sticking point if a well-known port is
requested)
Joe
----- Original Message -----
From: "Joe Touch"<[email protected]>
To: "t.petch"<[email protected]>
Cc: "Christopher Morrow"<[email protected]>;<[email protected]>;
<[email protected]>; "Randy Bush"<[email protected]>
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<[email protected]> (as per sec 8.1.1.)
Contact (REQUIRED) IETF Chair<[email protected]>
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<[email protected]>
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
