descriptive and independent.=C2=A0 This en=
ables parallelism in option
processing and reduces implementation comp=
lexity.=E2=80=9D
descriptive and independent.  This enables parallelism =
in option
processing and reduces =
implementation complexity.=E2=80=9D
descriptive and independen=
t.=C2=A0 This enables parallelism in option
processing and reduces implementation complexity.=E2=80=9D<=
u>
descriptive and independent.  This enables parallelis=
m in option
processing and reduces implementation complexity."<=
u>
descriptive and independent.=C2=A0 This enables parall=
elism in option
processing and reduces implementation complexity."=
;
descriptive and independent.  This enables parallelis=
m in option
processing and reduces implementation complexity."<=
u>
=C2=A0SEC-GEN-13: Geneve Security mechanism MUST provide mea=
ns for a
transi=
t device to authenticate data prior it is being processed.
=C2=A0
This requirement is not consistent with Geneve archite=
cture, hence remove this requirement. 
=C2=A0
SEC-GEN-3,4 and SEC-GEN-5,6,7: All =
these SEC-GEN requirements (for partial encryption) are optimizations which=
 should not be part of requirements especially with =E2=80=9CMUST=E2=80=9D =
mandates. =C2=A0
The main objective of requirements is for protecting the tr=
affic between the NVEs (privacy/integrity/confidentiality). Applying partia=
l encryption is more of an optimization than to mitigate any specific threa=
t especially when other existing mechanisms are available to protect commun=
ications between NVEs.=C2=A0 Specify the use cases where options need to se=
lectively encrypted. What is the threat model and why such partial encrypti=
on of options is required.=C2=A0 So adding requirements for partial headers=
/payload/options could not be considered as a security requirement to addre=
ss a security threat, hence these requirements must not be included.=C2=A0 =

=C2=A0

SEC-OP-5: A secure deployment of a Geneve=
 overlay MUST evaluate
the risk associated to a change of the Geneve Outer Header, Geneve<=
/span>
Header (excluding Geneve Options) and Geneve Option. When a ris=
k
analysis concludes that the risk is too high, this piece of
information MUST be authenticated.
=C2=A0
SEC-OP-6: A secure deployment of a Geneve=
 overlay SHOULD
<=
span class=3D"m_3807981396123409526gmail-m_-7797871005321186789fontstyle01"=
>authenticate communications between NVE to protect the Geneve
=
Overlay infrastructure as well as the Tenants System=E2=80=99s
=
communications (Geneve Packet). A Geneve overlay provider MAY
d=
isable authentication of the inner packet and delegates it to theTenant Systems when communications between Tenant=E2=80=99s System is
secured. This is NOT RECOMMENDED. Instead, it is RECOMMENDED
that mechanisms binds the inner payload to the Geneve Header. To
prevent injection between virtualized network, it is strongly RECOMMENDED that at least the Geneve Header without =
Geneve Options
=
is authenticated.
=C2=A0
What specific risk does the operato=
r see based on the threat model and what piece of information should be aut=
henticated, =C2=A0
why this should be selectively authenticated as called =
for in these requirements? Can you specify the usage model for these requir=
ements.

SEC-OP-7: A secure deployment of a Geneve=
 overlay SHOULD NOT<=
br>process data prior authentication. If that is not possible, the=

Geneve overlay provider SHOULD evaluate its impact.
=C2=A0
This is too generic, what should th=
e operator do with this requirement, =C2=A0=E2=80=9C=E2=80=A6SHOUD evaluate=
 its impact=E2=80=9D?

=
=C2=A0
SEC-GEN-8: Geneve security mechanism MUST=
 provide the capability
to authenticate the inner payload.

<=
/span>
SEC-GEN-9: Geneve security mechanism SHOU=
LD provide the capability
to partially authenticate the inner payload header.

SEC-GEN-10: Geneve security mechanism MUS=
T provide the capability
to authenticate a single or a set of options while leave other
Geneve Option unauthenticated. Reversely, a Geneve security
mechanism MUST be able to leave a Geneve option unauthenticated,
while encrypting the others.
=C2=A0
SEC-GEN-11: Geneve security mechanism MUS=
T provide means toauthenticate the information of Geneve Header (Geneve Option
=
excluded). Reversely, a Geneve security mechanism MUST be able to<=
br>leave unauthenticated Geneve header information (Geneve Options=

excluded) while authenticating the other.=

=C2=A0
What is the threat model and what i=
s use case that is driving the partial encryption or authentication of opti=
ons? =C2=A0

=C2=A0
SEC-GEN-13: Geneve Security mechanism MUS=
T provide means for a
transit device to authenticate data prior it is being processed.<=
/u>
=C2=A0
This requirement is not consistent =
with Geneve architecture, hence remove this requirement. 
=C2=A0

SEC-OP-8: A secure deployment of a Geneve=
 overlay MUST evaluate
the communications subject to replay attacks. Communications that
are subject to this attacks MUST be authenticated with an anti
replay mechanism. Note that when partial authentication is
provided, the part not covered by the authentication remains a
surface of attack. It is strongly RECOMMENDED that the Geneve=

Header is authenticated with anti replay protection
=C2=A0
What is the threat model and use ca=
se that calls for partial authentication. Same comments as partial encrypti=
on applies to this comment as well.
=C2=A0

SEC-OP-9: A secure deployment of a Geneve=
 overlay MUST define the
security policies that associates the encryption, and
<=
span class=3D"m_3807981396123409526gmail-m_-7797871005321186789fontstyle01"=
>authentication associated to each flow between NVEs.<=
/span>
=C2=A0
SEC-OP-10: A secure deployment of a Genev=
e overlay SHOULD define
distinct material for each flow. The cryptographic depends on the<=
/span>
nature of the flow (multicast, unicast) as well as on the secur=
ity
mechanism enabled to protect the flow.=

=C2=A0
SEC-GEN-15: A Geneve security mechanism M=
UST be managed viasecurity policies associated for each traffic flow to be
pr=
otected. Geneve overlay provider MUST be able to configure NVEs
<=
span class=3D"m_3807981396123409526gmail-m_-7797871005321186789fontstyle01"=
>with different security policies for different flows. A flow MUSTbe identified at minimum by the Geneve virtual network identifier
and the inner IP and transport headers, and optionally additional
fields which define a flow (e.g., inner IP DSCP, IPv6 flow id,
Geneve options)
=C2=A0
=C2=A0
It is not clear as to what threat i=
s being addressed by requiring flow level granularity.=C2=A0 If communicati=
on between NVE to NVE need be encrypted/authenticated, then, at a minimum, =
security policy should be applied for the traffic between, for example, NVE=
 A to NVE B or NVE A to NVE C, etc.=C2=A0 
Any granularity =
beyond that is not a requirement to address any threat. This is undue burde=
n on NVEs, not needed to address specific threat or define the threat model=
. =C2=A0=C2=A0Hence remove flow level granularity requirement.=C2=A0 

=C2=A0=

SEC-GEN-17: A Geneve security mechanisms,=
 when multicast is used,
packets,MUST be able to assign distinct cryptographic group keys<=
/span>
to protect the multicast packets exchanged among the NVEs withi=
n
different multicast groups. Upon receiving a data packet, an<=
/span>
egress Geneve NVE MUST be able to verify whether the packet is<=
/span> 
sent from a proper ingress NVE which is a=
uthorized to forward that
packet.
=C2=A0
Need to define the threat model for=
 multicast, define multicast, =C2=A0most deployments multicast is implement=
ed using multiple unicast. So the requirement does not apply to such deploy=
ments.
=C2=A0

8. Appendix<=
/span>
=C2=A0
I suggest to remove the entire Appe=
ndix from the document. Let us first agree on the requirements before we ge=
t into mapping different solutions to meet the requirements. 

=C2=A0
Thanks,
Ilango