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

[Gabriel Lopez <[e-mail]>]

Hi Dacheng,


> El 23 oct 2015, a las 4:20, Dacheng Zhang <[e-mail]> escribió:
> 
> 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.

I’m not an expert on security routing protocols, but I think the idea es basically the same: to provide key material to the peers (router,  ipsec peer, etc.).

> 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?

It would depend on how routers trust each other. In our example, an IPSec peer could be provisioned with cryptographic keys from the controller (in the case peers belong to the same domain) or they could make use of IKE to dynamically negotiate these keys.

Best regards, Gabi.

> 
> Cheers
> 
> Dacheng
> 
> 在 15-10-23 上午5:54， "I2nsf on behalf of Rafa Marin Lopez"
> <[e-mail] on behalf of [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.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: [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]
>> -------------------------------------------------------
>> 
>> 
>> 
>> 
>> _______________________________________________
>> I2nsf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2nsf
> 
> 



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