Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04

[Paul Wouters]

On Fri, 30 Nov 2018, Waltermire, David A. (Fed) wrote:


This message starts a working group last call (WGLC) on 
draft-ietf-ipsecme-qr-ikev2-04, which will conclude on December 14, 2018 at UTC 
23:59. Please review and provide feedback on the -04 version 
(https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/). Please 
indicate if you believe this draft is ready for publication or if you have 
comments that must be addressed before the draft progresses to the IESG.


I believe the document is ready. We (libreswan) have implemented it and
performed successful interop with 3 other vendors (Cisco, Apple, Elvis+)

It is important because this eliminates one of the very few reasons left
why people would need to run IKEv1 instead of IKEv2.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Rafa Marin-Lopez]

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 


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