Gorry, some comments.
1.0
=> "It is not intended to be used to
specify a variant of an application, or a specific variant of a
protocol."
==> I would soften this, to say "It is not intended to be used to
differentiate minor variants in applications or protocols." I could see using
a service code to differentiate major variants; why not.
=> "Only one application may listen on a specific port
at any time,"
==> This contradicts RFC4340. "Passive sockets MAY, at the implementation's
discretion, be
associated with more than one Service Code; this might let multiple
applications, or multiple versions of the same application, listen on
the same port, differentiated by Service Code." RFC4340, 8.1.2. Also
this paragraph contradicts itself; the last sentence seems to indicate
multiple applications per listening port.
=> "Use of a Service Code value, instead of binding a service to a
particular publicly-known port number, permits a larger number of
concurrent connections for a particular service. For example, this
may be useful for applications where servers need to handle very
large numbers of simultaneous open ports to the same service."
==> This is misleading. A new connection can only be accepted if BOTH the
Service Code AND the Destination Port match. Service Codes do not change the
fact that services will most likely bind to well known ports. Service Codes
do not on their own increase the port space. The most a Service Code does is
identify the intended meaning of a port.
1.1
=> " o The use of port-based firewalls encourages application-writers to
disguise one application as another in an attempt to bypass
firewall filter rules. This encourages firewall writers to use
deep packet inspection in an attempt to validate that the
application actually is that associated with a port number. "
==> And Service Codes do not change this, either. A smart firewall would
STILL use deep packet inspection to verify that data wasn't being smuggled
through a fake Service Code. Service Codes do very little to increase
security on their own, at least from the point of view of network admins,
since they are controlled by possibly malicious parties (the end hosts). The
security impact of Service Codes is simply that they allow middleboxes to make
assumptions based on "intended protocol" rather than port. Middleboxes must
still VERIFY these assumptions.
=> "RFC 43404"?
=> "The intent was that the Service Code maintained its original role of
being the globally-unique identifier for the application or protocol
being used over DCCP, and that the pair of ports would effectively be
a 32-bit connection identifier, unique at both end-systems, even
though the two parts were allocated by the two different ends of a
connection. "
==> I don't know what "globally unique" means here. I would cut that phrase
and say "The intent was that the Service Code identify the application or
protocol being used over DCCP, providing middleboxes with information about
the intended use of a connection,".
2.1
=> " This section updates section 19.9 of [RFC4340] in the following way:
"Each DCCP port entered in this registry MUST be associated with at
least one pre-defined Service Code (see section 2.2)." "
==> How is this an update? RFC4340:
" Each port registration SHALL include the following information:
...
o A short English phrase describing the port's purpose. This MUST
include one or more space-separated textual Service Code
descriptors naming the port's corresponding Service Codes (see
Section 8.1.2)."
2.2
=> "A single destination port may be associated with more than one
Service Code value."
==> Prefer "passively opened socket" or "listening port" to "destination port".
=> Some text here is copied from RFC4340. I do not see the value of repeating
this text here. But if it is repeated, then it should be clearly identified
as repeated. A general problem with the document is lack of guidance as to
what is old and what is new.
=> "they MAY allocate a new Service Code (which MAY be associated with
the same set of DCCP well-known ports). "
==> I would advise that people SHOULD update the Well Known Ports registry in
this case, to add the new textual Service Code.
3
=> "This section explicitly updates RFC 4340 as follows:
"A DCCP implementation MUST allow multiple applications using
different DCCP service codes to listen on the same server port.
A DCCP implementation SHOULD provide a method that informs a server
of the Service Code value that was selected by an active connection." "
==> I disagree with the first requirement, the MUST. That is too harsh and I
see no need for it. I like the second requirement.
3.2
=> "Middleboxes [RFC3234] SHOULD instead use the Service Code
to identify the application-service (even when running on a non-
standard port). Middlebox devices are therefore expected to check
Service Code values before port numbers for DCCP. "
==> Please drop the word "instead", and replace "before" with "as well as, or
even instead of,". There are good reasons for middleboxes to check both ports
and service codes.
3.3.1
=> "A Service Code of zero MUST only be accepted for servers that
have no associated Service Code or are explicitly associated with the
Service Code value of zero."
==> Delete "have no associated Service Code or". As RFC4340 and this draft
state, every socket has at least one service code. An implementation may
choose to supply a default of zero, of course, but that still associates a
service code with the app
=> " RFC 4340 states that a Service Code MAY be associated with more than
one destination port (corresponding to a set of port values). Also a
single destination port MAY be associated with multiple Service
Codes, although an active (open) connection can only be associated
with a single Service Code. "
==> Actually, RFC4340 only explicitly says the second of these (that a single
passively opened port MAY have multiple SCs), although both are true.
5.1
=> I would cut this section. I disagree with it. In particular I do not
think we should recommend a change in the way OSes allocate DCCP port numbers.
6
=> It does not make sense to allocate a single PERF service code for a number
of different and incompatible applications ("e.g., iperf, ttcp, etc."). This
allocation should be dropped or made more specific.
Eddie
Gorry Fairhurst wrote:
I have just uploaded a new version of the Service Codes draft. The main
focus of this revision was to consolidate the text towards some
solutions (previous revisions included a range of options gathered from
the list and seeking to answer questions that were raised).
- Historical material was added.
- Comments from the list have been included.
The concept of adding weak semantics to a SC=0 was removed. This was
added at the request of implementers, with the aim of offering easier
implementation on at least one target platform. It has been removed
in this document because it weakens interoperability and complicates
the Spec.
The proposal to allow several levels of support was introduced in
previous drafts following suggestions from the WG, but was removed
in this revision. The method was seen to introduce complexity, and
resulted in complex interoperability scenarios.
- I removed the "test" method, this was no longer required.
- The draft was reorganized to improve clarity and simplify concepts.
Comments and questions relating to sections of this draft would be very
welcome,
best wishes,
Gorry
