Last Call Review of draft-ietf-dccp-serv-codes-
review-ietf-dccp-serv-codes-secdir-lc-kelly-2009-04-24-00

Request Review of draft-ietf-dccp-serv-codes
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-05
Requested 2009-04-02
Authors Gorry Fairhurst
Draft last updated 2009-04-24
Completed reviews Secdir Last Call review of -?? by Scott Kelly
Assignment Reviewer Scott Kelly
State Completed
Review review-ietf-dccp-serv-codes-secdir-lc-kelly-2009-04-24
Review completed: 2009-04-24

Review
review-ietf-dccp-serv-codes-secdir-lc-kelly-2009-04-24

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document clarifies the use of service codes in DCCP. It does not
define new protocol elements, but instead adds detail that is not
present in RFC 4340 ("Datagram Congestion Control Protocol (DCCP)")

The security considerations section discusses 4 areas of interest:

  - Server Port number reuse

  - Interaction with NATs and firewalls

  - Interpretation of DCCP Service Codes over-riding traditional use
      of reserved/Well Known port numbers

  - Interaction with IPsec and DTLS security

I have a couple of minor comments: first, it might be good to explicitly
refer to RFC 4340, which has its own security considerations section,
since the things discussed there are not discussed here.

The second comment relates to the fact that servers supporting these
service codes give concrete service identification for a given port more
readily than servers 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.

--Scott