Hi Smith,
I just found this interesting higher level summary of the functions and
methodology
of IANA written by Jari Arkko, Chair of the IETF:
http://www.ietf.org/blog/2014/01/iana/
I'm still searching for an I-D or an ICANN/IANA policy that discusses
dual-use ports
(for UDP/DTLS or TCP/TLS) and IETF recommendations for supporting them.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Fri, Feb 28, 2014 at 1:31 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:
> Thanks Ira!
>> I did look at the IANA port registry page, at the top of which there are
> many references to RFC 6335. Unfortunately RFC 6335 doesn't contain
> statements or references to documents that state the IESG's position on
> this.
>> One could imagine an informative RFC that updates RFC 6335 and also
> includes a code example demonstrating how to support TLS and non-TLS
> variants using POSIX sockets and openssl or similar free software APIs.
>> Smith
>>>> On 2014-02-28, at 9:19 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Smith and HP folks,
>> These excellent comments are all very timely!
>> I'll issue a new draft soon that incorporates all of these improvements.
> We
> hope to convince the IETF Applications Area Directors to put that version
> into IETF Apps Last Call and assign a Document Shepherd to then take it
> to IETF Last Call.
>> Related to approaches for using a single port for both a plain application
> protocol (over TCP) and equivalent secure version (over TLS over TCP):
>> (1) The IESG (steering group that oversees the IETF) decided against any
> more dual-port registrations for application protocols over ten years ago
> (we were told we couldn't do it with IPP 1.1, RFC 2911).
>> (2) I think there's an IAB (parent of IESG) policy somewhere (maybe an RFC)
> about port registration.
>> (3) Note that the "System" range of port numbers (up to 1023), intended
> for OS kernel support and assigned by IESG to standards-track RFCs, has
> long since been exhausted.
>> (4) In a standards-track RFC for "ipps:" we aren't allowed to put an annex
> with code fragments - but such guidance could be published by the PWG.
>> (5) Since port 631 has been in use for years for secure IPP ("ipps:") in
> CUPS
> and supported by multiple printer vendors, we can't change the port number
> now (and the IESG would block the publication of "ipps:" entirely if we
> tried
> to do so).
>> BTW - here's the link to the current IANA port and service names registry:
>>>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml>> Cheers,
> - Ira
>>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto: blueroofmusic at gmail.com> Winter 579 Park Place Saline, MI 48176 734-944-0094
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>> On Fri, Feb 28, 2014 at 12:33 AM, Kennedy, Smith (Wireless Architect) <
>smith.kennedy at hp.com> wrote:
>>> Greetings,
>>>> Some folks in HP were reading over the "IPP over HTTPS and 'ipps' URI
>> Scheme" document, and they had some questions about port numbers, which
>> triggered my re-reading it. I wish to report the following issues:
>>>>>> Section 3 item (2), Page 7:
>>>> 2) The IPP Client converts the 'ipps' URI to an 'https' URI
>> (replacing 'ipps' with 'https' and inserting port 631);
>>>> This overlooks the possibility that there may be an alternate port in the
>> URI, as described more completely in section 4.2. To accommodate this, I
>> think it is more appropriate for this clause to be phrased more along these
>> lines:
>>>> 2) The IPP Client converts the 'ipps' URI to an 'https' URI
>> (replacing 'ipps' with 'https' and inserting the port number
>> from the URI or port 631 if the URI doesn't include a port
>> number);
>>>>>> Section 4.2, Page 9:
>>>> Note: IPP Printers ought to be cautious about depending on URI
>> lengths above 255 bytes, because some older IPP Client
>> implementations might not properly support these lengths.
>>>> Should "ought" really rather be "SHOULD"?
>>>>>> Section 4.2, Page 9: This should include a reference to section 4.3:
>>>> If the port is empty or not given, then port 631 MUST be used.
>>>>>> Section 4.3, Page 10: This should include a reference to section 4.3:
>>>> An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:"
>> with "https:" and inserting port 631 (if the 'port' is not present in
>> the original 'ipps' URI).
>>>>>>>> Section 4.3, Page 10: Missing mention of RFC 6335 or similar references,
>> that provide an explanation why the existing well-known port number (631)
>> is being overloaded for the TLS variant may be appropriate. This should be
>> included for the sake of those that aren't familiar with this newer "port
>> number allocation design pattern" being used by IANA and the IETF.
>>>>>> Section 4.6.1, Page 11: "The first and second 'ipps' URI above MUST be
>> resolved to port 631 (IANA assigned well-known port for IPP)." should refer
>> to section 4.3.
>>>>>> Section 4.7, Page 12: This should include a reference to section 4.3:
>>>> - A port that is empty or not given MUST be treated as equivalent to
>> the well-known port for that 'ipps' URI (port 631).
>>>>>> Section 5.1, Page 13: Grammatical error:
>>>> d) MUST the required TLS version(s) according to the corresponding
>> IPP versions as defined in section 7 of this specification;
>>>>>> Section 5.1, Page 13: Include a reference to section 4.3:
>>>> e) MUST only send IPP protocol connections to IANA assigned
>> well-known port 631 or to the explicit port specified in a given
>> 'ipps' URI;
>>>>>> Section 5.2, Page 14: Grammatical error
>>>> d) MUST the required TLS version(s) according to the corresponding
>> IPP versions as defined in section 7 of this specification;
>>>>>> Section 5.2, Page 14: This clause should also include either a reference
>> to and/or a statement that port 631 is to be used for both conventional IPP
>> over HTTP as well as IPP over HTTPS.
>>>> e) MUST only listen for incoming IPP protocol connections on
>> IANA-assigned well-known port 631 and MUST NOT listen for incoming
>> IPP protocol connections on any other port, unless explicitly
>> configured by system administrators or site policies;
>>>>>> Section 7.2.4, Page 18: Grammatical error - extra instance of "or"
>>>> Either service discovery or directory protocols SHOULD be used first
>> or or an IPP Client SHOULD first
>>>>>> Section 9: Add reference to RFC 6335 or similar references, that provide
>> an explanation why the existing well-known port number (631) is being
>> overloaded for the TLS variant may be appropriate. This should be included
>> for the sake of those that aren't familiar with this newer "port number
>> allocation design pattern" being used by IANA and the IETF. There is a
>> reference to [PORTREG] in section 9.2 but this seems inadequate to me.
>>>> I've marked up copy of the PDF draft, that I will send to Ira separately
>> so I don't spam everyone else. I don't know if this feedback is "too late"
>> but I thought I'd send it on anyway.
>>>> Cheers,
>>>> Smith
>>>> /**
>> Smith Kennedy
>> Hewlett-Packard Co.
>> */
>>>>>>>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>>>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140228/bd3cbd53/attachment.html>