Stewart Bryant has entered the following ballot position for draft-ietf-6man-udpzero-06: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This discuss applies to both this draft and draft-ietf-6man-udpchecksums-04 Fundamentally I support the liberalization of the position regarding IPv6 UDP checksums when UDP is used for tunnels and hope to get to a yes position on both drafts. However, there is some text that needs discussion, and then we need to discuss the consequences of that discussion. The rational for the slightly conservative position taken in the case of tunnels seems to based on the following text: "IP packets may be corrupted as they traverse an Internet path. Evidence has been presented [Sigcomm2000] to show that this was once an issue with IPv4 routers, and occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the link-layer [RFC3819]. There is no current evidence that such cases are rare in the modern Internet, nor that they may not be applicable to IPv6. It therefore seems prudent not to relax this constraint. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 further motivate the need to protect from this type of error." However we do have a body of evidence that is not discussed in the document. Firstly we have a decade of experience with MPLS VPNs where the VPN Identifier label, which is used to steer the traffic to a particular customer network (i.e. is functionally equivalent to an address), is not protected by a checksum. I am not aware of any concerns expressed by operators in this regard, and I am not aware of any work in the MPLS WG to introduce checksum like protection. We also have a decade of experience with pseudowires. With one exception that we will discuss in a minute, none of the PW designs have any form of data integrity protection other than the CRC imposed by the network datalink at each hop. In the specific case of the Ethernet PW, there are two modes: one in which the CRC is stripped at ingress to the PW and recalculated at egress, and another where it is preserved end to end. There is very little, if any, deployment of the end to end CRC preservation mode. Given that there must be some low level of corruption of the frames, I would conclude that the protocols that are likely to be tunneled are sufficiently hardened that the occasional corruption is of no practical consequence. Thus I would conclude that the level of corruption is sufficiently rare and of sufficiently minor consequence that at least in the case of service provider networks implementing UDP tunneling, it is safe to omit the UDP checksum without analysis of the application. I would propose that the text should include some acknowledgement of this recent body of evidence and that the recommendation be aligned in consequence to unconditionally allow C/S free tunneling, at least within a well managed domain without additional consideration. Section 5.1 seems to be duplicated in the two drafts. It would be better if the text were just in one RFC and the other pointed to it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You also note that an application may rely on the checksum to protect it against packets that may damage it. I find this very weak argument, since such an application would be vulnerable to packets deliberately malformed by an attacker, or malformed by a software bug in a peer. The correct approach is surely to harden the application, and thus the checksum argument is not persuasive. You note the need to signal the agreement not to use c/s, I think that you need to include the configuration of this property as an alternative, and note that configuration may be implicit in the definition of the UDP payload. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
