[radext] [IANA #814383] Application for a Service Name "radiusdtls"

"Pearl Liang via RT" <iana-prot-param@iana.org> Mon, 23 March 2015 21:23 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id B4BFE1A1B1E; Mon, 23 Mar 2015 14:23:41 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942EB1A1AFF; Mon, 23 Mar 2015 14:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.19
X-Spam-Level:
X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tevKQnRqTqI; Mon, 23 Mar 2015 14:23:39 -0700 (PDT)
Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52BE1A1A9D; Mon, 23 Mar 2015 14:23:39 -0700 (PDT)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2NLNdIU014362; Mon, 23 Mar 2015 21:23:39 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id 9305CC20665; Mon, 23 Mar 2015 21:23:39 +0000 (UTC)
RT-Owner: pearl.liang
From: "Pearl Liang via RT" <iana-prot-param@iana.org>
In-Reply-To: <201503200852.t2K8qCpf012076@smtp1.lax.icann.org>
References: <RT-Ticket-814383@icann.org> <201503200852.t2K8qCpf012076@smtp1.lax.icann.org>
Message-ID: <rt-4.2.9-13014-1427145819-54.814383-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #814383
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: pearl.liang@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Mon, 23 Mar 2015 21:23:39 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/fFJw78onvohBCjQgVmODw5GUwoU>
X-Mailman-Approved-At: Mon, 23 Mar 2015 15:29:39 -0700
Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, chair@ietf.org, iesg@ietf.org
Subject: [radext] [IANA #814383] Application for a Service Name "radiusdtls"
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: iana-prot-param@iana.org
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 21:23:41 -0000

Dear IESG/Authors:

We have processed this request (included below).
This message is to confirm that we have registered the following as per
draft-ietf-radext-dynamic-discovery-13:

radiusdtls		tcp	Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiusdtls" for discovery of RADIUS/DTLS servers	[IESG]	[IETF_Chair]	2015-03-23		[draft-ietf-radext-dynamic-discovery-13]			Defined TXT keys: None
radiusdtls		udp	Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiusdtls" for discovery of RADIUS/DTLS servers	[IESG]	[IETF_Chair]	2015-03-23		[draft-ietf-radext-dynamic-discovery-13]			Defined TXT keys: None

Please see:
http://www.iana.org/assignments/service-names-port-numbers

When the document has been approved for publication as an RFC, we will update
the draft string to the approved RFC number.

Thank you,

Pearl Liang
ICANN


On Fri Mar 20 08:52:15 2015, chair@ietf.org wrote:
> 
> Application for a Port Number and/or Service Name
> 
> Assignee: IESG <iesg@ietf.org>
> Contact Person: IETF Chair <chair@ietf.org>
> 
> Resource Request:
> 
> [ ] Port Number
> [x] Service Name
> 
> Transport Protocols:
>     [ ] TCP
>     [x] UDP
>     [ ] SCTP
>     [ ] DCCP
> 
> Service Code:         []
> Service Name:         [radiusdtls]
> Desired Port Number:  []
> Description:          [Authentication, Accounting and Dynamic
> authorization via the RADIUS protocol.  This service name is used to
> construct the SRV service label "_radiusdtls" for discovery of
> RADIUS/DTLS servers.]
> 
> Reference:
> [http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-13]
> 
> Defined TXT Keys:
> 
> 1.  If broadcast/multicast is used, how and what for?
> [Not used.]
> 
> 2.  If UDP is requested, please explain how traffic is limited, and
> whether the
>     protocol reacts to congestion.
> [The payload transmitted via servers which can be discovered with this
> draft is RADIUS. RADIUS is a AAA protocol with severe size
> limitations. It is explicitly NOT designed for bulk data transfer.]
> 
> 3.  If UDP is requested, please indicate whether the service is solely
>     for the discovery of hosts supporting this protocol.
> [The service name here is only used for the discovery of hosts
> supporting the RADIUS/DTLS protocol as defined in RFC7360.]
> 
> 4.  Please explain how your protocol supports versioning.
> [The protocol immediately initiates DTLS (no STARTTLS or similar).
> DTLS version negotiation follows as usual.]
> 
> 5.  If your request is for more than one transport, please explain in
>     detail how the protocol differs over each transport.
> [No other transport besides UDP requested; note however the parallel
> service name radiustls which will be requested for RADIUS/TLS over
> TCP.]
> 
> 6.  Please describe how your protocol supports security. Note that
> presently
>     there is no IETF consensus on when it is appropriate to use a
> second port
>     for an insecure version of a protocol.
> [Traditional RADIUS over UDP has no version negotiation and no
> protocol phase which would allow the equivalent of STARTTLS. A new
> port is thus required and was assigned in RFC7360. The service name
> requested here only allows to discover servers supporting RFC7360 in
> DNS. The discovery algorithm in this draft uses DNSSEC where
> available, but has provisions for server authorisation verification in
> the absence of DNSSEC (using PKIX certificate extensions).]
> 
> 7.  Please explain why a unique port assignment is necessary as
> opposed to a
>    port in range (49152-65535) or existing port.
> [No port is requested here (RFC7360 already has a port for
> RADIUS/DTLS).]
> 
> 8.  Please explain the state of development of your protocol.
> [The discovery protocol as defined in the reference draft is already
> in use on the internet by a large roaming consortium. The consortium
> only makes use of RADIUS/TLS though, so no actual hosts have been
> discovered for RADIUS/DTLS.]
> 
> 9.  If SCTP is requested, is there an existing TCP and/or UDP service
> name or
>     port number assignment? If yes, provide the existing service name
> and port number.
> [SCTP is not requested.]
> 
> 10.  What specific SCTP capability is used by the application such
> that a
>     user who has the choice of both TCP (and/or UDP) and SCTP ports
> for
>     this application would choose SCTP? See RFC 4960 section 7.1.
> [SCTP is not requested.]
> 
> 11. Please provide any other information that would be helpful in
>     understanding how this protocol differs from existing assigned
> services.
> []