Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 5)

From: Rafa Marin-Lopez <[email-masked]>
Date: Sat, 1 Dec 2018 10:34:06 +0100

Hi Paul,all:

Here you can find our answers for section 5.

> Section 5.1:
> 
> The diagram lists:
> 
> 	|   IKE    |      IPsec(SPD,PAD)  |
> 
> Shouldn't that be:
> 
>        | IKE(PAD) | IPsec(SPD, SAD)
> 
> IKE is using the PAD information to tell IPsec to establish SPDs and SADs) ?

[Authors] The PAD is something defined in RFC 4301, which is independent of the key management protocol.

From RFC 4301:
"The entry specifies the authentication protocol
   (e.g., IKEv1, IKEv2, KINK) method"
   
Therefore it is not something attached to the key management protocol itself but more related with IPsec implemenation. What it is true that PAD is not implemented in current Linux kernel and usually this information is set in the IKE implementation. Finally we have only described in Fig. 1 that SPD and PAD must be configured from the Controller. The SAD will be managed by the IKEv2 implementation. Same happens in Fig. 2.

> 
> 
> Section 5.1.1:
> 
> What does this mean:
> 
> 	Moreover, an east-west interface is required to exchange IPsec-related information.

[Authors] In SDN terminology an east-west interface is the communication interface between two controllers.

For example: https://tools.ietf.org/html/rfc7426 <https://tools.ietf.org/html/rfc7426>

If we have two gateways where we need to establish an IPsec SA and both are under the control of two different controllers then both Security Controllers needs to exchange information so that they need to agree in some information so that the configure their own gateways properly (see Fig. 5). An example: they have to agree that IKEv2 authentication will be based on raw public keys or pre-shared keys. And if it pre-shared keys they will have to agree in the PSK (Yes, one option to explore is IKEv2, more related comments in posterior answers.)
> 
> Section 5.2:
> 
>   In this case, the NSF does not deploy IKEv2 and, therefore, the
>   Security Controller has to perform the management of IPsec SAs by
>   populating and monitoring the SPD and the SAD.
> 
> I would write:
> 
> In this case, the NSF does not deploy IKEv2 and, therefore, the
> Security Controller has to perform the IKE security functions and management
> of IPsec SAs by populating and managing the SPD and the SAD.
> 
> I added "IKE security functions" to make sure some entity is responsible
> for those items that are normally done by IKE (IV generation, prevent counter
> resets for same key, etc).
> 
> I changed monitoring to managing, because I don't understand how it would "monitor"
> the NSF or what it would monitor. I assume also if during monitoring it finds
> something that needs changing (eg vpn tunnel up or down) that it will do so,
> so I think managing is the better word.

[Authors] Agreed with this text. Very reasonable.
> 
> For this diagram, I would say IPsec(SPD, SAD) would need to also list the IKE
> security function it needs to use in an IKE-less scenario, which above I had
> called "management of IPsec SAs”

[Authors] 

How about this non-exhaustive list:

- IV generation
- prevent counter resets for same key
- Generation of pseudo-random cryptographic keys for the IPsec SAs
- Rekey of the IPsec SAs based on notification from the NSF  (i.e. expire)
- Generation of the IPsec SAs when required based on notifications (i.e. sadb_acquire)
- NAT Traversal discovery and management. 
- ....

What about the following (non-exhaustive) tasks?
- SPI random generation
- Cryptographic algorithm/s selection
- Usage of extended sequence numbers
- Establishment of proper traffic selectors 
- ....
> 
> Section 5.3:
> 
> As mentioned before, a better title would be: IKE vs IKEless
> 
> I would also start this section with:
> 
> Case 1 is more secure, because all security features of IKE are used to manage
> the IPsec SAs.

[Authors] We do understand the comment.

How about this new text:

“IKE case provides better security properties than IKE-less case. In particular, the Security Controller is not able to observe what are the cryptographic keys used to protect data traffic."

> 
> Section 5.3.1:
> 
>   For case 1, the rekeying process is carried out by IKEv2, following
>   the configuration defined in the SPD.
> 
> Technically this is the SPD and SAD, as the SPD would for example list the
> maximum number of packets allowed, but the SAD lists the number of packets
> that have happened.

[Authors] Ok. We will replace the text: 

s/"For case 1, the rekeying process is carried out by IKEv2, following the configuration defined in the SPD."/"For IKEv2 case, the rekeying process is carried out by IKEv2, following the configuration defined in the SPD and SAD."
> 
> I am a bit confused by the rekey description. I guess it assumes that the
> Security Controller sending of information is blocking? Eg when it tells
> the node to install an inbound IPsec SA, it is blocked from doing anything
> else. If this is not the case, then the 3 step program should be clarified
> that it needs to also receive confirmations. And if this is a non-blocking
> process, who is responsible for "retransmits" of these confirmations ?
> The same applies to the blocking or time-wait between step 2 and 3.

[Authors] Yes, the controller goes through this process in a blocking way per each step. That is, the Security Controller needs to finish correctly the step 1 before proceeding with step 2. This is possible since the Security Controller will receive a NETCONF rpc-reply with OK after installing the inbound in peer A and the same for peer B. When receiving both OKs, it can proceed to step 2. The same happens between step 2 and step 3.

The reason of doing this in this way is to prepare first the new inbound IPsec SAs and everything is ready, then the new outbound IPsec SAs. When the new outbound IPsec SAs are set, we have observed (at least in Linux kernel) that the new outbound IPsec SA is immediately used. Since the other peer has already the corresponding inbound SA no traffic loss happens.

However if we assume that some traffic loss is allowed, we could send inbound and outbound IPsec SAs in parallell to both nodes involved in the rekey. What do you think?

Regarding retransmission of the confirmation the NETCONF transport (SSH/TCP or TLS/TCP) will provide this.
> 
> Also, I would say step 3 can be get rid of if the IPsec implementation can
> itself detect traffic on the new IPsec SA and it can delete the old IPsec
> SA itself without instruction from the Security Controller.

[Authors] Correct. We were wondering though how common this is (at least in linux kernels we have not seen this behaviour). Moreover, the Security Controller should know how this is implemented internally in the NSF to avoid sending this delete. Either that, or the NETCONF server in the NSF should pay attention to this by interacting with the kernel (through netlink¿?¿?) and remove it when it sees that traffic. I have seen that libreswan has a wishlist about this feature. Is there any movement in this side?
> 
> Section 5.3.2:
> 
> 	If one of the NSF restarts, it may lose part or all the IPsec state
> 
> This "may" suggests a very interesting case. I doubt the NSF would store on
> non-volatile memory the IPsec symmetric keys for encryption, and the counter
> or ICV's used. If it could store that, the document needs some text about
> this in the Security Considerations because it will allow for easier theft
> of session material.

[Authors] Yes, this "may" is unfortunate because our assumption is that all this information will be in volatile memory. More specifically, we assume that NSF does not have any information in the startup-config (non-volatile), only in the running-config datastore (volatile)
> 
> Rather, I suspect this may really is not true, and all of these devices would
> lose state?

[Authors] Correct. Although other aspects could be considered in the future (for example, is it reasonable to think that IKE configuration could be in non-volatile as well just in case the node falls?)
> 
> 	In both cases, the Security Controller MUST be aware of the affected NSF
> 
> I think this MUST is a little misleading. It is not desired behaviour but just
> an observation - it cannot not know its TCP session died ? Perhaps write:
> 
> 	In both cases, the Security Controller is aware of the affected NSF

[Authors] Yes, this is better.

> 
> A similar case for the next sentence MUST keyword:
> 
> 	Moreover, the Security Controller MUST have a register about all the
> 	NSFs that have IPsec SAs with the affected NSF.
> 
> so write:
> 
> 	Moreover, the Security Controller has a register about all the
> 	NSFs that have IPsec SAs with the affected NSF.

[Authors] Agree. 

> 
> 
> 	(It is TBD in the model).
> 
> This remark seems to need to be resolved before publication ?

[Authors] It is already fixed but we missed to remove this text.

+--rw initial-contact?     boolean
> 
>   In Case 2, if the Security Controller detects that a NSF has lost the
>   IPsec SAs (e.g. it reboots) it will follow similar steps to rekey:
>   the steps 1 and 2 remain equal but the step 3 will be slightly
>   different.  For example, if we assume that NSF B has lost its state,
>   the Security Controller MUST only delete the old IPsec SAs from A in
>   step 3.
> 
> I don't understand why this paragraph about NSF state loss seems to talk
> about "step 3" which can only be referring to the "rekeying process" of
> the previous section. It should only mention that it should configure new
> IPsec SAs between the failed node and all the nodes the failed node talked
> to and only after those are estlibhsed, it can send a delete for the old
> IPsec SAs on the non-failed nodes. This prevents the non-failed nodes from
> leaking plaintext.

[Authors] Agree. However I was thinking that failed node may not come to life again.
In such a case, if a failed node falls, the active IPsec SAs in the rest of non-failed nodes with the failed node are not useful. Therefore, the SC could first delete the old IPsec SAs on the non-failed nodes. If the failed node comes to live, then the SC will install first the new inbound IPsec SAs and after these IPsec SAs are established then to install the outbound IPsec SAs. What do you think?

Having said that, we propose to replace this paragraph with the following text:

"In IKE-less case, if the Security Controller detects that a NSF has lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs of the non-failed nodes established with the failed node (step 1). This prevents the non-failed nodes from leaking plaintext. If the failed node come to live, the Security Controller will configure the new inbound IPsec SAs between the failed node and all the nodes the failed talked to (step 2). After these inbound IPsec SAs have been established, the Security Controller can configure the outbound IPsec SAs (step 3)."

> 
> Section 5.3.3:
> 
> I'm confused how the Security Controller can know what NAT ports to convey to
> the NSF agent. Without IKE traffic, there is no port NAT mapping? So unless
> the Security Controller _is_ the NAT gateway, it would never know this
> information? So I am skeptical if the NAT case can ever work without IKE.
> I also do not know how the Security Controller could decide between UDP,
> TCP or TLS without information from an IKE negotiation.

[Authors] Basically as we state in our text, the SDN paradigm generally assumes
 the Security Controller will have a view of the network it controls. Based on this, the Security Controller can know if there is a NAT configured between two hosts. For example, if you take a look to:
   
   https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-17 <https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-17>
   
   the Security Controller could use this netconf module with a gateway to collect NAT information or even configure a NAT.
   
   Regarding the usage of UDP, TCP or TLS, since it controls all the network it is something that the Security Controller should decide.
   
   In any case, if this NETCONF module is not available and the Security Controller cannot know if a host is behind a NAT or not, then IKE case should be the right one and not the IKE-less.

Best Regards.
-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>
-------------------------------------------------------

---

From: Gabriel Lopez <[email-masked]>
Date: Mon, 3 Dec 2018 23:50:33 +0100

Hi Paul, all.

Answers for section 6 in line.

> El 18 nov 2018, a las 7:52, Paul Wouters <[email-masked]> escribió:
> 
> 
> 
> Section 6.1:
> 
> Note that the use of start and end addresses, means that this can never work
> with IKEv1, that can only negotiate CIDR networks. Perhaps this should be
> explicitely stated somewhere just in case some developer thinks they can
> use IKEv1 for this?

[Authors] ok, note that the yang element is explicitely named "IKEv2", anyway, we can clarify this point in the document. In fact, we believe that we should proceed with only IKEv2.

BTW, we propose to change the model moving from the current "list of TSs including a list of IP addresses and port ranges" for each policy  to a list of TSs per policy with one local and remote subnets per TS (instead of "ranges"). What do you think?

> 
> I dont understand the names in:
> 
> 	next-layer-protocol*   ipsec-next-layer-proto
> 
> It talks about ip-address and not ipsec-next-layer-ip-address? Simiarly it
> talks about local-ports. So why not just call this proto or protocol ?

[Authors] The label "protocol" is widely used in the model. It is just a way to identify the context.

> 
> Is selector-priority needed? Can the ts-number not be specified to be "lower
> numer is higher priority” ?

[Authors] It could (in fact, it is ordered by user, which means the controller in our case)
In fact, RFC4301 only specifies that "An SPD is an ordered list of entries"

> 
> 
> Why do we have security-protocol? If you are considered about small footprints,
> clearly you would implement only ESP and use ESP-NULL if encryption is not
> needed. And simply not implement AH (which is already optional not mandatory
> to implement for IPsec). Also, this assumes IPCOMP, which has its own complexity,
> would also not be used. I think a case for AH would be very weak, while a case
> for IPCOMP could be made. I'd recommend only supporting ESP, at which point
> you would not need this parameter, or you could keep it for completeness
> sake even though it could only have one value "esp". This would also allow
> an updated ESP or some ESPlite to be used in the future if such a thing would
> be developed.

[Authors] We agree with only make use of  ESP and ESP-NULL.

> If we only go with AEAD algorithms, then the whole ah-algorithms part can be
> removed too. And esp-algorithms could be changed to only contain esp-encryption
> (or could be renamed aead-algorithm)

[Authors] Same as before

> 
> I see spd-mark but not spd-security-context  (see my Labeled IPsec draft)

[Authors]

Regarding the XFRM mark element and the security context described in the draft, if there is a clear use case for these elements we can keep them in the model.

> 
> I found the names in lifetimes confusing. "added" really means maxlife and
> "current" really means maxidle I think? So I think the names would be
> clearer as "time", "idle", "packets", "bytes". I think the time and idle
> units of uint64 could be narrowed down if the yang language allows some
> kind of timestamp type.

[Authors] We have made use of the terminology in RFC2367, Section 2.3.2. Indeed the yang model has a timestamp (RFC 6991). We can add "time", "idle", "packets" and "bytes”.

> 
> I am missing an entry for TFC (confidentiality, padding)

ok, It could be included in the model (for IKE and IKE-less cases.

> I also see no entry for IPCOMP algorithm. But I am fine with not allowing
> IPCOMP at all :)

[Authors] Agree

> 
> I am missing replay window parameters ?

Currently, the replay-window parameter is defined only in the SAD configuration for IKE-less case. It should be also included in the SPD configuration for IKE case.

Do you think we should include the additional replay-seq, replay-oseq, replay-seq-hi, replay-oseq-hi parameters for IKE-less case?

> 
> I don't know what statefulfragCheck is ?

Whether or not to allow IKE fragmentation. (Libreswan/Strongwan support that, valid values are are yes, (the default), no or force).

Probably a better name for this?

> 
> Section 6.2
> 
> See Section 6.1 comments.
> 
> Why are the encap entries in 6.2 and not 6.1 ?

[Authors] For case 2 (IKE-less) espencap is configured like part of the SA, not the policy. For IKE case encap is part of the IKEv2 configuration (section 6.4)

> 
> What is the "state?" entry ?

[Authors] state is of type sa-state (Larval, Mature, Dying, Dead).
These states can be useful when the model is used by the SC to recover SA's state data from the node or when modelling the sadb_expire message

> Why is rpcs: only here?

[Authors] You are right, rpcs should be in a 6.5 section. Note that notifications are defined for SAD and SPD in IKE-less case and that there are not notifications for IKE and PAD models

> 
> I would not use minbits, maxbits. All modern ciphers, especially AEAD, are fixed key sizes. Make it a list of key sizes

[Authors]
Agree

> 
> I seem to miss the AEAD IV values ?

[Authors] This container represents information about the algorithm supported, we assume that AEAD algorithms can be also represented here (AES_GCM, AES_CCM, CHACHA20-POLY1305, ....). IV values are not represented here.

> Possibly the truncation values ?

[Authors] For auth-trunc values, we will include that in container ah-sa unless AH is finally removed.

