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

Linda Dunbar <linda.dunbar@huawei.com> Thu, 22 October 2015 20:07 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: sdn@ietfa.amsl.com
Delivered-To: sdn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61CC1B3F7C for <sdn@ietfa.amsl.com>; Thu, 22 Oct 2015 13:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bij-x6e4t4vn for <sdn@ietfa.amsl.com>; Thu, 22 Oct 2015 13:06:59 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C1A1B3F76 for <sdn@irtf.org>; Thu, 22 Oct 2015 13:06:58 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml706-chm.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSE41897; Thu, 22 Oct 2015 15:06:31 -0500 (CDT)
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Thu, 22 Oct 2015 13:06:25 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Gabriel Lopez <gabilm@um.es>, Rafa Marin Lopez <rafa@um.es>
Thread-Topic: [I2nsf] [Sdn] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection
Thread-Index: AQHRDKQmzKrIC/qIy0W+y47uFrSOGJ537v3A
Date: Thu, 22 Oct 2015 20:06:25 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D7208A@dfweml701-chm>
References: <CD8880C6-90B6-4125-BBCE-6AA0B76DA2D7@um.es> <4A95BA014132FF49AE685FAB4B9F17F657D71571@dfweml701-chm> <89725C38-5C24-44B2-9957-BAD267993F92@um.es> <160732AF-02A9-48FB-BF91-94412A1688C0@um.es>
In-Reply-To: <160732AF-02A9-48FB-BF91-94412A1688C0@um.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.236]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657D7208Adfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/sdn/nCZdcUsdrQondZ3yRAJjEM_rTBI>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, "sdn@irtf.org" <sdn@irtf.org>, Alejandro Abad UM <alejandroprimitivo.abad@um.es>
Subject: Re: [Sdn] [I2nsf] New update of draft-abad-sdnrg-sdn-ipsec-flow-protection
X-BeenThere: sdn@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List to Discuss SDN Research Group in the IRTF <sdn.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/sdn>, <mailto:sdn-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sdn/>
List-Post: <mailto:sdn@irtf.org>
List-Help: <mailto:sdn-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/sdn>, <mailto:sdn-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 20:07:02 -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: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<mailto: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<mailto: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<mailto:sdn@irtf.org>; i2nsf@ietf.org<mailto: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.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: rafa@um.es<mailto:rafa@um.es>
-------------------------------------------------------




_______________________________________________
I2nsf mailing list
I2nsf@ietf.org<mailto: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<mailto:rafa@um.es>
-------------------------------------------------------




_______________________________________________
sdn mailing list
sdn@irtf.org<mailto: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<mailto:gabilm@um.es>