Sorry for the delay with my review.
Many times in the document NAT is cited as the reason for DCCP simultaneous
open, but really the reason is that some devices require connection to be
initiated by a 'trusted' host. This is true of host-based firewalls, the
default policy on many firewalls, and (due to port overloading) NAPTs. A
"traditional NAT" (which maps an IPv4 address 1-for-1 with another IPv4
address), does *not* need DCCP simultaneous open at all. It would be useful
to clarify the real requirement for DCCP simultaneous open in the
specification. I believe it is necessary if the DCCP server is, itself,
behind a NAT, and will only be effective if there is a way to communicate the
DCCP client's IP address and DCCP port out-of-band (e.g., SDP) -- yes?
The introduction mentions that DCCP simultaneous open can be disabled ("turned
off"). However, there is no further information regarding this. Is there a
reason why a DCCP stack would want to disable this functionality? As you
know, there is no way for a host to determine if specific communications might
be NATted, so it is difficult to say "turn it off if the host is not behind a
NAT".
Do both the DCCP client and DCCP server need to implement simul-open in order
for simultaneous open to be effective?
Specifics:
Section 1.2:
In this document we do not consider use of pre-configured, static NAT
address maps, which would also allow outside hosts to connect to the
private network in cases (2) and (3). ^^^^^^
^^^^^^
should be "to specific hosts in the"
A DCCP implementation conforming to [RFC4340] requires a relay server
to perform NAT traversal. The extension specified by this document
updates RFC 4340 to enable DCCP NAT traversal without the aid of
relay servers.
If the NAT is DCCP-aware (that is, supports draft-ietf-behave-dccp),
I believe a relay server is only necessary for cases (2) and (3). This
should be clarified via something like:
A DCCP implementation conforming to [RFC4340] and a NAT conforming
to draft-ietf-behave-dccp would require a DCCP relay server to perform
NAT traversal for cases (2) and (3). The extension specified by
this document updates RFC 4340 to enable DCCP NAT traversal without
the aid of DCCP relay servers.
Section 2.2:
The figure has its bit numbers mis-aligned by one character.
At the time of writing. there areo known uses of the header option
^^^^
"are no" ??
([RFC4340], sec. 5.8) with a DCCP-Listen packet.
later,
Servers SHOULD set both Sequence Number fields to 0; clients MUST
ignore the value of the Sequence Number fields; and middleboxes MUST
NOT interpret sequence numbers on DCCP-Listen packets.
This seems counter to RFC4340's requirement that initial sequence
numbers be chosen randomly. It would be useful to point out that
the sequence number of the DCCP-Listen packet has no relationship
with the initial sequence number; a forward pointer to the design
decisions section could be further help. Something like:
The sequence number of a DCCP-Listen packet is not related to
the DCCP sequence number for normal DCCP messages. Thus, for
DCCP-Listen packets, servers SHOULD set both Sequence Number
fields to 0; clients MUST ignore the value of the Sequence Number
fields; and middleboxes MUST NOT interpret sequence numbers on
DCCP-Listen packets.
I'm not sure why middlebox interpretation is a MUST NOT; could this be
explained? Is it to allow future use of different values?
The end of Section 2.2 cites SDP, which is RFC4566, which needs to
be added to the informational references.
Section 2.3.1,
The server SHOULD repeat sending a DCCP-Listen packet while in state
INVITED, at a 200 millisecond interval and up to at most 2
repetitions (Section 3 discusses this choice of timer interval). The
retransmission timer is restarted with the same 200ms interval after
the second retransmission. When, upon the next timeout, the server
is still in the INVITED state, it SHOULD progress to LISTEN, and
resume processing as specified in [RFC4340].
I found the paragraph above confusing. The first sentence says
"send DCCP-Listen, wait 200ms, send another DCCP-Listen, wait 200ms,
send another DCCP-Listen." The second sentence then appears to
say the retransmission timer is restarted with the same 200ms
value (but the value didn't previously change!). I can't
follow the intent. I read section 3.3, too, and I cannot figure
out how many packets are really supposed to be sent. Section
3.3 says: "recommend a maximum number of 3 timeouts (2
repetitions) results from the following considerations.".
Server endpoints SHOULD in general ignore any incoming DCCP-Listen
packets. As an exception to this rule, a DCCP Server in state LISTEN
MAY generate a Reset (Code 7, "Connection Refused") in response to a
DCCP-Listen packet.
This should more clearly indicate it is a DCCP Reset.
This Reset is an indication that two servers are
simultaneously awaiting connections on the same port.
Fully-specified server endpoints SHOULD treat ICMP error messages
received in response to a DCCP-Listen packet as "soft errors" that do
not cause a state transition.
It would be useful to discuss why this is a SHOULD -- perhaps
in the Design Decisions section. I believe it allows two hosts to
do a simultaneous DCCP open, when those hosts are directly connected
(that is, without a draft-ietf-behave-dccp-compliant NAT between
them).
Section 3.1, Rationale for a New Packet Type
The last two paragraphs discuss why DCCP-Listen sequence
numbers are ignored and why they were retained. This discussion
belongs in a different (new?) section, because it is really
explaining the design decision *of* the DCCP-Listen packet
type, rather than why a new packet type was necessary.
Section 4, Security Considerations
The technique specified in this document exposes the state of a DCCP
server that has been explicitly pre-configured to accept a connection
from a known client.
I would not characterize SDP signaling as "pre-configured". How
about simply 'signaled'.
Later in that same paragraph, SIP is cited, whereas earlier in
the document SDP was cited. SDP is used by SIP and RTSP, and seems
the better reference.
I believe that [NAT-APP] has been abandoned. (I'm not saying drop
the reference, I just wanted to point it out.)
-d
