Hi, I agree that Geneve is essentially a tunnel between NVEs. If NVEs are considered as end points, the communication can be secured using IPsec or DTLS from one NVE to the other NVE. However, the document specifies Transit Devices that can interpret the Geneve packets (section 2.2.1). If the Geneve communication between NVEs were protected by IPsec or DTLS, the Transit Devices would not be able to access the Geneve packet as a result, my understanding is that a Geneve tunnel cannot be secured with transit device. In other words, securing a Geneve deployment with transit devices will require to redesign the deployment - without transit devices - if security should be enabled. I see this as a major issue.
When I mentioned that IPsec was used to secure the infrastructure, I meant that IPsec is used between the originating NVE and the transit device as well as between the transit device and the terminating NVE - as opposed to IPsec being used between NVEs. In this case, I would not consider IPsec protecting the end-to-end Geneve tunnel, but instead IPsec would be used to segments of the communications. The reason I mentioned infrastructure is that NVEs and the transit devices could be seen as a mesh trusted platform carrying the Geneve tunnel. I am not saying this is what I would recommend. Your concern seems to be integrity protection. I have not found any mention of AH or ESP in the document, so maybe there is a reference I am missing. On the other hand, integrity protection-only might be the only case compatible with transit devices as long as they are able to interpret appropriately the packet. In this case, the transit device should support AH, ESP, DTLS with authentication only. If that would be the case, a given deployment including transit device, would be ale to provide integrity protection by only activating integrity protection only at the NVEs. I am not aware of transit device implementing this. Yours, Daniel On Mon, Jul 8, 2019 at 12:37 PM Kathleen Moriarty < [email protected]> wrote: > 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 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
