Gorry, comments on service-codes-04.
The original draft of the DCCP specification did not use traditional
ports; instead the client allocated a 32-bit identifier to uniquely
identify the connection. ... This design
suffered from the downside of being sufficiently different from
existing protocols that there were concerns that it would hinder the
use of DCCP through NATs and other middleboxes.
An additional downside is that this design prevents the deployment of two
servers for the same service on a single machine, something that is trivial
with ports. This is the true reason why ports reappeared, although
NAT/middlebox concerns also played a part.
This permits a flexible correspondence between services
and port numbers than possible using the corresponding socket pair
(4-tuple of layer-3 addresses and layer-4 ports).
"a MORE flexible correspondence"
Note that more than one DCCP server may share the same server port,
since in DCCP the Service Code mechanism is the method for unique
identification of a service.
This is not correct: the COMBINATION of server port and Service Code uniquely
identifies a LISTENING APPLICATION. It is important to get this right.
2.7. A method to hash the Service Code to a Dynamic Port
I do not find this section convincing. Among other things:
- operating systems use the dynamic port range for client ports, and therefore
there is a chance that a server attempting to open the indicated port for
listening will be prevented from doing so because of an existing short-lived
client port.
- the function can return port 65535 which i believe some OSes refuse to open
- there is no need for a large range of server ports (because of the unique
mapping of server port + service code to application).
- the section is unclear whether it is suggesting a possible procedure or
defining a requirement.
I suggest instead that the document allocate one Registered Port intended for
use by DCCP applications with no port allocation of their own. This port
would become something like a "default DCCP port," and applications using it
would be using the originally intended service code model.
If because of current OS constraints (such as the Linux implementation's) more
than one "default DCCP port" is required, that is too bad, but a small range
of, say, 256 or 1024 Registered Ports would suffice in practice until that
implementation limitation is overcome.
Port numbers and IP addresses are the traditional methods to identify
a flow within an IP network. When the DCCP header has not been
encrypted, Middleboxes [RFC3234] should use the Service Code to
identify the application-service (even when running on a non-standard
port). When consistently used, the Service Code can provide a more
specific indication of the actual service (e.g. indicate the type of
multimedia flow, or intended application behaviour). Middlebox
devices are therefore expected to check Service Code values as well
as, or even instead of port numbers for DCCP.
I disagree with this paragraph. It puts requirements on middleboxes and
recommends shifting away from well-known practices (e.g., port numbers) to
unknown practices with few practical benefits (Service Codes cannot be
trusted). "are therefore expected" is too strong. There are good reasons to
manage DCCP applications based on ports, including familiarity. The most I
would say is something like "Middleboxes that use DCCP may additionally use
the Service Code to identify an application service, even when running on a
non-standard port. When consistently used, the Service Code can provide a
specific hint of the intended service, such as the type of multimedia flow or
intended application behavior." Additional text, if any, should explain WHY
middleboxes should shift towards using the Service Code; this would be more
convincing and appropriate than the current requirement.
This section would be more useful if it pointed out to middlebox authors some
issues with port numbers. For example:
"Middlebox authors are cautioned that new DCCP connections are identified by
the pair of Server Port and Service Code. In particular, this means that IANA
may allocate a server port to more than one application. All such
applications will be distinguished by Service Code. A middlebox that intends
to differentiate applications SHOULD therefore test the Service Code as well
as the destination or source port on a DCCP-Request or DCCP-Response packet.
Security Consideration: DCCP's use of Service Codes as well as ports to
demultiplex incoming connections may change the service model expected by
middleboxes. The port-numbers registry already contains some instances of
multiple application registrations for a single port number for TCP and UDP.
This is relatively rare, however. Since DCCP's Service Code allows multiple
applications to safely share the same port number, even on the same machine,
port number reuse in DCCP may be more common than in TCP and UDP. Middleboxes
that intend to differentiate applications should therefore examine Service
Codes on connection requests as well as port numbers."
DCCP connections identified by the Service Code continue to use IP
addresses and ports, although neither port number may be Well Known.
Nothing about this is different from TCP or UDP. It should be cut.
Although Service Codes label a connection and can (and is encouraged
to) associate specific delivery properties (e.g. use Service Codes to
identify the real-time nature of a flow that claims to be using RTP),
Not good English.
This
document updates RFC4340 to also add:
"A specific Service Code value MAY be associated with more than one
server port, although only a single port is registered by IANA."
It would be good to define exactly what the updates to RFC 4340 are doing
here. So far all of the updates are clarifications, i.e., do not change the
meaning, except arguably for the "SHOULD" requirement for multiple
applications on the same listening port. Please explain exactly what each
change does. E.g., not "This document updates RFC4340 to also add:", but
"This document updates RFC4340 to also add: .... This change clarifies
RFC4340, but does not change its meaning."
o "IANA should normally assign a value above 1024 to a DCCP server
port. IANA allocation requests to allocate port numbers in the Well
Known Ports range (0 through 1023), require Expert Review prior to
allocation by IANA [RFC4340]. Requests for registered ports in the
range 1024-49151, do not normally require Expert Review."
What's the logic for this requirement? I would remove it. Service Code
demultiplexing should mean that ANY allocation request for a port does not
normally require Expert Review.
o "IANA MUST NOT allocate more than one DCCP server port with a
single Service Code value.
Strongly disagree. I see no reason for such a restriction. This also goes
against what you recommend middleboxes do.
o A request for additional Service Codes to be associated with an
already allocated Port Number requires expert review. These requests
will normally be accepted when they originate from the contact
associated with the port registration. In other cases, these
applications will be expected to use an unallocated port, when this
is available."
Again, I disagree. What is the logic? Is this designed to keep the meanings
of ports stable for middlebox authors? See my text above.
RFC 4340 notes that a short port name MUST be associated with each
DCCP server port that has been registered, and that this name is
expected to be unique within the registry. This document updates this
by adding that:
o "A port name may be generated from the Service Code value
represented in hexadecimal, e.g. SC:fdpz corresponds to the port name
'0x6664707a'."
In the case of DCCP, it is considered useful to use a value that
shows the association with the Service Code, and since service codes
are 32-bit numbers this requires the a hexadecimal representation.
This differs with the tradition of naming ports in UDP and TCP.
Again, I disagree. This uglifies port numbers. The colon character is not
used in any existing port number registration. The registrations in the
service-codes draft itself do not follow this logic. And finally there is
already a well-known mechanism for associating Service Codes with ports:
RFC4340 requires that the port number registration's short English phrase
include the Service Code; this is easily parsed. Please remove this.
This document notes that it is not required to supply an approved
document (e.g. a published RFC) to support an application for a DCCP
Service Code or port number value, although RFCs may be used to
request Service Code values via the IANA Considerations section (e.g.
[ID.SC]). A specification is however required to allocate a Service
Code that uses a combination of ASCII digits, uppercase letters, and
character space, '-', '.', and '/') [RFC4340].
This is not a change from RFC4340 and should be marked as such.
Hope this helps.
Eddie
Gorry Fairhurst wrote:
Dear all,
I've just posted a new revision of the Service Codes draft. This version
contains the result of some discussion on the IANA procedures and some
editorial work to prepare this for a WGLC.
I'd appreciate inputs from those interested in the IANA procedures to
help determine if the text reflects the new procedures intended for DCCP
- this change should ideally track the changes proposed for UDP, TCP,
etc - but also needs to clarify some of the things presented in RFC 4340.
I hope the draft will appear soon,
Best wishes,
Gorry
(as a document author)
