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?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
