Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Thu, 05 November 2020 14:29 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567D83A125D; Thu, 5 Nov 2020 06:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=H4NtFM8x; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Y+iaHjBE
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 kZDQLqaOuX7U; Thu, 5 Nov 2020 06:29:37 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CB43A1234; Thu, 5 Nov 2020 06:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22715; q=dns/txt; s=iport; t=1604586576; x=1605796176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=U/9GILUhkSbjgiafYFM6Sq+foiQJAt0wLyYi3LlBU0I=; b=H4NtFM8xyKst7zO1iYkHOiX9653b4yPBO5DZ5Vul7AgkmMRwOHAc6L8l 5/xgjLrbv55RuejSVw2Fk9VDrNe9NQX8a1hnu8i/magryTnJnIGSdDl7d U7sBJOwX6YRFi96KMTdq/jNP8/YSt+Sxd+ETdvE9m4ZTThbQzXB4jt0Fl o=;
X-IPAS-Result: A0AbIgAIC6Rf/5FdJa1iHAEBATwBAQQEAQECAQEHAQGBZoEhGwISKSgHcFkvLoQ9g0kDjVKBBIkPiX2Eb4JTA1QLAQEBDQEBHw4CBAEBhEoCF4F2AiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBBBIRHQEBLgkBDwIBCA4DAwECKwICAh8RGgMIAgQOBSKDBAGBfk0DLgGlNQKBO4hodoEygwQBAQWFCA0LghAJgTYCAQGCcINxgimDA4ErG4FBP4ERJxyCGjU+gX8cgXpJHoJZM4Isih+GGTaCOAE9hxqcJC9UCoJtlXaFEwMfgxiKEoVMjneEXZxWkl4CBAIEBQIOAQEFgWsjgVdwFRpLAYI+CUcXAg2OVm4BCHqBSYpYdDgCBgEJAQEDCQF7iwaBZ18BAQ
IronPort-PHdr: 9a23:xAHLDhMnAH+3DMvxMS8l6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvK093kPITcPS96EMh+nXtvXmXmoNqdaEvWsZeZNBHxkClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKnMFgTEdqtL1HXq2e5uDgVHBi3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,453,1596499200"; d="scan'208,217";a="572698960"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2020 14:29:35 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A5ETZrD004713 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2020 14:29:35 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Nov 2020 08:29:34 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Nov 2020 08:29:34 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 5 Nov 2020 08:29:34 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SoSHf/QOVC+Ay96RwYQ7sC2aO4lWoIOj+vjqe4tuDOKsUecg2wwWU140+4b/aribOG3uKJi/xuZ88KoUq0a3b12SqxcGqwk0DLmGIgMcGIuWLUiJ3Q/4H+VuvH/wnzLkQpA5AVl3dPcaEgL/bNV2r+svhFHUyrJlRa5qqY05jEdso6jxbVH0AgnFIL6QjVG6pBqIMl7j6S0GSvEkfXW/+yUGTgWizcXdGKwg7Eaa9fFhCh4Lj72h4wncDjyQ3S09SMcO9226cSoMlQQouy9wQvrsMHmLl3cQEJ21CF2pQC5cwpNib+7FKBnB3EazO8OCZ/eeQdTfnBzjTUmJLxpBsQ==
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=U/9GILUhkSbjgiafYFM6Sq+foiQJAt0wLyYi3LlBU0I=; b=fpoFF6NoZZ6DG5UF1kIE3e8sCymXdx8xJNtsPufGXCps7yFRJXFRosUa7rAzl+XUKZFpGJzbzOi/VFwIpWB1FIk6F28mDraLDPiHGbbI35p/B2CMxV+cH073CoEn7aBqWy7gccbtHMg6QOJa8Qp/Njza08fHZebZ1Za8qA/qsDvFKhM7L2e20EZ0F6ormwul7d1i0WKTEtc4vdTfo5sBFoby/r7aQb0PMHN+8SPhZ3E+3Sx1jdnula8he7u/clmxQ2+PM9rIHmJfLtaOSVnRcuxxzs8+OB8Y5K1HyU1Snk7SLTWZlpPfgheQKV7ZyLOtJAsv4WVL8astF9IqZkbBpQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U/9GILUhkSbjgiafYFM6Sq+foiQJAt0wLyYi3LlBU0I=; b=Y+iaHjBEoKnhfZzgy1HbqKxKxYLSEIo3m8P56L/F4XomQT6FqUIUMq+sG/2hI0WImZOovT8uC4HWuVWc5cetAnLnm9TAkMLM7lLrcl3f8H/J3CxQildxoXILhZ9Ue/o+6fDy7YXlef0iiugIlXMxWjL/tfq2KdSdAXYJVFsWJO8=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4998.namprd11.prod.outlook.com (2603:10b6:510:32::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Thu, 5 Nov 2020 14:29:31 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 14:29:31 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Christoph Loibl <c@tix.at>
CC: The IESG <iesg@ietf.org>, "draft-ietf-idr-flow-spec-v6@ietf.org" <draft-ietf-idr-flow-spec-v6@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Jie Dong <jie.dong@huawei.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
Thread-Index: AQHWsn0LOOyqG/kvJkG8Nzevm9AKPKm4A4iAgAGoZgA=
Date: Thu, 05 Nov 2020 14:29:30 +0000
Message-ID: <0C643718-C749-41B1-B32C-58EE03468146@cisco.com>
References: <160447530519.19838.7495034603697648657@ietfa.amsl.com> <C50C3710-8B0E-4B0D-B81A-533921E23D7C@tix.at>
In-Reply-To: <C50C3710-8B0E-4B0D-B81A-533921E23D7C@tix.at>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
authentication-results: tix.at; dkim=none (message not signed) header.d=none;tix.at; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:cd9a:7e0a:28a7:cddb]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8445952e-9411-4f6a-3493-08d881973582
x-ms-traffictypediagnostic: PH0PR11MB4998:
x-microsoft-antispam-prvs: <PH0PR11MB49984C3E3EAEA46D5B3343ABA9EE0@PH0PR11MB4998.namprd11.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: GB4JGzMBTMPADgYzySd8OKIi5UoAQO+BQf1z4cdqlucHWeanTbRGlxyD4ta0fcbCOcjRyAAubN02LJn+tgIqlt1uXy6YdGhAk3/dbV2lQNwftgoSozVSlYpjkKLNxf84D0FQIX3seO/622UUJ2N9OAaTc+5GczrmZVE02vkjs+PuHxAwjncgLVXAy8anahft0gIyRnaJ6gYpVeP9TTr87LDQgSYp52Y/BlFYGnTzweqGXz3iBxI16nuhjhb+Xfo/ryUfaQk9JOI/32MnvADPqmnN1UnjD7UNKehvH0rNkfPJy+Uk7qO+hyLpnSXI6CMxzCjd7b7bpbHktUlHMYerJ8oo/3uH6C78qPQ9KHBgB+lbohh2k9yx4EQ2St2OBuib4Y4qdZySY1xBmbd5Am9oF9xO+hotGJ6pykN1gGAfJfNLUla7U+w1jQ4GqqQt1vUmkrgzcCcazryg24+ELwp3QnlM3OXfzC7NBG6fxzx19Ok=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(39860400002)(366004)(6916009)(36756003)(166002)(4326008)(76116006)(5660300002)(6506007)(53546011)(478600001)(83080400002)(316002)(224303003)(33656002)(8936002)(66574015)(86362001)(66476007)(64756008)(2906002)(54906003)(966005)(2616005)(66946007)(91956017)(83380400001)(6486002)(66446008)(6512007)(186003)(66556008)(71200400001)(781001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: iEFnYXWKz+t/7kvHINctqQOG02cpwapOAqS0tayI9Ww1OY+i+i6DWfylDxd/dJoqAVkWvo9UkIE9vFr+xmXbFWfJw6exlnTeWOVs5Mwxg1WHesZ8WOl7RylPIlNGVxQ6rrquNS/fsNt8wjCX4YphYK3LSjMJV0kmqMvbXLoIEsjPE8h3jxKOJNrfshq1C+tEzlGZzScVF9A2hW6NjTo5Qxb7WztlvgGh8YgUMmu6N8ORlS20qtsHZDj4yCn54cXdqdMXv1IhbyKHZsnLw0Z+F7Fyavj5tTVgpTm+aPcPi6qjs0KYjtxh/hcgbJ5XYlSS2zMqMmMLZYVeUpnGHreA04DFxUJ4u/jv9O4OlLCIToCf5cW3LAyfxYau8dh5BEmpAJAT6DWKnLbWOUjIKNwQORrQpdpJmS7r+67fNHzVOAZ6W9jv18t2lG7gqjNkejkpTA1vCYqlR27gx8digPhJ60jZzd/Y/hsZpgK/DQNbx/k3kDs4RmF9yU/JcgFTYnklLrPS47QRPIYrR/rlXGVKUc735XMsIo//vT+c6FTZa3llsV4dRxyjAkKs8k38O9WITbdniPmnm3xwimJGySMeSu14kiIul4oUEWrYKJEqVCwOY2eQRq3INCBckiL7wFmDi5EQAYPMWzA4m6IMmhUPR9zFbOTlp7PdA6o/jd+j41gs+eHfQf/DrLpw4fhxTwwwqJg3DwVlMqpqgQ9L4Ok4AQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_0C643718C74941B1B32C58EE03468146ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8445952e-9411-4f6a-3493-08d881973582
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 14:29:30.9431 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: k2Q6JsMz1z5ZRAV5pRreHN0WAnirMSZTW2Ewfe+bzUgifb4tvnTrAe79m6TBPRswTqXFR34QiJcvyV6Hunna7g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4998
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/A2ugvxfI34H1N-G6InPA_v-c2Nw>
Subject: Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 14:29:40 -0000

Christoph and Robert,

I guess that we all agree that the IPv6 extension header chain is a special “feature” of IPv6 that does not help simplification and is not easy to handle. Nevertheless, I like extension headers as they allow for extensibility of IPv6.

What really puzzles me is that the document assumes that the extension header chain can be parsed until the upper-layer protocol (that is really tough in hardware) but is unable to specify a flow based on the Next-Header field of the IPv6 header (that is trivial from my naïve point of view). So, I would assume if DDoS mitigation devices can do the most complex one (= filter on upper layer) they should also be able to do the simplest one (= filter on Next-Header) or even the medium one (= presence of a specific extension header in the chain).

Again , I appreciate that this is a complex issue but I cannot understand the reasoning of the WG.

Else, look for EV> in the text

Thank you BTW for your quick and detailed reply

Regards

-éric


From: Christoph Loibl <c@tix.at>
Date: Wednesday, 4 November 2020 at 15:11
To: Eric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-idr-flow-spec-v6@ietf.org" <draft-ietf-idr-flow-spec-v6@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Jie Dong <jie.dong@huawei.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Hi Éric,

Thanks for your review of the document. Please see my comments inline, I think this should clear your DISCUSS. I also attached a updated document that contains changes resulting from your comments.

Since the draft submission is closed now I will ask Alvaro to publish the changed document today.

Cheers Christoph


> ## DISCUSS:
>
> I am puzzled by the absence of a flow spec for the first Next-Header being a
> specific value and by the absence of a flowspec for the occurence of any
> extension header in the extension header chain. Extension headers are an
> important difference compared to IPv4 and could be 'nasty' as well (e.g.,
> hop-by-hop header). Why was this not considered by the authors ? Or is there
> another document in the WG to address this issue ?
>

We discussed matching on extension headers in general. But this is a little bit of a moving target. It also seemed to have very limited advantage to match on the next-header-id values only (except for the upper-layer protocol). The flexibility to also match on the "content"/"encoding" of extension headers is not the scope of this document. Flowspec in general in its current specification (as extension of rfc5575bis) is not very extensible. The match for every new extension-header and its properties would most probably introduce a new FS component (something that is not easily possible). To overcome such limitations, there are discussions in IDR with the working title "FS 2.0" that should overcome the extensibility problem.

> ## COMMENT:
> == COMMENTS ==
>
> -- Section 3.1 --
> Smart idea to have an offset but I wonder whether "Offset < Length < 129" is
> true... Esp. with some IPv6 addresses with an embedded IPv4 address (32 bit) at
> offset 96. Isn't "Offset + Length <= 128" better ?
>

No, the Length is not the number of bits to match. The number of bits to match is Length - Offset. Length is the bitnumber in the address where matching ends.

EV> indeed, it looks like I read it too fast and assumed that it was like the substring function in some programming language. My bad obviously, thank you for correcting me. Perhaps worth adding an example before the one in section 3.8.1? I do not remember whether the 5575-bis document has a similar concept (if so, then no need to provide an example even).

> -- Section 3.3 --
> How is the upper-layer defined here? Basically, how a node can determine
> whether it is an extension header or an upper-layer header? While I agree that
> there are not too many new upper-layer protocols being specified, I would
> prefer to have a definition of "upper-layer" here either by listing (or
> referring to a IANA registry) all existing extension headers (then all 'next
> header' not being 'extension header' are by default 'upper layer') or
> vice-versa.

This is the term used in RFC8200 for the "last" next-header. It also explains how to detect the upper-layer protocol.
EV> indeed the reference to RFC 8200 (that is already in the doc) is enough. But, now, I have another question: how will the ‘No Next Header’ be specified or processed by the Flow Spec ?

>
> -- Section 3.6 --
> Just curious ;-) Why is bit 7 not used in this encoding ?

The reason for this is to keep the flags aligned with the Fragementation-Flags in rfc5575bis (IPv4). rfc5575bis has matching on DF bit there.

EV> Good idea indeed

>
> -- Section 3.7 --
> I share Ben Kaduk's concern about the encoding of the flow label in less than
> 20 bits.

I answerd this question in response on Benjamins DISCUSS.

EV> and your reply to Ben is fine for me

> == NITS ==
>
> -- Section 3.1 (and possibly others) --
> Sometimes the field 'length' is all lower case and sometimes it is capitalized.
>

I updated the document accordingly

> -- Section 3.8.2 (and possibly others) --
> Please use RFC 5952 to write IPv6 addresses.

As of Benjamin's comments I also added a paragraph to explain the notation, which is needed to repress the range for the pattermatching.

EV> actually, my comment was not about the /64-104 notation but rather “::1234:5678:9A00:0” that should be written as “::1234:5678:9a00:0” :-) (lower case and no trailing 0) and “2001:db8::/32” (also lowercase)

--
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at