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

[Rafa Marin-Lopez <[e-mail]>]

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: [phone] Fax: [phone] e-mail: [e-mail] <mailto:[e-mail]>
-------------------------------------------------------