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

From: Tom Herbert <[email-masked]>
Date: Thu, 1 May 2014 08:18:04 -0700

On Thu, May 1, 2014 at 1:10 AM, Alexander Vainshtein <
[email-masked]> wrote:

>  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.
>
>
>
Thanks Sasha, this is a good point. Similar concerns have been mentioned
about the difficulty of switches to process packets with IP options. The
solutions there were to split into a fast and slow data path based on the
presence of options, or some implementations probably just dropped packets
with options.   In either case protocol conformance is maintained and there
was no need to change IP protocol. I'd suggest a similar approach can be
done where zero checksum value in a UDP packet takes an expedited data path.

Also, this discussion really seems to be specific to switch HW. I think
you'd be hard pressed to find a NIC that does not provide L4 checksum
offload. Retrofitting those NICs to provide checksum for encapsulation
(really a matter of supporting >1 csums in a packet) should mostly be an
API issue and even then most of the complexity in on TX side not RX.

>  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-masked]
>
> Mobile: 054-9266302
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Tom Herbert
> *Sent:* Thursday, May 01, 2014 4:48 AM
> *To:* Larry Kreeger (kreeger)
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *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-masked]> 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-masked]> 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-masked]
> >https://www.ietf.org/mailman/listinfo/tofoo
>
>
>

---

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

From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 30, 2014 8:14 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 6:54 PM, Larry Kreeger (kreeger) <[email-masked]<mailto:[email-masked]>> wrote:
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.

Are these implementations also ignoring IPv4 header checksum then?

