Re: [Sdn] [I2nsf] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection

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

Hi Linda:

> El 22 oct 2015, a las 22:06, Linda Dunbar <[e-mail]> escribió:
> 
> Rafa and Gabi,
>  
> Thank you very much for the explanation. That is very helpful.
>  
> Based on your explanation,  the Capability Layer interface for IPSec has been defined

If you are referring to the YANG model with IPsec then we have a good step with draft-wang-ipsecme-ipsec-yang

> but there is need for the Service Layer rules for IPSec. The service layer IPSec rules can be applied to many pairs of IPsec tunnels, so that administrators don’t need to manually setup each one. Is my understanding correct?

Right, that is also our understanding. 

>  
> Is it true that the IKE policies can be utilized between Security Controller and Client for the Service Layer interface?

Yes, that might be a possibility, though we understand a deeper analysis is required.

Best Regards.

>  
> Thanks, Linda
>  
> From: I2nsf [mailto:[e-mail]] On Behalf Of Gabriel Lopez
> Sent: Thursday, October 22, 2015 3:32 AM
> To: Rafa Marin Lopez
> Cc: [e-mail]; [e-mail]; Alejandro Abad UM; Linda Dunbar
> Subject: Re: [I2nsf] [Sdn] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection
>  
>  
> Hi,
>  
> Thanks for the review.
>  
> Please, note that the draft also include IKE policies.
>  
> As described in Rafa’s response, IKE allows two peers to dynamically negotiate the cryptography material for IPSec in a secure way.
> An example of IKE policies could be:
>  
> ike {
>             proposal proposal-1 {
>                         authentication-method pre-shared-keys;
>                         dh-group group1;
>                         authentication-algorithm sha1;
>                         encryption-algorithm 3des-cbc;
>                         lifetime-seconds 1000;
>             }
>             proposal proposal-2 {
>                         authentication-method pre-shared-keys;
>                         dh-group group2;
>                         authentication-algorithm md5;
>                         encryption-algorithm des-cbc;
>                         lifetime-seconds 10000;
> }
>  
> Best regards, Gabi.
>  
>  
> El 22 oct 2015, a las 10:19, Rafa Marin Lopez <[e-mail]> escribió:
>  
> Dear Linda:
> 
> First of all, thanks for commenting on our draft.
> 
> 
> El 22 oct 2015, a las 0:43, Linda Dunbar <[e-mail]> escribió:
> 
> Rafa, 
> 
> Thank you very much for sharing the draft. 
> 
> Can you elaborate what kind of IPSec policies that Apps can give to "SDN Controller”? 
> I am not an expert on IPSec, so pardon me if my question is not correct:  if client needs "protected IPsec traffic", can them simply establish two parallel IPSec tunnels? 
> 
> Any question is good. So, thank you. Let me try to clarify. When you want to establish an IPsec protected tunnel you have to configure rules/policies to determine what kind of traffic you want to protect. 
> 
> Imagine you have* :  
> 
> Network A(172.16.1.0/24) — GW_A (192.168.1.100/24)-Internet-(192.168.2.100/24) GW_B - (172.16.2.0/24) Network_B
> 
> With ipsec-tools in Linux you define the following policies to protect traffic between both networks with a tunnel. Administrators of both networks have to configure this in both GW_A and GW_B :
> 
> spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
>           esp/tunnel/192.168.1.100-192.168.2.100/require;
> 
> spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
>           esp/tunnel/192.168.2.100-192.168.1.100/require;
> 
> *See the detailed example in Fig. 5 in http://www.ipsec-howto.org/x304.html
> 
> Moreover it has to specify other parameters such as credentials to be used to establish IKE SA, cryptographic algorithms etc…
> 
> 
> 
> What is your goal? Only to give use cases for IPSec policy?
> 
> Our goal is to automatize the management of IPsec security associations so that administrators do not have add those rules in each device. The general idea stemmed from the following principle:
> 
> To establish an IPsec security association you run first IKE to negotiate the IPsec SA (control plane). Once it is established some parameters are configured in the kernel of the network devices, so they can process the IP packets with IPsec before forwarding (data plane). So for us, there is a clear separation between these two planes.
> 
> Additionally, please think that IPsec uses packet filtering (and cryptography). In this sense we consider that a NSF can perform this task. Thus, some interface as those to be defined in I2NSF may be required. Btw, you can find a YANG model for ipsec in the following link:
> 
> https://tools.ietf.org/html/draft-tran-ipecme-yang-ipsec-00
> 
> 
> 
> Or do you plan to dive in one step further to define the semantics of the polices or rules for IPSec?  
> 
> If I understand correctly your question I will say the semantics and rules for IPsec are already there as shown in the example. Another thing to consider is to define through an application a more general rule such as “I want to protect traffic against eavesdropping between these two networks" that is finally translated in more specific IPsec policies
> 
> We hope this clarify your doubts. In any case, if you have any other question do not hesitate to ask. 
> 
> Best Regards.
> 
> 
> Thanks, Linda 
> 
> -----Original Message-----
> From: I2nsf [mailto:[e-mail]] On Behalf Of Rafa Marin Lopez
> Sent: Wednesday, October 21, 2015 4:15 AM
> To: [e-mail]; [e-mail]
> Cc: Gabriel Lopez; Alejandro Abad UM; Rafa Marin Lopez
> Subject: [I2nsf] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection
> 
> Dear all:
> 
> You may find a new update about Software-Defined Networking (SDN)-based IPsec Flow Protection in this link:
> 
> https://tools.ietf.org/id/draft-abad-sdnrg-sdn-ipsec-flow-protection-01.txt
> 
> We have added some minor modifications and a section to explain the relationship with I2NSF work.
> 
> Comments are really welcome.
> 
> Best Regards.
> 
> -------------------------------------------------------
> Rafael 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]
> -------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
> 
> -------------------------------------------------------
> Rafael 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]
> -------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> sdn mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/sdn
>  
>  
> 
> -----------------------------------------------------------
> Gabriel López Millán
> Departamento de Ingeniería de la Información y las Comunicaciones
> University of Murcia
> Spain
> Tel: [phone]
> Fax: [phone]
> email: [e-mail]

-------------------------------------------------------
Rafael 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]
-------------------------------------------------------