HI Daniel, I read the document and saw that it was used as a tunnel and the end points were the ones that had access to the GENEVE information. With this in mind, the UDP layer for GENEVE encapsulated in an IP packet could then use IPsec. The security recommendations mentions the use of IPsec to fix many of the stated considerations.
I don't understand your comment that IPsec is used to secure the infrastructure, what do you mean, can you provide an example? I think the security considerations section says it's protecting GENEVE and that GENEVE is essentially a tunnel - you can use it over the Internet to join VLANs (this is a pretty obvious use case where IPsec would be used). Integrity protection on any routing overlay protocol should be a requirement, especially when the path of traffic can be altered by the routing overlay protocol from what would normally be used. The document says (or I read somewhere) no AH only support, so I am guessing that vendors have not implemented that interoperably, hence the reason for the ESP recommendation. Thanks for any clarification. Best regards, Kathleen On Mon, Jul 8, 2019 at 10:56 AM Daniel Migault <[email protected]> wrote: > Hi Kathleen, > > My understanding of the document is that IPsec is not used to secure > Geneve. Instead, IPsec is used to secure the infrastructure on top of which > Geneve would be operated, thus lowering down the security of Geneve itself. > As far as I understand, Geneve is incompatible with en-to-end security > (IPsec, DTLS) to protect Geneve NVE-to-NVE communications. The document > defines Transit Devices that intercept on-path packets of an NVE-to-NVE > communications, which is not possible with DTLS or IPsec. > > Yours, > Daniel > > > On Tue, Jul 2, 2019 at 3:43 PM Kathleen Moriarty < > [email protected]> wrote: > >> 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 >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > -- Best regards, Kathleen
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
