Re: [I2nsf] Magnus Westerlund's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS)

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 15 December 2020 08:28 UTC

Return-Path: <magnus.westerlund@ericsson.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 16D893A0E44; Tue, 15 Dec 2020 00:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 jFVKYyUlGjDz; Tue, 15 Dec 2020 00:28:07 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (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 BDB893A0E43; Tue, 15 Dec 2020 00:28:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVStqNnXQScLJmlJOBZSewHUd+esI6c9KOsQ2QF1vLeLZHjEKVhCSSFX9WYAUanvapkgJnsDYu5iWue09p7HpQhU3DeYJECBFFpjNLXjTMIMvRPBMiGcCeYcPGzGyl2CsE7sLcCGdY4s6kf1SMF0hmhzGNsepFuxvDUT9QIaV6L404fmPWknogd84TuzVJyAJt6ImLl4yIwG/AcmvHcdDVMVO31Q6firkb9iT2Fed+Bo2qb13x03XwHCgYsrYBgWpyEOx/3CJ9JBiFObwVurLlPfP+22TN3t4JmFH07zvEj/jajF9wQlMIHcmUDDOcFDW8UfNgocXNy4PI4kBSUCcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J9/kv1TObiu6FbLU+htR4G7a2cRckFsh1UTA5JRuc6g=; b=XXwS7oh43iCGbtYsrv99kaGgf1vradBQZ/2WyUi347DxKZvs6eNQL10JpJn+2dCRdwlRu+Ttg+3hs+ZoH1/WQhOx7qTTMgpE6Bkl1yLmOXGlJgVb/mmQdeTPWvpx4LfiaPoH53hZRf4BzY4TRTAsIDH1L3fpAsDqawPYFGZTGPvG2m+aby/jS/TXM1/UNDz/IRITc8uETi8FY37RB8fAfFwN9jyl2fWDJeYanUINiGnZGhy6nDRZeOZUDZt/o218ycPnvwLdWnEJoWStrj33Epux6BvWrA0B2io5/u3JWhMe5SVGP74hj4R1Oh8BjBWRYMRhj3agRgZMFO5Ax+1etA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J9/kv1TObiu6FbLU+htR4G7a2cRckFsh1UTA5JRuc6g=; b=oNKIpDuD4JK5Q/4ggvsY00w/HSpvgNUTHo+Q+fzS9EvoD+6DzvSqUVox2v6un/GBHO77g2IDdrVEqsG8r0BuOBJQHoNVVMOwe8Ud0oTYvop6n5rn7Q/xFLL3YKNtr5DLuR2J47+qfYzFVdSSjhAA+Z8BJKH5BKj5irSE1UKvgUk=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.9; Tue, 15 Dec 2020 08:28:03 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%7]) with mapi id 15.20.3676.011; Tue, 15 Dec 2020 08:28:03 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "rafa@um.es" <rafa@um.es>
CC: "draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org" <draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "i2nsf-chairs@ietf.org" <i2nsf-chairs@ietf.org>
Thread-Topic: [I2nsf] Magnus Westerlund's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS)
Thread-Index: AQHWs4O7uBqTMB1dq0C1v142YGiqrKnWI08AgALpz4CAAsIuAIAGiYsAgAATv4CAAB4agIAAHRkAgBRg/4CAAQiRAA==
Date: Tue, 15 Dec 2020 08:28:03 +0000
Message-ID: <2ec85370454ad4678991ee33a40eb6ddf2f8c8f8.camel@ericsson.com>
References: <160458812991.16036.6729267088975668048@ietfa.amsl.com> <9E65120A-D864-4E56-9954-BA536EF88363@um.es> <687e9ef3dcdc10e8f1e908a5c40156d48da8b75c.camel@ericsson.com> <71d91b42d5c20e41d8666f8ad0b9e541c046482a.camel@ericsson.com> <145F8F53-A9E7-4973-8578-26226170C2FE@um.es> <5a4ced1ef2a5c631f270296c66f57742c811ecbd.camel@ericsson.com> <357BEF23-698E-4EC2-B402-DA7F175FC3F4@um.es> <82a207320ed37ba5f025fa8b14cbb02f4e48ba98.camel@ericsson.com> <2C6A1A48-6F96-4326-9DE4-CCB2B4EFF613@um.es>
In-Reply-To: <2C6A1A48-6F96-4326-9DE4-CCB2B4EFF613@um.es>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1125edcb-1c00-4782-80a6-08d8a0d3572a
x-ms-traffictypediagnostic: HE1PR0702MB3772:
x-microsoft-antispam-prvs: <HE1PR0702MB3772B695FCA36E51A5829D6E95C60@HE1PR0702MB3772.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L+a+FoawLNg//33yXzU2xax6X1DqtuyWnmwi4G/5lXo70BnJ7hen5DDM2GbrIrtKOypslpFuVNllGF1NH+EmD/qTKQHoHHClnWTr/7jW73d9+0FMrB7Ctu/sAzR6XyNPE4CK27i9XjEi6l4zvHGIp+D+4lnMcFfuCZZYfw78cic7OeCMmgfKxxlGUYs5gVa42o6+Iij9OBNed5gYEJrmAojG2T2+0SeKNdH/YqYUKRWRMoFUsTT/kTBFsZkQQSzvUf8RAkPMXQkqj/QfgbJTUg+R6dv6UQvJ2QGl9W4OgoUp+rdhg0CREiCjDoSST0wY9425QYeW3XaOINutqQmkoFzrv+aELJtLoc2xQ2dPT+Naiyr1coQYL4dXk/+V1gra0vYSfnH908b56yHwVpDpVqKlQkfwx4lGuLKAeVRYmxcdr+Js+9PE3rzknD96qpTGuj7lyYNiOSle4OmaPWZQzDAeN4duCDdNKSkBUlMYcddOo8kbyXuwh9t8pdsXafocbhTDEjoL+BN0NQzEYxT2yQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(4326008)(8676002)(54906003)(478600001)(4001150100001)(6506007)(316002)(8936002)(2906002)(966005)(86362001)(44832011)(5660300002)(36756003)(2616005)(66476007)(186003)(83380400001)(26005)(66446008)(64756008)(99936003)(66556008)(66946007)(6486002)(6512007)(6916009)(76116006)(71200400001)(66616009)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 2FSrYHZtx0TNdhuFvIWsm1GG/e9ehMs/ukq0H8yvEFetJhsV9CDMQggAuto+pDxib/XkXQlT6eXw5uGzqtc3B9yJaf4gdYxXrQIZrqQis5iajTKI/2yQj17cwdIOzvQAyiB5szv/3ujCZoIl/KmJCxtsuT7c2G7EGmRkbqOXVtdQVdsvXovIgn8xxTRBgYOBJ1P4OtiG7q0XzMewy3p64D9uljEPTsa5Vr09Bxgjnzfv1/omycHRLmgBuhGNKm9ilAuZRXPKGb2B5kMe47r+Kdr+IhtnBnoPEz6yFPNbWf8Bsl0f8fHVDGITKCiMhi9NOW1eZ9wMEc5zSDAsIgT0G1TLLljHZK8jL6yiKnhWW5aFS6uamBjA2t4LnlUemhZ1Iwi/AwjkIP8dQkFgFoSj33cpoGtMT4TdOmnL2STi2pVFWpC06NZa1h6xHhCP7PssNxQkp/RXtZ8U4H4GRJccFaEHU9vkMUiiKacf1/LatQfhYZBvHmSYS4ySeVZ/XRbzrDi4kJrGduJXOGPjJy3pSNqLsfIrBNqgVNqbIYzNDXAxlp2LpoRtN7uj3irqv+3Kgs0aFJsooJnhmo4x/oW4qEfabB0Ko/axOWeDmPYwrhesnIIvpmV3wFXzHYyaxK4SMHW1zwjdRC69q7OHZXGMN8NSckL89qU8OoG+DpFgxVu0gTnI5wMjTOkDVJ/feJeTrcI72aiHFn1nljCgpC9jnv9t7Q6MoxIrbaVwBTX2okTl7xW6pNUCQqT4Ks/YhJZm0aKrzC0LZv/SElUlMfDUiee8L5/cPx3p/jwxr5Imm4ttXILI1JuymqlCEzygwOcgqMcCFp76+1An+x0lNm4GbZ7lH557a6U8tf9ajcapvxo5qIScNTy45JcwNrCaM3VKcy0hTL2WNKk8iWTfi2GhsqA+aVE0fsi+L4IjYnCYQRaE3iGMzuOrMi72NB51uYl7HFHPBRXMTEJTYFn4qltXJkK/IFq6WarQ+ynVMHDp4CTw9j3WYMXUtww9blW9I4EZ
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-XO8y/ChwXvGqCZgWRshH"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1125edcb-1c00-4782-80a6-08d8a0d3572a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 08:28:03.3182 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nTFrzHSB0RnmwcGsV24XRApoaC3JZTH366oxCtPbUB4BWOAHPxbAqoPa1QRlWpTAhUl4f2dGLRvMdJC+wxwpXmD/WfX/CrnlE4VhNMVSxeA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3772
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/QPEHHAB4m9GR8PPFqfzdXFAR95Y>
Subject: Re: [I2nsf] Magnus Westerlund's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS)
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: Tue, 15 Dec 2020 08:28:09 -0000

