Sent from my mobile device
> On Jul 30, 2019, at 1:36 PM, Greg Mirsky <[email protected]> wrote: > > Hi Anoop, > thank you for pointing to iOAM as the use case of Geneve options. As I > understand, the iOAM for Geneve document offers several options, including > one that takes advantage of Geneve options. But such use of options must not, > in my opinion, weaken the security in Geneve. We can emphasize that with the > text you've proposed and minor, in my opinion, re-wording: > Transit devices may not be capable to process Geneve option content if the > Geneve header is secured. I do like this addition. Thank you, Kathleen > > > Regards, > Greg > >> On Tue, Jul 30, 2019 at 12:20 PM Anoop Ghanwani <[email protected]> >> wrote: >> Hi Daniel, >> >> Perhaps what is causing confusion is that there's a difference between NVO3 >> OAM and I-OAM (the reference provided below). >> >> From my understanding, NVO3 OAM will involve only NVEs processing those >> packets, while depending on other OAM methods for the underlay. >> >> On the other hand, with I-OAM the idea is to gather information about all >> devices along the path. There are several different encapsulation drafts >> (e.g. IOAM using Geneve, IOAM using VXLAN GPE, IOAM using NSH, etc.), so >> this is not NVO3-specific. >> >> Perhaps what the Geneve document needs to note is that the Geneve header >> cannot be secured if there are devices other than NVEs that are required to >> process its contents. Unless there is some non-obvious way of doing it and, >> if it exists, it would be helpful if a reference is provided. >> >> Thanks, >> Anoop >> >>> On Tue, Jul 30, 2019 at 6:49 AM Daniel Migault >>> <[email protected]> wrote: >>> Hi, >>> >>> OAM has been raised during the meeting, so thank you for providing the >>> appropriated references of OAM. My understanding is that OAM is a Geneve >>> option that is updated by the OAM devices that are on path. Is that correct >>> ? >>> >>> IPsec or DTLS authenticate or encrypt the full Geneve packet ( Geneve >>> Header, Geneve Options and Geneve payload) between the NVEs. If my >>> assumption regarding the OAM devices is correct, the use of DTLS or IPsec >>> would not make possible to authenticate or encrypt and Geneve packet with >>> OAM enabled. Again if my assumption is correct, I believe that an >>> appropriated way to address this concern might be to be able to leave some >>> Geneve Option non authenticated. while other parts of the packet is >>> authenticated or encrypted. Such mechanism needs to be implemented at the >>> Geneve layer. >>> >>> Yours, >>> Daniel >>> >>>> On Fri, Jul 26, 2019 at 2:52 PM Anoop Ghanwani <[email protected]> >>>> wrote: >>>> Hi Ilango, >>>> >>>> What would be the recommended way to secure the Geneve header in cases >>>> where Geneve header extensions are used and routers in the underlay need >>>> to access/process the contents of the Geneve header? For example, this >>>> proposal: >>>> https://tools.ietf.org/html/draft-brockners-ippm-ioam-geneve-02 >>>> >>>> Thanks, >>>> Anoop >>>> >>>>> On Thu, Jul 25, 2019 at 2: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 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 a, >>>>> b, c are met. >>>>> >>>>> >>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
