RFC6434bis open issue - IPv6 EH protection

Tim Chown <Tim.Chown@jisc.ac.uk> Tue, 07 November 2017 11:59 UTC

Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0B13FE48 for <ipv6@ietfa.amsl.com>; Tue, 7 Nov 2017 03:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level:
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=jisc.ac.uk
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 aRTxicZ0GCQp for <ipv6@ietfa.amsl.com>; Tue, 7 Nov 2017 03:59:27 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E7E13FE47 for <ipv6@ietf.org>; Tue, 7 Nov 2017 03:59:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510055965; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=oQEqY/2v35gJk92bN9ypz8V+KMzUNiRYeffOn1TyF9w=; b=cqJ3a/ufbNambbz6EwghEraFnGtVidce+s4yCQkjskhpF+eUm7qSIbgLhVh6W/NLc6UHp3el3Ct6ILuGUWFIcb3regyShuL5GUxS6KvNIf6cUwQbbmh+0m9IPvtW//fX8kcr7OGMYeKmEn95lkDBcW14MjUOU1sDwEhqvNVd64s=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0175.outbound.protection.outlook.com [213.199.180.175]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-92-OqhvgJ73PmeXZN-VhR48XA-1; Tue, 07 Nov 2017 11:59:13 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Tue, 7 Nov 2017 11:59:12 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 11:59:12 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: 6man WG <ipv6@ietf.org>
Subject: RFC6434bis open issue - IPv6 EH protection
Thread-Topic: RFC6434bis open issue - IPv6 EH protection
Thread-Index: AQHTV7/TRDB8jV2rFUefxjYBgVVZEA==
Date: Tue, 7 Nov 2017 11:59:12 +0000
Message-ID: <4E35047B-BB4A-4ED2-BB1D-535EC54C6502@jisc.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:edda:61ec:7313:b139]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:oN5xBU8iSg6/f3oGMJf3WJAqvsQdwfrOBv7CwxgasKKS0OSEpsyAVicLf2jRRtCXORcJlVqIqBbrZY1ESPkuzchnWtBs2uX26Kd2lfkcfQCfgE5oUr9uQfTD9WKYS5p2buwT59efBFTdztebP4yASYYXo+VKUROkWzMmVAks3+o=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 62bf0f57-bca4-4871-eebc-08d525d6f61a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139;
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <AM3PR07MB1139E0055D4DB87411957655D6510@AM3PR07MB1139.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231021)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139;
x-forefront-prvs: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(57306001)(478600001)(50986999)(6506006)(6486002)(42882006)(6916009)(6436002)(316002)(102836003)(99286004)(72206003)(966005)(14454004)(2900100001)(83716003)(86362001)(5250100002)(6116002)(786003)(25786009)(53936002)(68736007)(74482002)(305945005)(7736002)(101416001)(97736004)(50226002)(8676002)(105586002)(36756003)(81156014)(81166006)(2906002)(6306002)(6512007)(8936002)(5660300001)(189998001)(82746002)(3660700001)(33656002)(3280700002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <424EF48344D30544B40662CE802FFD45@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 62bf0f57-bca4-4871-eebc-08d525d6f61a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 11:59:12.4201 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: OqhvgJ73PmeXZN-VhR48XA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jFMJWCRP-LIcabksi2jemr2NUA8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2017 11:59:31 -0000

Hi,

Here is a second open issue in the draft for which the authors would like comments.

In response to previous discussions, Tom Herbert kindly supplied some text on how nodes may protect themselves from excessive EH options.

There are two issues here.
1. Does the text look reasonable?
2. The text is quite long, and is not published elsewhere; is a separate draft more appropriate with just briefer text in 6434bis?

In general, we have minimised new text in 6434bis, and pointed at material published in RFCs elsewhere.

— snip —

5.3.  Protecting a node from excessive EH options

   Per RFC 8200, end hosts are expected to process all extension
   headers, destination options, and hop-by-hop options in a packet.
   Given that the only limit on the number and size of extension headers
   is the MTU, the processing of received packets could be considerable.
   It is also conceivable that a long chain of extension headers might
   be used as a form of denial-of-service attack.  Accordingly, a host
   may place limits on the number and sizes of extension headers and
   options it is willing to process.

   A host MAY limit the number of consecutive PAD1 options in
   destination options or hop-by-hop options to seven.  In this case, if
   the more than seven consecutive PAD1 options are present the the
   packet should be silently discarded.  The rationale is that if
   padding of eight or more bytes is required than the PADN option
   should be used.

   A host MAY limit number of bytes in a PADN option to be less than
   eight.  In such a case, if a PADN option is present that has a length
   greater than seven then the packet should be silently discarded.  The
   rationale for this guideline is that the purpose of padding is for
   alignment and eight bytes is the maximum alignment used in IPv6.

   A host MAY disallow unknown options in destination options or hob-by-
   hop options.  This should be configurable where the default is to
   accept unknown options and process them per RFC2460.  If a packet
   with unknown options is received and the host is configured to
   disallow them, then the packet should be silently discarded.

   A host MAY impose a limit on the maximum number of non-padding
   options allowed in a destination options and hop-by-hop extension
   headers.  If this feature is supported the maximum number should be
   configurable and the default value SHOULD be set to eight.  The
   limits for destination options and hop-by-hop options may be
   separately configurable.  If a packet is received and the number of
   destination or hop-by-hop optines exceeds the limit, then the packet
   should be silently discarded.

   A host MAY impose a limit on the maximum length of destination
   options or hop-by-hop options extension header.  This value should be
   configurable and the default is to accept options of any length.  If
   a packet is received and the length of destination or hop-by-hop
   options extension header exceeds the length limit, then the packet
   should be silently discarded.

— snip —

For the full document, see
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-5.3

Tim