> 
> Section 6.3:
> 
> I only see PSK and RSA algorithms? No ECDSA via RFC 7427 Digital Signatures?
> (no PAKE, we have two IKE PAKE's although it looks like we want an CFRG new one)

[Authors]
See answer in Appendix section.

> 
> Should PSK be of type "string". Some people want to hex entry? Although those are often written
> as strings with a 0x prefix.

[Authors]
Agree

> 
> I see some CRL entries, but no OCSP entries. Is it expected those URI's are stored within the certificates,
> and the received OCSP responses will never be communicated through this interface?

[Authors]
Agree. We can add CRL and OCSP URLs

> 
> I see no local and remote part, meaning that only symmetric authentication methods can be used. IKEv2 supports
> asymmetric authentication methods as well. Especially when using EAP and sometimes with AUTHHNULL, this method
> is very asymmetric. So I believe this entry needs to be split in a local/remote auth method.

[Authors]
Agree

> 
> Section 6.4:
> 
> type-autostartup issues...
> 
> typedef type-autostartup {
>      type enumeration {
>         enum ALWAYSON { description " ";}
>         enum INITIATE-ON-DEMAND {description " ";}
>         enum RESPOND-ONLY {description " ";}
>      }
>      description "Different types of how IKEv2 starts the IPsec SAs";
> 
> With libreswan we have similar keywords, and run into some interesting issues. We found what is really needed is to
> know the current state and the connection desired state. for example, when using ondemand and the connection is up,
> it is important to know it is up because of ondemand. So that when you receive a Delete request, you can go back
> to ondemand state. If you dont keep this state then you cannot tell the difference between alwayson/ondemand if
> the connection is "up". Similarly, we had issues where connections has a definition like above, but the administrator
> performs an action. It is unclear if such an action is considered a temporary override or basically a runtime update
> of the configuration. So lets say we are in respondonly, and the administrator brings the connection up. Now the other
> end sends a delete. Do you assume you are in alwayson state or in ondemand state? And if you believe alwayson, be
> prepared for a war with the remote endpoint that keeps sending deletes because it wants to be down.

[Authors] Do you think this is something the model should consider? We mean that, after all, behing the model we will have an implementation (could be libreswan, strongswan etc.. that it will deal with these aspects) It is true that we should define clearly what ALWAYSON, INITIATE-ON-DEMAND, RESPOND-ONLY, etc…

> 
> 
> Why is there nat-traversal and espencap. Why not just have espencap allow to have a value of 'none’ ?

[Authors]
Agree

> IKEv2 allows more then one oaddr  (eg multiple SOURCE NAT IPs) but the value is not a list?

[Authors]
Agree for the IKE case.
For pfkey_v2 (setkey), it does not allow to specify oaddr.
For xfrm, it does allow to specify only one oaddr.
Does make it sense to allow more than one oaddr for IKE-less case?

> 
> The terms phase1-* should be called ike-* or ike-sa-* as phase1/phase2 is IKEv1 terminalogy not used for IKEv2.

[Authors]
Agree. We can replace phase1-* by ike-sa-* and phase2-* by ike-child-sa-*.

> 
> Why is combined-enc-intr needed? These are stored with the encalg entries anyway.

[Authors]
Agree.

> 
> I see:
> 
> 	+--rw local
>        |   +--rw (my-identifier-type)?
> 
> 	+--rw remote
>        |   +--rw (my-identifier-type)?
> 
> I think "my-identifier-type" should be "identifier-type". Talking about "my" for the remote peer is very confusing.

[Authors]
Agree.

> 
> my-identifier-type does not support the value ID_NONE from RFC 7619

[Authors]
Agree. We will include that in the model.

> 
> Why is there no secion for ike-lifetime-{soft|hard} ? We also have FIPS requirements that IKE SA's cannot do more
> then X bytes for Y algorithm. And also bringing down idle IKE SA's etc.

[Authors]
We can include a soft/hard lifetime (seconds) for IKE SA. What does it means a soft/hard lifetime (bytes) for IKE SA. It is implemented in current distributions?

> 
> I think "added", "used", "bytes" "packets" should be called lifetime, idletime, maxbytes and maxpackets

[Authors]
See comment above.

> 
> The timestamp values "added" and "used" could have a better type than uint64, eg unix epoch of unixtime or something?

[Authors]
Current implementations make use of __u64 or even uint32_t. Anyway, we can modify the type. What do you propose?

> 
> the term ike-stats was confusing me. I thought at first these were the global IKE statistics, like how many tunnels
> are up, how many errors received, but it turned out to be the state of a singe IKE SA. So perhaps ike-sa-state is a
> better term?

[Authors]
Agree.

> IKE state I expect things like SPIi and SPIr as listed here.

[Authors]
global IKE statictics could be obtained by the SC through the ike-sa-state info for each IKE SA.

> 
> I am not sure why there are three nat-* bools instead of one value representing the nat-state? Possibly because we
> use a number of bits to indicate which of the NAT properties are set, and you don't do this kind of bit mapping in
> yang?
> 

[Authors] That could be represented with uint8 and using three bits , is that what you mean? We thought was clearer to have three booleans.

> I dont see an entry for "latest IKE SA". We have that in libreswan. You can have multiple IKE SA's when rekeying,
> and the older one is just lingering to die. Any operations such as informational requests, dpd/liveness probes
> should only be done with the "latest IKE SA".  However, this is kind of a state on the IKE node, so I am not
> sure if this belongs in the yang model or not.

[Authors] Is there any scenario where the SC is able to deal with this information for the IKE case? If so, we can try to model that like state data. 

> 
> I see a total SA's and halfopen SA's but I don't see anything related to anti-DDOS cookies. Eg the number of half
> open SA's before enabling cookies. Perhaps add half-open-cookies-treshhold ?
> 

[Authors]
Several parameters can be configured here:
- half-open-threshold: number of half open IKE SAs
- half-open-cookies-threshold: number of half open IKE SAs with cookie activated
- half-open-timer: timeout in seconds for connecting IKE SAs.

Best regards, Gabi.

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Dec 2018 21:29:26 +0000

I like the title of  “distributed keying” (case 1) vs “centralized keying” (Case 2).

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Tuesday, November 27, 2018 4:39 PM
To: Gabriel Lopez <[email-masked]>
Cc: [email-masked]; [email-masked] WG <[email-masked]>; Paul Wouters <[email-masked]>; Rafa Marin Lopez <[email-masked]>
Subject: Re: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

A couple of remarks (with no hats)

If we’re bikeshedding the names, I think the difference is that in one case the two NSFs generate traffic keys between themselves, and in the other it is the controller that generates the keys for them.  So how about “distributed keying” vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.

Also, I have been asked by someone not on this list whether our work covers the road warrior use case. I said it didn’t and wondered why. So I got these points:

  *   Road warriors are numerous and not where the administrator can configure them manually.
  *   Additionally, the configuration of what networks, gateways (NSFs), and resources a road warrior may access (in IPsec terms, the SPD and PAD) change often.
  *   Because of the above, some automatic method of configuring SPD and PAD is needed.
  *   There is also the issue of multiple VPN gateways covering similar domains, and VPN gateways being overloaded or down for maintenance, as well as malfunctions in the network behind those VPN gateways. So the decision on which gateway a road warrior should use to access a particular resource is also a natural question to ask an SDN controller.

Since I used to work for a VPN vendor, I can tell you what our product did:

  *   The current configuration was formatted (automatically by a management function) as a text file that the road warrior downloaded through the VPN gateway (the gateway doubled as a server serving this one file)
  *   The proper gateway to connect to was determined by pinging all gateways that were possible according to the configuration file.
  *   This did not account for any internal networking issues.

I don’t know if this should be part of *this* effort, but there is a use case for road warrior SDN.

Yoav

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 6 Dec 2018 11:06:44 +0100

Hi Linda:

I still have doubts about these terms. In both cases, there is a centralized key distribution: with IKE , the controller may distribute key material (i.g. the PSK for IKE authentication) or some certification. Without IKE  (case 2) the centralized key distribution refers to IPsec SAs. 

Moreover the word IKE is important in case 1 , only IKEv2 is considered. 

Best Regards.

> El 5 dic 2018, a las 22:29, Linda Dunbar <[email-masked]> escribió:
> 
>   <>
> Road warriors are numerous and not where the administrator can configure them manually.
> Additionally, the configuration of what networks, gateways (NSFs), and resources a road warrior may access (in IPsec terms, the SPD and PAD) change often.
> Because of the above, some automatic method of configuring SPD and PAD is needed.
> There is also the issue of multiple VPN gateways covering similar domains, and VPN gateways being overloaded or down for maintenance, as well as malfunctions in the network behind those VPN gateways. So the decision on which gateway a road warrior should use to access a particular resource is also a natural question to ask an SDN controller.
>  
> The current configuration was formatted (automatically by a management function) as a text file that the road warrior downloaded through the VPN gateway (the gateway doubled as a server serving this one file)
> The proper gateway to connect to was determined by pinging all gateways that were possible according to the configuration file.
> This did not account for any internal networking issues.
>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 11 Dec 2018 13:29:44 +0100

Hi Paul, all:

> 
> Appendix A:
> 
> Why is it "eipsec" and not "ipsec” ?

[Authors] We have fixed this now.
> 
> Why is the organization not the IETF? Is this commonly done for yang models?

[Authors] You're right. We will change this to:

"IETF I2NSF (Interface to Network Security Functions) Working Group"
> 
> encryption-algorithm-t - I think this should only list the MUST/SOULD items, so AES_GCM (1 flavour), AES_CCM (1 flavour) CHACHAPOLY1305 and NULL
> 
> 	description "Encryption algorithms -&gt; RFC_5996”;

[Authors] Right. Our doubt here is if we should refer instead to 

https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02

such as 

https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-08

is doing. If you check this link you will notice is referring to 

<algorithm xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-t\
   ypes">ct:rsa2048</algorithm>
   
which is referring to ietf-crypto-types

> 
> RFC 5996 is an obsolete reference. It should either refer to RFC 7296, or it should simply refer to the IANA registry involved.

[Authors] OK.
> 
> integrity-algorithm-t: If the above is agreed, this enumeration should only contain "none" and the entries from aes-cmac-96 and up. That is,
> not contain des,md5,sha1 and aes_xcbc.  Same obsolete reference is used here in the description.

[Authors] Ok.

> 
> type-autostartup: Maybe instead of RESPOND-ONLY, a better word is "STANDBY"? That way, the node could decide itself to bring a connection up
> without _requiring_ a remote signal, and could be triggered locally as as well as remotely to come up.

[Authors] Sounds reasonable. We should provide a better description of each value as well.

> I would say "different policies of when to start an IKEv2 based IPsec SA". Does it need clarification this value is ignored or unused for the
> "case 2" scenario?

[Authors] This typedef is not used in the part of the model associated to case 2 but we can something in the description. 
> 
> auth-protocol-type:  This should only contain IKEv2. The enum should remain in case we get IKEv2.1 or IKEv3 in the future.

[Author] Agree.

> 
>      description "Peer authentication protocols”;
> 
> I would say "IKE authentication protocol version", unless you want to keep the option open to have a non-IKE protocol. But I think that would
> run into many more issues of having parameters that are not defined for IKE?

[Author] Agree.
> 
> ipsec-mode: It should only contain Tunnel and Transport Mode. It would be nice to see some text that forbids using Transport Mode when NAT is
> requested, just to avoid a lot of problems and disappointments. L2TP/IPsec still has major scars due to its use of Transport Mode with NAT.

[Authors] Sounds reasonable.

> 
> esp-encap: as stated before, we are missing the port entry. I can also image that multiple encaps could be allowed, such as TCP-443 and TLS-443.
> Also note that the RFC for ESP over TCP recommends to continiously check if UDP encapsulation has become available, since it is so much prefered
> over TCP. But that only makes sense when the remote is a roaming client, and makes less sense if the network consists of data centers.

[Authors] Ok. Let's add the port entry. In any case, I believe that is something that implementation in the NSF (in particular the NETCONF server) could check (UDP encapsulation)

> 
> ipsec-protocol: I think this should only contain esp. See earlier comments. Notably, if supporting ipcomp here, the yang model must be clear
> that it could need an ipcomp + esp IPsec SA for a single 'connection'. Even if we only leave esp as a valid option, keep this enum in case
> we come up with a new esp version of some esp-lite version.

[Authors] We are in favour on leaving only ESP. If the WG agrees, let's proceed that way.

> 
> lifetime-action only has "terminate" and "rekey". For libreswan we use "clear", "hold" and "restart". The difference
> between clear and hold is what kernel policy to install for cleartext packets. For roadwarrionrs coming in, you
> want clear to leave no trace. for a site-to-site VPN you generally want "hold" to ensure you drop all packets until
> a new tunnel is established (possible ondemand, so this is different from restart)
[Authors] Basically we have "terminate" and "rekey" since RFC 4301 says:

"Lifetime of this SA: a time interval after which an SA must be
      replaced with a new SA (and new SPI) or terminated, plus an
      indication of which of these actions should occur."
	  
We are realizing that RFC 4301 should also be updated to reflect these new possibilities.

In any case, could you elaborate a little bit more about the difference between clear and hold and the effect in the kernel? We are assuming that affects the SAD.

> 
> ipsec-traffic-direction:
> 
> Traditionally, freeswan ony used inbound/outbound and not forward. Unfortunately, KAME and Linux/XFRM kept forward there. But I see no use
> case for it in these deployments. We have nothing specified in about ipsec-sa's for the forward (it's basically implied "completely open")
> But I understand it might be useful to just specify this because it is needed. But perhaps more language is then needed to clarify this?

[Authors] We think this is an implementation aspect. We think it is better to remove fwd policy. If fwd policy is required because we have an implementation based on Linux, the NETCONF server should install that fwd policy based on the in/out received.
> 
> ipsec-spd-operation:
> 
> The value BYPASS probably means "let go in the clear" but I don't find the name very obvious.

[Authors] It has been extracted from RFC 4301 definition. 

"Processing info -- which action is required -- PROTECT,
             BYPASS, or DISCARD."
			 
In relation with our previous comment we think it would be worthy to carry out an update in the RFC 4301

> The operation modes BYPASS and DISCARD cannot be configured with the current yang parameters
> for IKE? How would this be configured, eg to place a DISCARD for 192.1.2.0/24 ?

[Authors] It is not needed to configure it in the IKE model since it is already configured in the SPD model. The RFC 4301 defines how the SPD is composed, and following this, we have defined the SPD model regardless whether we are in IKE case or IKEless case. In other words, both cases uses the information contained in the SPD model. Having said this, we think it would be useful to explicitly "link" each connection in IKEv2 with the SPD entries associated to that connection. For example, per each connection we could add a list of spd-entry-id, which point to the SPD entries associated to that connection. From your comment we have realized that this issue is not well explained in the document.

Thus, regardless the case we are using, the policies establishing the type of traffic and protection to be applied are indicated in the SPD model (i.e. by means of a list of spd-entry). So the SPD model is used for both, IKE case and IKE-less case. Thus, we have the following situation. 

- For IKE case, the whole configuration is distributed in two parts. While the IKE SA configuration is represented as “ike-conn-entries”, the the CHILD SA configuration will be found as a list of “spd-entry”. 
- For IKE-less case, only the CHILD SA configuration will be accessible as a list of “spd-entry”.

What do you think?

> In libreswan
> we can configure a connection with type=transport|tunnel|drop|reject but that meshes up the
> IPsec Mode with the SPD Operation. It is also a bit odd to configure "IKE" for a "DISCARD"
> since it really does not define anything in IKE - it bypasses IKE to put in an IPsec policy
> (SPD). But if the yang model used the ipsec parts to do this, it could be mixing IKE + manual
> IPsec policies, which could really confuse the IKE daemon. I am not sure what the best fix for
> this is. Note REJECT which is DISCARD+ICMP message is not defined here. Should it? I don't
> think Linux/XFRM/netlink supports this.

[Authors] As we see it, we are not mixing IKE + manual IPsec policies. SPD is the central point of configuration for IPsec policies in the model. In any case, we talk about implementation. In particular, when the controller configures the SPD first and the IKE model with a connection, this connection will have a list of spd-entry-id to refer to the particular SPD entries that it has to configure in the IKE daemon associated to that connection.  About what is happening with drop / reject and the fix we don't really know either but I think this is not a problem for the model itself, right? As a note, ip xfrm allows : "allow" or "block" 
> 
> ipsec-next-layer-proto:
> 
> See earlier note. I think this is a really bad name.

[Authors] This is defined in RFC 4301 with this name. In ip xfrm is UPSPEC.  is Upper Layer Protocol better?
> 
> ipsec-spd-nam:
> 
> This is the first time I have seen an SPD as having a name. normally these just have numbers. Or they
> have a number that is the link between SPD and SAD (with linux, that is called reqid=)
> So maybe add an enum id_number so implementors could map this onto the linux implementation ?

[Authors] RFC 4301 says explicitly in page 28.

"- Name:  This is not a selector like the others above.  It is not
        acquired from a packet.  A name may be used as a symbolic
        identifier for an IPsec Local or Remote address."
		
"An SPD is an ordered list of entries each of which contains the
		   following fields.

		           o Name -- a list of IDs.  This quasi-selector is optional.
		             The forms that MUST be supported are described above in
		             Section 4.4.1.1 under "Name". “"

But yes, we can replace this name by other identifier, as you suggest.
> 
> auth-method-type:
> 
> See earlier comment about asymmetric authentication.
> 
> This should only contain pre-shared, null, eap, rsa, rfc7427(digital signatures). That is I think dss-signature can be removed.
> I also wonder if this entry needs to have a better difference for the source of the private/public keypair, eg raw RSA versus
> RSA certificate based authentication. I guess this is now implied by not having a certificate entry?

[Authors] Mmmmm... good question. We think we should include at least a "raw public key" leaf so if the leaf is set then we have raw public key. If we include certificate then we will have RSA certificate based authentication. In any case, if ECC-based signature is required we would also need to support ECC public and private keys. In any case, this part in the model needs to be udpated to support RFC 7670 and RFC 7427

 There is also another aspect: if eap is chosen, what eap method is allowed. I think a container mentioning the EAP method should  be included. Moreover, we should include a way to send the credentials for the particular EAP method.

> 
> Also rename description "Peer authentication method" to "IKE authentication method" (it should mention this is IKE, but also
> in case of asymmetric use, this is not neccessarilly for the peer but how we authenticate _to_ the peer)

[Authors] Sounds reasonable

> 
> sa-state:  I am not sure why this is needed? Unless someone would want to manually place larval/acquire states in the kernel
> without IKE, but then who is going to listen to these ACQUIRE messages? A non-IKE daemon? See earlier discussion on this topic.
> If you do want to get netlink/pf_key messages for max-counter, max-bytes etc without IKE, then this would be required. Otherwise
> this should be removed.

[Authors] This is precisely what we want: "to get netlink/pf_key messages for max-counter, max-bytes etc without IKE" . This is captured by the NETCONF server to send notifications to the controller in IKEless case. Having said this, most probably this state is not completely required though as we mentioned in section 6's comments , the IPsec SA appears in the state. It seems too much detail for the regular operation of the controller, even considering IKEless case.
> 
> lifetime: See earlier comments.
> 
> grouping auth-method-grouping: See earlier comments about asymmetric authentication and raw vs cert based signatures. Note based
> on above entries, this is missing a dss-signature section. So if you agree with earlier comment to remove dss-signature, then
> it not appearing here is fine.

[Authors] Yes, we are going to remove dss-signature and extend the auth-method container to contemplate the use of raw public keys as well as generic digital signatures (rfc 7427).
> 
> grouping identity-grouping:  See earlier comments on ID_NULL / AUTH_NULL support

[Authors] We failed to see this earlier comments about ID_NULL and AUTH_NULL, could you point us to them?

> 
> grouping port-range: I don't see anywhere that protocol and ports together are "overloaded" for things like ICMP message types.
> Should language be added for that?

[Authors] Not sure what are you are referring here... could you elaborate? We have seen that description should be changed as well.
> 
> SAD and SPD grouping : See earlier note about Security Labels. It would need to be added here. Linux/XFRM already supports these.

[Authors] Not sure about this. Right now, the usage of security labels seems associated to specific implemenation (Linux/XFRM) and https://tools.ietf.org/html/draft-sprasad-ipsecme-labeled-ipsec-00 has not been evolved since March 2018 (is it going to be adopted?).
> 
> I see container-ah and container-esp, but what about container-ipcomp? Again, if we remove IPCOMP as I'd like, then we are fine
> here. but if not, then something needs to be added here. If AH is removed as I'd recommended, it needs to be removed here.

[Authors] That's right. We think we could remove that ipcomp and ah if the WG is agree.
> 
> 	container sad-lifetime-soft {
>         	description "SAD lifetime hard state data";
> 
> that "hard" should be "soft”.

[Authors] Right.
> 
> I am confused that "hard" and "soft" have an action that can be similar. soft could have an action to just notify userland via
> XFRM/PF_key, but "hard" can only have an option "terminate” ?

[Authors] Your comment makes sense. 
> 
> container encap: Now I see the sport / dport, but I'm still confused how this is populated from the higher level Security Controller
> communication (if not IKE). Note also the Security Controllers cannot know the port numbers without sending any traffic so the
> NAT gateway crates a mapping.

[Authors] As mentioned earlier, this can be informed by the NSF through a YANG module related with NAT management. 
> 
> list traffic-selector-list: Can a traffic selector have a direction of fwd ? Not in the IKE protocol.

[Authors] fwd direction has been removed now.
> 
>            leaf mode { type ipsec-mode; description "transport/tunnel"; }

[Authors] True. We will add them but removing BEET.
> 
> This "description" does not match all the available options defined before.
> 
> container ah-algorithms: See AH comments before. Also see IPCOMP comments before.

[Authors] As mentioned we are in favour of removing AH and IPCOMP if the WG agrees on that.

> 
> 	description "Configure ESP encryption"
> 
> Maybe say "Configure ESP/AEAD encryption”

[Authors] This would be applicable if we finally agree that only AEAD will be used. But in the last e-mail exchange in the mailing list, it looks like we are not limiting us to a case where only AEAD is allowed. 
> 
> spd-mark:
> 
> Note that the IKE case cannot negotiate this spd-mark value. Is such a capability needed? It is similar to negotiating a Security Context.

[Authors] It is in linux kernels and handled by XFRM but we think you're right and we could remove it from the model. In any case, do you think there is an important example case for its usage?
> 
> 
> container spd-lifetime-*: See earlier comments on hard/soft and acceptable actions

[Authors] OK.
> 
> grouping isakmp-proposal: I would call this ike-proposal as isakmp is kind of an IKEv1 term. See also phase1-* value suggestions earlier to
> make those ike-* or ike-sa-* values. This group is also missing pfs= which for IKEv2 only starts to matter when rekeying and whether or not
> to do a new DH.

[Authors] Agree. We will change the name. Also true about pfs. We will add this information.

> 
> grouping phase2-info: Call this ipsec-info: or ipsec-sa-info:

[Authors] Correct. As mentioned we think it would be better if this ipsec-sa-info has a lists of spd-entry-id pointing the SPD policies associated.
> 
> 	leaf-list pfs_group { type uint32;

> 
> This should really be an enum and not a uint32.

[Authors] Ok. We will change it.
> 
> typedef sadb-msg-type: where/when are these used? That is, I understand the IKE <-> IPsec API uses this, but when does this ever need to
> go over the Security Controller's communication ?

[Authors] In IKEless, the sadb_acquire notification carries this information to the Controller. Basically, what it is happenning is that the NETCONF server in the NSF captures the sadb_acquire from the kernel and builds a NETCONF notification which is sent to the Controller. Having said this, it is true that this is not required anymore since we know that this type can be only SADB_ACQUIRE since we are sending a sadb_acquire. 
> 
> typedef sadb-msg-satype: same here

[Authors] The controller needs to know what IPsec SA should be negotiated. We have realized that notificiation sabd_acquire should carry the policy that caused the acquire so that the Controller can know how to add the IPsec SA. Thus, we propose the following modification to the sadb_acquire notification:

notification sadb_acquire {
      description "A IPsec SA is required ";
      uses selector-grouping;
	  container tunnel {
	           when "../mode = 'TUNNEL'";
	           uses tunnel-grouping;
	           description "If TUNNEL mode is used the sadb_acquire notification carries the endpoints";
	        }
   }
> 
> container algorithm-supported: See earlier comments about all moderm algorithms not having a min/max but only having a limited set, for
> current ones this is only 128/192/256

[Authors] Ok.
> 
> Note the version of IKE within the ietf-ipsec namespace only has IKEv2. I agree with that now but earlier in the document it has IKEv1
> support/entries. So this needs to be made consistent here.
[Authors] Correct. We should only keep ikev2

> 
> container ike-stats: does not contain encaps entry to show if it is using UDP, TCP or TLS and on which port.

[Authors] Are you referrig to the encapsulation of the IKEv2 messages? 
> 
> list child-sas: does not contain some "state" that can be negotiated as part of an IKE session. For example, if narrowing was used, it could
> be that the current SPD is more narrow then the "connection" defined SPD. There seems to be no way to store this. Thus narrowing is not
> possible. If narrowing is not in scope here, it should probably be made more explicit. Otherwise, it needs to be better integrated.

[Authors] Basically, we are including a list of child-sas negotiated. Basically, in terms of implementation, as an example, we would provide this information with the output, for example, either ip xfrm state list or using the list-sa event in strongswan (https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici_README.html)
> 
> container number-ike-sas: See earlier note about missing COOKIES parameter here.
> 
> 
> SPD related question: Is there support for multiple TSi/TSr generating a list of spd's in a single Child SA? If so, a Child SA can have
> multiple SPDs. Otherwise, it cannot. I dont think the model is very clear on this aspect. (I speak from experience, libreswan as an
> implementation is also not very clearly specified here, and we have one known interop issue with openbsd's iked because of this)

[Authors] So openbsd's iked allows a child SA assocciated to several policies, right? 

Regarding your comment " list of spd's in a single Child SA" . Could you ellaborate a little bit more? The model is not clear in this aspect since we have not considered this case. Are you referring that a list of policies are mapped to the same child SA?. In any case, we think this would be part of the implemenation of the ike model. That is: we are doing is to inject the SPD entries that have been configured in the SPD model in the connections defined in the IKEv2 model into the particular IKEv2 implementation. For example we can use VICI in strongswan for that. If the IKEv2 implementation is able to associate a list of spd in single child SA, should the controller be able to say anything about it? Do you think we should add a flag or something for this?
> 
> 
> // Those RPCs are needed by a Security Controller in case 2 */
> 
> Please think about XFRM/netlink and/or ACQUIRE messages that are needed if there is no IKE daemon. eg when max-counter is reached
> or when a hard limit action is performed by the kernel.

[Authors] We already have modelled those messages (sadb_acquire is a notification) 

notification sadb_acquire {
      description "A IPsec SA is required ";
      uses base-grouping;
   }

   notification sadb_expire {
      description "A IPsec SA expiration (soft or hard)";
	  ....

> 
> I am missing an "SPI already in use" error, in the case it is attempted to install an SPD that already exists and thus would conflict.
> 
> 

[Authors] That will happen when the controller sends an NETCONF edit-config trying to add that an already existing SPI. From NETCONF rfc  "The <rpc-error> element is sent in <rpc-reply> messages if an error
   occurs during the processing of an <rpc> request."

Right now, , the spi value is the key element for the list of SAs in the model for this case, so the NETCONF server will detect it is already used. If it is already used the NETCONF server considers the SC wants to "update" de SA, but not to add a new one. 
   
It is true that we have NOT defined any explicit "error-message" for this rpc-error. We will add this.

Best Regards.

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Fernando Pereñíguez García <[email-masked]>
Date: Tue, 11 Dec 2018 19:52:13 +0100

Hi Paul, all,

Next you can find our answers to your comments on sections 8 and 9.

Section 8:

Is this section supposed to be an "Implementation Details" Section as per
RFC 7942? If so, it is missing the required
note to the RFC Editor to remove the entire section before publication as
RFC.

[Authors]

Agree. We will include it.

Section 9.1:

In case 1, add a note to use only strong PSKs, with a minimal length and
strength.

[Authors]
Agree. We will add it.

Section 9.2:

when ESP is used

Hoping my advise is taken to only use ESP and not AH, and to use ESP-null
in the case of encryption being unwanted, please
remove this comment as ESP would always be used.

includes the keys for integrity and encryption

If we only allow AEAD's, maybe rewrite or leave this out.

[Authors]

s/"In the case 2, the controller sends the IPsec SA information to the SAD
that includes the keys for integrity and encryption (when ESP is used)" /
"In the case 2, the controller sends the IPsec SA information to the SAD
that includes the required cryptographic keys for ESP or AH"

Regards,
Fernando.

-- 
----------------------------------------------------------------------------------------------------
Fernando Pereñíguez García, PhD
Department of Sciences and Informatics
University Defense Center, (CUD), San Javier Air Force Base, MDE-UPCT
C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax: +34 968 189 970
------------------------------------------------------------------------------------------------------

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Dec 2018 15:59:14 -0500 (EST)

On Tue, 11 Dec 2018, Fernando Pereñíguez García wrote:

These answers look fine. Thanks.

Paul
(the other emails will take a little more time :)

> Date: Tue, 11 Dec 2018 13:52:13
> From: Fernando Pereñíguez García <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
>     Rafa Marin Lopez <[email-masked]>, Gabriel López Millán <[email-masked]>
> To: [email-masked]
> Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03
>     (Sections 8 - 9)
> X-Spam-Flag: NO
> 
> Hi Paul, all,
> Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required
> note to the RFC Editor to remove the entire section before publication as RFC.
> 
> [Authors]
> 
> In case 1, add a note to use only strong PSKs, with a minimal length and strength.
> 
> [Authors]
> Agree. We will add it.
> 
> Section 9.2:
> 
> when ESP is used
> 
> Hoping my advise is taken to only use ESP and not AH, and to use ESP-null in the case of encryption being unwanted, please
> s/"In the case 2, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used)" / 
> "In the case 2, the controller sends the IPsec SA information to the SAD that includes the required cryptographic keys for ESP or AH"
> 
> 
> Regards,
> Fernando.
> 
>  
> --