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, 07 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
- RFC6434bis open issue - IPv6 EH protection Tim Chown
- Re: RFC6434bis open issue - IPv6 EH protection Fernando Gont
- Re: RFC6434bis open issue - IPv6 EH protection Brian E Carpenter