Hi, I received some comments from Magnus Nyström I am using as a base for the update of the document. I believe I have addressed all comments which led to significant changes to the document and the current version represents a major improvement. I would like to thank Magnus for its review.
While the comments led to a significant changes and clarifications I did not notice any major issues. Please find inline the comments as well as the response. Yours, Daniel From: Magnus Nyström <mailto:[email protected]> Sent: Sunday, February 03, 2019 12:35 PM To: Daniel Migault <mailto:[email protected]> Subject: Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve Hi Daniel, I have reviewed the document now. Overall I think this is a good document and I definitely agree with the recommendation to leverage TLS or IPSec to meet the stated Geneve security requirements. A few observations: • Perhaps I missed it, but it felt the document was less explicit about integrity protection needs (in addition to encryption/confidentiality needs)? <mglt> You are correct. While we believe all combinations provided for confidentiality have been summed up in SEC-GEN-8, it is clearer for the reader to follow the same scheme for confidentiality and integrity. The new version updates the integrity section to aligned with the confidentiality section. We also clarified IPsec/AH versus IPsec/ESP in term of coverage, as well as the use of authenticated encryption to avoid the confusion that encryption might (still) be understood as non authenticated. </mglt> • On TLS, was there a specific analysis made of TLS 1.3? I assume DTLS isn't applicable in the context of this document? <mglt> First in many places, TLS should be DTLS. The new version has carefully checked TLS is not used instead. We did not performed a specific analyses for TLS 1.3. Geneve can be protected by DTLS. One issue is that DTLS 1.3 is still a draft and may not provide authentication only cipher suites. The current document clarifies that integrity protection may be also provided through encryption. The main text leaves TLS and discussions further analysis are provided in the annex section. The inner traffic can be protected by any protocol including DTLS. The current text was mostly listing TLS and not DTLS so I added DTLS as well as IPsec/AH, IPsec/ESP. </mglt> • SEC-GEN-8 confused me a bit: Geneve Security mechanism MUST provide means for a tunnel endpoint (NVE) to authenticate data prior it is being processed. A tunnel endpoint (NVE) MUST be able to authenticate at least: * the Geneve Header and a subset of Geneve Options * the Geneve Header, a subset of Geneve options and the Geneve inner payload * the Geneve Header, a subset of Geneve options and the Geneve inner payload or the portion of the inner payload in case the Tenant's System provides some authentication mechanism. It looks like the second bullet is a superset of the first one, and the last one a superset of the second one, and so since the preceding statement is "at least", isn't the last capability (bullet) the deciding one? I.e., it should be sufficient to just mention that alternative? Or should the "at least" be replaced with "at least one of"? <mglt> This item does not exist anymore, and the integrity protection now follows the same structure as the encryption section. What we meant was at least all of them. The “least” was written in term of capabilities. Since we apply a similar structure for the integrity section. The new document provides the different capabilities explicitly in specific requirements. </mglt> • For SEC-GEN-9 (and similar), is there a minimum set of options to authenticate? <mglt> No there is no minimum. The current document provides an explicit description similarly to the encryption section which I guess removes the confusion. We also clarify that in the text by specifying none one or multiple Geneve Options. The current document also clarify when the fixed part of the Geneve Header is concerned. This is performed using the Geneve Header (except Geneve Options) as there is no terminology for that part. </mglt> • In 5.4, the text states: It is strongly RECOMMENDED that the Geneve Header is both authenticated with anti replay protection. I am not sure what was meant with "both ... with" - did you mean to say "both authenticated and protected against replay"? If so, would it be possible to make this mandated? <mglt> The replay protection has undergo major changes. I believe the split between replay and integrity is now clearer. The current version mandates authentication is associated to anti-replay protection. </mglt> • The two Appendices on mapping TLS and IPSec to the requirements are useful, but I feel it would be helpful to systematically go through all the requirements for both options. As it is, I felt some where missing from the TLS appendix and pretty much all of them from the IPSec appendix. <mglt> The current version matches DTLS and IPsec with every operational requirements as well as Geneve security requirements. </mglt> • The TLS section contains some things that confused me, e.g.: TLS security is established by UDP destination ports TLS is for TCP, not UDP, for UDP DTLS is used - but perhaps I misunderstood? <mglt>You are correct. It is DTLS not TLS. We checked TLS is being replaced by DTLS when applied to Geneve.</mglt> Another example is around the comment about TLS not being able to provide padding etc. - as TLS is transport security , it is not transport security's responsibility to inject padding but it can transport it...? <mglt> In order to prevent traffic pattern recognition, a Geneve security mechanism need to be able to pad. What we wanted to highlight is that DTLS does not provide this ability and this has to be handled outside of DTLS. IPsec/ESP on the other hand make it possible. I believe the current proposal is clearer. </mglt> A third example is: TLS does not provide the ability for a transit device to authenticate the option before processing it If an integrity and authenticity-supporting TLS cipher suite is chosen, then I don't see why the above would be true - again, I may misunderstand something, but normally I would expect the TLS layer to verify and decrypt incoming messages and then hand off to the Geneve layer where option processing would occur? <mglt> What we wanted to point out was that NVE to NVE protected by DTLS prevents a transit node in the middle to authenticate the Geneve Option. The current text clarifies the scenario and explicitly clarify that end-to-end security is being design to prevent someone in the middle (like a transit device) to access the information. The current text also highlights that even when authentication only is used, the transit device will have the ability to access the information but not the ability to authenticate the information. </mglt> • As mentioned, the IPsec appendix seems short in comparison to the TLS one - should preferably systematically review IPsec against all the SEC-OP and SEC-GEN requirements just as the TLS appendix does. <mglt> The current version provide for both DTLS and IPsec a matching to all requirements. </mglt> One additional comment on this Appendix: However, the use of these security policies in a context of Geneve is not natively supported It is not clear to me why it would not be possible to use or support such policies in the context of Geneve? Moreover, would TLS policies be natively supported? <mglt> What we wanted to say I that this is not impossible, but some work / adaptation needs to be done. IPsec has a policy base architecture which is not the case for DTLS. However even for IPsec, additional integration would be needed as the required traffic selectors required for Geneve may not be available with current IPsec implementation. We tried to clarify this in the current text. In both cases, this is achievable, but requires some extra work to be done . </mglt> Thanks - and apologies again for the delay, /M _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
