Subject: [nvo3] VXLAN (UDP tunnel protocols) and non-zero checksums

From: Tom Herbert <[email-masked]>
Date: Wed, 30 Apr 2014 12:01:52 -0700

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 Apr 2014 14:46:48 -0500

This is what VXLAN draft says:

The UDP checksum field SHOULD be transmitted as zero.  When a packet
   is received with a UDP checksum of zero, it MUST be accepted for
   decapsulation.  Optionally, if the encapsulating endpoint includes a
   non-zero UDP checksum, it MUST be correctly calculated across the
   entire packet including the IP header, UDP header, VXLAN header and
   encapsulated MAC frame.  When a decapsulating endpoint receives a
   packet with a non-zero checksum it MAY choose to verify the checksum

value.  If it chooses to perform such verification, and the
   verification fails, the packet MUST be dropped.  If the
   decapsulating destination chooses not to perform the verification,
   or performs it successfully, the packet MUST be accepted for
   decapsulation.

What is wrong with it?

Behcet

On Wed, Apr 30, 2014 at 2:01 PM, Tom Herbert <[email-masked]> wrote:

> _______________________________________________
> Tofoo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tofoo
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 Apr 2014 13:01:36 -0700

>    or performs it successfully, the packet MUST be accepted for
This makes the verification of (a non-zero) UDP checksum optional,
which as I pointed out seems contrary to established UDP standard. If
the verification isn't done then the MUST to drop packets with an
invalid checksum is moot. Also, there really should be no reason that
VXLAN needs to define a custom use of UDP checksum. The UDP checksum
is either computed across the UDP payload which should be clear in
VXLAN, or may be zero per using zero checksum in tunneling guidelines.
These should hold for all foo/UDP.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 Apr 2014 16:23:28 -0500

Here is what VXLAN says on tunneled traffic:

Tunneled traffic over the IP network can be secured with traditional
   security mechanisms like IPsec that authenticate and optionally
   encrypt VXLAN traffic. This will, of course, need to be coupled with
   an authentication infrastructure for authorized endpoints to obtain
   and distribute credentials.

Based on this, UDP checksum text seems to be consistent, no?

Behcet

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 1 May 2014 00:13:13 +0000

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?  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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 Apr 2014 18:48:13 -0700

On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger)
<[email-masked]>wrote:

> 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

 - Larry

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 1 May 2014 01:54:32 +0000

See inline, marked with LK>. - Larry

From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 30, 2014 6:48 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Dinesh Dutt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums

On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

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.

LK> I am referring to switching ASIC implementations.  There is no software nor traditional UDP stack involved.

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.

LK> Neither I nor the VXLAN draft claims that UDP checksums are useless, however I think it is an exaggeration to say "nothing" protects the VNI from corruption when the packet is being carried over Ethernet with a robust CRC32 protecting it.

Thanks,
Tom

On 4/30/14 12:01 PM, "Tom Herbert" <[email-masked]<mailto:[email-masked]>> wrote:

>[email-masked]<mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 Apr 2014 20:14:26 -0700

On Wed, Apr 30, 2014 at 6:54 PM, Larry Kreeger (kreeger)
<[email-masked]>wrote:

>   From: Tom Herbert <[email-masked]>
> To: Larry Kreeger <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, Dinesh Dutt <
> [email-masked]>
> On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger) <
> [email-masked]> wrote:
>
>> Hi Tom,
>>
>  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.
>
>  LK> I am referring to switching ASIC implementations.  There is no
> software nor traditional UDP stack involved.
>
> Are these implementations also ignoring IPv4 header checksum then?

>  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
>  LK> Neither I nor the VXLAN draft claims that UDP checksums are useless,
> however I think it is an exaggeration to say "nothing" protects the VNI
> from corruption when the packet is being carried over Ethernet with a
> robust CRC32 protecting it.
>
> Assuming we are using Ethernet (I don't believe this can be a requirement
either) this only provides hop to hop protection, not end to end. I don't
have a completely error free network and checksum errors while low, are
non-zero. Sending a packet to the wrong VM is fundamentally bad and could
be quite costly,  so for me UDP checksums would be the minimum requirement.
This would need to apply to the case where the protocol is switched also.

In any case, the requirements and constraints for when it's acceptable to
ignore non-zero checksums for UDP should be specified in a more general way
if is being allowed.  Maybe an addendum to RFC 6935?

Tom

 Thanks,