Thank you, Ilango, inline. On Thu, Jul 25, 2019 at 5:18 PM Ganga, Ilango S <[email protected]> wrote:
> Hello Kathleen, > > > > Thanks for your review of draft-ietf-nvo3-geneve-13. We could provide > additional clarification in section 4.3 to address your comment. Please let > us know if this satisfies your comment. > > > > Current text in Section 4.3, first paragraph: > > In order to provide integrity of Geneve headers, options and payload, > > for example to avoid mis-delivery of payload to different tenant > > systems in case of data corruption, outer UDP checksum SHOULD be used > > with Geneve when transported over IPv4. An operator MAY choose to > > disable UDP checksum and use zero checksum if Geneve packet integrity > > is provided by other data integrity mechanisms such as IPsec or > > additional checksums or if one of the conditions in Section 4.3.1 > <https://tools.ietf.org/html/draft-ietf-nvo3-geneve-13#section-4.3.1> a, > > b, c are met. > > > > Proposed text to 4.3 that we believe would address your comments: > > > > In order to provide integrity of Geneve headers, options and payload, > > for example to avoid mis-delivery of payload to different tenant > > systems in case of data corruption, outer UDP checksum SHOULD be used > > with Geneve when transported over IPv4. "The UDP checksum provides a > statistical guarantee that a payload was not corrupted in transit. These > integrity checks are not strong from a coding or cryptographic perspective > and are not designed to detect physical-layer errors or malicious > modification of the datagram (see RFC 8085 section 3.4). In deployments where > such a risk exists, an operator SHOULD use additional data integrity > mechanisms such as offered by IPSec (see Section 6.2)." > > > > An operator MAY choose to > > disable UDP checksum and use zero checksum if Geneve packet integrity > > is provided by other data integrity mechanisms such as IPsec or > > additional checksums or if one of the conditions in Section 4.3.1 > <https://tools.ietf.org/html/draft-ietf-nvo3-geneve-13#section-4.3.1> a, > > b, c are met. > > I think the additional text is helpful to have the full security considerations understood. I appreciate you adding it in the draft. I'll respond to other messages in the thread and apologize for my delay. Best regards, Kathleen > > > Thanks, > > Ilango > > > > > > *From:* nvo3 [mailto:[email protected]] *On Behalf Of *Kathleen > Moriarty > *Sent:* Tuesday, July 2, 2019 12:43 PM > *To:* [email protected] > *Subject:* [nvo3] Review of draft-ietf-nvo3-geneve-13 > > > > Hello, > > > > I just read through draft-ietf-nvo3-geneve, sorry I am out-of-cycle in the > review process, but it looks like it has not started IETF last call yet. I > have what's really just a nit and request for a little more text. > > > > Section 4.3.1 > > The value of the UDP checksum is overstated. The text should note that > corruption is still possible as this is a checksum and not a hash with low > collision rates. Corruption happens and goes undetected in normal > operations today. > > The security considerations section does address the recommendation to use > IPsec, but making the connection on the UDP checksum being inadequate could > be helpful. > > > > Reality: > > > > The way this is written, I suspect there really are no plans to use IPsec > with GENEVE, are there? The MUST statements around not altering traffic > can only be achieved with IPsec, so if the intent is really to enforce the > early MUST statements in the document, sooner mention of IPsec would be > good. If this is more for detecting corruption (and not having that be > 100% or close) that should be clear up front. > > > > I'm just envisioning use cases where the virtual path is set differently > to the physical path for expected operations to route through desired > security functions, then an attacker alters checksums to avoid detection of > these changes. > > > > Thanks and sorry for a late review! > > > > -- > > > > Best regards, > > Kathleen > -- Best regards, Kathleen
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
