Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses?

Hi Paul:

Thank you for your comments. Please, see mine inline.

>>> [Rafa] I guess, it will depend on the scenario. I remember an e-mail to I2NSF (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html) mentioning that they were doing sort of case 2 and they would like to have a standard way of doing it. Precisely the effort behind our I-D is trying to provide an standard interface standard not only for case 1 (with IKE in the NSF) but also for case 2 (no IKE in the NSF). 
>>> 
> 
> Don't. You will need to builtin there same security features as IKE has.

[Rafa] Yes, but in case 2 all those features (e.g. key management operations) are in the controller but not in the NSFs. The NSFs only implements IPsec stack and deploys, for example, a NETFCONF server for the communication with the controller. Thus, all the key management operations are performed in the controller in case 2 and the resulting IPsec SAs are installed in the NSFs using, for example, NETCONF. 

> Focus instead of implementing "minimal ikev2"
> 
> https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01

[Rafa] Minimal IKEv2 implementation in the NSF would be case 1. 
Nevertheless, implementing minimal ikev2 does not solve, for example, NAT-T for case 1 so controller should do something anyway.

> 
> 
> For example, most modern ciphers require timely rekeying and must never reuse IV/counters with the same private key.

[Rafa] Why do you imply that IV/counters will be the same with same private key? That is not the assumption in case 2 where the controller always generates fresh IPsec SAs.

> Synching that across independent hosts is impossible.

[Rafa] I do not see how it is impossible when a controller that have access to both NSFs provides that information. If it is not impossible when using IKEv2, it should not be impossible for case 2. 

The point is that the result of running IKEv2 is the IPsec SAs in the IPsec kernel of both NSFs. In case 2, that state is coming from the controller that is performing the key management operations (generate fresh key material, IV, etc… per each IPsec SA). The controller has a  connection with both NSFs using, for example, NETCONF. Moreover, as I commented , you can read this e-mail (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html). So there is proof that it is working.

Thus, it is more difficult to manage, yes, (in fact, we admit that in our I-D), but not impossible. 
In fact, I think it would be worthy if you can provide a concrete example of that use case where both NSFs are under the same controller. Maybe we can help you to address your concern and explain how the operation would be in that specific case you have in mind.

Best Regards and many thanks for your comments.

> 
> Paul
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

-----------------------------------------------------------
Rafael 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: rafa@um.es
----------------------------------------------------------