Re: [dccp] WGLC for draft-ietf-dccp-udpencap
The WGLC has now concluded, thanks to everyone who sent comments! Gorry already provided a good summary, and an updated version of the draft that should address most of the comments. I'm proposing that the next steps would be as follows: * The draft will be discussed in the MMUSIC group in Prague, to get additional input about the SDP part. If the current text is ok (possibly with minor modifications), I will proceed with write-up and publication request. * If it seems that more work is needed on SDP and signaling, we'll need to think about the possible options. I'm not thrilled about the idea of taking much more time just for tuning SDP (on which this group might not have perfect expertise). In that case, we might consider the option of having this draft focus just on the UDP encapsulation of DCCP, and separate the signaling part into a different document. But let's see the MMUSIC feedback first. - Pasi On Feb 25, 2011, at 12:56 PM, Pasi Sarolahti wrote: Hi, This mail starts a working group last call for the UDP encapsulation draft. The draft is available at http://tools.ietf.org/html/draft-ietf-dccp-udpencap-06 . Please read the draft and send any comments to the DCCP mailing list. The WGLC lasts for two weeks, until March 11. - Pasi
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
How about the destination ports need to match and we don't worry as much about the source ports? If we have to have specify both the udp and dccp destination port, I have no idea how existing applications are going to be able to easily use this. What would you even put in a DNS SRV record. On Mar 3, 2011, at 2:48 AM, Pasi Sarolahti wrote: Hi Cullen, (cc:ing dccp mailing list as well) The dccp/udp port issues were discussed in the DCCP WG some time ago. With the source port one problem is that a NAT could change the UDP port but not the inner DCCP port. There were opinions for keeping the two port spaces separate, to support tunneling scenarios through a well-known UDP port at the server end. - Pasi On Mar 2, 2011, at 11:35 PM, Cullen Jennings wrote: I'm wondering what would be the downside of saying the UDP source / dest port had to match the DCCP source and dest port? This would make it much easier to figure out hot to integrate this into something like ICE or decide what UDP and DCCP ports one uses for a URL like sip:example.com:5060
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
Hi Cullen, (cc:ing dccp mailing list as well) The dccp/udp port issues were discussed in the DCCP WG some time ago. With the source port one problem is that a NAT could change the UDP port but not the inner DCCP port. There were opinions for keeping the two port spaces separate, to support tunneling scenarios through a well-known UDP port at the server end. - Pasi On Mar 2, 2011, at 11:35 PM, Cullen Jennings wrote: I'm wondering what would be the downside of saying the UDP source / dest port had to match the DCCP source and dest port? This would make it much easier to figure out hot to integrate this into something like ICE or decide what UDP and DCCP ports one uses for a URL like sip:example.com:5060
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
On 28/02/2011 21:42, Dan Wing wrote: The purpose of this IANA-assigned port is for the OS or a framework to receive and process DCCPoUDP messages for delivery to the DCCP stack on the host. This port SHOULD NOT be used by an application doing DCCPoUDP encapsulation, because it prevents another application from also doing the same thing. I propose this text added as para two of section 3.8: The purpose of this IANA-assigned port is for the operating system or a framework to receive and process DCCP-UDP datagrams for delivery to the DCCP module. This port SHOULD NOT be used as a Source UDP Port by an application performiung DCCP-UDP encapsulation, because this would prevent another application from also doing the same thing. Gorry
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
Thanks Dan and Remi !!! It was great to have feedback on this draft from other perspectives. 1-5 relate to RTP/SDP usage, these have not yet been addressed. Including, + Remi's email of 28/02/2011. + An example SDP probably wouldn't hurt. I will need help from the WG with this. I've responded to the transport protocol related issues below, Gorry 6. The Encapsulated Port Reuse is defined in a section titled DCCP Reset, which is confusing. Please fix. Resolved. 7. The Encapsulated Port Reuse seems very scary, as I could spoof it -- it contains only three bytes: the DCCP packet type (1 byte) and UDP port number (2 bytes). This is insufficient considering its impact to an ongoing DCCP connection. More information needs to be included in the payload to prevent off-path attackers from abusing this. Resolved - text changed to avoid future confusion. 8. Section 3.6, ICMP handling for messages relating to DCCP-UDP, it seems there could be a problem if the ICMP error is the minimum length (which means it only indicates the UDP port number) but multiple DCCP sessions are mux'd inside of it. My reading of 3.8, and the assignment of a single port for DCCP-over-UDP, is that it is possible and encouraged to have multiple DCCP sessions running over a single UDP port. This problem with short ICMP errors should be pointed out in the ICMP section. Propose: The minimal length ICMP error message generated in response to processing a UDP Datagram only identifies the Source UDP Port and Destination UDP Port. The ICMP message does not carry sufficient information to discover the encapsulated DCCP Port values. A DCCP-UDP endpoint that supports multiple DCCP connections over the same pair of UDP ports (see section xref target=port) may not therefore be able to associate an ICMP message with a unique DCCP-UDP connection. 9. Section 3.7, Path Maximum Transmission Unit Discovery, needs to remind implementers to consider the UDP overhead when doing PMTUD. Done, and also noted reduced DCCP MPS. 10. Section 3.3.1, partial checksums. Do NATs support partial checksums, or do some of them drop UDP packets with bad checksums? RFC4787 is silent (on purpose, as I recall). Indeed :-) I'm not sure what change you suggest, but propose the following updated text to replace section 3.3.1 to improve clarity: This document describes an encapsulation for DCCP that uses the UDP transport. It requires that the UDP checksum to be enabled. This checksum provides coverage of the entire encapsulated DCCP datagram. DCCP-UDP supports the syntax of partial checksums. It also supports negotiation of the Minimum Checksum Coverage feature and settings of the CsCov field. However, the UDP checksum field in DCCP-UDP always covers the entire DCCP datagram and the DCCP checksum is ignored on receipt. An application that enables the partial checksums feature in the DCCP Module will therefore experience a service that is functionally identical to using full DCCP checksum coverage. This is also the service that the application would have received if it had used a network path that did not provide optimised processing for DCCP partial checksums. ---
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
The minimal length ICMP error message generated in response to processing a UDP Datagram only identifies the Source UDP Port and Destination UDP Port. The ICMP message does not carry sufficient information to discover the encapsulated DCCP Port values. A DCCP-UDP endpoint that supports multiple DCCP connections over the same pair of UDP ports (see section xref target=port) may not therefore be able to associate an ICMP message with a unique DCCP-UDP connection. Perfect. Thanks. 9. Section 3.7, Path Maximum Transmission Unit Discovery, needs to remind implementers to consider the UDP overhead when doing PMTUD. Done, and also noted reduced DCCP MPS. 10. Section 3.3.1, partial checksums. Do NATs support partial checksums, or do some of them drop UDP packets with bad checksums? RFC4787 is silent (on purpose, as I recall). Indeed :-) I'm not sure what change you suggest, but propose the following updated text to replace section 3.3.1 to improve clarity: This document describes an encapsulation for DCCP that uses the UDP transport. It requires that the UDP checksum to be enabled. This checksum provides coverage of the entire encapsulated DCCP datagram. DCCP-UDP supports the syntax of partial checksums. It also supports negotiation of the Minimum Checksum Coverage feature and settings of the CsCov field. However, the UDP checksum field in DCCP-UDP always covers the entire DCCP datagram and the DCCP checksum is ignored on receipt. An application that enables the partial checksums feature in the DCCP Module will therefore experience a service that is functionally identical to using full DCCP checksum coverage. This is also the service that the application would have received if it had used a network path that did not provide optimised processing for DCCP partial checksums. Perfect. Thanks. -d
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
Hello, One of the DCCP charis asked me to review draft-ietf-dccp-udpencap-06. So here comes a bunch of comments: * The SDP support really ought to use a different protocol in the m=field. This stuff is not DCCP. * An example SDP probably wouldn't hurt. * This specification is relevant not only to NAT(/firewall) traversal, but also to implementating DCCP within an application with support from the TCP/IP stack. This seems entirely absent. * A proposed integration with the socket API would not hurt either. Then again, it is true that there is no proposed socket API for DCCP at all in IETF :-( * I find the two pairs of port numbers objectionable. Inner port numbers make sense for network-layer tunneling (e.g. Teredo, IPsec over UDP...). But it is counter-intuitive and needless complicated for transport-layer encapsulation. Existing RTP/SDP applications (the main use case for DCCP) have no provisions for two pairs of port numbers, and two layers of demultiplexing. (For example, VLC media player parses the SDP m= and c= lines into a sockaddr, this is impossible with two level of port numbers). * I don't see much value for a standardized IANA port allocation here. In fact, it might do more harm than good with some braindead port-preserving NATs: random source port are more likely to work there. Best regards, -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
Thanks for your comments, I can reply - but I will need others in the WG to chime-in on these topics. On 28/02/2011 10:58, Rémi Denis-Courmont wrote: Hello, One of the DCCP charis asked me to review draft-ietf-dccp-udpencap-06. So here comes a bunch of comments: * The SDP support really ought to use a different protocol in the m=field. This stuff is not DCCP. I need help from SDP people on this comment - the idea was that this looked like DCCP to the app. * An example SDP probably wouldn't hurt. It would be really good, can someone offer such an example please? * This specification is relevant not only to NAT(/firewall) traversal, but also to implementating DCCP within an application with support from the TCP/IP stack. This seems entirely absent. It has been mentioned in the past, and we could add some text to the motivation to explain this. Any thoughts from others? * A proposed integration with the socket API would not hurt either. Then again, it is true that there is no proposed socket API for DCCP at all in IETF :-( Indeed, and I'd assume any DCCP API could describe this. I hope you're expecting me to say that this should be in another draft. * I find the two pairs of port numbers objectionable. Inner port numbers make sense for network-layer tunneling (e.g. Teredo, IPsec over UDP...). But it is counter-intuitive and needless complicated for transport-layer encapsulation. Existing RTP/SDP applications (the main use case for DCCP) have no provisions for two pairs of port numbers, and two layers of demultiplexing. This topic was discussed at length on the list, and resulted in the two approaches outlined. I'm not sure what to add. (For example, VLC media player parses the SDP m= and c= lines into a sockaddr, this is impossible with two level of port numbers). * I don't see much value for a standardized IANA port allocation here. In fact, it might do more harm than good with some braindead port-preserving NATs: random source port are more likely to work there. The assigned ports may be important for apps that don't use SDP and need to communicate with a listening server. I'm guessing that SDP-based apps may not need this. Best regards, Gorry
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
This mail starts a working group last call for the UDP encapsulation draft. The draft is available at http://tools.ietf.org/html/draft-ietf- dccp-udpencap-06 . Please read the draft and send any comments to the DCCP mailing list. 1. I agree with Rémi Denis-Courmont's comment that a new m= line needs to be defined. However, that might be best done separately by the MMUSIC working group? 2. This is also something that might be best done by MMUSIC, who owns ICE: Currently the text just says: Procedures for handling DCCP-STD and/or DCCP-UDP with Interactive Connectivity Establishment (ICE) may need to be developed, but are left for further work. This can be tightened up a bit. Currently, the text implies a=dccp-in-udp indicates the offerer supports dccp-over-UDP and The presence of a=dccp-in-udp conveys no information about whether or not the offerer is listening for DCCP-STD connections -- which is fine, but there is no way for the other party to determine if, in fact, DCCP is supported. There needs to be some sort of liveliness check for that. We have the same problem with IPv4/IPv6 selection (which is what prompted us to write draft-wing-v6ops-happy-eyeballs-ipv6) and we have the same problem with TCP/SCTP selection (which is what prompted us to write draft-wing-tsvwg-happy-eyeballs-sctp). For offer/answer protocols like SIP, ICE (RFC5245) should be recommended. So, I suggest: When an SDP contains m=DCCPoUDP (*), it indicates the sender supports DCCP over UDP, and that the sender might also be expecting native DCCP packets (DCCP-STD) on that same DCCP port number. Because native DCCP packets have less overhead, it is desirable to use that encapsulation when possible. To do this, ICE [RFC5245] is RECOMMENDED, following the ICE extensions described in Section X.Y. Then, you'll need a section X.Y which says something like: This document updates ICE [RFC5245] with a new transport-extension: transport-extension =/ dccpoudp (*) (*) or whatever is the result of (1). I believe that is all that's necessary to extend ICE to support DCCP. However, the MMUSIC working group may have better input on that. (I am probably over-simplifying, considering a separate document was necessary to explain ICE with TCP...) 3. The limitation at the end of section 5 is unsatisfying: The new SDP attribute specified in this section is expected to be useful when the offering party is on the public Internet, or in the same private addressing realm as the answering party. Some other NAT/NAPT topologies may result in the advertised port being unreachable via the NAT/NAPT. afterall, if everybody is on the Internet and not behind a NAT, we wouldn't need DCCPoUDP at all! :-) 4. the text for a=dccp-in-udp, or whatever is chosen for the m= line, needs to apply to both the offerer and answerer. Currently the text says this has meaning for the offerer and (due to its silence about the answerer) implies the answerer cannot use that attribute or that the answerer using that attribute has no meaning. 5. For RTP, what is supposed to happen when the Encapsulated Port Reuse is received? 6. The Encapsulated Port Reuse is defined in a section titled DCCP Reset, which is confusing. Please fix. 7. The Encapsulated Port Reuse seems very scary, as I could spoof it -- it contains only three bytes: the DCCP packet type (1 byte) and UDP port number (2 bytes). This is insufficient considering its impact to an ongoing DCCP connection. More information needs to be included in the payload to prevent off-path attackers from abusing this. 8. Section 3.6, ICMP handling for messages relating to DCCP-UDP, it seems there could be a problem if the ICMP error is the minimum length (which means it only indicates the UDP port number) but multiple DCCP sessions are mux'd inside of it. My reading of 3.8, and the assignment of a single port for DCCP-over-UDP, is that it is possible and encouraged to have multiple DCCP sessions running over a single UDP port. This problem with short ICMP errors should be pointed out in the ICMP section. 9. Section 3.7, Path Maximum Transmission Unit Discovery, needs to remind implementers to consider the UDP overhead when doing PMTUD. 10. Section 3.3.1, partial checksums. Do NATs support partial checksums, or do some of them drop UDP packets with bad checksums? RFC4787 is silent (on purpose, as I recall). -d
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
-Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Gorry Fairhurst Sent: Monday, February 28, 2011 10:23 AM To: dccp@ietf.org; r...@remlab.net Subject: Re: [dccp] WGLC for draft-ietf-dccp-udpencap Thanks for your comments, I can reply - but I will need others in the WG to chime-in on these topics. On 28/02/2011 10:58, Rémi Denis-Courmont wrote: Hello, One of the DCCP charis asked me to review draft-ietf-dccp-udpencap- 06. So here comes a bunch of comments: * The SDP support really ought to use a different protocol in the m=field. This stuff is not DCCP. I need help from SDP people on this comment - the idea was that this looked like DCCP to the app. * An example SDP probably wouldn't hurt. It would be really good, can someone offer such an example please? * This specification is relevant not only to NAT(/firewall) traversal, but also to implementating DCCP within an application with support from the TCP/IP stack. This seems entirely absent. It has been mentioned in the past, and we could add some text to the motivation to explain this. Any thoughts from others? * A proposed integration with the socket API would not hurt either. Then again, it is true that there is no proposed socket API for DCCP at all in IETF :-( Indeed, and I'd assume any DCCP API could describe this. I hope you're expecting me to say that this should be in another draft. * I find the two pairs of port numbers objectionable. Inner port numbers make sense for network-layer tunneling (e.g. Teredo, IPsec over UDP...). But it is counter-intuitive and needless complicated for transport- layer encapsulation. Existing RTP/SDP applications (the main use case for DCCP) have no provisions for two pairs of port numbers, and two layers of demultiplexing. This topic was discussed at length on the list, and resulted in the two approaches outlined. I'm not sure what to add. (For example, VLC media player parses the SDP m= and c= lines into a sockaddr, this is impossible with two level of port numbers). * I don't see much value for a standardized IANA port allocation here. In fact, it might do more harm than good with some braindead port- preserving NATs: random source port are more likely to work there. The assigned ports may be important for apps that don't use SDP and need to communicate with a listening server. I'm guessing that SDP-based apps may not need this. Please add text making that clear. Something along the lines of: The purpose of this IANA-assigned port is for the OS or a framework to receive and process DCCPoUDP messages for delivery to the DCCP stack on the host. This port SHOULD NOT be used by an application doing DCCPoUDP encapsulation, because it prevents another application from also doing the same thing. -d
Re: [dccp] WGLC for draft-ietf-dccp-udpencap
The draft looks good! (There's one nit -- in S4 Encapsulations should be Encapsulation -- but good.) Eddie On 2/25/11 2:56 AM, Pasi Sarolahti wrote: Hi, This mail starts a working group last call for the UDP encapsulation draft. The draft is available at http://tools.ietf.org/html/draft-ietf-dccp-udpencap-06 . Please read the draft and send any comments to the DCCP mailing list. The WGLC lasts for two weeks, until March 11. - Pasi
