We need as a WG to understand what it means to use "Service Codes" - how
these should be used by applications, how midboxes may leverage them,
and what are the implications of allowing flexible assignments (more
opportunities for applications to pretend to be what they are not??)
There was not much response to Tom's message - so I'd like to re-start
this debate in the WG meeting next week with the aim of getting a
sensible and useful outcome which we can put in the User Guide.
Gorry
----
Some other reading material, that mentions related topics:
RFC4336 Problem Statement for the Datagram Congestion Control Protocol
(DCCP). March 2006.
Procedures for SCTP, TCP, and UDP Port Assignments by IANA
draft-lear-iana-no-more-well-known-ports-02.txt
A TCP Option for Port Names (expired)
http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt
----
Phelan, Tom wrote:
Hi DCCPers,
In Montreal, we had a discussion about what service codes should be used
by apps using DTLS over DCCP. The discussion was inconclusive, and we
decided to continue it on the list, so let's do it :-).
Remember that the Service Code is a field in DCCP-Request packets that
"Describes the application-level service to which the client application
wants to connect." (from RFC4340).
This is complicated because we're moving from a world where apps are
identified by ports to a world where they're identified by service codes
-- and just what do ports mean in this world?. Well-known ports are
useful; they allow you to connect without some sort of extra lookup.
But if you have a well-known port for an app there's going to be the
tendency to identify it by that. And what's the difference between a
well-known port and a well-known service code? Why do we have ports?
Personally, my view is that service codes should identify apps, and
ports allow you to run multiple instances of an app on a server or client.
Then there's the question of whether App A running over DCCP is
different from App A running over DTLS/DCCP. My conclusion is that they
are different, because the app over DTLS/DCCP can offer more
services/functions (confidentiality and authentication) than the app
over just DCCP (unless these functions were built directly into the app,
and then why bother with DTLS?). HTTP and HTTPS (and SIP and SIPS) use
different URIs because they offer different services -- similar, sure,
but different in some details. I would expect apps that use DCCP to
similarly offer different URIs for DTLS or not.
So given that, here's some proposed text as a straw man:
"An application using DTLS over DCCP MUST register a new service code
for the combination."
Tom P.
