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

Hi, 

Maybe this work is not really considered in the current agenda. But I
think it is very interesting. Also, I am thinking whether the similar idea
can be used to mange the policies of securing routing protocols. We used
to specify a key table specification for different routing protocols. At
that time, someone mentioned it could be a good idea to use controllers to
deploy keys for routing protocols, so that we don’t have to extend IKEv2
to negotiate them. 

Thoughts?

Cheers

Dacheng

在 15-10-23 上午5:54， "I2nsf on behalf of Rafa Marin Lopez"
<i2nsf-bounces@ietf.org on behalf of rafa@um.es> 写入:

>Hi Linda:
>
>> El 22 oct 2015, a las 22:06, Linda Dunbar <linda.dunbar@huawei.com>
>>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:i2nsf-bounces@ietf.org] On Behalf Of Gabriel Lopez
>> Sent: Thursday, October 22, 2015 3:32 AM
>> To: Rafa Marin Lopez
>> Cc: i2nsf@ietf.org; sdn@irtf.org; 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 <rafa@um.es> escribió:
>>  
>> Dear Linda:
>> 
>> First of all, thanks for commenting on our draft.
>> 
>> 
>> El 22 oct 2015, a las 0:43, Linda Dunbar <linda.dunbar@huawei.com>
>>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:i2nsf-bounces@ietf.org] On Behalf Of Rafa Marin
>>Lopez
>> Sent: Wednesday, October 21, 2015 4:15 AM
>> To: sdn@irtf.org; i2nsf@ietf.org
>> 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.t
>>xt
>> 
>> 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: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
>> _______________________________________________
>> I2nsf mailing list
>> I2nsf@ietf.org
>> 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: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
>> _______________________________________________
>> sdn mailing list
>> sdn@irtf.org
>> 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: +34 868888504
>> Fax: +34 868884151
>> email: gabilm@um.es
>
>-------------------------------------------------------
>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
>-------------------------------------------------------
>
>
>
>
>_______________________________________________
>I2nsf mailing list
>I2nsf@ietf.org
>https://www.ietf.org/mailman/listinfo/i2nsf