Thanks - this text was contributed quite a while ago, and it took me a
little while to work out what was intended. I suggest we delete the
problem paragraph, and that instead we replace the opening paragraph of
section 5 with:
"The security considerations of RFC 4340 identifies and offers guidance
on security issues relating to DCCP. This document discusses the usage
of Service Codes. It does not describe new protocol functions.
All IPsec modes protect the integrity of the DCCP header. This protects
the Service Code field from undetected modification within the network.
In addition, the IPsec Encapsulated Security Payload (ESP) mode may be
used to encrypt the Service Code field, hiding the Service Code value
within the network and also preventing interpretation by middleboxes.
The DCCP header is not protected by application-layer security, (e.g.,
the use DTLS [RFC5238] as specified in DTLS/DCCP [RFC4347]).
There are four areas of security that are important:"
- Would this address your comments?
Best wishes,
Gorry
---
Black_David@xxxxxxx wrote:
Gorry,
You've addressed everything except "this" one ;-) ...
** The last paragraph of Section 5.3 contains 2 sentences saying
that "this" is not an issue. It is not clear what "this" refers
to, making it impossible to determine what the issue might be.
In the last paragraph in Section 5.3, replace the "This" that
begins the paragraph with a specific phrase describing whatever
it is that is not an issue.
Thanks,
--David
-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx]
Sent: Monday, April 27, 2009 4:08 PM
To: Black, David
Cc: housley@xxxxxxxxxxxx; tphelan@xxxxxxxxxxxx;
lars.eggert@xxxxxxxxx; dccp@xxxxxxxx
Subject: Re: Gen-ART review of draft-ietf-dccp-serv-codes-08
David,
Many thanks for you review comments. These were all useful and have
resulted in the changes below. I am preparing an updated I-D
rev -09 to
include these changes.
---
Section 3.2: Middlebox [RFC3234] implementors therefore need to note
that new DCCP connections are identified by the pair of
Server Port and
Service Code. - Added "in addition to the IP address" to the
end of the
above sentence for clarity.
Section 3.2: Updated sentence to read: This means that the IANA may
allocate a server port to more than one DCCP application [RFC4340].
Section 3.3.2 Original sentence moved to previous section and this
section rewritten as: DCCP Service Codes are not restricted
to specific
ports, although they may be associated with a specific
well-known port.
This allows the same DCCP Service Code value to be associated with
more than one server port (in either the active or passive state).
Section 5.3: Added a new paragraph at start: The Internet Key
Exchange
protocol (IKEv2), does not currently specify a method to use DCCP
Service Codes as a part of the information used to setup an IPsec
security association.
---
In addition, a Security Directorate review also resulted in the
following helpful changes:
Section 5: Added one sentence at start: The security
considerations of
RFC 4340 identifies and offers guidance on security issues
relating to DCCP.
Section 5.2: Added one new paragraph at start of section: The use of
Service Codes provides more ready feedback that a concrete service is
associated with a given port on a servers, than for a service
that does
not employing service codes. By responding to an inbound connection
request, systems not using these codes may indicate that some service
is, or is not, available on a given port, but systems using this
mechanism immediately provide confirmation (or denial) that a
particular
service is present. This may have implications in terms of
port scanning
and reconnaissance.
---
I hope these address your comments, but if you have further
feedback or
other corrections, please do contact me.
Best wishes,
Gorry
Black_David@xxxxxxx wrote:
Gorry,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call
comments you may receive.
Document: draft-ietf-dccp-serv-codes-08
Reviewer: David L. Black
Review Date: April 14, 2009
IETF LC End Date: April 16, 2009
Summary:
This draft is on the right track, but has open issues, described
in the review.
Comments:
This draft expands the use of DCCP service codes, in essence
mandating that servers dispatch to DCCP services based on service
code *in addition* to server port (i.e., no longer dispatch only
on server port). In addition it defines a few basic DCCP services
that are useful for testing and benchmarking (e.g., chargen).
All of the points noted in this review are minor, but the ones
tagged below with ** are important. The problems with the
security considerations text in Section 5.3 are the primary
reason that the review summary is "open issues" rather than
"nits". This reviewer's expectation is that all of these
points will be relatively easy to address, but they do need
attention.
Table of Contents needs to be regenerated - not everything is
on p.4 ;-).
Section 3.2:
Middlebox [RFC3234] implementors
therefore need to note that new DCCP connections are
identified by
the pair of Server Port and Service Code.
Add "in addition to the IP address" to the end of the above
sentence for clarity.
** Section 3.2:
This means that the IANA
may allocate a server port to more than one application.
This sentence needs to be rephrased and extended, as this document
does not make any changes to the way that IANA currently allocates
server ports. The "may" above is susceptible to a misreading that
this draft does change IANA server port allocation procedures for
DCCP - another document would be necessary to make that change.
** Section 3.3.2 needs to be rewritten. It should be about
associating the same service code with multiple ports, but the
one and only sentence is about associating a port with multiple
service codes. The result of the rewrite should be that associating
the same service code with multiple ports is fine for both active
and passive ports - the passive case is of particular importance
to this draft.
** Section 5.3 needs to say something about extent of support (or
lack thereof) for DCCP in IKEv2. In particular, it is important
to state that IKEv2 as currently specified does not negotiate DCCP
service codes.
** The last paragraph of Section 5.3 contains 2 sentences saying
that "this" is not an issue. It is not clear what "this" refers
to, making it impossible to determine what the issue might be.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david@xxxxxxx Mobile: +1 (978) 394-7754
----------------------------------------------------
