Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve

["Ganga, Ilango S" <[e-mail]>]

Hi Magnus,

Thanks for your review and feedback. Please see inline for my responses.

Regards,
Ilango


From: Magnus Nyström [mailto:[e-mail]]
Sent: Tuesday, October 23, 2018 9:01 PM
To: [e-mail]; [e-mail]
Subject: Secdir review (early review) of draft-ietf-nvo3-geneve

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes "Geneve," a protocol for GEneric NEtwork Virtualization Encapsulation. The document is written in a clear manner and with a thorough Security Considerations section. I have just a few questions/comments:

- Section 3.4: The "MUST ignore" for the reserved bits should presumably state "SHALL be ignored for this version of the Geneve protocol." - as I imagine that in a future version, these bits may not be ignored?

<Ilango> In theory, a future version may change the behavior of any of the header fields including the reserved bits.  The header definition is for this version of the protocol.

Please see if the following text would satisfy the intent of your comment.
“Reserved field which MUST be zero on transmission and MUST be ignored on receipt.”

Or let us know if you still want to have this qualified with “for this version of the protocol”
</>

- Section 3.5.1: I wonder about the simultaneous requirement that one option must not affect the parsing or interpretation of another option but that the sequencing (order) of options may be significant - they seem to be contradictory since if the sequencing *is* significant, then some option must be impacted by a previous one's value? From a security perspective, I also wonder if there could be security consequences of re-ordering options (and how to tell if someone did re-order - see below)?

<Ilango> You raise a good point. The intent of this statement is, parsing and interpretation of options should not be dependent on one another. We are discussing among the authors to see how we can include appropriate clarifying statements to address your point. I will update you shortly.
</>

- Section 6.2, shouldn't such an Option be defined to reduce the risk of under-specified or subpar specifications of such integrity mechanisms? Or also from an interop perspective?

<Ilango> Using a Geneve option for the purpose of data integrity is more of an optimization. Otherwise data integrity could be provided by using existing mechanisms like IPsec (as stated in second paragraph of 6.2). We included the last paragraph to show other possibilities. We could remove this paragraph if it may cause any confusion.

We would like to keep the Geneve base specification independent of options specifications, options could be a defined in a future standards action.
</>


Thanks.
-- Magnus