Hi, Only having thought about this shortly, I think this is reasonable to add. I might have another opinion when we actually start writing it. But in that case I will come back and tell why I have another opinion.
Cheers Magnus On 2012-10-11 04:05, Ronald Bonica wrote: > Magnus, > > I think that we are on the same page and I am nearly ready to clear my > DISCUSS. > > Would you be willing to add a short section in an Appendix that illustrates > the kind of analysis that you are requiring of a protocol that wants to rely > on UDPZero? I am thinking of something like the following: > > Sample Text > =========== > Protocol Foo encapsulates an IP datagram within the following: > > - a foo header > - a UDP header > - an outer IPv6 header > > Because the UDP checksum is set to zero, the following fields are unprotected: > > - foo header: field1 > - foo header: field2 > - UDP header: source port > - UDP header: destination port > - outer IPv6 header: source address > - outer IPv6 header: destination address > > The consequence of corruption in field1 of the foo header is mumble. The > consequence of corruption in field2 of the foo header is grumble, but only if > some other condition is true. The consequence of corruption in any other > field is, at worst, loss of the packet. > > Assume a tunnel with the following characteristics: > > - sustained data rate of 1 Gbps > - Bit error rate of 10**-12 on each of 4 constituent links > - average packet size equal to 1500 bytes > > The bullet list, below, provides an estimate of the frequency with which each > of the above mentioned fields will be corrupted: > > - foo header: field1 (once per N seconds) > - foo header: field2 (once per N seconds) > - UDP header: source port (once per N seconds) > - UDP header: destination port (once per N seconds) > - outer IPv6 header: source address (once per N seconds) > - outer IPv6 header: destination address (once per N seconds) > > ========================== > End sample text > > Does this sound reasonable? > > Ron > > > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerl...@ericsson.com] >> Sent: Wednesday, October 10, 2012 4:59 AM >> To: Ronald Bonica >> Cc: The IESG; 6man-cha...@tools.ietf.org; draft-ietf-6man- >> udpz...@tools.ietf.org; ipv6@ietf.org >> Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: >> (with DISCUSS) >> >> On 2012-10-09 20:57, Ronald Bonica wrote: >>> Ronald Bonica 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 is a two-part DISCUSS-DISCUSS. Both parts relate to bullet >> points >>> in Section 5.1. >>> >>> Bullet 5 >>> ====== >>> "Tunnels that encapsulate IP may rely on the inner packet >>> integrity checks provided that the tunnel will not significantly >>> increase the rate of corruption of the inner IP packet." >>> >>> - What does it mean to *significantly* increase the rate of >> corruption >>> of the inner IP packet? >> >> That is a good question. And the answer is it depends. If you are >> considering a tunnel protocols which target deployment area is one >> where you have very low rates of corruption, lets say below 10^-6 then >> a factor of 2 or even 10 might be fine as the resulting end-to-end >> basic IP service may still be fine. But if that same tunnel is supposed >> to support something that requires a packet loss rate below 10^-6 then >> any increase in corruption might be to high. >> >>> - Shouldn't we also be concerned about corruption of the UDP header >>> and any additional encapsulation that comes between the UDP header >> and >>> the inner IP packet? >> >> I think the formulation actually is considering that. If the >> IPv6/UDP/FOO tunnel protocol carries IP and FOO is senesitive to >> corruption then isn't the payload of the tunnel, i.e. the inner IP >> going to suffer an increased corruption rate. >> >>> - How does a tunnel ingress node know whether the tunnel will >>> significantly increase the rate of corruption of the inner IP packet? >> >> That is something you have to statistically analyze when designing the >> protocol and deciding on using zero-checksum. >> >>> >>> Bullet 7 >>> =====- >>> " UDP applications that support use of a zero-checksum, should not >>> rely upon correct reception of the IP and UDP protocol >>> information (including the length of the packet) when decoding >>> and processing the packet payload. In particular, the >>> application must be designed so that corruption of this >>> information does not result in accumulated state or incorrect >>> processing of a tunneled payload." >>> >>> - How could any application achieve this goal? Possibly by analyzing >>> the consequences if any field in the IPv6 or UDP header were >> corrupted? >>> (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't >>> the analysis have to include any additional encapsulation that comes >>> between the UDP header and the inner IP header? >> >> Yes, this is a design analysis which includes the tunnel protocols >> headers. >> >>> >>> - Wouldn't the analysis, mentioned above, have to include assurances >>> regarding the case when the destination port is corrupted? >>> Specifically, would it have to include a guarantee that if the >>> encapsulated inner packet were delivered to any randomly chosen port, >>> it would not cause any harm to the application listening on that >> port? >> >> Clearly it can't include a guarantee that it will not harm what ever is >> at the randomly chosen port. But one part we try to get across in this >> document is that this is the reason we want to ensure that default >> remains to have the UDP checksum enabled to avoid having applications >> not having considered this in their design or at least been analyzed to >> be safe enough to get zero checksummed packets. >> >> The next step is the question of potential harm is a statistics game. >> And the more traffic that are transported over the network with zero- >> checksum the higher the probability that you will get a packet not >> intended for your context. Thus you will have to deal with it. Here I >> think most tunnel egresses are reasonably simple to analyze what >> happens. You attempt to decapsulate it according to whats in the >> packet. >> If that is not a mismatch you try to do the next step for the inner >> packet, switching or forwarding that based on whats there. That either >> matches or not the context and are thus sent further or discarded. If >> there is a checksum on that level it can help discarding packets that >> completely misses the context. >> >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com >> ---------------------------------------------------------------------- > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
