Re: WGLC for draft-ietf-dccp-udpencap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

---







[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux