Re: [I2nsf] [IPsec] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

"Susan Hares" <shares@ndzh.com> Mon, 22 July 2019 15:37 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D212012B; Mon, 22 Jul 2019 08:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Level:
X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 SS8sHTuT3Bzs; Mon, 22 Jul 2019 08:37:04 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACD212013B; Mon, 22 Jul 2019 08:36:57 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.154.200;
From: Susan Hares <shares@ndzh.com>
To: 'Rafa Marin Lopez' <rafa@um.es>, 'Yoav Nir' <ynir.ietf@gmail.com>
Cc: ipsec@ietf.org, mbj@tail-f.com, i2nsf@ietf.org, 'Gabriel Lopez' <gabilm@um.es>, 'Fernando Pereñíguez García' <fernando.pereniguez@cud.upct.es>, 'Valery Smyslov' <smyslov.ietf@gmail.com>, idr-chairs@ietf.org, bess-chairs@ietf.org, "'Vigoureux, Martin (Nokia - FR/Paris-Saclay)'" <martin.vigoureux@nokia.com>
References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> <4A3ADE90-C7E5-4198-9D2E-A441806A00B1@um.es>
In-Reply-To: <4A3ADE90-C7E5-4198-9D2E-A441806A00B1@um.es>
Date: Mon, 22 Jul 2019 11:36:34 -0400
Message-ID: <008201d540a3$3ef9c1a0$bced44e0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01D54081.B7EDEE00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QMPmbQ9AnwHr9GmqCDx4A==
Content-Language: en-us
X-Antivirus: AVG (VPS 190722-4, 07/22/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/uqmkcHiVK_ntKk2wlbXaPOlZWwE>
Subject: Re: [I2nsf] [IPsec] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 15:37:09 -0000

Rafa and Yoav:

 

[IDR co-chair hat on]  and Caveat – I am not a IPSEC or security expert. 

 

>I don’t think it’s very useful for the controller to distribute a policy (SPD entries) but no SAs (SAD entries) in the IKE-less case.  It makes sense >in the IKE case because the NSFs can then use IKE to generate the SAs, but in the IKE-less case that would mean that one NSF gets a packet >that should be protected, sends a message to the controller, which generates an SA and sends it to both the requester and the other NSF.  This >seems high latency.

 

We may have a case that suggests it is useful for the controller to distribute policy but no SA (SAD) entries in the Ike-less cae.  

 

The IDR and BESS Working groups are considering using BGP to create secure VPNs.  The architecture is controller-device where the controller distributed the security information (SPD, SA).  Some of the pathways in these VPNS will use IPSEC with Ike over the link.  Some  of these pathways will be IKE-less (e.g.) secure private VPN without encrypted lengths .   The VPNs will combine both paths.  

 

BGP signaling is passing the keying nonce, rekying time, secure encryption type, and SA transform information.  The BGP is a point-to multiple-point distribution method (using BGP route-reflectors) combing BGP and IPSEC information distribution.   BGP is being secured per link (over IPSEC) and the data is being secure in a variety of methods (BGP origin, filters, or BGPSEC). 

 

We’ve set-up a session on Wed (7/24) to discuss the BGP proposals with security experts.   As the leader of the session, I need help to understand why you think “it is not very useful”.    You can respond to me privately or just attend the session. 

 

Sue Hares 

 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Rafa Marin Lopez
Sent: Monday, July 22, 2019 11:11 AM
To: Yoav Nir
Cc: ipsec@ietf.org; mbj@tail-f.com; i2nsf@ietf.org; Gabriel Lopez; Fernando Pereñíguez García; Rafa Marin Lopez; Valery Smyslov
Subject: Re: [I2nsf] [IPsec] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

Hi Yoav:

 

El 21 jul 2019, a las 3:23, Yoav Nir <ynir.ietf@gmail.com> escribió:

 

Hi, Valery

 

[no hats]

 

Thanks for that.

 

I think this demonstrates that the current document is not enough and we will need some follow-up documents explaining when to use either case.

 

[Authors] The objective of the current document is to present the idea and the interfaces to make things possible. Once we have this, we have also to work on performance analysis, experimentation (we are actually working on this already) and other uses cases.

 

In any case, we are more than happy to contribute on those potential documents, of course. 





 

I don’t think it’s very useful for the controller to distribute a policy (SPD entries) but no SAs (SAD entries) in the IKE-less case.  It makes sense in the IKE case because the NSFs can then use IKE to generate the SAs, but in the IKE-less case that would mean that one NSF gets a packet that should be protected, sends a message to the controller, which generates an SA and sends it to both the requester and the other NSF.  This seems high latency.

 

[Authors] What you have just described is the proactive vs reactive mode of operation that you can find in SDN-based networks. In our case, in the reactive mode, you install the SPD first and waits for a sadb_acquire notification. In the proactive mode you install the IPsec SAs at the same time. In fact, section 7.1 (Figure 4) in our I-D assumes proactive (step 2)

 

   2.  The Security Controller translates the flow-based security

       policies into IPsec SPD and SAD entries.

 

Clearly there are advantages and disadvantages in proactive and reactive models, as it may happen in Openflow network. For example, proactive reduces latency but it may create unnecessary state in the NSFs. Reactive increases latency but the state is created in the NSFs just when it is required. You can install rules to avoid a PACKET_IN (the “notification”) so you avoid the delay. As I mentioned to Valery, all of this is expected and assumed in the SDN paradigm (the IKE-less is the most similar to SDN paradigm nowadays). 

 

As per “high latency” I would say “higher latency”. And that’s true. The latency increases (it is reactive mode) but this latency is generally assumable in SDN networks (until certain level of tolerance, of course). In fact you can find interesting studies out there about this in Openflow networks. 





 

I think the case for IKE-less is where the controller sends SPD entries and SAD entries at the same time (perhaps later updating the SAD entries to rekey).

In that case the action of the controller is to bring up a tunnel.  For example, if the user (or application) decides that communications between node A and node B should be encrypted, the controller will send both policy and keys at the same time to make that tunnel.

 

[Authors] This would be the proactive mode, very valid to reduce latency. But I assume it is a decision for the SC to make. Right now the YANG model admits both cases (proactive and reactive). In fact an hybrid (proactive for some flows and reactive for others) might be possible.

 

Best Regards.



 

Yoav





On 20 Jul 2019, at 10:38, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

 

Hi,

 

thank you for updating the document. I still think that some aspect

of IKE-less use case are not discussed yet (well, probably they are not 

"serious", depending on one's definition of "serious").

 

Unlike IKE case. which we can consider as mostly static configuration,

the IKE-less case is a dynamic one. If IPsec SA are being created 

on demand (via kernel-acquire) and the traffic volume is high,

then depending on the IPsec policy IKE-less case can become 

a highly dynamic, which implies additional requirement on both

the network connecting SC and NSF and the performance of the protocol used to 

secure their communications. In other words, in IKE case the communication

between IKE daemon and kernel is seamless, while in IKE-less

case the communication between NSF ("kernel") and SC adds

noticeable delay (and can potentially add quite a long delay),

which can influence total performance of the system.

 

Generally IKE-less case requires more communications between

different nodes to establish or rekey IPsec SA, than IKE case

(I assume that IKE SA is already established), that may have

an impact on high-speed networks with short-lived IPsec SAs,

especially if they are created per transport connection

(say one IPsec SA for one TCP session).

 

I believe, that SC's task of managing IPsec SAs in IKE-less case 

may become quite complex, especially because due to the

additional delay, introduced by the network, the picture of the

state of the SAs the SC has can become inaccurate (well, 

it will always be inaccurate, but with short delays it doesn't matter).

Just an example. Consider an SC receives a signal from NSF that an SA

is soft expired and starts rekeying process by first installing a new

pair of inbound SAs. It successfully installs them on the NSF

it receives notification from, but then it receives a notification

that the other NSF has rebooted, so it must clear all the SAs on

its peers, including the just installed new one (which is only

half-done). There seems to be a lot of nuances, and the document 

completely ignores them. Not that I think that the task

is impossible, but the algorithm of managing the SAs can become

quite complex and possibly unreliable.

 

I didn't find this discussion in the draft (sorry if I missed it).

 

Regards,

Valery.

 

 

 

 

Thanks for getting this done and published.

 

We will wait with requesting publication until the I2NSF session next week.  Between now and then, please re-read the draft and send a message to the list is something is seriously wrong.

 

Barring any such shouting, we will request publication right after the meeting.

 

Thanks again,

 

Linda and Yoav






On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < <mailto:rafa@um.es> rafa@um.es> wrote:

 

Dear all:

We submitted a new version of the I-D (v05) where we have applied several changes. In the following you have a summary of the main changes, which we will expand/explain during our presentation: 

- We have dealt with YANG doctors’ review (Martin's)

- We have dealt with Paul Wouters’ comments and Tero’s comments.

 

- We have added more specific text in the descriptions.

- Notifications have a simpler format now since most of the information that contained in the past is already handled by the Security Controller.

- State data has been reduced. For example, in IKE case, most of the information is related with IKE and not with the specific details about IPsec SAs that IKE handles (after all, IKE can abstract this information from the Security Controller).

 

- We have included text in the security section to discuss about the default IPsec policies that should be in the NSF when it starts before contacting with the SC such as the IPsec policies required to allow traffic between the SC and the NSF.

 

- We have added a subsection 5.3.4 about NSF discovery by the Security Controller.

- In order to specify the crypto-algorithms we have used a simple approach by including an integer and adding a text pointing the IANA in the reference clause. For example:


typedef encryption-algorithm-type {
           type uint32;
           description 
               "The encryption algorithm is specified with a 32-bit
               number extracted from IANA Registry. The acceptable
               values MUST follow the requirement levels for
               encryption algorithms for ESP and IKEv2.";
           reference 
                "IANA Registry- Transform Type 1 - Encryption
                Algorithm Transform IDs. RFC 8221 - Cryptographic
                Algorithm Implementation Requirements and Usage
                Guidance for Encapsulating Security Payload (ESP)
                and Authentication Header (AH) and RFC 8247 -
                Algorithm Implementation Requirements and Usage
                Guidance for the Internet Key Exchange Protocol
                Version 2 (IKEv2).";
       }

 

- We have included three additional Annexes with examples in about the usage of the YANG model.

 

- We have performed pyang --lint --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 in our model without warnings.

 

Best Regards.






Inicio del mensaje reenviado:

 

De:  <mailto:internet-drafts@ietf.org> internet-drafts@ietf.org

Asunto: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, 23:34:03 CEST

Para: < <mailto:i-d-announce@ietf.org> i-d-announce@ietf.org>

Cc:  <mailto:i2nsf@ietf.org> i2nsf@ietf.org

Responder a:  <mailto:i2nsf@ietf.org> i2nsf@ietf.org

 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions WG of the IETF.

       Title           : Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors         : Rafa Marin-Lopez
                         Gabriel Lopez-Millan
                         Fernando Pereniguez-Garcia
           Filename        : draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
           Pages           : 81
           Date            : 2019-07-07

Abstract:
  This document describes how providing IPsec-based flow protection by
  means of a Software-Defined Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to support this service.
  It considers two main well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The SDN-based service described in
  this document allows the distribution and monitoring of IPsec
  information from a Security Controller to one or several flow-based
  Network Security Function (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF Facing Interface by providing models
  for configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
  to establish Security Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this draft is:
 <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/

There are also htmlized versions available at:
 <https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05
 <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05

A diff from the previous version is available at:
 <https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-05> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/> .

Internet-Drafts are also available by anonymous FTP at:
 <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I2nsf mailing list
 <mailto:I2nsf@ietf.org> I2nsf@ietf.org
 <https://www.ietf.org/mailman/listinfo/i2nsf> https://www.ietf.org/mailman/listinfo/i2nsf

 

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151  <mailto:rafa@um.es> e-mail: rafa@um.es
-------------------------------------------------------

 

 

 

 

_______________________________________________
I2nsf mailing list
 <mailto:I2nsf@ietf.org> I2nsf@ietf.org
 <https://www.ietf.org/mailman/listinfo/i2nsf> https://www.ietf.org/mailman/listinfo/i2nsf

 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec