Tom, Larry and all,
I do not want to argue for or against UDP checksums in VXVLAN .
Just want to point that ability of HW to check/generate the IPv4 checksums does
not, IMHO and FWIW, that the same HW can easily do UDP checksums.
AFAIK, IPv4 forwarding HW in most cases has access to a relatively small part
at the beginning of the packet. This is enough to deal with the IPv4 header
but is not enough to compute UDP checksums – because these include the entire
packet payload.
This does not mean that HW-assisted computation of UDP ckechsums is not
possible – only that it would be rthogonal to HW-assisted computation of IPv4
header checksums.
My 2c,
Sasha
Email: [email protected]
Mobile: 054-9266302
From: nvo3 [mailto:[email protected]] On Behalf Of Tom Herbert
Sent: Thursday, May 01, 2014 4:48 AM
To: Larry Kreeger (kreeger)
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [nvo3] [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums
On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger)
<[email protected]<mailto:[email protected]>> wrote:
Hi Tom,
I'll give you my perspective on why I feel the behavior described in the
VXLAN draft is a good thing. First, it is my assumption that some
implementations (e.g. many hardware implementations), will not implement
checksum generation, nor checksum validation. I believe this is an
implementation reality. If implementations are required to check a
non-zero checksum, but can't actually do it, what alternatives do they
have?
Barring that the implementations you're referring to only implement IPv6, these
implementations must be already be doing checksum validation for IPv4 header--
so the checksum logic must have been implemented and I'm not sure the argument
that this HW can't calculate the UDP csum would have much merit. A specific
example implementation would be nice here, for instance in the case that the
stack decapsulates the checksum can always be done in SW if verification is not
provided by the device.
Also, as I pointed out, the UDP checksum is *not* useless in VXLAN. In an L3
routed network there is nothing that protects the vni from corruption expect
possibly the UDP checksum. Without any additional security mechanisms is VXLAN
header (like a cookie), the only way I could deploy VXLAN is with checksums
enabled. So in my opinion, the draft should be encouraging use of UDP checksums
instead of discouraging them.
Thanks,
Tom
One is to drop all packets with a non-zero checksum (because one
might be invalid and even one invalid one slipping through would be
unacceptable). Another alternative is to accept all checksum values. The
second option greatly enhances interoperability with implementations that
choose to generate a checksum and implementations that cannot validate the
checksum. It allows a mixed environment where "better" implementations
(that can validate) can interoperate with "inferior" implementations that
are unable to validate the checksum.
BTW, VXLAN is not the only tunneling protocol to specify this behavior.
LISP (RFC 6830), specifies exactly the same behavior.
- Larry
On 4/30/14 12:01 PM, "Tom Herbert"
<[email protected]<mailto:[email protected]>> wrote:
>Hi,
>
>I noticed that the VXLAN draft allows an implementation to potentially
>ignore a non-zero invalid UDP checksum.
>
>From: http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-09
>
>"When a decapsulating endpoint receives a packet with a non-zero
>checksum it MAY choose to verify the checksum"
>
>However, from RFC 1122:
>
>"If a UDP datagram is received with a checksum that is non-zero and
>invalid, UDP MUST silently discard the datagram."
>
>It doesn't seem like 1122 allows checksum verification to be optional,
>so these would seem to be a conflict. Presumably, ignoring the RX csum
>is included for performance but since the sender can already send zero
>checksums in UDP (they are optional in IPv4 and allowed for IPv6
>tunnels in RFC 6935) I'm not sure this is necessary. Besides that, the
>UDP checksum is potentially the only thing that protection of the vni
>against corruption end to end so allowing a receiver to ignore a bad
>checksum seems very risky.
>
>As a comparison, RFC 3931 (L2TP) has the following wording:
>
>"Thus, UDP checksums MAY be disabled in order to reduce the associated
>packet processing burden at the L2TP endpoints."
>
>This is somewhat ambiguous, but seems like the correct interpretation
>should be that zero checksums may be sent with L2TP/UDP, but on
>receive non-zero checksums should still be validated.
>
>Are these interpretations correct? Is there there a need to clarify
>the requirement for UDP tunnel protocols and checksums?
>
>Thanks,
>Tom
>
>_______________________________________________
>Tofoo mailing list
>[email protected]<mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/tofoo
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
