Thanks for your comments, see below. Gorry
> 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. > 1) I'm not sure whether you are saying MPLS is robust to these effects *OR* that MPLS stacks have monitored for this case, e.g. do log such an unexpected VPN Identifier label, and somehow report this (and hence there is evidence that MPLS routers do not see such errors) > 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. > 2) On acceptability of residual corruption: I think I missed something - If you are saying that using Ethernet "bridging" is safe at L2, then that's not this discussion. I am interested in any experience that would help in understanding the impact of no checksum for IPv6, e.g. experience in how often the IPv4 checksum and IPv4/UDP checksum fail. 3) On practical rate of residual corruption: Is there experience of using MPLS/PWE across low-end and legacy routers? I am not aware of this, but I would be really interested in knowing more about the reliability across an end-to-end path i.e. PWE and MPLS through home gateways, firewalls, load-balancers, NAT and NAPT. What experience has the community seen? > 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. > 4) I disagree. > 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. > 5) It seems OK to note the new evidence for use within a well-managed domain, can you supply references to the usage and experience? I have a question: would the domain include host stacks and end-to-end usage or just carrier usage? > 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. > 6) I'm surprised/misunderstood - many deployed uses of the UDP transport have relied on the UDP cksum (more latterly this not been the advice of the IETF, but hard to enforce). Is this suggesting the IETF actually declare these (existing deployed IPv4) apps as unsuitable for use with IPv6 over the general Internet. That's NOT something I would personally like to do, have I understood correctly? > 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. > 7) The intent was not to change the semantic of the cksum for apps that expected the original behaviour. If you have an app that is willing to use no cksum - such as the tunnels - this may be fine, then I see two possibilities: It works (e.g. within a carrier network) or it may fail (e.g. via a NAPT/firewall that recalculates a cksum). I think it would be "nice" for the "app" to know it has UDP connectivity, but no UDP zero cksum connectivity - i.e. not just break when a route changes or a user moves to a new network. What do you suggest apps should do? > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
