Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Paul Wouters <paul@nohats.ca> Wed, 29 May 2019 14:44 UTC

Return-Path: <paul@nohats.ca>
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 111C0120122; Wed, 29 May 2019 07:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 pmSKbRc8-e6g; Wed, 29 May 2019 07:44:19 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC7412010C; Wed, 29 May 2019 07:44:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45DYPs040gzFQV; Wed, 29 May 2019 16:44:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1559141057; bh=rOQ/3E0TD2Df6s1x0ivdkoeT8jzJbKBRMJGcXADu8Ps=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LySkQHvSllmbUjvFYaMxuT1eqayLpDx4PGO8ccKQFCJio9ejzZT/TQVeFdPQZeo0u F5a5LRKAV6UUGZAzI4Vt2xcjYElqR4ZcHNn+mQSRc3X6T3s483Yq5AeZG/7VymCFMJ Il0qU8B4G5PKCopKW6oLO86Qhzj2woYbO0W2fTCg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id CDiAFj6B2AQq; Wed, 29 May 2019 16:44:15 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 29 May 2019 16:44:14 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id AC5833159D9; Wed, 29 May 2019 10:44:13 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AC5833159D9
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A4B0940BE921; Wed, 29 May 2019 10:44:13 -0400 (EDT)
Date: Wed, 29 May 2019 10:44:13 -0400
From: Paul Wouters <paul@nohats.ca>
To: Rafa Marin Lopez <rafa@um.es>
cc: Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
In-Reply-To: <718671CF-46BF-427A-A008-A9F8EB3631D0@um.es>
Message-ID: <alpine.LRH.2.21.1905291036480.22788@bofh.nohats.ca>
References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <DBBD75C3-9FB3-473F-A627-062DB3F5C32D@um.es> <alpine.LRH.2.21.1904210811200.1903@bofh.nohats.ca> <ED73306E-F807-42A4-B063-D45E133B8419@um.es> <alpine.LRH.2.21.1905241401320.3939@bofh.nohats.ca> <718671CF-46BF-427A-A008-A9F8EB3631D0@um.es>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/H2R1MX0b52dE2Ak1HbVos92f4VQ>
Subject: Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
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, 29 May 2019 14:44:21 -0000

On Wed, 29 May 2019, Rafa Marin Lopez wrote:

> Please see some additional comments inline:

> [Authors] We understand. In the IKE-less case we do not have this kind of "configured but not up” state. We assume that once the SC configures the NSF with the IPsec SA, the NSF will apply the configuration right way without waiting anything else.
>
> In IKE case it is possible to define this with the type-autostartup (on-demand) by adding your text to the description. However, I was thinking that, actually, this is a general security policy that should be applied in both iKE-case and IKE-less and, even, when the NSF starts in the network and there is no contact with the NSF.
>
> Perhaps the best place to mention this is in the Security Considerations section. Then, we can add in the model the text you mention. We could include this paragraph in Security Considerations (the general part not specific to any case):
>
> “For security reasons, a NSF MUST NOT allow any traffic unless the Security Controller mandates so. In other words, since the NSF needs IPsec information coming from the SC, if that information is not in place yet the safest option is DISCARD (drop) packets."

I assume there are two types of deployment, "cleartext but encrypt when
possible" and "encryption mandatory". So I feel the MUST NOT is a bit
too strong. Perhaps limit it to say "if encryption is mandatory for
all traffic of an NSF, its default policy MUST be to drop packets to
prevent cleartext packet leaks".

But then you also do not need per-tunnel "drop" policies, so the SC does
not have to instruct the NSF for anything.

>> This one did not get answered. Do you plan to link to the protocol
>> registry at IANA ?
>
> [Authors] Our approach so far will be similar to the one we found in RFC 8519. There they use a type uint8 and give a description and preference. More specifically:
>
> leaf protocol {
>      type uint8;
>      description
>        "Internet Protocol number.  Refers to the protocol of the
>         payload.  In IPv6, this field is known as 'next-header',
>         and if extension headers are present, the protocol is
>         present in the 'upper-layer' header.";
>      reference
>        "
> RFC 791
> : Internet Protocol
>
> RFC 8200
> : Internet Protocol, Version 6 (IPv6) Specification.";
>    }
>
> Therefore, we would like to add something a uint8 and referring to IANA registry. Is this approach acceptable for you?

Sounds good.

> We will take also the same approach for crypto-algs so far in order to see if this is valid for yang-doctors' review

Okay.

>>> [Authors] According to RFC 4301 - 4.4.2.1.  Data Items in the SAD:
>>> Sequence Counter Overflow: a flag indicating whether overflow of
>>>       the sequence number counter should generate an auditable event and
>>>       prevent transmission of additional packets on the SA, or whether
>>>       rollover is permitted.  The audit log entry for this event SHOULD
>>>       include the SPI value, current date/time, Local Address, Remote
>>>       Address, and the selectors from the relevant SAD entry.
>>
>>
>> Hmm, I have never heard of this so I should look into it, but I guess it
>> means you should have the option for it, but please default it to not
>> allow rollover, and it would need to forbid rollover for AEAD’s.
>
> [Authors] We have included this in the description:
>
> "The flag indicating whether overflow of the sequence number counter should prevent
> transmission of additional packets on the IPsec SA (FALSE), or whether rollover is permitted (TRUE). If Authenticated Encryption with Associated Data (AEAD) is used this flag MUST BE false.”;

Okay, good.

With these, I think you resolved all my outstanding issues I had.
Thanks!

Paul