LK2> Yep.  The text in the VXLAN draft applies to both IPv4 and IPv6.  In fact, IPv6 was only added to the draft in a later version and all original implementations supported only IPv4 encapsulation (I'm not aware of any IPv6 implementations, but maybe there are some out there).

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.

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.

LK2> I suppose it depends on the routers and switches in use, but a well designed one should not flip any payload bits while routing/switching (e.g. use internal CRCs across its backplane).

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.

LK2> It is much easier for software on hosts to do this (and maybe NICs).  You might be hard pressed to find a hardware gateway that does it in a cost effective manner.

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,
Tom

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 13:20:53 -0700

On 4/30/2014 2:23 PM, Behcet Sarikaya wrote:
> 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?

No; the UDP checksum is not for authetication. It is an error check.

The only party that can decide to make the UDP checksum optional when 
using IPv4 is the source - by inserting zero.

It's not the receiver's choice to ignore that checksum if it's not zero. 
That's where this doc breaks the current standards.

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 1 May 2014 15:30:18 -0500

> That's where this doc breaks the current standards.
The important point in the above text that I quoted was encryption being
optional not about authentication.
So checksum would be zero if the payload is encrypted and non-zero if it is
not not and both cases are possible.

Behcet

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 13:34:03 -0700

On 5/1/2014 1:30 PM, Behcet Sarikaya wrote:
>
>
>
> On Thu, May 1, 2014 at 3:20 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     The only party that can decide to make the UDP checksum optional
>     when using IPv4 is the source - by inserting zero.
>
>     It's not the receiver's choice to ignore that checksum if it's not
>     zero. That's where this doc breaks the current standards.
>
> So checksum would be zero if the payload is encrypted and non-zero if it
> is not not and both cases are possible.

Receiver processing is simple:

	- if the checksum is zero, ignore

	- if the checksum is NOT zero, it MUST match

No other part of the packet needs to be examined. If the *sender* wants 
to have the receiver ignore the checksum, it inserts zero. If not, the 
receiver MUST process and validate it.

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 1 May 2014 15:38:23 -0500

On Thu, May 1, 2014 at 3:34 PM, Joe Touch <[email-masked]> wrote:

> No other part of the packet needs to be examined. If the *sender* wants to
> have the receiver ignore the checksum, it inserts zero. If not, the
Sure. I think we are in agreement.

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 May 2014 14:00:49 -0700

On Thu, May 1, 2014 at 1:34 PM, Joe Touch <[email-masked]> wrote:

> This is true with caveat that an implementation MAY ignore a zero
checksum, not MUST ignore a zero checksum. This is specified in RFC1122.
 VXLAN draft also breaks this by making accepting packets with zero
checksums a MUST. From a practical perspective, if the UDP checksum were
the only thing I had to protect the vni I would want the capability to drop
packets received with zero checksums in my deployment.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 14:08:52 -0700

On 5/1/2014 2:00 PM, Tom Herbert wrote:
...
> checksum, not MUST ignore a zero checksum. This is specified in RFC1122.

It says that the app MAY optionally be able to configure the system to 
pass zero-checksum UDP packets up or discard them.

I.e., a *configuration* MAY decide to accept or drop zero-checksum UDP 
packets; the UDP layer isn't in control of that by itself.

> checksums a MUST.

That's not "breaking" anything; VXLAN is - to UDP - an application.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 02 May 2014 11:15:46 +0100

On 01/05/2014 04:14, Tom Herbert wrote:
>
>
> 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.

Interesting, for years I have been looking for someone to put forward
some statistics on the error rate in a modern network, to get some
hard data on the UDP c/s issue. What error rate are you seeing?

Also can you help me understand what class of switch/router you are
seeing this on: h/w forwarding, s/w forwarding, host basted s/w 
forwarding... If you know whether the packet memory has any form of 
error detection/protection that would also be interesting.

Thanks

Stewart

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 May 2014 09:10:58 -0700

On Fri, May 2, 2014 at 3:15 AM, Stewart Bryant <[email-masked]> wrote:

> 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.
>
>
> We see well less than 100 errors per day throughout out network. This is
internal traffic only, rates on from Internet are much higher as one would
expect. I haven't done all the math, but this may be in line with nominal
error rate in the network and the probability of an undetected error
getting though MAC CRC.

My bigger concern is the effects when hardware (or software) fails. Most
hardware failures are fairly noticeable and don't corrupt packets, and the
usual effects are packet loss or increased latency. We have seen cases
though, where hardware fail by corrupting packet data and/or not doing
validation correctly. In the worse case, we have seen undetected data
corruption make it all the way to the application. Failures like this are
still very rare, however when they occur they may be difficult to debug and
even identifying the failure may take a long time.

To mitigate the risks of undetected data corruption in the network, a
separate end to end CRC is commonly performed by the applications over
sensitive data. This is a component of an RPC layer for instance. I think
we'd like to see the probability of an undetected data corruption to be no
more than 2^-64 (I believe the vni in VXLAN qualifies as sensitive data).

Note that neither checksum nor CRC provide for authentication which is
emerging as another requirement for intra data center traffic-- and
encryption as a requirement won't be far behind.

> forwarding... If you know whether the packet memory has any form of error
> detection/protection that would also be interesting.
>

We haven't looked into it at that level, any of those would be suspect
including the NIC and host software. The normal errors seem fairly random
and since there being detected at the RX host it wouldn't be obvious how to
determine where in the network the corruption actually occurred.

There is probably both devices that have memory protection and legacy ones
that don't.

Tom

 Thanks

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 May 2014 14:34:25 -0700

On Thu, May 1, 2014 at 2:08 PM, Joe Touch <[email-masked]> wrote:

> Perhaps not, but making it a MUST in the encapsulation protocol definition
to always accept UDP packets with zero checksums seems a bit austere. For
instance, if I know within my deployment that all senders are configured to
use checksums, then receiving a packet with zero checksum should be
considered an invalid packet.

Tom

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 May 2014 15:25:10 -0700

On 5/2/2014 2:34 PM, Tom Herbert wrote:
...
>            VXLAN draft also breaks this by making accepting packets with
>         zero checksums a MUST.
>
> Perhaps not, but making it a MUST in the encapsulation protocol
> definition to always accept UDP packets with zero checksums seems a bit
> austere. For instance, if I know within my deployment that all senders
> are configured to use checksums, then receiving a packet with zero
> checksum should be considered an invalid packet.

Sorry if I'm missing something here - this started with the following, 
from draft-mahalingam-dutt-dcops-vxlan-09, which focuses on the non-zero 
checksum case:

The point is that this is NOT an option. If the UDP checksum is nonzero, 
it MUST be validated.

(this isn't open to interpretation; if you want to have VXLAN accept 
non-zero checksums that are invalid, then you are not compliant with 
what few standards the Internet has)

---

When the UDP checksum is zero, RFC1122 says that:
	
	- an app MAY optionally be able to configure a system
	to accept zero-checksum UDP packets up or discard them

It would be a bad idea for VXLAN to assume that this configuration is 
available. However, that leaves only two cases:

	1) if accept/discard of zero-checksum IS available, then
	VXLAN would configure it to accept

	2) if accept/discard of zero-checksum is NOT available,
	then UDP *MUST* pass the zero-checksum packets to VXLAN.
	It's up to VXLAN to decide how to handle them - and it's
	OK to require VXLAN to MUST accept them (i.e., to treat
	them the same way as a valid non-zero checksum)

When you have a stronger validation mechanism, I see no reason to drop 
packets with zero checksums for that reason alone - however, VXLAN 
really needs to say that *it* will do that drop if necessary, not to 
assume that UDP can be configured to do so.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 May 2014 15:34:09 -0700

