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

[Joe Touch <[e-mail]>]

On 5/2/2014 4:15 PM, Tom Herbert wrote:
>> 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.
 >
> 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.

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

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

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