Early Review of draft-ietf-nvo3-geneve-08
review-ietf-nvo3-geneve-08-secdir-early-nystrom-2018-10-25-00
| Request | Review of | draft-ietf-nvo3-geneve-08 |
|---|---|---|
| Requested rev. | 08 (document currently at 14) | |
| Type | Early Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2018-10-26 | |
| Requested | 2018-10-09 | |
| Requested by | Matthew Bocci | |
| Draft last updated | 2018-10-25 | |
| Completed reviews |
Rtgdir Early review of -01 by John Drake
(diff)
Secdir Early review of -08 by Magnus Nystrom (diff) Tsvart Early review of -08 by David Black (diff) |
|
| Comments | This document has just entered working group last call. It represents a new encapsulation for data center overlay networks, and therefore needs an early review from both a security and a transport perspective. The last call ends on 26th October, but it is fine if the area reviews are a week or two after that. |
|
| Assignment | Reviewer | Magnus Nystrom |
| State | Completed | |
| Review | review-ietf-nvo3-geneve-08-secdir-early-nystrom-2018-10-25 | |
| Reviewed rev. | 08 (document currently at 14) | |
| Review result | Has Issues | |
| Review completed: | 2018-10-25 |
Review
review-ietf-nvo3-geneve-08-secdir-early-nystrom-2018-10-25
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? - 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)? - 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? Thanks. -- Magnus