Hi,

Yes, I think the proposed way forward is appropriat and that this has been
concluded. I will clear when an updated document is available.

Cheers

Magnus

On Mon, 2020-12-14 at 17:41 +0100, Rafa Marin-Lopez wrote:
> Dear Magnus:
> 
> Just to check we came to a conclusion to this discussion. Please see below.
> 
> > El 1 dic 2020, a las 18:28, Magnus Westerlund <
> > magnus.westerlund=40ericsson.com@dmarc.ietf.org> escribió:
> > 
> > Hi,
> > 
> > See inline. 
> > 
> > On Tue, 2020-12-01 at 16:44 +0100, Rafa Marin-Lopez wrote:
> > > Dear Magnus:
> > > 
> > > Please see our comments inline:
> > > 
> > > > El 1 dic 2020, a las 14:56, Magnus Westerlund <
> > > > magnus.westerlund@ericsson.com> escribió:
> > > > 
> > > > Hi,
> > > > 
> > > > Please see inline. 
> > > > 
> > > > On Tue, 2020-12-01 at 13:46 +0100, Rafa Marin-Lopez wrote:
> > > > > Dear Magnus:
> > > > > 
> > > > > > El 27 nov 2020, a las 9:56, Magnus Westerlund <
> > > > > > magnus.westerlund@ericsson.com> escribió:
> > > > > > 
> > > > > > So as long as the option is to turn on "Normal Mode" for tunnel
> > > > > > processing of the ECN bits or not then you can disregard the whole
> > > > > > thing
> > > > > > about
> > > > > > RFC 8311. The applications that will use alternative behaviors for
> > > > > > ECN
> > > > > > will
> > > > > > have
> > > > > > to know that the consumer understand the semantics. So in this case
> > > > > > as
> > > > > > the
> > > > > > IPSec
> > > > > > tunnel only copies the bits back and forth no additional action is
> > > > > > needed. 
> > > > > 
> > > > > [Authors] We have a comment about this and regarding RFC 6040. As we
> > > > > mentioned
> > > > > in our previous e-mail, the RFC 6040 states:
> > > > > 
> > > > > "Modes:  RFC 4301 tunnel endpoints do not need modes and are not
> > > > > updated by the modes in the present specification. Effectively,
> > > > > an RFC 4301 IPsec ingress solely uses the REQUIRED normal mode of
> > > > > encapsulation, which is unchanged from RFC 4301 encapsulation. 
> > > > > It will never need the OPTIONAL compatibility mode as explained 
> > > > > in Section 4.3”.
> > > > > 
> > > > > Therefore an IPsec tunnel ALWAYS copy the ecn bits from the inner to
> > > > > the
> > > > > outer
> > > > > header (normal mode). We do not see any other alternative.
> > > > > 
> > > > > In consequence, after this discussion, our proposal would be just to
> > > > > remove
> > > > > the leaf ecn since, according to this text, there is a single option:
> > > > > copy.
> > > > > 
> > > > > Does it sound reasonable?
> > > > 
> > > > I might be missing something here but I don't think removing the leaf is
> > > > the
> > > > correct option unless you plan to mandate ECN processing by both
> > > > endpoints
> > > > to be
> > > > always on.
> > > 
> > > [Authors] We think we may also be missing something. Your sentence “to
> > > mandate
> > > ECN processing by both endpoints to be always on.” is the key. It turns
> > > out
> > > that (under our interpretation of) RFC 6040 - section 4.3 mentions
> > > precisely
> > > that that you have ECN in both endpoints for IPsec tunnels: 
> > > 
> > > "Therefore, both endpoints of an RFC 4301
> > > tunnel can be sure that the other end is compatible with 
> > > RFC 4301, because the tunnel is only formed after IKEv2 key
> > > management has completed, at which point both ends will be
> > > compliant with RFC 4301 by definition.  Therefore an IPsec tunnel
> > > ingress does not need compatibility mode, as it will never
> > > interact with legacy ECN tunnels.  To comply with the present
> > > specification, it only needs to implement the required normal
> > > mode, which is identical to the pre-existing RFC 4301 behaviour.
> > > 
> > > Moreover, related with this,  Section 2.24 Explicit Congestion
> > > Notification
> > > (ECN) in RFC 7296 mentions
> > > 
> > > 2.24.  Explicit Congestion Notification (ECN)
> > > 
> > > When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
> > >   ECN usage is not appropriate for the outer IP headers because tunnel
> > >   decapsulation processing discards ECN congestion indications to the
> > >   detriment of the network.  ECN support for IPsec tunnels for
> > >   IKEv1-based IPsec requires multiple operating modes and negotiation
> > >   (see [ECN]).  IKEv2 simplifies this situation by requiring that ECN
> > >   be usable in the outer IP headers of all tunnel mode Child SAs
> > >   created by IKEv2.  Specifically, tunnel encapsulators and
> > >   decapsulators for all tunnel mode SAs created by IKEv2 MUST support
> > >   the ECN full-functionality option for tunnels specified in [ECN] and
> > >   MUST implement the tunnel encapsulation and decapsulation processing
> > >   specified in [IPSECARCH] to prevent discarding of ECN congestion
> > >   indications.
> > > 
> > > 
> > > [Authors] Therefore , it seems from both texts above, that it is assumed
> > > that
> > > ECN would be always on for the IPsec tunnels. Are we missing something
> > > here?
> > 
> > It is great that support is mandated. I think I am making a difference
> > between
> > supporting and using. But it looks like this would work without any
> > configuration, thus you might be correct that this is not a necessary and it
> > can
> > be removed.
> 
> [Authors] Ok, good. So let’s remove it, then.


