> 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
