Hi Greg, One example of this use case is described in draft-brockners-ippm-ioam-geneve
Jesse On Mon, Oct 22, 2018 at 2:34 AM Greg Mirsky <[email protected]> wrote: > > Hi Ilango, et al., > if I understand the text you're proposing: > Transit devices not interpreting Geneve headers (that may or may not include > Options) > SHOULD process Geneve packets as any other UDP packet and maintain > consistent forwarding behavior. > a transit node MAY process Geneve packets using Geneve layer information. > What are scenarios that would require such an option? How that functionality > controlled, advertised, and traceable by OAM? > > Regards, > Greg > > On Sun, Oct 21, 2018 at 9:22 PM Ganga, Ilango S <[email protected]> > wrote: >> >> Hi Daniel, >> >> >> >> Please see my responses inline. I think this should address all your >> comments. >> >> >> >> Thanks, >> >> Ilango >> >> >> >> >> >> From: Daniel Migault [mailto:[email protected]] >> Sent: Wednesday, October 17, 2018 7:28 AM >> To: Ganga, Ilango S <[email protected]> >> Cc: Bocci, Matthew (Nokia - GB) <[email protected]>; [email protected]; >> [email protected]; T. Sridhar <[email protected]> >> Subject: RE: [nvo3] Working Group Last Call and IPR Poll for >> draft-ietf-nvo3-geneve-08.txt >> >> >> >> Hi Illango, >> >> >> >> Thanks for the response, please see my comments. I believe they can be >> easily addressed in the next version. >> >> >> >> Yours, >> Daniel >> >> >> >> From: Ganga, Ilango S <[email protected]> >> Sent: Wednesday, October 17, 2018 1:45 AM >> To: Daniel Migault <[email protected]> >> Cc: Bocci, Matthew (Nokia - GB) <[email protected]>; [email protected]; >> [email protected]; T. Sridhar <[email protected]> >> Subject: RE: [nvo3] Working Group Last Call and IPR Poll for >> draft-ietf-nvo3-geneve-08.txt >> >> >> >> Hi Daniel, >> >> >> >> Thanks for your review and comments. Please see my responses inline. >> >> >> >> Regards, >> >> Ilango >> >> >> >> >> >> From: Daniel Migault [mailto:[email protected]] >> Sent: Friday, October 12, 2018 2:57 PM >> To: Ganga, Ilango S <[email protected]> >> Cc: Bocci, Matthew (Nokia - GB) <[email protected]>; [email protected]; >> [email protected] >> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for >> draft-ietf-nvo3-geneve-08.txt >> >> >> >> Hi, >> >> >> >> I reviewed the document. Please find my comments below. >> >> >> >> Yours, >> >> Daniel >> >> 3.4. Tunnel Header Fields >> >> C (1 bit): Critical options present. One or more options has the >> critical bit set (see Section 3.5). If this bit is set then >> tunnel endpoints MUST parse the options list to interpret any >> critical options. On endpoints where option parsing is not >> supported the packet MUST be dropped on the basis of the 'C' bit >> in the base header. If the bit is not set tunnel endpoints MAY >> strip all options using 'Opt Len' and forward the decapsulated >> packet. >> <mglt> >> I am fine with the text, but this may contradict that Opt Len is compared to >> the sum of option len. (see my comment next section). I guess that is a >> clarification to be made next section. >> </mglt> >> >> <Ilango> The text in this section reads fine; since the option header is >> defined in next section 3.5, it is appropriate to keep the text in that >> section. Also, please see response to next section. >> >> </> >> >> <mglt2>I will see the next section. </mglt2> >> >> >> 3.5. Tunnel Options >> >> >> Type (8 bits): Type indicating the format of the data contained in >> this option. Options are primarily designed to encourage future >> extensibility and innovation and so standardized forms of these >> options will be defined in a separate document. >> >> The high order bit of the option type indicates that this is a >> critical option. If the receiving endpoint does not recognize >> this option and this bit is set then the packet MUST be dropped. >> If the critical bit is set in any option then the 'C' bit in the >> Geneve base header MUST also be set. Transit devices MUST NOT >> drop packets on the basis of this bit. The following figure shows >> the location of the 'C' bit in the 'Type' field: >> >> 0 1 2 3 4 5 6 7 8 >> +-+-+-+-+-+-+-+-+ >> |C| Type | >> +-+-+-+-+-+-+-+-+ >> >> The requirement to drop a packet with an unknown critical option >> <mglt> >> maybe s/an unknown critical option/an unknown option with the critical bit >> set would be clearer. >> </mglt> >> >> >> >> <Ilango> The term critical option is described in section 3.4 and used in >> 3.5, so use of this term here to refer to an unknown critical option reads >> fine. Though for consistency with the sentence in section 3.5.1, we could >> also say “unknown options with C-bit set”. >> >> </> >> >> <mglt2> I am fine with your proposed change. </mglt> >> >> >> applies to the entire tunnel endpoint system and not a particular >> component of the implementation. For example, in a system >> comprised of a forwarding ASIC and a general purpose CPU, this >> does not mean that the packet must be dropped in the ASIC. An >> implementation may send the packet to the CPU using a rate-limited >> control channel for slow-path exception handling. >> >> R (3 bits): Option control flags reserved for future use. MUST be >> zero on transmission and ignored on receipt. >> >> Length (5 bits): Length of the option, expressed in four byte >> multiples excluding the option header. The total length of each >> option may be between 4 and 128 bytes. A value of 0 in the Length >> field implies an option with only the option header without the >> variable option data. >> >> >> >> <mglt> >> I understand the sentence below as a check between the sum of option length >> and Opt len. This does not seems related to the treatment of one option, and >> maybe should be moved up to the description of Opt Len in the Geneve Header >> section. >> >> >> >> <Ilango> This section is where the Tunnel Options are defined hence this is >> the most appropriate and right place for this text. >> >> </> >> >> >> >> <mglt2>I am fine with that as well, as long as you believe that is the right >> place.</mglt2> >> >> >> I also have an issue on how to interpret that sentence. When receiving a >> Geneve Packet, the following sentence prevent from jumping to Opt Len >> skipping off options. It could be understood as a mandatory check in which >> case (whether there is a C bit set in the Geneve Header or not) the >> terminating node to go through all options, read the Length sum them and >> them compare it to the Opt Len. If such check is mandatory, I am wondering >> if Opt Len in the Geneve Header is then limited for internal use of the >> terminating node. If that is something optional, maybe we should explicitly >> say it, or maybe detail when such comparison is expect to happen. >> </mglt> >> >> >> >> <Ilango> No, it does not prevent the nodes from skipping the options to >> reach the start of encapsulated payload. For example a transit node that >> does not process the options can skip over the options by using the Option >> length field in the Geneve header. The endpoints that process the options >> are the ones that need to do this check as stated in this sentence. >> >> For better clarity, we could add clarifying text to the sentence as follows: >> >> “…. invalid and MUST be silently dropped if received by an endpoint that >> processes the options.” >> >> </> >> >> <mglt2>I believe that is clarifying to add the text you proposed.</mglt2> >> >> >> Packets in which the total length of all >> options is not equal to the 'Opt Len' in the base header are >> invalid and MUST be silently dropped if received by an endpoint. >> >> >> >> >> Gross, et al. Expires April 10, 2019 [Page 15] >> >> Internet-Draft Geneve Protocol October 2018 >> >> >> Variable Option Data: Option data interpreted according to 'Type'. >> >> >> 3.5.1. Options Processing >> >> Geneve options are intended to be originated and processed by tunnel >> endpoints. However, options MAY be interpreted by transit devices >> along the tunnel path. Transit devices not processing Geneve headers >> <mglt> >> I am reading Genve header as a Geneve option of the Genve header, but not >> the fixed Geneve header. If that is correct, It may be clearer to use Genve >> option instead of Geneve header as to avoid confusion on the scope of >> transit device. From the text above, using Geneve header could mean the fix >> header, in which case it may make easier to figure out the difference >> between transit device and tunnel endpoint. >> </mglt> >> >> <Ilango> As illustrated clearly in sections 3.1 and 3.2 Geneve header >> includes fixed length headers and options. So in this statement, Geneve >> header includes options. >> >> </> >> >> <mglt2> >> >> This is I believe English clarification and English is not my native >> language, so I am only providing my feed back, but differ to others on what >> to do. >> >> >> >> The statement as I read it says that transit devices MAY interpret options. >> Which I interprete as the scope of transit device is limited to these >> options and transit device are not supposed to interprete the fix header. >> >> >> >> The following sentence says transit devices not interpreting the Geneve >> Header….” Which I read as fix header and option. While the statement is >> true, as header include option, I found it somehow confusing to introduce >> the fix header at that stage, as my understanding is that transit device are >> limited to the options. >> >> >> >> Re-reading the text I also believe - if that is correct -, we should specify >> that transit devices MAY treat a subset of the options. </mglt2> >> >> >> >> <Ilango2> The header may include options, and a transit device has to >> interpret the header to get to the options. We will rephrase the text to the >> following for clarity. >> >> Transit devices not interpreting Geneve headers (that may or may not include >> Options) >> >> SHOULD process Geneve packets as any other UDP packet and maintain >> >> consistent forwarding behavior. >> >> </Ilango2> >> >> >> SHOULD process Geneve packets as any other UDP packet and maintain >> consistent forwarding behavior. >> >> In tunnel endpoints, the generation and interpretation of options is >> determined by the control plane, which is out of the scope of this >> document. However, to ensure interoperability between heterogeneous >> devices some requirements are imposed on options and the devices that >> process them: >> >> o Receiving endpoints MUST drop packets containing unknown options >> with the 'C' bit set in the option type. Conversely, transit >> devices MUST NOT drop packets as a result of encountering unknown >> options, including those with the 'C' bit set. >> >> o Some options may be defined in such a way that the position in the >> option list is significant. Options or their ordering, MUST NOT >> be changed by transit devices. >> >> o An option MUST NOT affect the parsing or interpretation of any >> other option. >> >> >> >> >> <mglt> >> In case we have a option providing authentication, such option may affect >> the interpretation of the other options. s/interpretation/ndependance may >> not be better.... I think what we want to say is that option MUST be able to >> be processed in any order or in parallel. I am fine with the text if we do >> not find something better. >> </mglt> >> >> <Ilango> This is a good point, however we believe that this text captures >> the intent. >> </> >> >> <mglt2>The problem I have is that the current text prevents security >> options, so I guess some clarification should be brought to clarify the >> intent.</mglt2> >> >> <Ilango2> The intent of this statement is, parsing and interpretation of >> options is not dependent on one another. It does not preclude processing of >> any security option. >> >> </Ilango2> >> >> >> 6. Security Considerations >> >> As encapsulated within an UDP/IP packet, Geneve does not have any >> inherent security mechanisms. As a result, an attacker with access >> to the underlay network transporting the IP packets has the ability >> to snoop or inject packets. >> >> >> <mglt> >> I believe that monitoring is also an attack that should be mentioned. >> </mglt> >> >> <Ilango> Snooping covers the case of monitoring as well, so I don’t see a >> need for additional text. >> >> </> >> >> >> >> <mglt2>I understood “snoop” as being more active than passive monitoring. >> I am fine with the text.</mglt2> >> >> >> >> >> Legitimate but malicious tunnel >> endpoints may also spoof identifiers in the tunnel header to gain >> access to networks owned by other tenants. >> >> <mglt> >> I think Legitimate and malicious are not compatible. This is probably a >> "corrupted legitimate tunnel endpoint. I think we should also add that >> securing the geneve tunnel cannot prevent this type of threat. >> </mglt> >> >> <Ilango> Yes, we could change this to “Compromised endpoints may also spoof >> ….”. >> >> The next paragraph states that tunnel endpoints should only be operated in >> environments controlled by the service provider, this could potentially >> mitigate the threat of endpoints from getting compromised. >> >> </> >> >> >> >> >> Within a particular security domain, such as a data center operated >> by a single service provider, the most common and highest performing >> security mechanism is isolation of trusted components. Tunnel >> traffic can be carried over a separate VLAN and filtered at any >> untrusted boundaries. In addition, tunnel endpoints should only be >> operated in environments controlled by the service provider, such as >> the hypervisor itself rather than within a customer VM. >> >> >> When crossing an untrusted link, such as the public Internet, IPsec >> [RFC4301] may be used to provide authentication and/or encryption of >> the IP packets formed as part of Geneve encapsulation. >> >> <mglt> >> I understand the first paragraph as the one where the service provider owns >> the tenant, the geneve overlay as well as the infrastructure in which case, >> isolation and separation is performed by VLAN. The second paragraph mentions >> that the previously described data centers can be interconnected using a >> secure link. I consider this case as the one building a trusted environment >> to run Geneve overlay. >> >> >> >> I believe the security considerations for Geneve may be more focused on >> Genve itself, that is how the Geneve overlay network may remain secure while >> not relying on the security provided by the infrastructure. In that extent >> it help to consider the case where tenants, Geneve overlay provider, >> infrastructure providers are different entities. >> </mglt> >> >> <Ilango>The operator could use multiple security mechanisms, which could >> span across layers. For example, the operator could very well choose >> security mechanisms already provided by the underlay to secure their overlay >> networks. </> >> >> <mglt2>I understand, but it seems to me that the important things here are : >> >> Corrupted legitimate tunnel endpoint is not expected to be addressed by >> Geneve security mechanisms. >> Geneve overlay deployment relies on reliable (trusted) tunnel endpoints. >> This later point may be achieved in one or the other ways. You provide one >> way to do it, another way could be simply trusting your infrastructure >> provider. >> >> I believe that it may be more helpful to explicitly provide a trust model, >> illustrating it and leave the door open to other solutions. My current >> reading is that one way is proposed, but we may lack some information to >> evaluate if other ways can be acceptable as well.</mglt2> >> >> <Ilango2> I am not sure where you are going with this. The intent is to >> highlight potential risks and outline how to mitigate such risks, this >> paragraph describes the best practices used to secure a tunnel endpoint. We >> believe that this is sufficiently illustrated in the description. >> >> </Ilango2> >> >> >> >> Geneve does not otherwise affect the security of the encapsulated >> packets. As per the guidelines of BCP72 [RFC3552], the following >> sections describe potential security risks that may be applicable to >> Geneve deployments and approaches to mitigate such risks. It is also >> noted that not all such risks are applicable to all Geneve deployment >> scenarios, i.e., only a subset may be applicable to certain >> deployments. So an operator has to make an assessment based on their >> network environment and determine the risks that are applicable to >> their specific environment and use appropriate mitigation approaches >> as applicable. >> >> >> >> Gross, et al. Expires April 10, 2019 [Page 21] >> >> Internet-Draft Geneve Protocol October 2018 >> >> >> 6.1. Data Confidentiality >> >> Geneve is a network virtualization overlay encapsulation protocol >> designed to establish tunnels between network virtualization end >> points (NVE) over an existing IP network. It can be used to deploy >> multi-tenant overlay networks over an existing IP underlay network in >> a public or private data center. The overlay service is typically >> provided by a service provider, for example a cloud services provider >> or a private data center operator. >> >> <mglt> >> The text above seems to assume that the service overlay is always provided >> by the cloud provider (i.e. infrastructure provider). I do not believe this >> assumption is always true. >> >> A company may sell a system based on Geneve and may be willing to provide >> some protection against the infrastructure provider. >> </mglt> >> >> <Ilango> Yes, “typically” means not always, but it is the most common use >> case.</> >> >> <mglt2> I believe it is good we mention a use case we envisioned as being >> the most common use case, but I also think the security consideration should >> not only be based on one deployment. </mglt2> >> >> <Ilango2> We will add the following statement to the end of this paragraph >> for clarification. >> >> “This may or not may be the same provider as an underlay service provider” >> >> </Ilango2> >> >> >> Due to the nature of multi- >> tenancy in such environments, a tenant system may expect data >> confidentiality to ensure its packet data is not tampered with >> (active attack) in transit or a target of unauthorized monitoring >> (passive attack). A tenant may expect the overlay service provider >> to provide data confidentiality as part of the service or a tenant >> may bring its own data confidentiality mechanisms like IPsec or TLS >> to protect the data end to end between its tenant systems. >> <mglt> >> When a tenant is securing its communication using TLS or IPsec, there are >> still some metadata that the Geneve overlay MAY protect - typically (IP, >> ports). >> </mglt> >> >> <Ilango> The intent of this statement is a tenant may bring its own data >> confidentiality mechanism to protect its data without relying on the service >> provider. This is irrespective of security mechanisms provided by the >> service provider.</> >> >> >> >> <mglt2>I would suggest that we clearly state that data confidentiality >> provided by the tenant does not prevent the geneve overlay to provide it. >> From my reading of the text, it seems that tenant security is sufficient.I >> believe that is a bit misleading. </mglt2> >> >> <Ilango2>The text does not preclude a service provider to provide security >> mechanisms when the tenant brings its own security. I am not sure where you >> are getting this interpretation. If needed we can remove the last sentence >> of the second paragraph, if that addresses your concern. >> >> <Delete the following sentence from the end of next paragraph> >> >> The operator may choose not to enable the encryption if, >> >> for example, the packet data is already encrypted by the tenant >> >> system. >> >> </Ilango2> >> >> If an operator determines data confidentiality is necessary in their >> environment based on their risk analysis, for example as in multi- >> tenant environments, then an encryption mechanism SHOULD be used to >> encrypt the tenant data end to end between the NVEs. The NVEs may >> use existing well established encryption mechanisms such as IPsec, >> DTLs, etc., The operator may choose not to enable the encryption if, >> for example, the packet data is already encrypted by the tenant >> system. >> >> 6.1.1. Inter-data center traffic >> >> A tenant system in a customer premises (private data center) may want >> to connect to tenant systems on their tenant overlay network in a >> public cloud data center or a tenant may want to have its tenant >> systems located in multiple geographically separated data centers for >> high availability. Geneve data traffic between tenant systems across >> such separated networks should be protected from threats when >> traversing public networks. Any Geneve overlay data leaving the data >> center network beyond the operator's security domain, for example >> over the public Internet, SHOULD be secured by encryption mechanisms >> such as IPsec or other VPN mechanisms to protect the communications >> between the NVEs when they are geographically separated over >> untrusted network links. Implementation of specific data protection >> mechanisms employed between data centers is beyond the scope of this >> document. >> >> <mglt> >> I see that inter-data center traffic protection is more IP traffic >> protection than specific to Geneve. I think we can also safely go for a MUST >> be secured when the traffic is sent to the wild Internet. >> </mglt> >> >> <Ilango> Inter-data center need not always mean internet, for example it >> could be dedicated secure links. In which case the operator may decide to >> rely on the underlying security of the dedicated links, so we believe >> “SHOULD” is more appropriate here.</> >> >> <mglt2>I am reading this as two different implementations of a secure link >> between the data center. The requirement is that this link MUST be secured. >> One way to provide a secure link is to have a dedicated line in which case >> we SHOULD encrypt the traffic. Another way to establish a connection over >> the internet in which case the traffic MUST be encrypted. >> >> I believe it would help to clarify why SHOULD is mentioned here. One reason >> of the confusion is that only the link over internet is mentioned. </mglt2> >> >> <Ilango2>The operator based on their risk assessment should enable >> appropriate security mechanism. >> >> We could remove “for example over public Internet” from this sentence and >> this should address your concern. >> >> </Ilango2> >> >> >> 6.2. Data Integrity >> >> Geneve encapsulation is used between NVEs to establish overlay >> tunnels over an existing IP underlay network. In a multi-tenant data >> center, a rogue or compromised tenant system may try to launch a >> >> >> >> Gross, et al. Expires April 10, 2019 [Page 22] >> >> Internet-Draft Geneve Protocol October 2018 >> >> >> passive attack such as monitoring the traffic of other tenants, or an >> active attack such as spoofing or trying to inject unauthorized >> Geneve encapsulated traffic into the network. To prevent such >> attacks, an NVE MUST not propagate Geneve packets beyond the NVE to >> tenant systems and SHOULD employ packet filtering mechanisms so as >> not to forward unauthorized traffic between TSs in different tenant >> networks. >> >> <mglt>I believe that replayed traffic is also unauthorized in this case and >> may be considered in the description.</mglt> >> >> <Ilango> Unauthorized traffic should include all type of unauthorized >> traffic including traffic such as spoofing, replay, etc.,. This is minor >> editorial, if need be we could rephrase to provide clarity “unauthorized >> traffic such as spoofing, replay, etc.” >> >> </> >> >> <mglt2>I agree this is minor editorial, but the use of UDP eases such >> attacks, so I think it is important this appears in the security >> consideration.</mglt2> >> >> <Ilango2> Ok, we will rephrase to provide clarity >> >> “unauthorized traffic such as spoofing, replay, etc.” >> >> </Ilango2> >> >> >> >> <END> >> >> >> >> On Thu, Oct 11, 2018 at 1:34 PM Ganga, Ilango S <[email protected]> >> wrote: >> >> As a co-author, I believe the document is ready for publication as a >> standards track RFC. >> >> >> >> Thanks, >> >> Ilango >> >> >> >> >> >> From: Bocci, Matthew (Nokia - GB) [mailto:[email protected]] >> Sent: Tuesday, October 9, 2018 2:08 AM >> To: NVO3 <[email protected]> >> Cc: [email protected] >> Subject: Working Group Last Call and IPR Poll for >> draft-ietf-nvo3-geneve-08.txt >> >> >> >> This email begins a two-week working group last call for >> draft-ietf-nvo3-geneve-08.txt. >> >> >> >> Please review the draft and post any comments to the NVO3 working group >> list. If you have read the latest version of the draft but have no comments >> and believe it is ready for publication as a standards track RFC, please >> also indicate so to the WG email list. >> >> >> >> We are also polling for knowledge of any undisclosed IPR that applies to >> this document, to ensure that IPR has been disclosed in compliance with IETF >> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> If you are listed as an Author or a Contributor of this document, please >> respond to this email and indicate whether or not you are aware of any >> relevant undisclosed IPR. The Document won't progress without answers from >> all the Authors and Contributors. >> >> >> >> Currently there are two IPR disclosures against this document. >> >> >> >> If you are not listed as an Author or a Contributor, then please explicitly >> respond only if you are aware of any IPR that has not yet been disclosed in >> conformance with IETF rules. >> >> >> >> This poll will run until Friday 26th October. >> >> >> >> Regards >> >> >> >> Matthew and Sam >> >> _______________________________________________ >> 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
