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.
---