Yes


> >  
> > 
> > 
> > 
> > > > So I think there is a binary configuraiton option between enabling
> > > > the RFC6040 processing between inner and outer headers, and to not have
> > > > ECN
> > > > enabled at all, i.e. set ECN bits to Not-ECN on the outer encapsulation.
> > > > Copying
> > > > the bits on the ingress and not have the egress do the corresponding
> > > > operation
> > > > have some negative consequences to fairness. 
> > > 
> > > [Authors] Our doubt is that, according to the text pasted above, what
> > > would be
> > > the case where we have to set ECN bits to Not-ECN if the assumption from
> > > these
> > > two RFCs is that both endpoints are ECN capable? Are we missing something
> > > regarding to IPsec tunnels according to RFC 6040?
> > > 
> > > In the IKE less case, the I2NSF Controller can assume (and know) that
> > > these
> > > NSFs have ECN full-functionality as happens with IKEv2. In any case, if
> > > you
> > > foresee a case where one of the endpoints is not ECN, adding the leaf ecn
> > > is
> > > not major problem at all. 
> > > 
> > > What do you think?
> > 
> > I think that requires domain knowledge of the IPSec endpoints to know if
> > they
> > usually are fully compliant or if this needs configuration anyway. I don't
> > know
> > this. So this I think is a consideration if one can remove the leaf or nto.
> 
> [Authors] Our point was to highlight that both endpoints have ECN full-
> funcionality as per section 4.3 in RFC 6040. In fact, we only consider that
> NSFs are complaint with RFC 4301. In conclusion, it is safe to remove the
> leaf. Therefore, there is no choice for the I2NSF Controller to configure ECN
> support since the NSFs are assumed to be ECN full-functional. After this
> discussion, we believe it is important to mention this in the I-D in section 6
> as follows:
> 
> "It is assumed that NSFs involved in this document provide ECN full-
> functionality to prevent discarding of ECN congestion indications." 
> 
> We believe this clarifies the point. What do you think?

Yes, I am fine with that. 

> 
> > 
> > > > Also, I cringe a bit when you says copy. Becasue that what 6040 + 4301
> > > > defines
> > > > in not strictly copying. That is why it is important to have the right
> > > > formulation and not call it copy. 
> > > 
> > > [Authors] We understand. Does “setting” sound better?
> > 
> > "Setting it per RFC 6040" is more to my liking. 
> 
> [Authors] Noted.
> 
> Thank you very much.
> > Cheers
> > 
> > Magnus
> > _______________________________________________
> > I2nsf mailing list
> > I2nsf@ietf.org
> > 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 e-mail: rafa@um.es
> -------------------------------------------------------
>