Re: [port-srv-reg] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)

Hi, all,

TLS and DTLS are not transport protocols. The SRV spec specifies only the following syntax:

	_sname._tname.example.net

sname is a service name
tname is a transport protocol

Service names currently define all protocols from L5-L7 as a single, non-parseable name. E.g., HTTP, HTTPS, etc. There are variants for application protocols over SOAP over HTML, etc. But there aren't dots separating the names (dots aren't permitted in service names, nor are underscores), and there's no structure to those names.

I'm not aware of any documents that use other syntax that ever proposed to update RFC 2782. The few exceptions (e.g., of specifying SRV entries with nonstandard syntax) we've found to date have not been deployed, and we're expecting to issue an update to those docs to correct or deprecate them.

In this case, the approach I would expect - which is used much more commonly - is:

	_diameter-s._tcp.example.net		-- this means "diameter over TLS"
	_diameter-s._udp.example.net		-- this means "diameter over DTLS"

Diameter-s, diameters, or any such new service name would be used to indicate the secure variant of diameter.

This differs from the recent NAPTR application protocol tag. The following was the summary of updates from that discussion on DIME-extended-naptr, FWIW:

(1) State that the S-NAPTR Service/Protocol tags are unrelated to the IANA Service Name and Transport Protocol Port Number Registry.

(2) State that the Application Protocol tag must not be parsed in any way by the querying application or resolver. The delimiter (".") is present in the tag to improve readability and does not imply a structure or namespace of any kind.

(3) State that the choice of delimiter (".") for the Application Protocol tag follows the format of existing S-NAPTR registry entries but this does not imply that that it shares semantics with any other RFCs that have created registry entries using the same format.

Joe

On Sep 22, 2011, at 9:14 AM, Peter Saint-Andre wrote:

> [Adding port-srv-reg@ietf.org for expert insight...]
> 
> Context for the ports and services folks:
> 
> During IESG review of draft-ietf-dime-rfc3588bis-29, I discovered that
> this specification appears to be using 'tls' and 'dtls' as SRV Proto
> values (and that it does not add 'diameter' to the ports and services
> registry). This strikes me as problematic, but feedback from your team
> would be helpful.
> 
> Thanks!
> 
> On 9/22/11 7:31 AM, Peter Saint-Andre wrote:
>> On 9/22/11 2:43 AM, Korhonen, Jouni (NSN - FI/Espoo) wrote:
>>> Peter,
>>> 
>>> 
>>> -----Original Message----- From: ext Peter Saint-Andre
>>> [mailto:stpeter@stpeter.im] Sent: Thursday, September 22, 2011 5:10
>>> AM To: The IESG Cc: dime-chairs@tools.ietf.org;
>>> draft-ietf-dime-rfc3588bis@tools.ietf.org Subject: Peter
>>> Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS
>>> and COMMENT)
>>> 
>>> Peter Saint-Andre has entered the following ballot position for 
>>> draft-ietf-dime-rfc3588bis-29: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to
>>> all email addresses included in the To and CC lines. (Feel free to
>>> cut this introductory paragraph, however.)
>>> 
>>> Please refer to
>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more
>>> information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> 
>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV
>>> Service of 'diameter'. 3588bis seems to add two more Proto values:
>>> 'tls' and 'dtls'. However, RFC 6335, which defines updated rules for
>>> the ports and services registry, allows only TCP, UDP, SCTP, and DCCP
>>> as transport protocols. Furthermore, this specification does not
>>> register the 'diameter' SRV Service value in accordance with RFC
>>> 6335. Because these values were not defined or registered by
>>> draft-ietf-dime-extended-naptr, I think they need to be defined
>>> here.
>>> 
>>> [JiK]: In extended-naptr I-D we have a note we came up with a lengthy
>>> discussion (and eventually to an agreement) with Joe Touch. How would
>>> RFC3588bis be different from extended-naptr in this case regarding
>>> the use of "diameter" and "dtls"?
>>> 
>>> The S-NAPTR Application Service and Protocol tags defined by this 
>>> specification are unrelated to the IANA Service Name and Transport 
>>> Protocol Port Number Registry (see [I-D.ietf-tsvwg-iana-ports]).
>>> 
>>> [JiK]: RFC3588bis only introduces "diameter.dtls" in addition what is
>>> already in extended-naptr I-D.
>> 
>> That's not how I read it. 3588bis says:
>> 
>>   3.  If no NAPTR records are found, the requester directly queries for
>>       SRV records '_diameter._sctp'.realm, '_diameter._dtls'.realm,
>>       '_diameter._tcp'.realm and '_diameter._tls'.realm depending on
>>       the requesters network protocol capabilities.
>> 
>> Those are not S-NAPTR Application Service and Protocol tags, they are
>> SRV Service and Proto values.
>> 
>> We might need to follow up separately with the Port Expert Team.
> 
> <snip/>
> 
> _______________________________________________
> Port-srv-reg mailing list
> Port-srv-reg@ietf.org
> https://www.ietf.org/mailman/listinfo/port-srv-reg