On Fri, May 2, 2014 at 3:25 PM, Joe Touch <[email-masked]> wrote:
> Sorry if I'm missing something here - this started with the following, from draft-mahalingam-dutt-dcops-vxlan-09, which focuses on the non-zero checksum case:
>
>
> The point is that this is NOT an option. If the UDP checksum is nonzero, it MUST be validated.
>
> (this isn't open to interpretation; if you want to have VXLAN accept non-zero checksums that are invalid, then you are not compliant with what few standards the Internet has)
>
I am referring to:

"When a packet is received with a UDP checksum of zero, it MUST be
accepted for decapsulation."

> It would be a bad idea for VXLAN to assume that this configuration is available. However, that leaves only two cases:
>
> When you have a stronger validation mechanism, I see no reason to drop packets with zero checksums for that reason alone - however, VXLAN really needs to say that *it* will do that drop if necessary, not to assume that UDP can be configured to do so.
>
> Joe
>
>
>
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 May 2014 15:45:29 -0700

> accepted for decapsulation."

That is a completely valid choice w.r.t. RFCs 1122 and 768.

1122 is the most specific on these points:

             A host MUST implement the facility to generate and validate
             UDP checksums.  An application MAY optionally be able to
             control whether a UDP checksum will be generated, but it
             MUST default to checksumming on.

             If a UDP datagram is received with a checksum that is non-
             zero and invalid, UDP MUST silently discard the datagram.
             An application MAY optionally be able to control whether UDP
             datagrams without checksums should be discarded or passed to
             the application.

The "application" here is VXLAN. So you can say that VXLAN SHOULD set 
the UDP checksum to zero, but you cannot say that it MUST (because 
app-layer control is a MAY).

When receiving nonzero invalid checksums, you cannot say that VLXAN will 
process those packets, because UDP MUST silently discard them.

When receiving zero checksums, you cannot say that VXLAN MUST NOT see 
them, because app-layer control of discard is optional.

----

I think your objection may be that you don't think we can assume that 
zero-checksum packets arrive at VXLAN, because of how RFC1122 is worded. 
However, RFC768 permits zero-checksum packets as valid and useful to the 
upper layer, so I interpret RFC 1122 as saying "the app might be able to 
configure UDP to discard zero-checksum packets", but if it doesn't, 
those packets already will end up at the application.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 May 2014 16:15:32 -0700

> zero-checksum packets arrive at VXLAN, because of how RFC1122 is worded.
No, I expect zero checksums will be the common case.

> configure UDP to discard zero-checksum packets", but if it doesn't, those
> packets already will end up at the application.
>
My interpretation of the VXLAN draft precludes the possibility of an
implementation being able to reject received zero-checksums even as a
configuration option, or even for select senders. So if we receive a
zero checksum from a sender that we know has not disabled checksums,
per the draft we need to accept even though we know this is a
corrupted packet. This may not break the standard, but it doesn't seem
robust either. Is my interpretation correct?

My core concern in all of this is still whether the vni in VXLAN in
being adequately protected against corruption (this would apply to
other encapsulation protocols that carry vni also). The integrity of
the vni is paramount in supporting the isolation requirements of
network virtualization.

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 May 2014 16:58:06 -0700

> No, I expect zero checksums will be the common case.

I meant that you don't think that this common case will be correctly 
handled.

> configuration option, or even for select senders.

Agreed - as writte, it cannot reject those packets merely because thye 
have a zero checksum -

   "When a packet
    is received with a UDP checksum of zero, it MUST be accepted for
    decapsulation. "

(note that I have no position as to whether this is good or bad; VXLAN 
could decide to reject such packets if that's what the WG decides).

> So if we receive a
> corrupted packet.

I don't know how you can make this claim.

You don't know it's a corrupted packet - esp. because it's highly 
unlikely that the checksum would be zero'd solely by corruption. What 
you know - at best - is that the source decided to send a zero-checksum 
packet.

A sender that transmits zero checksums does so deliberately (on an 
ongoing basis). It does so when it believes that another layer will 
check for packet corruption, or when packet corruption isn't important.

> This may not break the standard, but it doesn't seem

VXLAN can make whatever decision you want; you can decide to accept 
zero-sum packets for further processing, to reject them, or to decide on 
a per-endpoint basis given other knowledge of the endpoint. All 
behaviors are compliant with current standards.

What you cannot do is accept a packet with a non-zero checksum that is 
invalid. Those should never be sent to VXLAN; they MUST be silently 
dropped by UDP. That's where this discussion originated.

As to robustness, IMO, the best would be to send packets with UDP 
checksums, so you drop corrupt packets as early as possible. If you 
don't want to incur the cost of checking (which is often in offload 
engines anyway), then you'd be relying on the upper layer (VXLAN layer) 
to check for errors.

However, I don't see that here - what I see is an ethernet header but 
that doesn't protect the E2E of the UDP packet, and that's not good enough.

> the vni is paramount in supporting the isolation requirements of

Then what you want is to require VXLAN to MUST send non-zero UDP 
checksums. At that point, saying "VXLAN receiver MUST discard 
zero-checksums" is fine, and both statements are compliant with existing 
standards.

Alternately, if you allow - or encourage - zero-checksum UDP, then you 
want to add a checksum of some kind to the VXLAN header.

But again, you're talking about the zero-checksum case, not the non-zero 
case where this all started.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 May 2014 18:47:35 -0700

> You don't know it's a corrupted packet - esp. because it's highly unlikely
> that the checksum would be zero'd solely by corruption. What you know - at
> best - is that the source decided to send a zero-checksum packet.
>
Factually, I only know that I received a packet with checksum of zero,
not that one want sent. If I have external information that says the
sender has not disabled checksums then something must have gone awry.
This is not just the rare case of corrupted checksum value, but
unfortunately zero is the likely value if the sender is not properly
setting the checksum. Since the checksum is always zeroed in the
packet before computation, there are many opportunities for bugs in
drivers, stacks, and HW where the checksum is not actually written
correctly (especially possible in presence of TSO and checksum offload
in NICs)-- in this case packets may be sent incorrectly with a
checksum of zero. This condition could be difficult to detect since
everything might otherwise appear okay. I would take this into
consideration when contemplating use of zero checksums.

> A sender that transmits zero checksums does so deliberately (on an ongoing
> basis). It does so when it believes that another layer will check for packet
> corruption, or when packet corruption isn't important.
>
>
> VXLAN can make whatever decision you want; you can decide to accept zero-sum
> packets for further processing, to reject them, or to decide on a
> per-endpoint basis given other knowledge of the endpoint. All behaviors are
> compliant with current standards.
>
> invalid. Those should never be sent to VXLAN; they MUST be silently dropped
> by UDP. That's where this discussion originated.
>
> As to robustness, IMO, the best would be to send packets with UDP checksums,
> so you drop corrupt packets as early as possible. If you don't want to incur
> the cost of checking (which is often in offload engines anyway), then you'd
> be relying on the upper layer (VXLAN layer) to check for errors.
>
> However, I don't see that here - what I see is an ethernet header but that
> doesn't protect the E2E of the UDP packet, and that's not good enough.
>
>
> Then what you want is to require VXLAN to MUST send non-zero UDP checksums.
> At that point, saying "VXLAN receiver MUST discard zero-checksums" is fine,
> and both statements are compliant with existing standards.
>
> Alternately, if you allow - or encourage - zero-checksum UDP, then you want
> to add a checksum of some kind to the VXLAN header.
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 May 2014 21:07:09 -0700

> sender has not disabled checksums then something must have gone awry.

Absolutely. Let's assume you follow the VXLAN draft. In that case:

    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.

The proposed spec says that the source can either enable or disable the 
checksum (SHOULD doesn't mean MUST).  It says nothing about tracking 
whether the source has disabled zero checksum. It's very clear that when 
you get a zero checksum, you should accept it.

If you want to track things the way you're proposing, then you need to 
update that draft.

---

However, the case you're proposing is bizarre - it would happen only if 
the endpoint said one thing and did another. It *could* happen from an 
error, but that's unlikely.

So let's say it DID happen - and that the spec says to check (which it 
currently doesn't). You then have conflicting info - on one hand, the 
endpoint said it would not zero the checksum, and on the other hand it did.

So what do you do? You can treat *EITHER* the packet or the info about 
the endpoint as incorrect - and you have *no* information that tells you 
which. You want to treat the packet as an error, but the info you have 
about the endpoint is equally suspect.

IMO, this is a case that's useless to consider in the spec; at that 
point, you're have no reason to trust anything you know about that 
endpoint at all, and you might as well cut it off completely -- 
regardless of what it sends.

> setting the checksum.

Protocol specs are not designed to address or avoid all implementation 
errors.

Your protocol ought to care whether the checksum is zero - or not care. 
The current draft doesn't care.

> Since the checksum is always zeroed in the
> checksum of zero.

If you want to prevent your protocol from being susceptible to this kind 
of implementation error, you need to change the spec so you always drop 
packets when the checksum is zero.

However, checksum errors aren't there to find implementation errors; 
they're there to find transmission or copying errors.

> This condition could be difficult to detect since

This discussion wasn't about zero checksums, but if that's what you want 
to discuss, here's my view:

	- allow zero checksums when you don't care about checksums

	- if you care about checksums, don't allow zero checksums

Anything else, esp. per endpoint, is madness, IMO. The use of checksums 
ought to depend on whether you care about the errors they find - not the 
failure modes that might generate zero checksums.

Joe