IETF Logo Mail Archive

Re: [I2nsf] Reviewing sdn-ipsec-flow-protection

Rafa Marin-Lopez <rafa@um.es> Wed, 14 November 2018 09:31 UTC

Return-Path: <rafa@um.es>
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 C9EF212D4EB for <i2nsf@ietfa.amsl.com>; Wed, 14 Nov 2018 01:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 9b_s1wb6Bx-B for <i2nsf@ietfa.amsl.com>; Wed, 14 Nov 2018 01:30:58 -0800 (PST)
Received: from xenon41.um.es (xenon41.um.es [IPv6:2001:720:1710:601::41]) by ietfa.amsl.com (Postfix) with ESMTP id 9749E1293FB for <i2nsf@ietf.org>; Wed, 14 Nov 2018 01:30:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 6ECAA202F3; Wed, 14 Nov 2018 10:30:54 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon41.um.es
Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24PVQk40j3OD; Wed, 14 Nov 2018 10:30:54 +0100 (CET)
Received: from eduroam_um-6-102.inf.um.es (eduroam_um-6-102.inf.um.es [155.54.6.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 6C5722015C; Wed, 14 Nov 2018 10:30:53 +0100 (CET)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <6839D47C-4074-486F-9350-8EB7B378036C@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E73F8974-7748-4F50-B62A-221237BAE425"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 14 Nov 2018 10:30:52 +0100
In-Reply-To: <A881C135-9BF7-4E93-BB7A-75EB3D1FF605@gmail.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, i2nsf@ietf.org, Paul Wouters <paul@nohats.ca>
To: Yoav Nir <ynir.ietf@gmail.com>
References: <A881C135-9BF7-4E93-BB7A-75EB3D1FF605@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/BCyqF8dPFsWLAF7x7UR9FxgsmEw>
Subject: Re: [I2nsf] Reviewing sdn-ipsec-flow-protection
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: Wed, 14 Nov 2018 09:31:01 -0000

Hi Yoav:

> El 8 nov 2018, a las 17:11, Yoav Nir <ynir.ietf@gmail.com> escribió:
> 
> Hi, all
> 
> As discussed in the room, we need some reviewers for the sdn-ipsec-flow-protection draft ([1])

Thanks for these comments. Please see our response below.
> 
> While any comments on any part of the document are welcome, I would like people to concentrate on the following issues:
> The YANG model in Appendix A
> Some of the crypto seems obsolete (example: DES). We would get into trouble in SecDir review.  OTOH ChaCha20-Poly1305 is missing..

Agree. We will remove DES and add the algorithm you mention.

> Some of the modes are obsolete (BEET)

We will remove it.

> KINK & IKEv1

We will remove it.

> The YANG model in Section 6
> I think there’s a bit of TMI in there:  Not all fields in an IPsec implementation need to be sent from the controller (SA state, like “larval”)

True. We will try to polish this.

> The interaction between Controller and NSF
> There’s no way for the controller to retrieve NSF capabilities. What if the NSF does not implement rc5?  It’s fine if we say that the Controller knows in advance what the capabilities of each NSF are, but it should be stated.

Agree. Nevertheless, I would say that the most correct way is when the controller asks the NSF about capabilities after NSF and controller connect. 

> ISTM like the Controller sends the private key and the certificate to the NSF. While this is a possible model, it is also quite common for private keys to be generated in the NSF and never leave the cryptographic boundary. I think this should be at least allowed.

I guess you’re referring to section 9.1  We think the NSF should always generate the public and private key. If raw public key is used the NSF sends that public key to the Controller just for a simple registration. If the public key needs to be in a certificate, the NSF can send the public key to the Security Controller for certification. 

In summary,  the private key never leaves the NSF in both cases. If agreed, we will modify this text to only consider this case.
> 
> Thanks to Paul Wouters and two others who volunteered to review. Substantive reviews will be rewarded with a beer in Prague.

Thanks Paul, and volunteers. 
> 
> Yoav
> 
> [1] https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 <https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03>_______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

v2.23.0 | Report a Bug | By Email