[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MBONED] [Fwd: I-D Action:draft-eubanks-chimento-6man-00.txt]
On Tue, Feb 24, 2009 at 12:17 PM, Dino Farinacci <dino at cisco.com> wrote:
> Here are my comments. Draft text comes first and indented and my comments
> follow.
>
>> The argument made by the draft authors is that since multicast
>> packets already have a UDP header with a checksum, there is no
>> additional benefit and indeed some cost to nodes to both compute and
>> check the UDP checksum of the outer (encapsulating) header. However,
>> Consequently, IPv6 should make an exception to the rule that the UDP
>> checksum MUST not be 0, and allow tunneling protocols to set the
>> checksum field of the outer header only to 0 and skip both the sender
>> and receiver computation.
>
> It is worse than that for AMT. Since the control packets are encapsulated in
> an IGMP packet format. There is an IGMP checksum performed as well, then on
> top of that encapsulated in UDP, with the UDP checksum performed there too.
>
> So please note that the burden might be less in the control-plane, but it is
> less necessary to do UDP checksum as well in this case. I think you
> shouldn't deprecate the behavior in the spec, but outline how double
> check-summing is occurring in this case.
Dino, I believe the current spec must be deprecated because it
specifically forbids a 0 checksum.
Greg
>> 3. Exception for lightweight tunneling: Amend IPv6 to allow a 0
>> value in the UDP checksum field for leightweight tunneling
>> protocols which allows them to bypass any checksum computation in
>> the outer header if the inner packet is protected. Rules for
>> usage in this case must be developed.
>
> Be more clear that the encapsulator does not have to compute a checksum on
> packet forwarding and the decapsulator, because the UDP checksum is 0, does
> not need to check the checksum.
>
>> 4. Another possibilty is to allow an exception for the AMT protocol
>> only. This may seem undesirable, but it would restrict the
>> implementation of a zero checksum UDP header over IPv6 only to
>> the AMT endpoints. Any misdelivered packets (i.e. arriving at a
>> non-AMT endpoint) would simply be discarded.
>
> There are other protocols coming that will use UDP encapsulation. It is
> becoming popular to use UDP so you get LAGs to work inside of the tunnel as
> well as an easier way to get through firewalls.
>
> One example is LISP.
>
>> Others on the mailing list have pointed out other issues with
>> changing the IPv6 specification to allow a checksum of 0 on the outer
>> packet header. In particular, Matt Mathis points out that some
>> tunneling devices ignore the DF bit and fragment silently. This
>> would allow two fragmented UDP packets to be spliced together and be
>> decapsulated and forwarded by a tunnel endpoint.
>
> But can we make a mention that link-layer CRC, ECC, and checksum do find
> high percentage of link errors, so there is another level of protection we
> can rely on. Please state that somewhere in the spec.
>
>> Magnus Westerlund proposed some restrictions on using a UDP header
>> checksum of 0. These are:
>
> Since Magnus is being referred to multiple times in this draft, I suggest
> you put his contact info at the end.
>
>> 2. The tunneling protocol and implementation must not use
>> fragmentation of the inner packets being carried.
>
> I would change "must not" to "should not".
>
>> We would suggest the following elaborations of the above
>> restrictions, if a change in the IPv6 specification moves forward:
>>
>> o An inner IPv4 packet with a UDP checksum equal to 0 must not be
>> tunneled.
>>
>> o Non-IP inner packets must have a CRC or other mechanism for
>> checking packet integrity.
>>
>> o Other tunneling protcocols that use the UDP checksum equal to 0
>> MUST NOT be tunneled themselves, even if more deeply encapsulated
>> packets have checksums or other integrity checking mechanisms.
>>
>> o We would recommend that general protocol stack implementations do
>> NOT implement this change. The exception should remain restricted
>> to devices serving as endpoints of the lightweight tunneling
>> protocol adopting the change.
>>
>> In addition, we would recommend that a security analysis be done in
>> order to assess whether any new vulnerabilities are introduced by
>> such a change.
>
> This is to strong of language. You create more work for hardware
> implementations to adhere to this. Which means they will just ignore it.
>
> I would change all occurences of "must" to "should".
>
> Thanks,
> Dino
>
> On Feb 24, 2009, at 5:21 AM, Brian Haberman wrote:
>
>> All,
>> Here is the draft that proposes to loosen the UDP checksum rule for
>> IPv6. I would appreciated if discussions of this draft occur on the 6MAN
>> mailing list (ipv6 at ietf.org).
>>
>> Regards,
>> Brian
>>
>>
>> -------- Original Message --------
>> Subject: I-D Action:draft-eubanks-chimento-6man-00.txt
>> Date: Mon, 23 Feb 2009 10:45:01 -0800 (PST)
>> From: Internet-Drafts at ietf.org
>> Reply-To: internet-drafts at ietf.org
>> To: i-d-announce at ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> Title : UDP Checksums for Tunneled Packets
>> Author(s) : M. Eubanks
>> Filename : draft-eubanks-chimento-6man-00.txt
>> Pages : 7
>> Date : 2009-02-23
>>
>> We address the problem of computing the UDP checksum on tunneling
>> IPv6 packets when using lightweight tunneling protocols.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-eubanks-chimento-6man-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>> _______________________________________________
>> MBONED mailing list
>> MBONED at ietf.org
>> https://www.ietf.org/mailman/listinfo/mboned
>
> _______________________________________________
> MBONED mailing list
> MBONED at ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
>