... > 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. Looks good to me. Thanks. > >>> 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. I read this section again, and I think if you just stuck consistently with talking about when a retransmission occured, or when a timer expired, or when you wait, the text would be clearer. I got confused with "first repetition" and "first expiration" -- which is the same time that the second packet (=first retranmission) is sent. > >> 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. thanks. > > > >> 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. Ok, thanks for letting me know. -d
