Hi Greg, These comments seem to be mostly about the specifics of draft-brockners-ippm-ioam-geneve rather than the infrastructure that Geneve provides. I think the best way to address them might be to direct the comments to the authors of that draft in a separate thread. That should allow more people to see them rather than being buried in this thread.
Several of your comments also do not align with my understanding of draft-brockners-ippm-ioam-geneve - they appear to be referencing properties of your OAM proposals rather than that which is in the draft. I would suggest that you re-read the draft to make sure that it matches what you believe. However, I will defer to the authors of that draft for further comment. Jesse On Thu, Oct 25, 2018 at 8:26 PM Greg Mirsky <[email protected]> wrote: > > Hi Jesse, > I have some concerns with what is proposed in > draft-brockners-ippm-ioam-geneve. The main - it requires additional > capability negotiation to avoid the data packets being dropped because of the > egress Geneve node not supporting iOAM and fails to parse the iOAM message. > Second - inconsistency in the use of O-bit. The draft states (though without > proper use of the normative language): > Packets that carry IOAM > data fields in addition to regular data payload / customer traffic > must not set the O bit. Packets that carry only IOAM data fields > without any payload must set the O bit. > That, in my opinion, is confusing and inconsistent. iOAM requests allocation > of two Next Protocol values and that should be sufficient. Why the value of > O-bit depends on whether there is or there is no data payload immediately > following iOAM message? How does that help in processing? > > Regards, > Greg > > On Thu, Oct 25, 2018 at 3:44 PM Jesse Gross <[email protected]> wrote: >> >> 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
