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