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

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 21 Oct 2015 11:15:10 +0200

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: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 21 Oct 2015 22:43:40 +0000

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? 

 What is your goal? Only to give use cases for IPSec policy? Or do you plan to dive in one step further to define the semantics of the polices or rules for IPSec?  

Thanks, Linda 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Rafa Marin Lopez
Sent: Wednesday, October 21, 2015 4:15 AM
To: [email-masked]; [email-masked]
Cc: Gabriel Lopez; Alejandro Abad UM; Rafa Marin Lopez
Subject: [I2nsf] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection

Dear all:

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: [email-masked]
-------------------------------------------------------

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 22 Oct 2015 10:19:57 +0200

Dear Linda:

First of all, thanks for commenting on our draft.

> El 22 oct 2015, a las 0:43, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa, 
> 
> Can you elaborate what kind of IPSec policies that Apps can give to "SDN Controller”? 

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.

---

From: Gabriel Lopez <[email-masked]>
Date: Thu, 22 Oct 2015 10:31:48 +0200

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 <[email-masked]> escribió:
> 
> Dear Linda:
> 
>> El 22 oct 2015, a las 0:43, Linda Dunbar <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Rafa,
>> 
> *See the detailed example in Fig. 5 in http://www.ipsec-howto.org/x304.html <http://www.ipsec-howto.org/x304.html>
> 
> https://tools.ietf.org/html/draft-tran-ipecme-yang-ipsec-00 <https://tools.ietf.org/html/draft-tran-ipecme-yang-ipsec-00>
> 
> 
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>
> sdn mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/sdn <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: [email-masked] <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 22 Oct 2015 20:06:25 +0000

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

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

Thanks, Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Gabriel Lopez
Sent: Thursday, October 22, 2015 3:32 AM
To: Rafa Marin Lopez
Cc: [email-masked]; [email-masked]; Alejandro Abad UM; Linda Dunbar
Subject: Re: [I2nsf] [Sdn] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection

Hi,

Thanks for the review.

ike {
            proposal proposal-1 {

Best regards, Gabi.

El 22 oct 2015, a las 10:19, Rafa Marin Lopez <[email-masked]<mailto:[email-masked]>> escribió:

Dear Linda:

El 22 oct 2015, a las 0:43, Linda Dunbar <[email-masked]<mailto:[email-masked]>> escribió:

Rafa,

Imagine you have* :

Best Regards.

Thanks, Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Rafa Marin Lopez
Sent: Wednesday, October 21, 2015 4:15 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Gabriel Lopez; Alejandro Abad UM; Rafa Marin Lopez
Subject: [I2nsf] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection

Dear all:

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: [email-masked]<mailto:[email-masked]>
-------------------------------------------------------

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>
-------------------------------------------------------

_______________________________________________
sdn mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 22 Oct 2015 23:54:17 +0200

Hi Linda:

> El 22 oct 2015, a las 22:06, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa and Gabi,
>  
> 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.

> [email-masked]
> email: [email-masked]

---

From: "Dacheng Zhang" <[email-masked]>
Date: Fri, 23 Oct 2015 10:20:14 +0800

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"
<[email-masked] on behalf of [email-masked]> 写入:

>> 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?
>
>> Is it true that the IKE policies can be utilized between Security
>>Controller and Client for the Service Layer interface?
>
>> Subject: Re: [I2nsf] [Sdn] New update of
>>draft-abad-sdnrg-sdn-ipsec-flow-protection
>>  
>>  
>> Hi,
>>  
>> Thanks for the review.
>>  
>> As described in Rafa’s response, IKE allows two peers to dynamically
>>negotiate the cryptography material for IPSec in a secure way.
>> 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 :
>> 
>> Moreover it has to specify other parameters such as credentials to be
>>used to establish IKE SA, cryptographic algorithms etc…
>> 
>> 
>> 
>> 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:
>> 
>> 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
>> 
>> Subject: [I2nsf] New update of
>>draft-abad-sdnrg-sdn-ipsec-flow-protection
>> 
>> Dear all:
>>

---

From: Gabriel Lopez <[email-masked]>
Date: Fri, 23 Oct 2015 11:57:51 +0200

Hi Dacheng,

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

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Oct 2015 09:45:57 -0400

This does seem interesting even if if beyond the scope of I2NSF.
Are you going to be in Japan?
I will not, but margaret and Mark from Painless Security will be.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 23 Oct 2015 16:14:47 +0200

Hi Sam:

Thanks for your interest in the document.  Unfortunately we won’t go this time. In any case we can prepare a call to discuss if you want. 

Definitely one of the possible tasks of the security controller may be key distribution, which is, in our opinion, very interesting.

Best Regards

> El 23 oct 2015, a las 15:45, Sam Hartman <[email-masked]> escribió:
>

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 27 Oct 2015 09:42:17 +0800

I will not go to Japan this time. But I plan to attend the next IETF
meeting. Linda plans to visit China before the meeting， so I will try to
get a chance to discuss with her about this. I think my friends from
Huawei may be also interested in this topic. ^_^