Thanks for these comments.
Dan Wing wrote:
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.)
I think this over-states the risk of a server sending a
DCCP-Listen.
A DCCP-Listen is only sent if the DCCP server knows the IP address
and DCCP port of an impending DCCP client connection attempt. Does
an attacker learn anything by seeing the DCCP server emit a
DCCP-Listen packet a few milliseconds before the incoming DCCP-
Request?
The only thing I believe an attacker would learn is the IP address
and DCCP port of the impending DCCP-Request. With that knowledge,
the attacker could spoof that IP address and DCCP port and thus
successfully spoof being that DCCP client endpoint. This would
require the attacker to be on-path between the DCCP server and DCCP
client (in order to see the DCCP-Listen packet).
Contrast that to the situation where DCCP-Listen is not sent. In
that situation, the attacker would have to be on-path between the
DCCP client and the DCCP server, and the attacker would have to
destroy the DCCP-Request packet (e.g., invalidate its Ethernet
checksum) and generate its own DCCP-Request by spoofing the
IP address and DCCP port.
So, I believe the real risk of sending the DCCP-Listen is that
it creates an opportunity for an on-path attacker to spoof the
DCCP client if that attacker is on-path between the DCCP server
and the DCCP client.
Sending DCCP-Listen only increases the attack surface if there
is asymmetric routing between the DCCP client and server.
And if my analysis is wrong, I am sure someone will correct me.
...
Yes. I was trying to explain a reason why the server may not do this,
but I think you are correct and I just over-emphasised this. I now think
this discussion belongs only in the security section.
I'd prefer:
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 (see Section 4).
Following this discussion, I have now re-writen the security
considerations section, replacing the entire text with the sugessted
text below.
NEW:
The method specified in this document generates a DCCP-Listen packet
addressed to a specific DCCP client. This exposes the state of a DCCP
server that is in a passive listening state (i.e. waiting to accept a
connection from a known client).
The exposed information is not encrypted and therefore could be seen on
the network path to the DCCP client. An attacker on this return path
could observe a DCCP-Listen packet and then exploit this by spoofing a
packet (e.g. DCCP-Request, DCCP-Reset) with the IP addresses, DCCP
ports, and service code that correspond to the values to be used for the
connection. As in other on-path attacks, this could be used to inject
data into a connection or to deny a connection request. A similar
on-path attack is also possible for any DCCP connection, once the
session is initiated by the client (RFC4340, Section 18).
The DCCP-Listen packet is only sent in response to explicit prior
out-of-band signaling from a DCCP client to the DCCP server (e.g. SDP
[RFC] information communicated via the Session Initiation Protocol
[RFC]), and will normally directly precede a DCCP-Request sent by the
client (which carries the same information).
This update does not significantly increase the complexity or
vulnerability of a DCCP implementation that conforms to RFC4340. A
server SHOULD therefore by default permit generation of DCCP-Listen
packets. A server that wishes to prevent disclosing this information MAY
refrain from generating DCCP-Listen packets, without impacting
subsequent DCCP state transitions, but possibly inhibiting middlebox
traversal.
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).
That is a total of three packets, right?
Yes.
send packet, wait 200ms
send packet, wait 200ms <--- "first repetition" (first expiration)
send packet <--- "second repeition" (second expiration)
Yes.
I can add a similar picture, if this helps.
If the
server is still in the INVITED state after a further period of 200ms
following transmission of the second DCCP-Listen packet,
^^^^^^
"third"
Yes, "third packet" (i.e. second copy). I'll check this and will fix.
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.
Thanks.
By the way, I noticed some inconsistency between "fully-specified"
and "fully specified" (no hyphen) throughout the document.
Thanks, will also be fixed.
-d
Note: this set of comments address issues that were not yet addressed
in the recently updated rev -03, but will be addressed in rev -04.
Gorry
