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

[Tom Herbert <[e-mail]>]

> 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.
>
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.
>
>
>> This may not break the standard, but it doesn't seem
>> robust either. Is my interpretation correct?
>
>
> 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.
>
>
>> 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.
>
>
> 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