Subject: :Some comments on: draft-eubanks-chimento-6man-00.txt

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 Mar 2009 10:32:32 +0000

Thanks for writing this. It is good to see some arguments recorded, and 
I hope we can now proceed to some useful debate and understanding of the 
problem and solution. UDP is specified as an Internet Area 
specification, and there are network issues (such as IP header 
integrity), but the impact of such a change also raises transport-layer 
issues. I have some comments from this perspective on the draft (below).

Best wishes,

Gorry

---
1) Page 2, 1.2

- While it is true that a UDP over IPv4 session can disable the 
checksum, this is not recommended (e.g. RFC 5405). So, although there is 
no protocol "problem", the case still needs to be made to show the 
protocol has been designed with appropriate checks!

---
2) Page 2, 1.3, bullet 2

- I am surprised that the need to compute and cache an internet checksum 
over one pseudo-header per socket (or transport flow) is regarded as a 
computationally intensive task. Is this really what is being asserted in 
the first point at the end of bullet 1?

- I'd like to see some clarification of the issues behind the statement 
that NAT-traversal for UDP-Lite/IPv6 causes "problems". Using (IPv6 over 
UDP with cksum=0) should also cause problems if a NAT is compliant to 
IPv6. If you change the protocol, you change the NAT behaviour. Is the 
difference only whether you change the protocol number?

---
3) Page 2, 1.3, bullet 4

- I find this concept troublesome, can you help? Does this solution 
presume that a sender targets an endpoint configured as a router? (see 
note 6 below)

---
4) Page 4, 1.4

- This is not so for IPv4. Using an outer encaps of (IPv4 over UDP with 
cksum=0) does provide checksum coverage of the length, transport 
protocol ID and the IP addresses in use. The IP checksum also provides 
some reassembly checks - if the ID fields are consistent. It does not 
verify the port values, nor payload correctness.

- This section does not point to a key issue (as on the list recently). 
This is the implications and detectability of mis-delivery of a packet 
to an incorrect endpoint/socket.

- Some time ago there was some research that showed malformed packets 
were circulating the internet, a side effect of broken internal 
processing in routers (this was not the first time this had been 
observed, although I suspect it is hard to quantify how often this 
happens). This is the sort of thing these checks are meant to cover, 
internal transfer errors in end host stacks and routers. When the 
checksum is used with UDP/IPv6, it significantly reduces the impact of 
undetected corruption of state (and data) on both the host stack and the 
applications using the transport service. UDP applications could add 
code to do these checks on ports, length, addresses (but many do not).

---
5) Page 5

- I think the draft says, you must not tunnel (IPv4 over UDP with 
cksum=0) over any tunnel where the outer header has no checksum. This 
seems reasonable. This draft then defines (IPv6 over UDP with cksum=0), 
I think this should this also be explicitly excluded?

- Is it possible that AMT could use (IPv6 over UDP with cksum=0) to 
transport IPv4 packets? - If so, what is the correct AMT behaviour when 
the tunnel has been forwarding a stream of inner packets using IPV4, 
then encounters a packet with an IPv4 UDP checksum disabled?

---
6) Page 5

- I do not understand how you can mandate different behaviour for hosts 
than routers? Do you think this differentiation is clear at a transport 
level? - endpoint stacks need to forward the IP packet and demux them to 
the transport. How does the transport stack then know whether to forward 
the packet to the application?
- One possibility could be that the "application relay" calls-down to 
change the non-default behaviour for the socket layer for this port to 
KNOW that this is supporting AMT?

---
7) Page 5

  - The decision to omit an integrity check at the IPv6 level means that 
the transport check is overloaded with many functions including:

* It validates the endpoint address was not corrupted within a router - 
this packet was meant for this destination and a wrong header has not 
been spliced to a different payload.
* It validates the extension header processing is correctly delimited - 
the start of data has not been corrupted. The protocol types does this 
also to some extent.
* It validates reassembly processing, when used.
* It validates the length field.
* It validates the ports have not been corrupted within a router - i.e. 
the correct application gets the payload (applications should also check 
source ports/address).
* It validates the payload integrity.

- In IPv4, the first 4 checks are made by the IPv4 header checksum.

- For v6 this checking occurs within the stack using the UDP cksum 
information. Simply using the IPv4 API to UDP would not require the 
stack or applications to CHECK many of the fields being received. So, a 
tunnel using the new method would really need to check the UDP port 
number against that specified for the IANA reserved value AMT control 
and data packets - would it also check sport and source IP?
- How should this be implemented, can you help me understand?

- I think the important issue here is to provide adequate checks if a 
packet is mis-delivered to a DIFFERENT port or a DIFFERENT endpoint to 
that originally intended, and whether applications running on these 
ports are sufficiently protected/robust to this.

---
8) Refs

Should this draft cite RFC 5405, which has things to say on UDP-based 
tunnels, on checksums, and the use of checksums by applications?