Dan Wing wrote:
Sorry for the delay with my review.
Thanks Dan for doing this. I think you reading has been very helpful,
and the result will hopefully be a much improved document that is easier
to read and much more clear.
Your different perspective has inspired a restructuring of the document.
I hope to have a new version soon that will address the issues you and
Tom have raised.
I include some specific responses in-line. I will also revise the document.
Gorry
-----
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.
>
OK. The restructuring will hopefully address this.
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?
Yes, updated as above.
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".
OK will reword. The only issue I can think of relates to security
policy, as mentioned in the security considerations.
NEW:
The use of a dedicated DCCP packet type, ties usage to a specific
condition, ensuring the method is inter-operable with hosts that do not
implement this update, or disable it. (e.g. DCCP servers that employ a
secuirty where they do not wish to disclose the port on which they are
listening can refrain from generating DCCP-Listen packets, without
impacting subsequent DCCP state transitions.)
Do both the DCCP client and DCCP server need to implement simul-open in order
for simultaneous open to be effective?
No. That was bad text, also noted by Tom Phelan. We've fixed this. The
opening text will now read:
NEW:
"This method is useful in scenarios when a DCCP server is located behind
a middlebox (e.g. host-based firewalls, the default policy on many
firewalls, and (due to port overloading) NAPTs)."
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). ^^^^^^
^^^^^^
This section has now been rewritten.
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.
Changed to your text.
Section 2.2:
The figure has its bit numbers mis-aligned by one character.
Fixed, glad someone spotted that.
At the time of writing. there areo known uses of the header option
^^^^
"are no" ??
([RFC4340], sec. 5.8) with a DCCP-Listen packet.
Fixed.
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 have implemented these changes.
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 field as specified has no meaning, always zero. There is therefore
no need to read the field, and avoid assuming special semantics. As
specified, clients MUST also ignore.
The end of Section 2.2 cites SDP, which is RFC4566, which needs to
be added to the informational references.
Done.
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.".
AH, then we should re-write:
NEW:
"The server SHOULD repeat sending a DCCP-Listen packet while in the
INVITED state, at a 200 millisecond interval and up to at most 2
repetitions ([ref] discusses this choice of timer interval). If the
server is still in the INVITED state after a further period of 200ms
following transmission of the second DCCP-Listen packet, it SHOULD
progress to the LISTEN state, and resume processing as specified in
[RFC4340]. This be implemented using a retransmission timer for the
INVITED state. The timer is restarted after sending each DCCP-Listen
packet, with an interval of 200ms. It is cancelled when the server
leaves this state. The first and second expiry of this timer trigger
transmission of the DCCP-Listen Packet. A third expiry of the timer
results in the server progressing to the LISTEN state.
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.
Agree. This and other instances have been corrected.
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).
NEW:
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. Reception of an ICMP error message as a
result of sending a DCCP-Listen packet does not necessarily indicate a
failure of the following connection request, and therefore should not
result in a server state change. This reaction to soft errors exploits
the valuable feature of the Internet that for many network failures, the
network can be dynamically reconstructed without any disruption of the
endpoints.
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.
Done.
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 agree. Suggest:
"The technique specified in this document exposes the state of a DCCP
server that is waiting to accept a connection from a known client.
Establishing this state requires prior out-of-band signalling between
the client and server (e.g. SDP [RFC4566] information communicated via
the Session Initiation Protocol [RFC3261]).
I believe that [NAT-APP] has been abandoned. (I'm not saying drop
the reference, I just wanted to point it out.)
OK - useful to know.
-d
