Magnus,
Thanks! I will downgrade my DISCUSS to a comment and trust you to make that
change.
Ron
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerl...@ericsson.com]
> Sent: Friday, October 12, 2012 5:24 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)
>
> 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
--------------------------------------------------------------------
