Re: Gen-ART review of draft-ietf-dccp-serv-codes-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
----------------------------------------------------




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux