Skip to main content

A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)
RFC 9061

Revision differences

Document history

Date Rev. By Action
2021-07-14
14 (System)
Received changes through RFC Editor sync (created alias RFC 9061, changed title to 'A YANG Data Model for IPsec Flow Protection Based on Software-Defined …
Received changes through RFC Editor sync (created alias RFC 9061, changed title to 'A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)', changed abstract to 'This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) Controller. It considers two main well-known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic.

This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.', changed pages to 90, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-07-14, changed IESG state to RFC Published)
2021-07-14
14 (System) RFC published
2021-06-25
14 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9061">AUTH48-DONE</a> from AUTH48
2021-06-10
14 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9061">AUTH48</a>
2021-05-11
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-05-03
14 Bernie Volz Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2021-04-23
14 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-04-23
14 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-04-23
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-04-21
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-04-15
14 (System) RFC Editor state changed to EDIT
2021-04-15
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-04-15
14 (System) Announcement was received by RFC Editor
2021-04-15
14 (System) IANA Action state changed to In Progress
2021-04-15
14 (System) Removed all action holders (IESG state changed)
2021-04-15
14 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-04-15
14 Cindy Morgan IESG has approved the document
2021-04-15
14 Cindy Morgan Closed "Approve" ballot
2021-04-15
14 Cindy Morgan Ballot approval text was generated
2021-04-15
14 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-03-25
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-03-25
14 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-14.txt
2021-03-25
14 (System) New version approved
2021-03-25
14 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Gabriel Lopez-Millan <gabilm@um.es>, Rafael Marin-Lopez <rafa@um.es>
2021-03-25
14 Rafael Marin-Lopez Uploaded new revision
2021-03-01
13 (System) Changed action holders to Rafael Marin-Lopez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan (IESG state changed)
2021-03-01
13 Roman Danyliw IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::AD Followup
2021-03-01
13 Benjamin Kaduk
[Ballot comment]
A huge thanks for the many thoughtful updates in the -13; they do a great
job of resolving my discuss and comment points …
[Ballot comment]
A huge thanks for the many thoughtful updates in the -13; they do a great
job of resolving my discuss and comment points from the -12 and have really
improved the document a lot.

Section 5

  In terms of security, IKE case provides better security properties
  than IKE-less case, as discussed in section Section 8.  The main
  reason is that the NSFs generate the session keys and not the I2NSF
  Controller.

nit: s/section Section/Section/

Section 5.2

  In the IKE case, the I2NSF Controller MAY need to configure the
  affected NSF with the new IKEv2, SPD and PAD information.

nit: s/MAY/may/

  imply avoiding contact with the I2NSF Controller.  Finally, the I2NSF
  Controller MAY also need to send new parameters (e.g., a new fresh
  PSK for authentication) to the NSFs which had IKEv2 SAs and IPsec SAs
  with the affected NSF.

nit: s/MAY/may/

Section 6.1.2

      grouping lifetime {
        [...]
        leaf bytes {
          type yang:counter64;
          default 0;
          description
            "If the IPsec SA processes the number of bytes
            expressed in this leaf, the IPsec SA expires and
            SHOULD be rekeyed. The value 0 implies
            infinite.";

Since this is the *limit*, it should just be a uint64; the counter type
should be used for the statistics, not the configured limit.
My apologies for being sloppy in in writing my earlier comment; I can
see how you thought that I was suggesting to use the "counter64" type
here, but that was not my intent.

        list dscp-mapping {
          [...]
          leaf inner-dscp {
            type inet:dscp;
            description
              "The DSCP value of the inner IP packet. If this
              leaf is not defined it means ANY inner DSCP value";
          }

We should probably specify one way or the other if it's allowed to have
(e.g.) one element of this list that has both inner+outer DSCP values,
and another element that has only the outer value (to match "everything
else").  That is, is the "ANY inner DSCP value" really "any", or "any
not matching other configuration"?

Section 6.2.3

      typedef autostartup-type {
        [...]
          enum start {
            description
              "IKE/IPsec configuration is loaded
              and transferred to the NSF's kernel, and the
              IKEv2 based IPsec SAs are established
              immediately without waiting any packet.";

nit: "waiting for"

              container eap-method {
                when "../auth-method = 'eap'";
                leaf eap-type {
                  type uint64 {range "1 .. 4294967295"; }

[I don't really understand why we need uint64 vs uint32 with the
explicit range limit like that, but it's not harmful.]

Section 6.3.3

              container tunnel {
                when "../mode = 'tunnel'";
                uses nsfikec:tunnel-grouping;
                leaf-list dscp-values {
                  type inet:dscp;
                  description
                    "DSCP values allowed for packets carried over
                    this IPsec SA. If no values are specified, no
                    DSCP-specific filtering is applied";

nit: It might be worth a couple more words to clarify that this is for
ingress packets received, and thus the value that would be the "inner"
DSCP value in the other configuration we have for the DSCP mapping.

                container replay-window {

If I understand correctly, the 'w', 't', and 'b' paremeters herein are
related, with the gap t-b usually (always?) being of value w.  I don't
know enough about YANG constraints to say whether they should be used to
recognize this relationship, but even if not, some prose might be in
order.

Section 8.2

When people say that "encryption algorithms [...] MUST have, at least,
the same strength as the algorithms used [...]" we like to see clarity
on how the "strength" is measured.  In this case it's probably fairly
clear to most readers, but spelling out the bit strength of the
symmetric cipher is probably still worthwhile.
2021-03-01
13 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from No Record
2021-02-27
13 Benjamin Kaduk
[Ballot comment]
[This is to some extent an interim "note to self" state and may not be
of much value to other observers.  The -13 …
[Ballot comment]
[This is to some extent an interim "note to self" state and may not be
of much value to other observers.  The -13 clearly addresses the DISCUSS
points I had on the -12, so removing the Discuss.  The non-DISCUSS comments
I had on the -12 are preserved below, as verifying which (if any) still remain
valid will take a little time to investigate.]

Abstract

We should not use unexpanded acronyms like SPD, SAD, and PAD in the
abstract unless there are very well-known.

Section 1

  [RFC6071].  In these cases, hosts, gateways or both may act as NSFs.
  Consideration for the host-to-gateway scenario is out of scope.

Is there anything to say about what gaps would need to be filled in
order to address the host-to-gateway case (vs how much of the mechanisms
defined herein could be reused)?

  the I2NSF Controller and the NSF.  Using YANG data modelling language
  version 1.1 [RFC7950] and based on YANG models defined in
  [netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
  7296
[RFC7296], this document defines the required interfaces with a
  YANG model for configuration and state data for IKE, PAD, SPD and SAD

RFCs 4301 and 7296 do not define YANG models.  Is the intent to say that
this is based on YANG models defined in netconf-vpn and
I-D.tran-ipsecme-yang, and the data structures defined in RFC 4301 and
RFC 7296?

  o  To define the interfaces required to manage and monitor the IPsec
      SAs in the NSF from a I2NSF Controller.  YANG data models are
      defined for configuration and state data for IPsec and IKEv2
      management through the I2NSF NSF-Facing interface.  Thus, this
      document does not define any new protocol.

It might perhaps be worth saying that the YANG models can be used via
existing protocols such as NETCONF and RESTCONF.

Section 3

  The following term is defined in [RFC6437]:

  o  Flow/traffic flow.

That does not seem to be used as a single term in RFC 6473; perhaps it's
best to say that they are two terms that are related or have identical
definition/usage.

Section 4.1

  flexible management of IPsec SAs in flow-based NSFs.  In order to
  support this capability in the IKE case, a YANG data model for IKEv2,
  SPD and PAD configuration data, and for IKEv2 state data MUST be
  defined for the I2NSF NSF-Facing Interface.

I think this is probably better as a descriptive "needs to" than a BCP
14
"MUST".

Section 4.2

We should perhaps say something before the figure about what the I2NSF
User does, in order to justify their inclusion in the figure (or
otherwise introduce the figure before it appears).

Section 5.1

  IPsec SAs management.  With the YANG data models defined in this
  document the I2NSF Controller can configure and conduct the rekey

Does the "and conduct" apply only to the IKE-less case, or the IKE-ful
one as well?  If only the IKE-less case we might consider some
additional notation such as "and, as needed, conduct".

Section 5.2

  In the IKE case, the I2NSF Controller will configure the affected NSF
  with the new IKEv2, SPD and PAD information.  It has also to send new
  parameters (e.g. a new fresh PSK for authentication) to the NSFs
  which have IKEv2 SAs and IPsec SAs with the affected NSF.  Finally,

It does not seem intuitively obvious to me that the controller *always*
has to send new parameters to the other NSFs (that have SAs with the
affected NSF).  E.g., for IKE-ful SAs that use certificate
authentication, what would need to change on the other NSFs?

  Alternatively, IKEv2 configuration MAY be made permanent between NSFs
  reboots without compromising security by means of the startup

Similarly, this MAY seems to require that the previous paragraph has
some hedging langauge that the procedures it describes are only one
possible option (with this paragraph being the other option).

Section 5.3

  some of the peers or both are located behind a NAT.  If there is a
  NAT network configured between two peers, it is required to activate

I am not familiar with "NAT network" as a term; is there a reference for
it?

  the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],

Why is TLS needed?  I understand that RFC 8229 talks about how it can be
done, but why is that necessary here?

  configured between two hosts, and apply the required policies to both
  NSFs besides activating the usage of UDP or TCP/TLS encapsulation of

(TLS again)

Section 6

  In order to support the IKE and IKE-less cases we have modeled the
  different parameters and values that must be configured to manage

The use of the first person is uncommon in RFCs; phasing like "models
are provided for the different parameters and values [...]" is more
common.

Section 6.1

We have a 'spd' tree in the IKE-ful model, so it's a bit surprising that
we don't match the treatment of the IKE-less model and say that the SPD
model has mainly been extracted from [parts of] RFC 4301.

(side note?) The tree diagram apparently doesn't have a good way of
showing the "when" relationship between (e.g.) auth-method and the
sibling nodes (eap-method, pre-shared, etc.), which confused me briefly.

Using string names instead of YANG references for correlating the PAD
entries is rather surprising to me.

  to be secured (local/remote subnet and ports, etc.) and how must be
  protected (AH/ESP, tunnel/transport, cryptographic algorithms, etc.);

I think that AH support was present in a previous version of the
document but has since been removed, so we should not mention AH here.

Section 6.2

  o  Each IPsec policy (spd-entry) contains one traffic selector,
      instead of a list of them.  The reason is that we have observed
      actual kernel implementations only admit a single traffic selector
      per IPsec policy.

It's not entirely clear that we need to cripple the overall model just
because some implementations would not support the full functionality.
My understanding is that having many traffic selectors for a single
policy (or SA, which has similar text later in this section) can be
quite useful in some cases.

  o  Combined algorithms have been removed because encryption
      algorithms MAY include authenticated encryption with associated
      data (AEAD).

A reference here would be helpful (IIUC, the "MAY" here is in effect
quoting the external document, and not a new requirement).
(Likewise for the corresponding SAD-model item.)

  The notifications model has been defined using as reference the
  PF_KEYv2 standard in [RFC2367].

RFC 2367 is only an Informational document, so calling it a "standard"
(as opposed to a "protocol" or "specification" may not be the best
choice.

    |    |  +--rw protocol-parameters? ipsec-protocol-parameters

Isn't this type nsfikec:ipsec-protocol-parameters?

  absence of an IKE software in the NSF: traffic direction to apply the
  IPsec policy, and a value to link an IPsec policy with its associated
  IPsec SAs.  [...]

Maybe "a 'requid' value to link [...]" since it is otherwise a little
hard to find by searching?

Section 8

  On the one hand, it is important to note that there MUST exist a
  security association between the I2NSF Controller and the NSFs to
  protect the critical information (cryptographic keys, configuration
  parameter, etc.) exchanged between these entities.

We should probably state explicitly that the nature of and means to
create that SA is out of scope for this specification (i.e., it's part
of device provisioning or onboarding).

  this information.  Although we can assume this attack is not likely
  to happen due to the assumed security measurements to protect the
  I2NSF Controller, it still deserves some analysis in the hypothetical
  case that the attack occurs.  The impact is different depending on

I don't think this sentence actually adds any value; whether or not the
attack is likely, the potential consequences are significant enough that
we have to document it.

Section 8.1

                                                        Alternatively,
      the NSF could generate the private key and export only the public
      key to the I2NSF Controller.

(Again, the mechanisms by which to do this are outside the scope of this
specification.  We do have some text like this for the following bullet
regarding certificates, which could easily be repurposed for use here.)

Section 10.2

Many of these entries don't really contain sufficient information to
unambiguously locate the intended reference document.  E.g.,
[libreswan], [netconf-vpn], [ONF-SDN-Architecture], [SDNSecServ],
[SDNSecurity], [strongswan].  For many of them it seems like it would be
quite straightforward to include URLs and/or publisher information,
e.g., https://ieeexplore.ieee.org/document/6702553 and
https://datatracker.ietf.org/meeting/87/materials/slides-87-sdnrg-2 seem
fairly likely to remain stable references.

We use RFC 3948 as reference for the UDP encapsulation facility, so it
probably should be a normative reference; likewise for RFC 8229 and
TCP(/TLS) encapsulation.

Appendix A

      typedef ipsec-protocol-parameters {
        type enumeration {
          enum esp { description "IPsec ESP protocol."; }
        }
        description
          "Only the Encapsulation Security Protocol (ESP) is
          supported but it could be extended in the future.";

I assume that the usual caveats about extension via identity vs enum are
well-understood by the WG (i.e., a full revision of the module would be
needed to enable use of a new value; augmentation would not suffice).
(This potentially applies to many of the enumerated types in this
document, but I will only note it this one time.)

        description
          "IPsec traffic direction is defined in two
          directions: inbound and outbound. From a NSF
          perspective inbound means the traffic that enters
          the NSF and outbound is the traffic that is sent
          from the NSF.";

This is perhaps not the greastest wording, since in the gateway case any
given traffic both enters and is sent from the NSF.  I think it is
probably tolerable, since we refer specifically to the IPsec traffic,
but might be worth further thought.

        description
          "IPsec protection can be applied to specific IP
          traffic and layer 4 traffic (TCP, UDP, SCTP, etc.)
          or ANY protocol in the IP packet payload. We
          specify the IP protocol number with an uint8 or
          ANY defining an enumerate with value 256 to
          indicate the protocol number. NOTE: In case
          of IPv6, the protocol in the IP packet payload
          is specified in the Next Header field of the IPv6
          packet.";

[There are perhaps some complications around this description when
extension headers are in use.]

        leaf bytes {
          type uint32;
          default 0;
          description
            "If the IPsec SA processes the number of bytes
            expressed in this leaf, the IPsec SA expires and
            should be rekeyed. The value 0 implies
            infinite.";

32 bits for a byte lifetime is perhaps overly restrictive; some
encryption schemes do not have cryptographic need to rekey that
frequently, so a 64-bit counter would be more appropriate for them.

            is a waste of resources. If the IPsec SA is idle
            during this number of seconds the IPsec SA
            should be removed. The value 0 implies
            infinite.";
        }
        reference
          "Section 4.4.2.1 in RFC 4301.";

I don't see any mention of "idle" in RFC 4301.

        leaf bypass-dscp {
          type boolean;
          default true;
          description
            "If DSCP (Differentiated Services Code Point)
            values in the inner header have to be used to
            select one IPsec SA among several that match
            the traffic selectors for an outbound packet";

This doesn't really give me a clear picture of what action to take when
it has value 'true' (vs 'false').

        list local-ports {
          key "start end";
          uses port-range;
          description
            "List of local ports. When the inner
            protocol is ICMP this 16 bit value
            represents code and type.
            If this list is not defined
            it is assumed that start and
            end are 0 by default (any port).";

Shouldn't these extra semantics be attached to the port-range grouping
itself?  Also, the repurposing of start/end for ICMP code/type is quite
unconventional.

        leaf anti-replay-window {
          type uint64;
          default 32;
          description
            "A 64-bit counter used to determine whether an
            inbound ESP packet is a replay.";
          reference
            "Section 4.4.2.1 in RFC 4301.";

Is this the counter or the bit-map or the size of the bit-map?
I don't think a uint64 combined with default 32 makes sense.

            leaf seq-overflow {
              type boolean;
              default false;

I think we may want to give a stronger indication that setting this to
'true' is strongly discouraged.

                leaf id {
                  type uint8;
                  description
                    "The index of list with the
                    different encryption algorithms and
                    its key-length (if required).";

I'm not sure what this id is indexing into and how it would indicate key
length.  Is the idea that this is a sequential index for the very 'list
encryption' that it is contained in?  If so, I think we would need to
write more specifics about its semantics and how it is assigned.

Appendix B

        "This module contains IPsec IKE case model for the SDN-based
        IPsec flow protection service. An NSF will implement this
        module.

Why do we have the last sentence?  IIUC we do not mandate implementation
of the IKE case, since the IKE-less case is seen as making this more
accessible for lower-resourced NSFs.

          enum on-demand {
            description
              "IKE/IPsec configuration is loaded
              into IKE implementation. The IPsec policies
              are transferred to the NSF's kernel but the
              IPsec SAs are not established immediately.
              The IKE implementation will negotiate the
              IPsec SAs when the NSF's kernel requests it
              (i.e. through an ACQUIRE notification).";

I'm not sure I understand the intended semantics of the ACQUIRE
notification, here -- the sadb-acquire notification is part of this YANG
module, which would typically imply that it is send from the NSF to the
I2NSF Controller.  I'm not sure where the NSF's kernel is, in that path.
(We also haven't really talked about "NSF kernel"s previously, though
we did have significant discussion of kernel IPsec/IKE implementations.)

      typedef pfs-group{

"pfs-group" (and the "pfs-groups" nodes of this type) calls to mind
"perfect forward secrecy", but the guidance from SAAG is moving towards
dropping the "perfect" part since it is a bit misleading and its meaning
is not terribly well-defined.

          list pad-entry {
            [...]
            leaf name {
            [...]
            choice identity {

I guess I would have expected some discussion somewhere (possibly up in
§6.1) about why there is both a 'name' and an 'identity'.  (I might
surmise that it is to allow differently-named-and-configured SAs to the
same remotem peer, but that is just supposition if there's no text in
the document about it.)

                leaf dnx509 {
                  type string;

I assume from the 'string' type and the example that we use the
presentation form and not (e.g.) the DER encoded form.  This is probably
worth stating explicitly.

                leaf eap-type {
                  type uint8;
                  mandatory true;
                  description
                    "EAP method type. This
                    information provides the
                    particular EAP method to be
                    used. Depending on the EAP
                    method, pre-shared keys or
                    certificates may be used.";

A reference to where the actual method type values are obtained (e.g.,
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4)
seems in order.  I note that there is a range allocatable via
"Specification Required" in that registry that is not representable in a
uint8.

              container pre-shared {
                when
                  "../auth-method[.='pre-shared' or
                  .='eap']";

This seems a little unfortunate, as I don't think that it is appropriate
to require ("mandatory true") the pre-shared secret leaf to be present,
universally, for all EAP methods.o

              container digital-signature {
                when
                  "../auth-method[.='digital-signature'
                  or .='eap']";

Similarly here, for the mandatory 'public key' choice -- if I am reading
this correctly the YANG would require us to have both pre-shared *and*
public-key values present for the 'eap' auth-method.

                leaf ds-algorithm {
                  type uint8;
                  default 1;

My understanding is that algorithm 14 (the generic "digital signature")
is currently preferred as the default algorithm, since it is not tied to
a particular public key type.  See
https://tools.ietf.org/html/rfc8247#section-3.1 for discussion of why it
is expected to be the way of the future.

                      signature algorithm. For
                      example, an RSA key is
                      represented as RSAPublicKey as
                      defined in RFC 8017, and an
                      Elliptic Curve Cryptography
                      (ECC) key is represented
                      using the 'publicKey'
                      described in RFC 5915.";

This is perhaps a bit under-specified without a clear procedure for
going from a digital signature algorithm codepoint to the specification
of the public key encoding.  That said, I'm not sure that there is a
very good thing to say here, and even the RFC 7427 generic "Digital
Signature" type is effectively still deferring to the ASN.1
AlgorithmIdentifier.  (Similarly for the 'private-key', of course.)

                  leaf cert-data {
                    type binary;
                    description
                      "X.509 certificate data -
                      PEM4. If raw-public-key
                      is defined this leaf is
                      empty.";

If the leaf it of type binary we don't need the (ASCII) PEM encoding.
(Also, why the '4' in "PEM4"?)

                leaf crl-uri  {
                  type inet:uri;
                  description
                    "X.509 CRL certificate URI.
                    If it is not defined
                    the default value is empty.";

An RFC 5280 reference would probably be appropriate here as well.

                leaf oscp-uri {
                  type inet:uri;
                  description
                    "OCSP URI.
                    If it is not defined
                    the default value is empty.";

and maybe 2560 or 5280 here.

          leaf-list authalg {
            type nsfikec:integrity-algorithm-type;
            default 12;
            ordered-by user;
            description
              "Authentication algorithm for establishing

Using "authentication algorithm" in the description here (and "authalg"
as the node name) seems needlessly confusing, since these are the IKEv2
integrity algorithms, and there is a separate thing that is the IKE
authentication methods.

          list encalg {
            key id;
            min-elements 1;
            ordered-by user;
            leaf id {
              type uint8;
              description
                "The index of the list with the
                different encryption algorithms and its
                key-length (if required). E.g. AES-CBC,
                128 bits";

As was the case for esp-algorithms/encryption, I'm not sure what this id
is indexing into and how it would indicate key length.  Is the idea that
this is a sequential index for the very 'list encryption' that it is
contained in?  If so, I think we would need to write more specifics
about its semantics and how it is assigned.

          leaf half-open-ike-sa-timer {
            type uint32;
            default 0;
            description
              "Set the half-open IKE SA timeout
              duration.";

What are the units?  Does 0 really mean 0 (vs infinity)?

          container child-sa-info {
            leaf-list pfs-groups {

["pfs" again, just noting the location; no new comment other than the
one above]

            leaf current-rekey-time {
              type uint64;
              units "seconds";
              description
                "Seconds before IKE SA MUST be rekeyed.";
            }
            leaf current-reauth-time {
              type uint64;
              units "seconds";
              description
                "Seconds before IKE SA MUST be
                re-authenticated.";

I don't think either of these strictly speaking need to be RFC 2119
"MUST"s.

        container number-ike-sas {

In general it seems like these counters could be gauge64's instead of
uint64's.

Appendix C

            container ipsec-sa-config {
              [...]
              leaf spi {
                type uint32 { range "0..max"; }

I would have expected a clear indication of whether this value is for
sending or receiving.

              leaf seq-number-counter {

Why is this leaf writable?

              leaf anti-replay-window {
                type uint32;
                default 32;
                description
                  "A 32-bit counter and a bit-map (or
                  equivalent) used to determine
                  whether an inbound ESP packet is a
                  replay. If set to 0 no anti-replay

First, in the common module the anti-replay-window was a uint64, but
here it's uint32.  Second, my confusion/comment from the common module
seem to also apply here.

                leaf replay-window {
                  type uint64;
                  description
                    "Current state of the replay
                    window.";

Probably a little bit more description and/or reference is in order
here.

                leaf packet-dropped {
                  type uint64;

IIUC this could be a counter64.

                leaf failed {
                  type uint32;
                  description
                    "Number of packets detected out
                    of the replay window.";

How is this different from 'packet-dropped' (and why does it only need
to be a 32-bit counter)?  Also, would a 'counter32' (or 'counter64')
type be appropriate?

      notification sadb-acquire {
        if-feature ikeless-notification;
        description
          "An IPsec SA is required. The traffic-selector
          container contains information about the IP packet
          that triggers the acquire notification.";

If I understand correctly, the scenario here is that an inbound packet
arrives at (or is generated by) the NSF and it is determined that the
packet needs IPsec protection to proceed.  Some guidance on whether we
should use exact-address match to determine the source and destination
prefixes or some heuristic to select a less-specific prefix seems like
it would be in order.  (Or is this all supposed to be specified in the
corresponding SPD entry?)

        container lifetime-current {
          description
            "IPsec SA current lifetime. If
            soft-lifetime-expired is true this container is
            set with the lifetime information about current
            soft lifetime.";

I'm not 100% sure I understand what goes in this field -- intuitively,
though, it seems like what would be most useful to the I2NSF Controller
would be the time before the *hard* lifetime expires (since we already
know that the soft lifetime has expired by virtue of this being a
sadb-expire notification with soft-lifetime-expired set to true).

      notification sadb-seq-overflow {
        if-feature ikeless-notification;
        description "Sequence overflow notification.";
        leaf ipsec-sa-name {
          type string;
          mandatory true;
          description
            "It contains the SAD entry name (unique) of
            the IPsec SA that is about to have sequence
            number overflow and rollover is not permitted.
            It is assumed the I2NSF Controller will have
            a copy of the IPsec SA information (except the
            cryptographic material and state data) indexed
            by this name (unique identifier) so the it can
            know all the information (crypto algorithms,
            etc.) about the IPsec SA that has expired in
            order to perform a rekey of the IPsec SA.";
        }

There seems to be internal disagreement here ("about to have ...
overflow" vs "that has expired") -- it seems more useful for this to be
the "about to" behavior, but in that case we should give some guidance
about how to measure "about to".

Appendix D

  This example shows a XML configuration file sent by the I2NSF
  Controller to establish a IPsec Security Association between two NSFs
  (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP,
  authentication based on X.509 certificates and applying the IKE case.

Maybe note that some (base64) values have been simplified and/or
truncated for brevity?  ("base64encodedvalue==" is not a valid base64
encoding of a DER-encoded X.509 certificate, for example)

       
        <authalg>7</authalg>

Perhaps a non-SHA1 example would age better (even though HMAC-SHA1 is
not known to be weak at this point).

                  <local-ports>
                    <start>0</start>
                    <end>0</end>
                  </local-ports>
                  <remote-ports>
                    <start>0</start>
                    <end>0</end>
                  </remote-ports>

These are the default values and could be omitted, if I understand
correctly.

Appendix E

I would prefer if the examples did not show seq-overflow as true.

                <inner-protocol>any</inner-protocol>

Is this encoded as "any" as shown, or as 256?

Appendix G.1.2

      *  The I2NSF Controller chooses two random values as SPIs: for
          example, SPIa1 for NSF A and SPIb1 for NSF B.  These numbers
          MUST NOT be in conflict with any IPsec SA in NSF A or NSF B.

Is this restriction for the respective SPI<X>/NSF<X> pairs, or for the
full matrix of combinations?
(Similarly in G.2)

Appendix G.2

  If step 1 is successful but some of the operations in step 2 fails
  (e.g. the NSF A reports an error when the I2NSF Controller is trying
  to install the new outbound IPsec SA), the I2NSF Controller MUST
  perform a rollback operation by deleting any new outbound SA that had
  been successfully installed during step 2 and by deleting the inbound
  SAs created in step 1.

I think it's important that the two rollbacks are done in the order
listed here.


NITS

Section 1

  resources through software.  The SDN paradigm relocates the control
  of network resources to a centralized entity, namely SDN Controller.

"the SDN Controller".

                                        For example, Software-Defined
  WANs (SD-WANs).  [...]

incomplete sentence (no verb).

  can be established using IPsec.  The management of IPsec SAs in data
  centers using a centralized entity is a scenario where the current
  specification maybe applicable.

s/maybe/may be/

  I2NSF NSF-Facing interface.  In this document we define a service
  allowing the I2NSF Controller to carry out the key management
  procedures.  More specifically, we define YANG data models for I2NSF

I'm not sure that "service" is the best word, here.

  NSF-Facing interface that allow the I2NSF Controller to configure and
  monitor IPsec-enabled flow-based NSFs.

missing article ("the" or "a") before "I2NSF NSF-Facing interface".
(Also, it's weird that "Facing" is capitalized but "interface" is not.)

  IPsec architecture [RFC4301] defines clear separation between the

more articles: "The IPsec architecture", "a clear separation"

  which allows to centralize the key management procedures in the I2NSF

s/to centralize/centralizing/

      charge of provisioning the NSF with the required information in
      the SPD, PAD (e.g.  IKE credential) and IKE protocol itself (e.g.
      parameters for the IKE_SA_INIT negotiation).

comma after "e.g." (twice)
"credentials" plural
There's amismatch between "in the [databases] and "in IKE protocol
itself" -- it should more properly be "for the IKE protocol itself",
which makes the list non-parallel, so it would be "in the SPD and PAD
(...), and for the IKE protocol itself".

      required parameters to create valid entries in the SPD and the
      SAD into the NSF.  Therefore, the NSF will have only support for

"into" is not right; maybe "in" or "of".
s/have only/only have/

  o  To describe the architecture for the I2NSF-based IPsec management,

s/the I2NSF-based/I2NSF-based/

Section 4

  As mentioned in Section 1, two cases are considered, depending on
  whether the NSF implements IKEv2 or not: IKE case and IKE-less case.

more articles: "the" for both cases

  parameters (e.g.  cryptographic algorithms for establishing an IKEv2

comma after "e.g."

  information about the end points information (through the I2NSF

redundant "information"s

Section 4.2

  o  Cryptographic algorithm/s selection.

Just "algorithm" works fine for both the singular and plural case.

Section 5

  IKEv2/IPsec implementation, hosts can easily install it.  As
  downside, the NSF needs more resources to hold IKEv2 such as memory

"As a downside"
"to use IKEv2"

  Alternatively, IKE-less case benefits the deployment in resource-

"the IKE-less case"

  centralized controller (like the I2NSF Controller) is aware about

s/about/of/

  provided and discussed (e.g.  hierarchical controllers; having
  multiple replicated controllers, dedicated high-speed management
  networks, etc).  In the context of I2SNF-based IPsec management, one

I think s/;/,/ to be consistent about the list separator within a single
list.

  waiting for notifications (e.g. a notification sadb-acquire when a

comma after "e.g."

Section 5.1

  the old one (if a IPsec SA lifetime has not been defined).  This
  rekeying process starts when the I2NSF Controller receives a sadb-
  expire notification or it decides so, based on lifetime state data

s/or it decides so/or on the I2NSF Controller's initiative/

Section 5.2

  with the new IKEv2, SPD and PAD information.  It has also to send new

s/has also/also has/

Section 5.3

  some of the peers or both are located behind a NAT.  If there is a
  NAT network configured between two peers, it is required to activate
  the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],

The "it is required" could be misread to have "it" mean "the NAT
network"; rewording the second clause to be "UDP or TCP/TLS
encapsulation for ESP packets ([RFC3948]) is required" would help with
that.

  [RFC8229]).  Note that the usage of IPsec transport mode when NAT is
  required MUST NOT be used in this specification.

"usage" and "used" seem redundant.

Section 5.4

  NSF registration refers to the process of facilitating the I2NSF
  Controller information about a valid NSF such as certificate, IP

s/facilitating/providing/ or similar

  address, etc.  This information is incorporated in a list of NSFs
  under its control

full stop at end of sentence.

  capabilities of this NSF, such as what is the cryptographic suite
  supported, authentication method, the support of the IKE case and/or

s/is/are/, s/suite/suites/

Section 6.1

  configure the Peer Authentication Database with authentication
  information about local and remote peers.  More precisely, it

"authentication information about local peers" reads a bit oddly.

  authentication method and credentials that will use a particular
  peer.

s/that will use a particular peer/that a particular peer will use/

Section 6.2

  The data model consists of a unique "ipsec-ikeless" container which,
  in turn, is integrated by two additional containers: "spd" and "sad".

"integrated by" is probably not the right term here; "composed of" might
be better.

  The "spd" container consists of a list of entries that conform the

s/conform/form/ (or similar), I think.

  IPsec SAs.  The "sad" container is a list of entries that conform the

(ditto)

  Security Association Database.  In general, each entry allows to
  specify both configuration information (SPI, traffic selectors,

s/to specify/specifying/

Section 8.3

        to be used for the authentication (e.g. to impersonate a NSF),

comma after "e.g." (occurs several times in this section).

        changing to a allow policy), and in general changing the IKE SA

s/a/an/

        example, encryption/key contains a ESP encryption key value and

s/a ESP/an ESP/

        encryption/iv contains a initialization vector value.

s/a initialization/an initialization/

        Similarly, integrity/key has ESP integrity key value.  Those

s/has/has an/

Appendix A

          "The encryption algorithm is specified with a 16-bit
          number extracted from IANA Registry. The acceptable

missing article for "IANA Registry" (so probably "the", since only one
registry is listed).
(similarly for integrity-algorithm-type)

          "The integrity algorithm is specified with a 16-bit
          number extracted from IANA Registry.
          The acceptable values MUST follow the requirement
          levels for encryption algorithms for ESP and IKEv2.";

s/encryption/integrity/, right?

          enum none {
            description
              "NOT ESP encapsulation.";

"Not" probably doesn't need to be capitalized.

        description
          "Types of ESP encapsulation when Network Address
          Translation (NAT) is present between two NSFs.";

Perhaps s/is/may be/, as it doesn't seem like an intrinsic requirement
for the use of encapsulation.

        description
          "When the lifetime of an IPsec SA expires an action
          needs to be performed over the IPsec SA that

"over" doesn't seem like the right word; perhaps "for"?

        description
          "This group of nodes allows to define the type of
          encapsulation in case NAT traversal is
          required and port information.";

s/and/and includes/

          description
            "When a NSF stores an IPsec SA, it
            consumes system resources. In an idle NSF this

Maybe s/In an idle NSF/For an idle SA/?

            enum clear {
              description
                "Disable the DF (Don't Fragment) bit
                from the outer header. This is the

s/from/in/

        container traffic-selector {
          description
            "Packets are selected for
            processing actions based on the IP and inner
            protocol header information, selectors,
            matched against entries in the SPD.";

The grammar here doesn't make sense, to the extent that I can't really
even guess the intended meaning.  It makes the most sense if I just end
the sentence after "inner protocol header information".  Perhaps the
remaining bit was intended to be a separate statement that "selectors
are matched against" something?

              description
                "True if this IPsec SA is using extended
                sequence numbers. True 64 bit counter,
                False 32 bit.";

How about (for the second sentence): "If true, the 64-bit extended
sequence number counter is used; if false, the normal 32-bit sequence
number counter is used"?

                    "Configuration of ESP authentication
                    based on the specified integrity
                    algorithm. With AEAD algorithms,
                    the integrity node is not used.";
s/AEAD algorithms/AEAD encryption algorithms/

Appendix B

        description
          "IKE authentication protocol version specified in the
          Peer Authorization Database (PAD). It is defined as
          enumerate to allow new IKE versions in the

s/enumerate/enumerated/

          enum digital-signature {
            description
              "Select digital signature method.";

s/method/as the authentication method/ to match the others.

      container ipsec-ike {
        description
          "IKE configuration for a NSF. It includes PAD
          parameters, IKE connections information and state

s/connections/connection/

            "Configuration of Peer Authorization Database
            (PAD). The PAD contains information about IKE

s/Peer/the Peer/.

            peer (local and remote). Therefore, the Security

s/peer/peers/

            Controller also stores authentication
            information for this NSF and can include
            several entries for the local NSF not only
            remote peers. Storing local and remote

comma before "not only".

            information makes possible to specify that this

s/makes possible/makes it possible/

            NSF with identity A will use some particular
            authentication with remote NSF with identity B
            and what are the authentication mechanisms
            allowed to B.";

s/allowed/allowed for communication/

                  description
                    "Specifies the identity as a
                    single four (4) octet.";

"four-octet value".  (The current text says that it is a single byte
with value 0x4, which is not a very useful identifier.)

                    "Specifies the identity as a
                    Fully-QualifiedDomain Name

space in "Qualified Domain".

              case rfc822-address-string {

(I'm still a little confused why email address identifiers are useful
enough to be in the core spec, but I think I am behind on the email
thread so maybe it is answered there.)

                  description
                    "Specifies the identity as a
                    ASN.1 X.500 Distinguished

s/a/an/

                    "ID_NULL identification used
                    when IKE identification payload

"The ID_NULL identification method is used when the IKE identification
payload [...]".

                "This container allows the Security
                Controller to configure the
                authentication method (pre-shared key,
                eap, digitial-signature, null) that
                will use a particular peer and the

"will be used with"

                credentials, which will depend on the

"credentials to use"

                    "If the I2NSF Controller
                    knows that the NSF
                    already owns a private key
                    associated to this public key
                    (the NSF generated the pair
                    public key/private key out of
                    band), it will only configure

I think this is better with "e.g.," at the start of the parenthetical.

            "IKE peer connection information. This list
            contains the IKE connection for this peer
            with other peers. This will be translated in
            real time by IKE Security Associations
            established with these nodes.";

Is "translated" the right word here?

          leaf autostartup {
            type autostartup-type;
            default add;
            description
              "By-default: Only add configuration
              without starting the security
              association.";

This seems to be describing the default behavior, not the function of
the leaf overall.

          leaf version {
            type auth-protocol-type;
            default ikev2;
            description
              "IKE version. Only version 2 is supported
              so far.";

"so far" is perhaps a bit colloquail for RFC style.

                "Time in seconds between each IKE SA
                rekey.The value 0 means infinite.";

Space at the sentence break.

                "If non-zero, perfect forward secrecy
                is required when requesting new
                IPsec SA. The non-zero value is
                the required group number. [...]

How about:

% If non-zero, forward secrecy is required when a new IPsec SA is being
% created.  The (non-zero) value indicates the group number to use for
% the key exchange process used to achieve forward secrecy.

                "Soft IPsec SA lifetime soft.

redundant "soft"s.

                description
                  "True if this IPsec SA is using
                  extended sequence numbers. True 64
                  bit counter, false 32 bit.";

[same comment as previously]

                    description
                      "ESP encryption IV value. If
                      this leaf is not defined the
                      IV is not defined (e.g.
                      encryption is NULL)";
                  }

Maybe say how the IV length is determined?

                    IPsec Encapsulation Security
                    Payload (ESP). This container
                    allows to configure integrity
                    algorithm when no AEAD

s/allows to configure/allows configuration of/
s/algorithm/algorithms/

                      the key is not defined (e.g.

comma after "e.g.".

                    "Packets detected out of the
                    replay window and dropped
                    because they are replay
                    packets.";

s/they are/they are assumed to be/

            description
              "List of SAD entries that conforms the SAD.";

s/conforms/forms/ again, I think.
2021-02-27
13 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Record from Discuss
2021-02-24
13 Erik Kline [Ballot Position Update] Position for Erik Kline has been changed to Yes from Discuss
2021-02-19
13 Magnus Westerlund [Ballot comment]
Thanks for the discussion that resulted in that we could actually simplify things and avoid need for configuration.
2021-02-19
13 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2021-02-18
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-02-18
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-02-18
13 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-13.txt
2021-02-18
13 (System) New version approved
2021-02-18
13 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Gabriel Lopez-Millan <gabilm@um.es>, Rafael Marin-Lopez <rafa@um.es>
2021-02-18
13 Rafael Marin-Lopez Uploaded new revision
2020-11-19
12 Derek Atkins Request for Telechat review by SECDIR Completed: Ready. Reviewer: Derek Atkins. Sent review to list.
2020-11-12
12 Bernie Volz Assignment of request for Telechat review by INTDIR to Hui Deng was marked no-response
2020-11-05
12 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-11-05
12 Magnus Westerlund
[Ballot discuss]
        leaf ecn {
          type boolean;
          default false;
    …
[Ballot discuss]
        leaf ecn {
          type boolean;
          default false;
          description
            "Explicit Congestion Notification (ECN). If true
            copy CE bits to inner header.";
          reference
            "Section 5.1.2 and Appendix C in RFC 4301.";
        }

There is something wrong here, likely in the description of the option. This as the outer IP header on sender side needs to set ECN field to ECT to enable so that any CE marks can be received. I think it is reasonable to have an option to just enable ECN, but that requires several things. Secondly with the changes in RFC 8311, there might be need to be more explicit in the configuration of ECN to actually indicate which ECT value that should be set on send side for the established IPsec tunnel. Due to under discussion experiments with ECT values per RFC 8311 we should verify that just copying the inner header value to the external is fine and don't break anything as path and/or marking behavior may not be the same.

I think there is also the question if RFC 6040 needs to be referenced in this context to ensure that people pick up on that RFC 6040 updates RFC 4301.
2020-11-05
12 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2020-11-05
12 Robert Wilton
[Ballot comment]
There has already been some extensive discussion regarding the YANG models and the YANG model structure, so thank you for accommodating these changes …
[Ballot comment]
There has already been some extensive discussion regarding the YANG models and the YANG model structure, so thank you for accommodating these changes and making the modules more widely reusable.

I note that you have included the YANG modules as appendices rather than in the main body of the document.  Given that the YANG module text is normative, and the main component of this specification, it would be better to follow the convention from other existing RFCs containing YANG modules and document the YANG modules in the main body of the document, probably as a new section before section 7 (IANA considerations).

Regards,
Rob
2020-11-05
12 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-05
12 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below one blocking DISCUSS point, some non-blocking COMMENT points, and some nits. …
[Ballot comment]
Thank you for the work put into this document.

Please find below one blocking DISCUSS point, some non-blocking COMMENT points, and some nits.

I support Erik Kline's DISCUSS points as well as Ben Kaduk's DISCUSS point about vendor-specific.

I hope that this helps to improve the document,

Regards,

-éric
== COMMENTS ==

-- Section 5 --
Isn't there also the 'load sharing by IPSEC-only NSF' a use case ? Where simple ECMP could split traffic to several IPSec-only NSFs configured with the same parameters (SADB, SPD, ...) (anti-reply being probably impossible to offer though)

-- Section 6 --
It seems that this section sometimes uses the term 'model' instead of 'module'.

-- Section 6.1 --
I would have preferred to use 'local-prefix' rather than 'local-subnet' as the latter is old looking IPv4 subnet.

The "state" part does not seem to contain the current state of the IKE finite state machine, is it on purpose ?

-- Section 8.2 --
As IKEv2 provides "perfect forward secrecy" should this section mandating the use of a secure channel between SDN and the NSF also with "perfect forward secrecy" and same reasoning for the encryption algorithms of course.
2020-11-05
12 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-11-04
12 Benjamin Kaduk
[Ballot discuss]
Let's discuss whether it's appropriate to include vendor-specific
functionality (e.g., linux NETKEY/XFRM marking) in a standards-track
protocol/model.

The ASN.1 GeneralName type is an …
[Ballot discuss]
Let's discuss whether it's appropriate to include vendor-specific
functionality (e.g., linux NETKEY/XFRM marking) in a standards-track
protocol/model.

The ASN.1 GeneralName type is an abstract type; in order to represent it
in a string we must have some discussion of how it is encoded.  (A
similar concern might apply to the other ASN.1 types used, such as
DistinguishedName, though the latter does have a fairly well-established
string presentation form, so the concern is of lesser magnitude there.
That said, RFC 5280 is not a suitable reference for the
DistinguishedName string presentation form.)

In a similar vein, the 'id-key' identity representation is listed as
type 'string' but the description lists it as an "opaque octet string".
YANG strings are not directly suitable for holding binary content (which
is what an opaque octet string is), so either a scheme for encoding
arbitrary binary content as a string is needed, the YANG 'binary' type
should be used, or this node needs to be documented as only allowing
valid Unicode (IIUC, in UTF-8 encoding, though
https://tools.ietf.org/html/rfc6020#section-9.4 is not as clear about
this as I would like).

The two 'anti-replay-window' leafs are (1) using different-width types,
and (2) do not have enough of a description to indicate what content
they hold, especially whe combined with a default value of 32.
(I mention both locations in the COMMENT.)
2020-11-04
12 Benjamin Kaduk
[Ballot comment]
Abstract

We should not use unexpanded acronyms like SPD, SAD, and PAD in the
abstract unless there are very well-known.

Section 1

  …
[Ballot comment]
Abstract

We should not use unexpanded acronyms like SPD, SAD, and PAD in the
abstract unless there are very well-known.

Section 1

  [RFC6071].  In these cases, hosts, gateways or both may act as NSFs.
  Consideration for the host-to-gateway scenario is out of scope.

Is there anything to say about what gaps would need to be filled in
order to address the host-to-gateway case (vs how much of the mechanisms
defined herein could be reused)?

  the I2NSF Controller and the NSF.  Using YANG data modelling language
  version 1.1 [RFC7950] and based on YANG models defined in
  [netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
  7296
[RFC7296], this document defines the required interfaces with a
  YANG model for configuration and state data for IKE, PAD, SPD and SAD

RFCs 4301 and 7296 do not define YANG models.  Is the intent to say that
this is based on YANG models defined in netconf-vpn and
I-D.tran-ipsecme-yang, and the data structures defined in RFC 4301 and
RFC 7296?

  o  To define the interfaces required to manage and monitor the IPsec
      SAs in the NSF from a I2NSF Controller.  YANG data models are
      defined for configuration and state data for IPsec and IKEv2
      management through the I2NSF NSF-Facing interface.  Thus, this
      document does not define any new protocol.

It might perhaps be worth saying that the YANG models can be used via
existing protocols such as NETCONF and RESTCONF.

Section 3

  The following term is defined in [RFC6437]:

  o  Flow/traffic flow.

That does not seem to be used as a single term in RFC 6473; perhaps it's
best to say that they are two terms that are related or have identical
definition/usage.

Section 4.1

  flexible management of IPsec SAs in flow-based NSFs.  In order to
  support this capability in the IKE case, a YANG data model for IKEv2,
  SPD and PAD configuration data, and for IKEv2 state data MUST be
  defined for the I2NSF NSF-Facing Interface.

I think this is probably better as a descriptive "needs to" than a BCP
14
"MUST".

Section 4.2

We should perhaps say something before the figure about what the I2NSF
User does, in order to justify their inclusion in the figure (or
otherwise introduce the figure before it appears).

Section 5.1

  IPsec SAs management.  With the YANG data models defined in this
  document the I2NSF Controller can configure and conduct the rekey

Does the "and conduct" apply only to the IKE-less case, or the IKE-ful
one as well?  If only the IKE-less case we might consider some
additional notation such as "and, as needed, conduct".

Section 5.2

  In the IKE case, the I2NSF Controller will configure the affected NSF
  with the new IKEv2, SPD and PAD information.  It has also to send new
  parameters (e.g. a new fresh PSK for authentication) to the NSFs
  which have IKEv2 SAs and IPsec SAs with the affected NSF.  Finally,

It does not seem intuitively obvious to me that the controller *always*
has to send new parameters to the other NSFs (that have SAs with the
affected NSF).  E.g., for IKE-ful SAs that use certificate
authentication, what would need to change on the other NSFs?

  Alternatively, IKEv2 configuration MAY be made permanent between NSFs
  reboots without compromising security by means of the startup

Similarly, this MAY seems to require that the previous paragraph has
some hedging langauge that the procedures it describes are only one
possible option (with this paragraph being the other option).

Section 5.3

  some of the peers or both are located behind a NAT.  If there is a
  NAT network configured between two peers, it is required to activate

I am not familiar with "NAT network" as a term; is there a reference for
it?

  the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],

Why is TLS needed?  I understand that RFC 8229 talks about how it can be
done, but why is that necessary here?

  configured between two hosts, and apply the required policies to both
  NSFs besides activating the usage of UDP or TCP/TLS encapsulation of

(TLS again)

Section 6

  In order to support the IKE and IKE-less cases we have modeled the
  different parameters and values that must be configured to manage

The use of the first person is uncommon in RFCs; phasing like "models
are provided for the different parameters and values [...]" is more
common.

Section 6.1

We have a 'spd' tree in the IKE-ful model, so it's a bit surprising that
we don't match the treatment of the IKE-less model and say that the SPD
model has mainly been extracted from [parts of] RFC 4301.

(side note?) The tree diagram apparently doesn't have a good way of
showing the "when" relationship between (e.g.) auth-method and the
sibling nodes (eap-method, pre-shared, etc.), which confused me briefly.

Using string names instead of YANG references for correlating the PAD
entries is rather surprising to me.

  to be secured (local/remote subnet and ports, etc.) and how must be
  protected (AH/ESP, tunnel/transport, cryptographic algorithms, etc.);

I think that AH support was present in a previous version of the
document but has since been removed, so we should not mention AH here.

Section 6.2

  o  Each IPsec policy (spd-entry) contains one traffic selector,
      instead of a list of them.  The reason is that we have observed
      actual kernel implementations only admit a single traffic selector
      per IPsec policy.

It's not entirely clear that we need to cripple the overall model just
because some implementations would not support the full functionality.
My understanding is that having many traffic selectors for a single
policy (or SA, which has similar text later in this section) can be
quite useful in some cases.

  o  Combined algorithms have been removed because encryption
      algorithms MAY include authenticated encryption with associated
      data (AEAD).

A reference here would be helpful (IIUC, the "MAY" here is in effect
quoting the external document, and not a new requirement).
(Likewise for the corresponding SAD-model item.)

  The notifications model has been defined using as reference the
  PF_KEYv2 standard in [RFC2367].

RFC 2367 is only an Informational document, so calling it a "standard"
(as opposed to a "protocol" or "specification" may not be the best
choice.

    |    |  +--rw protocol-parameters? ipsec-protocol-parameters

Isn't this type nsfikec:ipsec-protocol-parameters?

  absence of an IKE software in the NSF: traffic direction to apply the
  IPsec policy, and a value to link an IPsec policy with its associated
  IPsec SAs.  [...]

Maybe "a 'requid' value to link [...]" since it is otherwise a little
hard to find by searching?

Section 8

  On the one hand, it is important to note that there MUST exist a
  security association between the I2NSF Controller and the NSFs to
  protect the critical information (cryptographic keys, configuration
  parameter, etc.) exchanged between these entities.

We should probably state explicitly that the nature of and means to
create that SA is out of scope for this specification (i.e., it's part
of device provisioning or onboarding).

  this information.  Although we can assume this attack is not likely
  to happen due to the assumed security measurements to protect the
  I2NSF Controller, it still deserves some analysis in the hypothetical
  case that the attack occurs.  The impact is different depending on

I don't think this sentence actually adds any value; whether or not the
attack is likely, the potential consequences are significant enough that
we have to document it.

Section 8.1

                                                        Alternatively,
      the NSF could generate the private key and export only the public
      key to the I2NSF Controller.

(Again, the mechanisms by which to do this are outside the scope of this
specification.  We do have some text like this for the following bullet
regarding certificates, which could easily be repurposed for use here.)

Section 10.2

Many of these entries don't really contain sufficient information to
unambiguously locate the intended reference document.  E.g.,
[libreswan], [netconf-vpn], [ONF-SDN-Architecture], [SDNSecServ],
[SDNSecurity], [strongswan].  For many of them it seems like it would be
quite straightforward to include URLs and/or publisher information,
e.g., https://ieeexplore.ieee.org/document/6702553 and
https://datatracker.ietf.org/meeting/87/materials/slides-87-sdnrg-2 seem
fairly likely to remain stable references.

We use RFC 3948 as reference for the UDP encapsulation facility, so it
probably should be a normative reference; likewise for RFC 8229 and
TCP(/TLS) encapsulation.

Appendix A

      typedef ipsec-protocol-parameters {
        type enumeration {
          enum esp { description "IPsec ESP protocol."; }
        }
        description
          "Only the Encapsulation Security Protocol (ESP) is
          supported but it could be extended in the future.";

I assume that the usual caveats about extension via identity vs enum are
well-understood by the WG (i.e., a full revision of the module would be
needed to enable use of a new value; augmentation would not suffice).
(This potentially applies to many of the enumerated types in this
document, but I will only note it this one time.)

        description
          "IPsec traffic direction is defined in two
          directions: inbound and outbound. From a NSF
          perspective inbound means the traffic that enters
          the NSF and outbound is the traffic that is sent
          from the NSF.";

This is perhaps not the greastest wording, since in the gateway case any
given traffic both enters and is sent from the NSF.  I think it is
probably tolerable, since we refer specifically to the IPsec traffic,
but might be worth further thought.

        description
          "IPsec protection can be applied to specific IP
          traffic and layer 4 traffic (TCP, UDP, SCTP, etc.)
          or ANY protocol in the IP packet payload. We
          specify the IP protocol number with an uint8 or
          ANY defining an enumerate with value 256 to
          indicate the protocol number. NOTE: In case
          of IPv6, the protocol in the IP packet payload
          is specified in the Next Header field of the IPv6
          packet.";

[There are perhaps some complications around this description when
extension headers are in use.]

        leaf bytes {
          type uint32;
          default 0;
          description
            "If the IPsec SA processes the number of bytes
            expressed in this leaf, the IPsec SA expires and
            should be rekeyed. The value 0 implies
            infinite.";

32 bits for a byte lifetime is perhaps overly restrictive; some
encryption schemes do not have cryptographic need to rekey that
frequently, so a 64-bit counter would be more appropriate for them.

            is a waste of resources. If the IPsec SA is idle
            during this number of seconds the IPsec SA
            should be removed. The value 0 implies
            infinite.";
        }
        reference
          "Section 4.4.2.1 in RFC 4301.";

I don't see any mention of "idle" in RFC 4301.

        leaf bypass-dscp {
          type boolean;
          default true;
          description
            "If DSCP (Differentiated Services Code Point)
            values in the inner header have to be used to
            select one IPsec SA among several that match
            the traffic selectors for an outbound packet";

This doesn't really give me a clear picture of what action to take when
it has value 'true' (vs 'false').

        list local-ports {
          key "start end";
          uses port-range;
          description
            "List of local ports. When the inner
            protocol is ICMP this 16 bit value
            represents code and type.
            If this list is not defined
            it is assumed that start and
            end are 0 by default (any port).";

Shouldn't these extra semantics be attached to the port-range grouping
itself?  Also, the repurposing of start/end for ICMP code/type is quite
unconventional.

        leaf anti-replay-window {
          type uint64;
          default 32;
          description
            "A 64-bit counter used to determine whether an
            inbound ESP packet is a replay.";
          reference
            "Section 4.4.2.1 in RFC 4301.";

Is this the counter or the bit-map or the size of the bit-map?
I don't think a uint64 combined with default 32 makes sense.

            leaf seq-overflow {
              type boolean;
              default false;

I think we may want to give a stronger indication that setting this to
'true' is strongly discouraged.

                leaf id {
                  type uint8;
                  description
                    "The index of list with the
                    different encryption algorithms and
                    its key-length (if required).";

I'm not sure what this id is indexing into and how it would indicate key
length.  Is the idea that this is a sequential index for the very 'list
encryption' that it is contained in?  If so, I think we would need to
write more specifics about its semantics and how it is assigned.

Appendix B

        "This module contains IPsec IKE case model for the SDN-based
        IPsec flow protection service. An NSF will implement this
        module.

Why do we have the last sentence?  IIUC we do not mandate implementation
of the IKE case, since the IKE-less case is seen as making this more
accessible for lower-resourced NSFs.

          enum on-demand {
            description
              "IKE/IPsec configuration is loaded
              into IKE implementation. The IPsec policies
              are transferred to the NSF's kernel but the
              IPsec SAs are not established immediately.
              The IKE implementation will negotiate the
              IPsec SAs when the NSF's kernel requests it
              (i.e. through an ACQUIRE notification).";

I'm not sure I understand the intended semantics of the ACQUIRE
notification, here -- the sadb-acquire notification is part of this YANG
module, which would typically imply that it is send from the NSF to the
I2NSF Controller.  I'm not sure where the NSF's kernel is, in that path.
(We also haven't really talked about "NSF kernel"s previously, though
we did have significant discussion of kernel IPsec/IKE implementations.)

      typedef pfs-group{

"pfs-group" (and the "pfs-groups" nodes of this type) calls to mind
"perfect forward secrecy", but the guidance from SAAG is moving towards
dropping the "perfect" part since it is a bit misleading and its meaning
is not terribly well-defined.

          list pad-entry {
            [...]
            leaf name {
            [...]
            choice identity {

I guess I would have expected some discussion somewhere (possibly up in
§6.1) about why there is both a 'name' and an 'identity'.  (I might
surmise that it is to allow differently-named-and-configured SAs to the
same remotem peer, but that is just supposition if there's no text in
the document about it.)

                leaf dnx509 {
                  type string;

I assume from the 'string' type and the example that we use the
presentation form and not (e.g.) the DER encoded form.  This is probably
worth stating explicitly.

                leaf eap-type {
                  type uint8;
                  mandatory true;
                  description
                    "EAP method type. This
                    information provides the
                    particular EAP method to be
                    used. Depending on the EAP
                    method, pre-shared keys or
                    certificates may be used.";

A reference to where the actual method type values are obtained (e.g.,
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4)
seems in order.  I note that there is a range allocatable via
"Specification Required" in that registry that is not representable in a
uint8.

              container pre-shared {
                when
                  "../auth-method[.='pre-shared' or
                  .='eap']";

This seems a little unfortunate, as I don't think that it is appropriate
to require ("mandatory true") the pre-shared secret leaf to be present,
universally, for all EAP methods.o

              container digital-signature {
                when
                  "../auth-method[.='digital-signature'
                  or .='eap']";

Similarly here, for the mandatory 'public key' choice -- if I am reading
this correctly the YANG would require us to have both pre-shared *and*
public-key values present for the 'eap' auth-method.

                leaf ds-algorithm {
                  type uint8;
                  default 1;

My understanding is that algorithm 14 (the generic "digital signature")
is currently preferred as the default algorithm, since it is not tied to
a particular public key type.  See
https://tools.ietf.org/html/rfc8247#section-3.1 for discussion of why it
is expected to be the way of the future.

                      signature algorithm. For
                      example, an RSA key is
                      represented as RSAPublicKey as
                      defined in RFC 8017, and an
                      Elliptic Curve Cryptography
                      (ECC) key is represented
                      using the 'publicKey'
                      described in RFC 5915.";

This is perhaps a bit under-specified without a clear procedure for
going from a digital signature algorithm codepoint to the specification
of the public key encoding.  That said, I'm not sure that there is a
very good thing to say here, and even the RFC 7427 generic "Digital
Signature" type is effectively still deferring to the ASN.1
AlgorithmIdentifier.  (Similarly for the 'private-key', of course.)

                  leaf cert-data {
                    type binary;
                    description
                      "X.509 certificate data -
                      PEM4. If raw-public-key
                      is defined this leaf is
                      empty.";

If the leaf it of type binary we don't need the (ASCII) PEM encoding.
(Also, why the '4' in "PEM4"?)

                leaf crl-uri  {
                  type inet:uri;
                  description
                    "X.509 CRL certificate URI.
                    If it is not defined
                    the default value is empty.";

An RFC 5280 reference would probably be appropriate here as well.

                leaf oscp-uri {
                  type inet:uri;
                  description
                    "OCSP URI.
                    If it is not defined
                    the default value is empty.";

and maybe 2560 or 5280 here.

          leaf-list authalg {
            type nsfikec:integrity-algorithm-type;
            default 12;
            ordered-by user;
            description
              "Authentication algorithm for establishing

Using "authentication algorithm" in the description here (and "authalg"
as the node name) seems needlessly confusing, since these are the IKEv2
integrity algorithms, and there is a separate thing that is the IKE
authentication methods.

          list encalg {
            key id;
            min-elements 1;
            ordered-by user;
            leaf id {
              type uint8;
              description
                "The index of the list with the
                different encryption algorithms and its
                key-length (if required). E.g. AES-CBC,
                128 bits";

As was the case for esp-algorithms/encryption, I'm not sure what this id
is indexing into and how it would indicate key length.  Is the idea that
this is a sequential index for the very 'list encryption' that it is
contained in?  If so, I think we would need to write more specifics
about its semantics and how it is assigned.

          leaf half-open-ike-sa-timer {
            type uint32;
            default 0;
            description
              "Set the half-open IKE SA timeout
              duration.";

What are the units?  Does 0 really mean 0 (vs infinity)?

          container child-sa-info {
            leaf-list pfs-groups {

["pfs" again, just noting the location; no new comment other than the
one above]

            leaf current-rekey-time {
              type uint64;
              units "seconds";
              description
                "Seconds before IKE SA MUST be rekeyed.";
            }
            leaf current-reauth-time {
              type uint64;
              units "seconds";
              description
                "Seconds before IKE SA MUST be
                re-authenticated.";

I don't think either of these strictly speaking need to be RFC 2119
"MUST"s.

        container number-ike-sas {

In general it seems like these counters could be gauge64's instead of
uint64's.

Appendix C

            container ipsec-sa-config {
              [...]
              leaf spi {
                type uint32 { range "0..max"; }

I would have expected a clear indication of whether this value is for
sending or receiving.

              leaf seq-number-counter {

Why is this leaf writable?

              leaf anti-replay-window {
                type uint32;
                default 32;
                description
                  "A 32-bit counter and a bit-map (or
                  equivalent) used to determine
                  whether an inbound ESP packet is a
                  replay. If set to 0 no anti-replay

First, in the common module the anti-replay-window was a uint64, but
here it's uint32.  Second, my confusion/comment from the common module
seem to also apply here.

                leaf replay-window {
                  type uint64;
                  description
                    "Current state of the replay
                    window.";

Probably a little bit more description and/or reference is in order
here.

                leaf packet-dropped {
                  type uint64;

IIUC this could be a counter64.

                leaf failed {
                  type uint32;
                  description
                    "Number of packets detected out
                    of the replay window.";

How is this different from 'packet-dropped' (and why does it only need
to be a 32-bit counter)?  Also, would a 'counter32' (or 'counter64')
type be appropriate?

      notification sadb-acquire {
        if-feature ikeless-notification;
        description
          "An IPsec SA is required. The traffic-selector
          container contains information about the IP packet
          that triggers the acquire notification.";

If I understand correctly, the scenario here is that an inbound packet
arrives at (or is generated by) the NSF and it is determined that the
packet needs IPsec protection to proceed.  Some guidance on whether we
should use exact-address match to determine the source and destination
prefixes or some heuristic to select a less-specific prefix seems like
it would be in order.  (Or is this all supposed to be specified in the
corresponding SPD entry?)

        container lifetime-current {
          description
            "IPsec SA current lifetime. If
            soft-lifetime-expired is true this container is
            set with the lifetime information about current
            soft lifetime.";

I'm not 100% sure I understand what goes in this field -- intuitively,
though, it seems like what would be most useful to the I2NSF Controller
would be the time before the *hard* lifetime expires (since we already
know that the soft lifetime has expired by virtue of this being a
sadb-expire notification with soft-lifetime-expired set to true).

      notification sadb-seq-overflow {
        if-feature ikeless-notification;
        description "Sequence overflow notification.";
        leaf ipsec-sa-name {
          type string;
          mandatory true;
          description
            "It contains the SAD entry name (unique) of
            the IPsec SA that is about to have sequence
            number overflow and rollover is not permitted.
            It is assumed the I2NSF Controller will have
            a copy of the IPsec SA information (except the
            cryptographic material and state data) indexed
            by this name (unique identifier) so the it can
            know all the information (crypto algorithms,
            etc.) about the IPsec SA that has expired in
            order to perform a rekey of the IPsec SA.";
        }

There seems to be internal disagreement here ("about to have ...
overflow" vs "that has expired") -- it seems more useful for this to be
the "about to" behavior, but in that case we should give some guidance
about how to measure "about to".

Appendix D

  This example shows a XML configuration file sent by the I2NSF
  Controller to establish a IPsec Security Association between two NSFs
  (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP,
  authentication based on X.509 certificates and applying the IKE case.

Maybe note that some (base64) values have been simplified and/or
truncated for brevity?  ("base64encodedvalue==" is not a valid base64
encoding of a DER-encoded X.509 certificate, for example)

       
        <authalg>7</authalg>

Perhaps a non-SHA1 example would age better (even though HMAC-SHA1 is
not known to be weak at this point).

                  <local-ports>
                    <start>0</start>
                    <end>0</end>
                  </local-ports>
                  <remote-ports>
                    <start>0</start>
                    <end>0</end>
                  </remote-ports>

These are the default values and could be omitted, if I understand
correctly.

Appendix E

I would prefer if the examples did not show seq-overflow as true.

                <inner-protocol>any</inner-protocol>

Is this encoded as "any" as shown, or as 256?

Appendix G.1.2

      *  The I2NSF Controller chooses two random values as SPIs: for
          example, SPIa1 for NSF A and SPIb1 for NSF B.  These numbers
          MUST NOT be in conflict with any IPsec SA in NSF A or NSF B.

Is this restriction for the respective SPI<X>/NSF<X> pairs, or for the
full matrix of combinations?
(Similarly in G.2)

Appendix G.2

  If step 1 is successful but some of the operations in step 2 fails
  (e.g. the NSF A reports an error when the I2NSF Controller is trying
  to install the new outbound IPsec SA), the I2NSF Controller MUST
  perform a rollback operation by deleting any new outbound SA that had
  been successfully installed during step 2 and by deleting the inbound
  SAs created in step 1.

I think it's important that the two rollbacks are done in the order
listed here.


NITS

Section 1

  resources through software.  The SDN paradigm relocates the control
  of network resources to a centralized entity, namely SDN Controller.

"the SDN Controller".

                                        For example, Software-Defined
  WANs (SD-WANs).  [...]

incomplete sentence (no verb).

  can be established using IPsec.  The management of IPsec SAs in data
  centers using a centralized entity is a scenario where the current
  specification maybe applicable.

s/maybe/may be/

  I2NSF NSF-Facing interface.  In this document we define a service
  allowing the I2NSF Controller to carry out the key management
  procedures.  More specifically, we define YANG data models for I2NSF

I'm not sure that "service" is the best word, here.

  NSF-Facing interface that allow the I2NSF Controller to configure and
  monitor IPsec-enabled flow-based NSFs.

missing article ("the" or "a") before "I2NSF NSF-Facing interface".
(Also, it's weird that "Facing" is capitalized but "interface" is not.)

  IPsec architecture [RFC4301] defines clear separation between the

more articles: "The IPsec architecture", "a clear separation"

  which allows to centralize the key management procedures in the I2NSF

s/to centralize/centralizing/

      charge of provisioning the NSF with the required information in
      the SPD, PAD (e.g.  IKE credential) and IKE protocol itself (e.g.
      parameters for the IKE_SA_INIT negotiation).

comma after "e.g." (twice)
"credentials" plural
There's amismatch between "in the [databases] and "in IKE protocol
itself" -- it should more properly be "for the IKE protocol itself",
which makes the list non-parallel, so it would be "in the SPD and PAD
(...), and for the IKE protocol itself".

      required parameters to create valid entries in the SPD and the
      SAD into the NSF.  Therefore, the NSF will have only support for

"into" is not right; maybe "in" or "of".
s/have only/only have/

  o  To describe the architecture for the I2NSF-based IPsec management,

s/the I2NSF-based/I2NSF-based/

Section 4

  As mentioned in Section 1, two cases are considered, depending on
  whether the NSF implements IKEv2 or not: IKE case and IKE-less case.

more articles: "the" for both cases

  parameters (e.g.  cryptographic algorithms for establishing an IKEv2

comma after "e.g."

  information about the end points information (through the I2NSF

redundant "information"s

Section 4.2

  o  Cryptographic algorithm/s selection.

Just "algorithm" works fine for both the singular and plural case.

Section 5

  IKEv2/IPsec implementation, hosts can easily install it.  As
  downside, the NSF needs more resources to hold IKEv2 such as memory

"As a downside"
"to use IKEv2"

  Alternatively, IKE-less case benefits the deployment in resource-

"the IKE-less case"

  centralized controller (like the I2NSF Controller) is aware about

s/about/of/

  provided and discussed (e.g.  hierarchical controllers; having
  multiple replicated controllers, dedicated high-speed management
  networks, etc).  In the context of I2SNF-based IPsec management, one

I think s/;/,/ to be consistent about the list separator within a single
list.

  waiting for notifications (e.g. a notification sadb-acquire when a

comma after "e.g."

Section 5.1

  the old one (if a IPsec SA lifetime has not been defined).  This
  rekeying process starts when the I2NSF Controller receives a sadb-
  expire notification or it decides so, based on lifetime state data

s/or it decides so/or on the I2NSF Controller's initiative/

Section 5.2

  with the new IKEv2, SPD and PAD information.  It has also to send new

s/has also/also has/

Section 5.3

  some of the peers or both are located behind a NAT.  If there is a
  NAT network configured between two peers, it is required to activate
  the usage of UDP or TCP/TLS encapsulation for ESP packets ([RFC3948],

The "it is required" could be misread to have "it" mean "the NAT
network"; rewording the second clause to be "UDP or TCP/TLS
encapsulation for ESP packets ([RFC3948]) is required" would help with
that.

  [RFC8229]).  Note that the usage of IPsec transport mode when NAT is
  required MUST NOT be used in this specification.

"usage" and "used" seem redundant.

Section 5.4

  NSF registration refers to the process of facilitating the I2NSF
  Controller information about a valid NSF such as certificate, IP

s/facilitating/providing/ or similar

  address, etc.  This information is incorporated in a list of NSFs
  under its control

full stop at end of sentence.

  capabilities of this NSF, such as what is the cryptographic suite
  supported, authentication method, the support of the IKE case and/or

s/is/are/, s/suite/suites/

Section 6.1

  configure the Peer Authentication Database with authentication
  information about local and remote peers.  More precisely, it

"authentication information about local peers" reads a bit oddly.

  authentication method and credentials that will use a particular
  peer.

s/that will use a particular peer/that a particular peer will use/

Section 6.2

  The data model consists of a unique "ipsec-ikeless" container which,
  in turn, is integrated by two additional containers: "spd" and "sad".

"integrated by" is probably not the right term here; "composed of" might
be better.

  The "spd" container consists of a list of entries that conform the

s/conform/form/ (or similar), I think.

  IPsec SAs.  The "sad" container is a list of entries that conform the

(ditto)

  Security Association Database.  In general, each entry allows to
  specify both configuration information (SPI, traffic selectors,

s/to specify/specifying/

Section 8.3

        to be used for the authentication (e.g. to impersonate a NSF),

comma after "e.g." (occurs several times in this section).

        changing to a allow policy), and in general changing the IKE SA

s/a/an/

        example, encryption/key contains a ESP encryption key value and

s/a ESP/an ESP/

        encryption/iv contains a initialization vector value.

s/a initialization/an initialization/

        Similarly, integrity/key has ESP integrity key value.  Those

s/has/has an/

Appendix A

          "The encryption algorithm is specified with a 16-bit
          number extracted from IANA Registry. The acceptable

missing article for "IANA Registry" (so probably "the", since only one
registry is listed).
(similarly for integrity-algorithm-type)

          "The integrity algorithm is specified with a 16-bit
          number extracted from IANA Registry.
          The acceptable values MUST follow the requirement
          levels for encryption algorithms for ESP and IKEv2.";

s/encryption/integrity/, right?

          enum none {
            description
              "NOT ESP encapsulation.";

"Not" probably doesn't need to be capitalized.

        description
          "Types of ESP encapsulation when Network Address
          Translation (NAT) is present between two NSFs.";

Perhaps s/is/may be/, as it doesn't seem like an intrinsic requirement
for the use of encapsulation.

        description
          "When the lifetime of an IPsec SA expires an action
          needs to be performed over the IPsec SA that

"over" doesn't seem like the right word; perhaps "for"?

        description
          "This group of nodes allows to define the type of
          encapsulation in case NAT traversal is
          required and port information.";

s/and/and includes/

          description
            "When a NSF stores an IPsec SA, it
            consumes system resources. In an idle NSF this

Maybe s/In an idle NSF/For an idle SA/?

            enum clear {
              description
                "Disable the DF (Don't Fragment) bit
                from the outer header. This is the

s/from/in/

        container traffic-selector {
          description
            "Packets are selected for
            processing actions based on the IP and inner
            protocol header information, selectors,
            matched against entries in the SPD.";

The grammar here doesn't make sense, to the extent that I can't really
even guess the intended meaning.  It makes the most sense if I just end
the sentence after "inner protocol header information".  Perhaps the
remaining bit was intended to be a separate statement that "selectors
are matched against" something?

              description
                "True if this IPsec SA is using extended
                sequence numbers. True 64 bit counter,
                False 32 bit.";

How about (for the second sentence): "If true, the 64-bit extended
sequence number counter is used; if false, the normal 32-bit sequence
number counter is used"?

                    "Configuration of ESP authentication
                    based on the specified integrity
                    algorithm. With AEAD algorithms,
                    the integrity node is not used.";
s/AEAD algorithms/AEAD encryption algorithms/

Appendix B

        description
          "IKE authentication protocol version specified in the
          Peer Authorization Database (PAD). It is defined as
          enumerate to allow new IKE versions in the

s/enumerate/enumerated/

          enum digital-signature {
            description
              "Select digital signature method.";

s/method/as the authentication method/ to match the others.

      container ipsec-ike {
        description
          "IKE configuration for a NSF. It includes PAD
          parameters, IKE connections information and state

s/connections/connection/

            "Configuration of Peer Authorization Database
            (PAD). The PAD contains information about IKE

s/Peer/the Peer/.

            peer (local and remote). Therefore, the Security

s/peer/peers/

            Controller also stores authentication
            information for this NSF and can include
            several entries for the local NSF not only
            remote peers. Storing local and remote

comma before "not only".

            information makes possible to specify that this

s/makes possible/makes it possible/

            NSF with identity A will use some particular
            authentication with remote NSF with identity B
            and what are the authentication mechanisms
            allowed to B.";

s/allowed/allowed for communication/

                  description
                    "Specifies the identity as a
                    single four (4) octet.";

"four-octet value".  (The current text says that it is a single byte
with value 0x4, which is not a very useful identifier.)

                    "Specifies the identity as a
                    Fully-QualifiedDomain Name

space in "Qualified Domain".

              case rfc822-address-string {

(I'm still a little confused why email address identifiers are useful
enough to be in the core spec, but I think I am behind on the email
thread so maybe it is answered there.)

                  description
                    "Specifies the identity as a
                    ASN.1 X.500 Distinguished

s/a/an/

                    "ID_NULL identification used
                    when IKE identification payload

"The ID_NULL identification method is used when the IKE identification
payload [...]".

                "This container allows the Security
                Controller to configure the
                authentication method (pre-shared key,
                eap, digitial-signature, null) that
                will use a particular peer and the

"will be used with"

                credentials, which will depend on the

"credentials to use"

                    "If the I2NSF Controller
                    knows that the NSF
                    already owns a private key
                    associated to this public key
                    (the NSF generated the pair
                    public key/private key out of
                    band), it will only configure

I think this is better with "e.g.," at the start of the parenthetical.

            "IKE peer connection information. This list
            contains the IKE connection for this peer
            with other peers. This will be translated in
            real time by IKE Security Associations
            established with these nodes.";

Is "translated" the right word here?

          leaf autostartup {
            type autostartup-type;
            default add;
            description
              "By-default: Only add configuration
              without starting the security
              association.";

This seems to be describing the default behavior, not the function of
the leaf overall.

          leaf version {
            type auth-protocol-type;
            default ikev2;
            description
              "IKE version. Only version 2 is supported
              so far.";

"so far" is perhaps a bit colloquail for RFC style.

                "Time in seconds between each IKE SA
                rekey.The value 0 means infinite.";

Space at the sentence break.

                "If non-zero, perfect forward secrecy
                is required when requesting new
                IPsec SA. The non-zero value is
                the required group number. [...]

How about:

% If non-zero, forward secrecy is required when a new IPsec SA is being
% created.  The (non-zero) value indicates the group number to use for
% the key exchange process used to achieve forward secrecy.

                "Soft IPsec SA lifetime soft.

redundant "soft"s.

                description
                  "True if this IPsec SA is using
                  extended sequence numbers. True 64
                  bit counter, false 32 bit.";

[same comment as previously]

                    description
                      "ESP encryption IV value. If
                      this leaf is not defined the
                      IV is not defined (e.g.
                      encryption is NULL)";
                  }

Maybe say how the IV length is determined?

                    IPsec Encapsulation Security
                    Payload (ESP). This container
                    allows to configure integrity
                    algorithm when no AEAD

s/allows to configure/allows configuration of/
s/algorithm/algorithms/

                      the key is not defined (e.g.

comma after "e.g.".

                    "Packets detected out of the
                    replay window and dropped
                    because they are replay
                    packets.";

s/they are/they are assumed to be/

            description
              "List of SAD entries that conforms the SAD.";

s/conforms/forms/ again, I think.
2020-11-04
12 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-11-04
12 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-11-04
12 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-11-04
12 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-11-04
12 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-11-04
12 Warren Kumari
[Ballot comment]
Firstly, thank you for addressing the OpsDir review comments, and also to Menachem Dodge for having provided them. This week has been hectic, …
[Ballot comment]
Firstly, thank you for addressing the OpsDir review comments, and also to Menachem Dodge for having provided them. This week has been hectic, and so I've been relying on the directorate to help with my balloting...

I support Erik's DISCUSS, and think it should be easy to address...
2020-11-04
12 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-11-03
12 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-11-03
12 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-11-01
12 Erik Kline
[Ballot discuss]
general ]

* Similar to df-bit and ecn, should there be a tunnel-grouping leaf that
  controls how inner DSCP marking should be …
[Ballot discuss]
general ]

* Similar to df-bit and ecn, should there be a tunnel-grouping leaf that
  controls how inner DSCP marking should be reflected on the outer IPsec
  header? (RFC 2983 suggests using multiple tunnels instead and warns about
  the danger of packet reordering as a result of variable DSCP marking (as
  well as the potential information leak as a security issue), so maybe this
  isn't important.

  Separately, what about a setting to explicitly configure the DSCP mark on
  the outer header for all encap'd packets?

[ appendix A ]

* I'm unclear on what bypass-dscp=true means.  Does it mean that the DSCP
  value is *not* part of the traffic selector?

  Should this instead be called "ignore-dscp" or "skip-dscp"?

* Related: does the dscp-mapping leaf only have significance if bypass-dscp
  is false?  If so, is there some "must ../bypass-dscp ..." syntax that would
  be applicable?
2020-11-01
12 Erik Kline
[Ballot comment]
[[ comments ]]

[ appendix A ]

* WRT the df-bit description.  I think something should say that this
  MUST be ignored …
[Ballot comment]
[[ comments ]]

[ appendix A ]

* WRT the df-bit description.  I think something should say that this
  MUST be ignored or has no meaning when the local/remote IP addresses
  are IPv6 addresses.

[ appendix D ]

* "2001:DB8" -> "2001:db8" everywhere

  RFC 5952 section 4.3 says: lowercase for hex characters.

[ appendix E ]

* "2001:DB8" -> "2001:db8" everywhere

  RFC 5952 section 4.3 says: lowercase for hex characters.


[[ questions ]]

[ section 6.2 ]

* Why is spd-mask a hex-string when spd-mark is a uint32?  I would have
  expected them both to be uint32 or, at a minimum, both the same type.

  In appendix A they both appear to be uint32.


[[ nits ]]

[ section 1 ]

* Saying that SDN allows "users to directly program..." seemed a little odd
  (vis. common definitions of "users").  Perhaps s/users/administrators/, or
  "network operators"?  Alternatively "allows I2NSF Users", perhaps.

[ section 6.2 ]

* s/Notificsation/Notification/

* s/conform/constitute/g?

[ appendix A ]

* "NOT ESP encapsulation." -> "NO ESP encapsulation.", perhaps

[ appendix B ]

* s/typedef pfs-group{/typedef pfs-group {/

* s/the only defined right now/the only one defined right now/

* In the description for pad/identity/ipv4-address:

  "Specifies the identity as a single four (4) octet." ->
  "Specifies the identity as a single four (4) octet IPv4 address."
2020-11-01
12 Erik Kline [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline
2020-10-30
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-10-30
12 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-12.txt
2020-10-30
12 (System) New version approved
2020-10-30
12 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2020-10-30
12 Rafael Marin-Lopez Uploaded new revision
2020-10-23
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-10-23
11 Bernie Volz Request for Telechat review by INTDIR is assigned to Hui Deng
2020-10-23
11 Bernie Volz Request for Telechat review by INTDIR is assigned to Hui Deng
2020-10-22
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Derek Atkins
2020-10-22
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Derek Atkins
2020-10-22
11 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
2020-10-22
11 (System) New version approved
2020-10-22
11 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2020-10-22
11 Rafael Marin-Lopez Uploaded new revision
2020-10-22
10 Éric Vyncke Requested Telechat review by INTDIR
2020-10-21
10 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2020-10-21
10 Cindy Morgan Placed on agenda for telechat - 2020-11-05
2020-10-21
10 Roman Danyliw Ballot has been issued
2020-10-21
10 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2020-10-21
10 Roman Danyliw Created "Approve" ballot
2020-10-21
10 Roman Danyliw Ballot writeup was changed
2020-10-21
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-21
10 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-10.txt
2020-10-21
10 (System) New version approved
2020-10-21
10 (System) Request for posting confirmation emailed to previous authors: Gabriel Lopez-Millan <gabilm@um.es>, Rafael Lopez <rafa@um.es>, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>
2020-10-21
10 Rafael Marin-Lopez Uploaded new revision
2020-10-15
09 Roman Danyliw Per Yangdoctors review
2020-10-15
09 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup
2020-10-12
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-12
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-10-12
09 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt
2020-10-12
09 (System) New version approved
2020-10-12
09 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2020-10-12
09 Rafael Marin-Lopez Uploaded new revision
2020-09-16
08 Roman Danyliw Please make the simple editorial changes from the SECDIR and OPSDIR review; and follow-up on the GENART and YANGDOCTORS feedback (and related thread).
2020-09-16
08 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2020-09-08
08 Sabrina Tanamal
In the XML examples, the "nc" namespace is defined but never used as far as I can tell.  Which isn't an error or anything, just …
In the XML examples, the "nc" namespace is defined but never used as far as I can tell.  Which isn't an error or anything, just a bit surprising. Anyhow, looks good to me.
2020-09-08
08 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2020-09-08
08 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-09-04
08 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2020-09-04
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-09-04
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

three, new namespaces will be registered as follows:

ID: yang:ietf-ipsec-common
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ipsec-ike
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ipsec-ikeless
URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

three, new YANG modules will be registered as follows:

Name: ietf-ipsec-common
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common
Prefix: ic
Module:
Reference: [ RFC-to-be ]

Name: ietf-ipsec-ike
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike
Prefix: ike
Module:
Reference: [ RFC-to-be ]

Name: ietf-ipsec-ikeless
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless
Prefix: ikeless
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-09-04
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-09-03
08 Derek Atkins Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Derek Atkins. Sent review to list.
2020-09-03
08 Menachem Dodge Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Menachem Dodge. Sent review to list.
2020-08-31
08 Mohit Sethi Request for Last Call review by GENART Completed: On the Right Track. Reviewer: Mohit Sethi. Sent review to list.
2020-08-27
08 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2020-08-27
08 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2020-08-27
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2020-08-27
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2020-08-24
08 Martin Björklund Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Martin Björklund. Sent review to list.
2020-08-24
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2020-08-24
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Menachem Dodge
2020-08-21
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-08-21
08 Amy Vezza
The following Last Call announcement was sent out (ends 2020-09-04):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Yoav Nir <ynir.ietf@gmail.com …
The following Last Call announcement was sent out (ends 2020-09-04):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Yoav Nir <ynir.ietf@gmail.com>, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, i2nsf@ietf.org, i2nsf-chairs@ietf.org, ynir.ietf@gmail.com, rdd@cert.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt> (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard


The IESG has received a request from the Interface to Network Security
Functions WG (i2nsf) to consider the following document: - 'Software-Defined
Networking (SDN)-based IPsec Flow Protection'
  <draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how to provide IPsec-based flow protection
  (integrity and confidentiality) by means of an I2NSF Controller.  It
  considers two main well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The service described in this
  document allows the configuration and monitoring of IPsec information
  from a I2NSF Controller to one or several flow-based Network Security
  Function (NSF) that implement IPsec to protect data traffic.

  The document focuses on the I2NSF NSF-Facing Interface by providing
  YANG data models for configuration and state data required to allow
  the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD)
  and IKEv2 to establish IPsec Security Associations with a reduced
  intervention of the network administrator.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/



No IPR declarations have been submitted directly on this I-D.




2020-08-21
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-08-21
08 Roman Danyliw Last call was requested
2020-08-21
08 Roman Danyliw Last call announcement was generated
2020-08-21
08 Roman Danyliw Ballot approval text was generated
2020-08-21
08 Roman Danyliw Ballot writeup was generated
2020-08-21
08 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-08-07
08 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Martin Björklund
2020-08-07
08 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Martin Björklund
2020-08-05
08 Yoav Nir Requested Last Call review by YANGDOCTORS
2020-06-17
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-06-17
08 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt
2020-06-17
08 (System) New version approved
2020-06-17
08 (System) Request for posting confirmation emailed to previous authors: Rafael Lopez <rafa@um.es>, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Gabriel Lopez-Millan <gabilm@um.es>
2020-06-17
08 Rafael Marin-Lopez Uploaded new revision
2020-05-11
07 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-05-11
07 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/i2nsf/xZmbYgNXGUERGj7XqqUA7dPshmw/
2020-03-22
07 Roman Danyliw IESG state changed to AD Evaluation from Publication Requested
2019-11-20
07 Yoav Nir
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys …
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys on IPsec implementations (NSFs) using an SDN controller in two of the main IPsec scenarios: host-to-host, and gateway-to-gateway. It intentionally leaves out the client-to-gateway scenario, also known as the "road warrior", as such clients don't fit into the model of control by an SDN controller.  The working group has consensus that Standards Track is the appropriate track for this document.

2. Review and Consensus
The document describes two modes of configuration, or "cases" as they're called in the document: IKE and IKE-less. The "IKE" case involves configuring the NSFs with policies, identities, and credentials so that the IKE protocol can set up traffic keys. The "IKE-less" case involves configuring the NSFs with policies and traffic keys directly. The "IKE-less" case was controversial at first, with people from the IPsecME group objecting to it. Over time some usage scenarios were described where the IKE-less case may be more efficient, and the document now represents the consensus of the working group. It has received wide review, including from IPsec people such as Tero Kivinen and Paul Wouters.  The YANG models have received early review from the YANG doctors.

The authors have an incomplete implementation that is open source.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosure on the document.

4. Other Points
We believe the document is ready for publication.
The YANG model in this document raised the issue of embedding IANA registries in YANG models. In this case, it was the list of algorithms used for IKE or IPsec. Different versions of the document had different schemes, but we finally settled on embedding the algorithm number from the IANA registry as an integer.
2019-11-20
07 Yoav Nir Responsible AD changed to Roman Danyliw
2019-11-20
07 Yoav Nir IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2019-11-20
07 Yoav Nir IESG state changed to Publication Requested from I-D Exists
2019-11-20
07 Yoav Nir IESG process started in state Publication Requested
2019-08-06
07 Yoav Nir
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys …
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys on IPsec implementations (NSFs) using an SDN controller in two of the main IPsec scenarios: host-to-host, and gateway-to-gateway. It intentionally leaves out the client-to-gateway scenario, also known as the "road warrior", as such clients don't fit into the model of control by an SDN controller.  The working group has consensus that Standards Track is the appropriate track for this document.

2. Review and Consensus
The document describes two modes of configuration, or "cases" as they're called in the document: IKE and IKE-less. The "IKE" case involves configuring the NSFs with policies, identities, and credentials so that the IKE protocol can set up traffic keys. The "IKE-less" case involves configuring the NSFs with policies and traffic keys directly. The "IKE-less" case was controversial at first, with people from the IPsecME group objecting to it. Over time some usage scenarios were described where the IKE-less case may be more efficient, and the document now represents the consensus of the working group. It has received wide review, including from IPsec people such as Tero Kivinen and Paul Wouters.  The YANG models have received early review from the YANG doctors.

The authors have an incomplete implementation that is open source.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosure on the document.

4. Other Points
We believe the document is ready for publication.
The YANG model in this document raised the issue of embedding IANA registries in YANG models. In this case, it was the list of algorithms used for IKE or IPsec. Different versions of the document had different schemes, but we finally settled on embedding the algorithm number from the IANA registry as an integer.
2019-08-05
07 Yoav Nir IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2019-08-05
07 Yoav Nir
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys …
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys on IPsec implementations (NSFs) using an SDN controller in two of the main IPsec scenarios: host-to-host, and gateway-to-gateway. It intentionally leaves out the client-to-gateway scenario, also known as the "road warrior", as such clients don't fit into the model of control by an SDN controller.  The working group has consensus that Standards Track is the appropriate track for this document.

2. Review and Consensus
The document describes two modes of configuration, or "cases" as they're called in the document: IKE and IKE-less. The "IKE" case involves configuring the NSFs with policies, identities, and credentials so that the IKE protocol can set up traffic keys. The "IKE-less" case involves configuring the NSFs with policies and traffic keys directly. The "IKE-less" case was controversial at first, with people from the IPsecME group objecting to it. Over time some usage scenarios were described where the IKE-less case may be more efficient, and the document now represents the consensus of the working group. It has received wide review, including from IPsec people such as Tero Kivinen and Paul Wouters.  The YANG models have received early review from the YANG doctors.

The authors have an implementation that is intended to be open source, but it is not yet published.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosure on the document.

4. Other Points
We believe the document is ready for publication.
The YANG model in this document raised the issue of embedding IANA registries in YANG models. In this case, it was the list of algorithms used for IKE or IPsec. Different versions of the document had different schemes, but we finally settled on embedding the algorithm number from the IANA registry as an integer.
2019-08-05
07 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt
2019-08-05
07 (System) New version approved
2019-08-05
07 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2019-08-05
07 Rafael Marin-Lopez Uploaded new revision
2019-08-02
06 Yoav Nir
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys …
1. Summary
The document shepherd is Yoav Nir.  The responsible AD is Roman Danyliw.

This document describes a way to configure IPsec policy and/or keys on IPsec implementations (NSFs) using an SDN controller in two of the main IPsec scenarios: host-to-host, and gateway-to-gateway. It intentionally leaves out the client-to-gateway scenario, also known as the "road warrior", as such clients don't fit into the model of control by an SDN controller.  The working group has consensus that Standards Track is the appropriate track for this document.

2. Review and Consensus
The document describes two modes of configuration, or "cases" as they're called in the document: IKE and IKE-less. The "IKE" case involves configuring the NSFs with policies, identities, and credentials so that the IKE protocol can set up traffic keys. The "IKE-less" case involves configuring the NSFs with policies and traffic keys directly. The "IKE-less" case was controversial at first, with people from the IPsecME group objecting to it. Over time some usage scenarios were described where the IKE-less case may be more efficient, and the document now represents the consensus of the working group. It has received wide review, including from IPsec people such as Tero Kivinen and Paul Wouters.  The YANG models have received early review from the YANG doctors.

The authors have an implementation that is intended to be open source, but it is not yet published.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosure on the document.

4. Other Points
Other than a YANG nit and a few text formatting issues, we believe the document is ready for publication.
The YANG model in this document raised the issue of embedding IANA registries in YANG models. In this case, it was the list of algorithms used for IKE or IPsec. Different versions of the document had different schemes, but we finally settled on embedding the algorithm number from the IANA registry as an integer.
2019-08-02
06 Yoav Nir Notification list changed to Yoav Nir <ynir.ietf@gmail.com>
2019-08-02
06 Yoav Nir Document shepherd changed to Yoav Nir
2019-08-02
06 Yoav Nir Changed consensus to Yes from Unknown
2019-08-02
06 Yoav Nir Intended Status changed to Proposed Standard from None
2019-07-29
06 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt
2019-07-29
06 (System) New version approved
2019-07-29
06 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2019-07-29
06 Rafael Marin-Lopez Uploaded new revision
2019-07-07
05 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
2019-07-07
05 (System) New version approved
2019-07-07
05 (System) Request for posting confirmation emailed to previous authors: Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2019-07-07
05 Rafael Marin-Lopez Uploaded new revision
2019-04-17
04 Martin Björklund Request for Early review by YANGDOCTORS Completed: Not Ready. Reviewer: Martin Björklund. Sent review to list.
2019-04-07
04 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Martin Björklund
2019-04-07
04 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Martin Björklund
2019-04-06
04 Yoav Nir Requested Early review by YANGDOCTORS
2019-03-11
04 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt
2019-03-11
04 (System) New version approved
2019-03-11
04 (System) Request for posting confirmation emailed to previous authors: Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, i2nsf-chairs@ietf.org
2019-03-11
04 Rafael Marin-Lopez Uploaded new revision
2018-10-22
03 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-03.txt
2018-10-22
03 (System) New version approved
2018-10-22
03 (System) Request for posting confirmation emailed to previous authors: Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2018-10-22
03 Rafael Marin-Lopez Uploaded new revision
2018-07-02
02 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-02.txt
2018-07-02
02 (System) New version approved
2018-07-02
02 (System) Request for posting confirmation emailed to previous authors: Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2018-07-02
02 Rafael Marin-Lopez Uploaded new revision
2018-03-05
01 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-01.txt
2018-03-05
01 (System) New version approved
2018-03-05
01 (System) Request for posting confirmation emailed to previous authors: Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>
2018-03-05
01 Rafael Marin-Lopez Uploaded new revision
2017-10-28
00 Yoav Nir This document now replaces draft-abad-i2nsf-sdn-ipsec-flow-protection instead of None
2017-10-28
00 Rafael Marin-Lopez New version available: draft-ietf-i2nsf-sdn-ipsec-flow-protection-00.txt
2017-10-28
00 (System) WG -00 approved
2017-10-28
00 Rafael Marin-Lopez Set submitter to "Rafa Marin-Lopez <rafa@um.es>", replaces to (none) and sent approval email to group chairs: i2nsf-chairs@ietf.org
2017-10-28
00 Rafael Marin-Lopez Uploaded new revision