From nobody Mon Nov 19 08:31:00 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEF71292F1; Mon, 19 Nov 2018 08:30:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk CC: =?utf-8?q?=C3=89ric_Vyncke?= , warren@kumari.net, opsec@ietf.org, draft-ietf-opsec-ipv6-eh-filtering@ietf.org, evyncke@cisco.com, opsec-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 08:30:59 -0800 Archived-At: Subject: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 16:31:00 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-12-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note: The WGLC was sent to OpSec, 6MAN and V6OPS to get wider review: https://mailarchive.ietf.org/arch/msg/v6ops/MvzKKTYCDtWVtlIGxb6OfQlUats Abstract It is common operator practice to mitigate security risks by enforcing appropriate packet filtering. This document analyzes both the general security implications of IPv6 Extension Headers and the specific security implications of each Extension Header and Option type. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic *not* directed to them, for those cases in which such filtering is deemed as necessary. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 20 08:27:34 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B112F1AC; Tue, 20 Nov 2018 08:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VKEf4Fdv70k5; Tue, 20 Nov 2018 08:27:09 -0800 (PST) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC15812008A; Tue, 20 Nov 2018 08:27:09 -0800 (PST) Received: by mail-qk1-x742.google.com with SMTP id m5so3156686qka.9; Tue, 20 Nov 2018 08:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VvnzECN9hOH7wIN7pnjcUE/WUg8zQZf9H1jeqPkZ7Zs=; b=E/mcR3xT4A1HPGHWdGWyk7nAApCyluN141fCurQwxFCoA2UQpWTW93uYYQ/FSOj+mU C25Qd6AaTlvVmNH2vSPDSHAujo//QxSx9Ql1pdM1PhjFQ/DgmsUImfnIIGpNNqATf2mH scXzA0HNOgyaMTsKiuRSsCZKbAJ4VevWFj8oO/nT4Y7Jl1OzA50wtOUhCK8erjlkrd16 +TZU34HS0Fg0Re727jZiKSSzQGCo3M4CkMHXBZWIZWXryuYLRMfNwp+pSL1c6UGgYO6K WO+LB8ykWbT20hgbSWQyILv3O6gecsllxUTactVlhKg8z4anZOMOxKfLlzHoUrT1xDD3 +5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VvnzECN9hOH7wIN7pnjcUE/WUg8zQZf9H1jeqPkZ7Zs=; b=Hv9CKm0yR4GaD386fTb7Bgx5v5hQvc1mxsrDKziaRe0Ybvv6Q+ruJSymPGi8BcfbF0 /OiTjyo4Ss+qbMDcpTJsV700IEL+sbY7nRLsg3K54RIbX4C6kAsr9ficPNjtFEcJCf0u CQ8fcjBGjc+zlxP/XtnNrv6qHkdeMp2khTxUzD9XI/T9rbnbplPh92AuQN8RpwqWmuik DypOfJlIV95Sx1pYwp5nWsUtwV+TfbVxl1AhbhLA7S9lbk7akc2Yyx3m4H25kSWQP6/X 0jZ85YIqqiFs8lrKBEM8kCAPFpt+RWiCHWrOCp72Q0lyy9AaBE5Hg5guuWic9t2DU5ec RqnA== X-Gm-Message-State: AA+aEWbJ0lVwGrjjYBmBgOIy9FFAftOhzAbrS+Y5N0y3MGeFjWXI5rk8 OUjsyjicEe/OSzD6OopkUnvqiuSd X-Google-Smtp-Source: AFSGD/U8wS82uAm/KpRKkI4B92mUfnIyOpX8PAh2bCupJVurRXVO10mXCwIZNwiLLIeoWt/zFBcufw== X-Received: by 2002:a37:c3c3:: with SMTP id r64mr2365694qkl.70.1542731228627; Tue, 20 Nov 2018 08:27:08 -0800 (PST) Received: from [10.30.20.5] (pool-72-83-171-117.washdc.east.verizon.net. [72.83.171.117]) by smtp.gmail.com with ESMTPSA id c49sm10038701qtc.94.2018.11.20.08.27.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 08:27:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "R. Atkinson" In-Reply-To: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 11:27:07 -0500 Cc: opsec@ietf.org, iesg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0EB81EE5-C8C7-4B6A-9EF4-90B5049E5F88@gmail.com> References: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 16:27:12 -0000 All, I believe this document needs a few very important,=20 but hopefully not controversial edits before going ahead. =20 (I had thought these concerns had been worked out previously,=20 per email exchanges on the opsec list (and privately) circa=20 6 July 2018 with Fernando Gont. So I had expected to see a=20 -07 revision appear with the agreed fixes, but maybe something=20 fell through the cracks by accident. :-) Comments below are organized by Document Section. I am open to wordsmithing. Candidate new text has been provided for review (and ideally - to be adopted into a -07 revision). DOCUMENT TITLE: Recommendations on the Filtering of IPv6 Packets=20 Containing IP Extension Headers REQUEST: Could we somehow edit the title to make clear that these recommendations are specifically focused on =E2=80=9CTransit Routers=E2=80=9D ? REASONS: The current document title is slightly misleading. It implies the = recommendations=20 are entirely general, but actually (per the -06 Abstract) they are = "advice on the=20 filtering of such IPv6 packets at transit routers for traffic *not* = directed to them=E2=80=9D. Advice specific to a Transit Router might or might not apply to other IP = router deployments (e.g. inside an enterprise). SECTION "2.3 Conventions" EXISTING: Such configuration options may include the following possible settings: PROPOSED NEW: Such configuration options SHOULD include the following possible = settings: REASONS: 1) Operational Considerations If an implementer doesn=E2=80=99t include these configuration = capabilities, then operators might be left with interoperability issues and/or with an inability to deploy IETF technologies =E2=80=94 as is described later in = Section 3.4.1.4. 2) Consistency with RFC 7045. SECTION "3.4.1.5. Advice" EXISTING: For legacy nodes, the recommended configuration for the processing of these packets depends on the features and capabilities of the underlying = platform. PROPOSED NEW: For legacy nodes, the recommended configuration for the processing of these packets depends on the features and capabilities of the underlying = platform, the configuration of the platform, and also the deployment environment of the platform. REASONS: Which configuration for processing of HBH options is reasonable depends not only on the features/capabilities, but also how the system has = actually been configured (e.g. it might have enabled some feature that BREAKS proper operation if all packets with HBH headers are dropped) and also what kind of deployment environment it is in. RSVP remains fairly widely deployed and used today, although obviously it is not deployed or used everywhere; RSVP would break. Similarly, in an MLS deployment environment, transmitting packets containing the CALIPSO HBH is critical (more later on this). Section "4.3.9.5. Advice=E2=80=9D EXISTING: Intermediate systems that do not operate in Multi-Level Secure (MLS) networking environments should discard packets that contain this option. PROPOSED: "Recommendations for handling the CALIPSO option depend on the=20 deployment environment, rather than whether an intermediate system=20 happens to be deployed as a transit device (e.g., IPv6 transit = router). Explicit configuration is the only method via which an intermediate = system can know whether or not that particular intermediate system has been=20 deployed within a Multi-Level Secure (MLS) environment. In many cases,=20= ordinary commercial intermediate systems (e.g., IPv6 routers & = firewalls)=20 are the majority of the deployed intermediate systems inside an MLS=20 network environment. =20 For Intermediate systems that DO NOT implement RFC-5570, there=20 SHOULD be a configuration option to EITHER (a) drop packets containing=20= the CALIPSO option OR (b) to ignore the presence of the CALIPSO option and forward the packets normally. In non-MLS environments, such intermediate systems SHOULD have this configuration option set to (a) above. In MLS environments, such intermediate systems SHOULD have this option set to (b) above. The default setting for this = configuration option SHOULD be set to (a) above, because MLS environments are much less common than non-MLS environments. For Intermediate systems that DO implement RFC-5570, there SHOULD=20 be configuration options (a) and (b) from the preceding paragraph and=20= also a third configuration option (c) to process packets containing a CALIPSO option as per RFC-5570. When deployed in non-MLS environments, such intermediate systems SHOULD have this configuration option set to (a) above. When deployed in MLS environments, such intermediate systems SHOULD have this set to (c). The default setting for this configuration option MAY be set to (a) above, because MLS=20 environments are much less common than non-MLS environments. REASONS: In the global public Internet, the CALIPSO HBH option ought not appear, so that is the most common case. However, there are large = multi-continent networks (with multiple AS#s in use) that do carry explicit IP labels = such as CALIPSO. The majority of forwarding devices (routers/gateways) in such networks are ordinary commercial IP routers, while a much smaller number of forwarding devices are specialized products. So careful recommendations will make a big difference in such deployments. In those deployments, either dropping packets with a CALIPSO HBH present or stripping the HBH header entirely could cause severe operational problems =E2=80=94 basically such behaviour would create an=20= avoidable DOS attack. Kindly note that anecdotal reports indicate that=20= some financial firms have deployed the CALIPSO option to provide = separation of information flow between different groups (e.g. Trading Room staff ought not be able to see Merger & Acquisition staff=E2=80=99s activity = to comply with securities regulations in multiple countries/economies). Yours, Ran Atkinson From nobody Wed Nov 21 12:52:07 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336A612F295; Wed, 21 Nov 2018 12:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3a48eIkxf6aJ; Wed, 21 Nov 2018 12:51:57 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3865E127B4C; Wed, 21 Nov 2018 12:51:56 -0800 (PST) Received: from [192.168.3.73] (unknown [186.137.76.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B58A887746; Wed, 21 Nov 2018 21:51:49 +0100 (CET) To: "R. Atkinson" , ietf@ietf.org Cc: opsec@ietf.org, iesg@ietf.org References: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com> <0EB81EE5-C8C7-4B6A-9EF4-90B5049E5F88@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 21 Nov 2018 17:51:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0EB81EE5-C8C7-4B6A-9EF4-90B5049E5F88@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 20:52:01 -0000 Hello, Ran! Thanks so much for your comments! Inline.... On 20/11/18 13:27, R. Atkinson wrote: > All, > > I believe this document needs a few very important, > but hopefully not controversial edits before going ahead. > > (I had thought these concerns had been worked out previously, > per email exchanges on the opsec list (and privately) circa > 6 July 2018 with Fernando Gont. So I had expected to see a > -07 revision appear with the agreed fixes, but maybe something > fell through the cracks by accident. :-) It may have been my failure. If that was the case, please accept my apologies. > Comments below are organized by Document Section. > > I am open to wordsmithing. Candidate new text has been provided > for review (and ideally - to be adopted into a -07 revision). > > > > DOCUMENT TITLE: Recommendations on the Filtering of IPv6 Packets > Containing IP Extension Headers > > REQUEST: > > Could we somehow edit the title to make clear that these recommendations > are specifically focused on “Transit Routers” ? > > REASONS: > > The current document title is slightly misleading. It implies the recommendations > are entirely general, but actually (per the -06 Abstract) they are "advice on the > filtering of such IPv6 packets at transit routers for traffic *not* directed to them”. > Advice specific to a Transit Router might or might not apply to other IP router > deployments (e.g. inside an enterprise). I have no problem with updating the title as suggested. Chairs: May I go ahead and apply it? > SECTION "2.3 Conventions" > > EXISTING: > > Such configuration options may include the following possible settings: > > PROPOSED NEW: > > Such configuration options SHOULD include the following possible settings: Fine for me. > SECTION "3.4.1.5. Advice" > > EXISTING: > > For legacy nodes, the recommended configuration for the processing of > these packets depends on the features and capabilities of the underlying platform. > > PROPOSED NEW: > > For legacy nodes, the recommended configuration for the processing of > these packets depends on the features and capabilities of the underlying platform, > the configuration of the platform, and also the deployment environment > of the platform. > > REASONS: > > Which configuration for processing of HBH options is reasonable depends > not only on the features/capabilities, but also how the system has actually > been configured (e.g. it might have enabled some feature that BREAKS > proper operation if all packets with HBH headers are dropped) and also > what kind of deployment environment it is in. RSVP remains fairly > widely deployed and used today, although obviously it is not deployed > or used everywhere; RSVP would break. Similarly, in an MLS deployment > environment, transmitting packets containing the CALIPSO HBH is > critical (more later on this). Makes sense. Maybe we could add your paragraph on "REASONS" as a parenthetical (indented) note? > Section "4.3.9.5. Advice” > > EXISTING: > Intermediate systems that do not operate in Multi-Level Secure (MLS) > networking environments should discard packets that contain this > option. > > PROPOSED: > > "Recommendations for handling the CALIPSO option depend on the > deployment environment, rather than whether an intermediate system > happens to be deployed as a transit device (e.g., IPv6 transit router). > > Explicit configuration is the only method via which an intermediate system > can know whether or not that particular intermediate system has been > deployed within a Multi-Level Secure (MLS) environment. In many cases, > ordinary commercial intermediate systems (e.g., IPv6 routers & firewalls) > are the majority of the deployed intermediate systems inside an MLS > network environment. > > For Intermediate systems that DO NOT implement RFC-5570, there > SHOULD be a configuration option to EITHER (a) drop packets containing > the CALIPSO option OR (b) to ignore the presence of the CALIPSO option > and forward the packets normally. In non-MLS environments, such > intermediate systems SHOULD have this configuration option set to (a) > above. In MLS environments, such intermediate systems SHOULD > have this option set to (b) above. The default setting for this configuration > option SHOULD be set to (a) above, because MLS environments are much > less common than non-MLS environments. > > For Intermediate systems that DO implement RFC-5570, there SHOULD > be configuration options (a) and (b) from the preceding paragraph and > also a third configuration option (c) to process packets containing > a CALIPSO option as per RFC-5570. When deployed in non-MLS > environments, such intermediate systems SHOULD have this configuration > option set to (a) above. When deployed in MLS environments, such > intermediate systems SHOULD have this set to (c). The default setting > for this configuration option MAY be set to (a) above, because MLS > environments are much less common than non-MLS environments. Also makes sense. Unless somebody screams agains, I will apply the suggested edit. Thanks a lot for your continued help in improving documents! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Nov 22 06:21:37 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBEB130F00; Thu, 22 Nov 2018 06:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GPHLt5TSBKIC; Thu, 22 Nov 2018 06:21:06 -0800 (PST) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDB8130EE3; Thu, 22 Nov 2018 06:21:06 -0800 (PST) Received: by mail-qt1-x843.google.com with SMTP id n21so7572022qtl.6; Thu, 22 Nov 2018 06:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6plAmPFSEoAmWK213tZPZMyDnffzPipQo772jM0r0Yo=; b=AqvBI6E8zrSLv+9FEO6ZfOwZG2HAgOpF0vyDArkpT/tMjrISFAnJ8zpiMEfbh/irvE i/CTiRT8HWtmARirFOyqYnU/cMLY++01p11XPGdo06+Qku6igmWdAHdbrxIlch76uD4O NOrjIAYDzKdwxaTsukeMGT7Ma2EEkCQ1L4wGE7t5xc4jQ/imKPbUjl5ZHgozjW/urqiE KXLcgvOwBj4B+b8CGsUOkOMLY98QBsaCKgH73JlaDdfNuZp7v2Jy/z5ASV/uyrV09eEt BxuknjX2Wu1GJhfu6PAp7nah6eD0oePD7TIIkhd7d5HFeXrbcn6dVtwR1q5TtWqiNEAh Em4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6plAmPFSEoAmWK213tZPZMyDnffzPipQo772jM0r0Yo=; b=ZnO0BWd7U/qD2/ai4fhfIsT7hEpk6EW0KAtfQcWGDjhegxj1sBXouL5cOMJ9PjjAtT GcEID8jrD6zsoBBR4cZEAM9wvWHgzx7MyNed2KJRQl/ROnkz8f8DEharfI7Q2vWLD5NZ 9p/9aIPK99I3tqS5fkI3welp+sqsyRZxyutQ7nqVPNzposCGAA/vQs5s/c89NK3crQgP 5kWBUKGg3K4zhaLhJkDE/80Jqe0khQzMcFKRhlWd5mTSt8Y24itwA94HzPxizv3dxcXZ um/65fFvfOQ75bVYcBt4RS+qt+BEfY/IbNXp0XxJeuCJkLIeBF323jYGkmU/svuFU+fh 7NvQ== X-Gm-Message-State: AGRZ1gJBa88kFyfVt0IaLPRsAyXhkXKtyMHVyWl2Wo4eJUSEKYxCMXT5 VqN7KWdHWsH7Ihr18vpAdFpxFgtK X-Google-Smtp-Source: AFSGD/XfuXPxSoJJlBsKm7pWClWBm5xKJDBo5VGuhg2m/wLK5BfyfitRM0urH0K0MM/RCz9KzOXZeg== X-Received: by 2002:ac8:6bc5:: with SMTP id b5mr10083201qtt.182.1542896465165; Thu, 22 Nov 2018 06:21:05 -0800 (PST) Received: from [10.30.20.5] (pool-72-83-171-117.washdc.east.verizon.net. [72.83.171.117]) by smtp.gmail.com with ESMTPSA id e17sm27970834qte.12.2018.11.22.06.21.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 06:21:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "R. Atkinson" In-Reply-To: Date: Thu, 22 Nov 2018 09:21:03 -0500 Cc: ietf@ietf.org, opsec@ietf.org, iesg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7EA653CF-0DE8-4BCB-89F2-66C467FEB9C9@gmail.com> References: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com> <0EB81EE5-C8C7-4B6A-9EF4-90B5049E5F88@gmail.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 14:21:10 -0000 > On Nov 21, 2018, at 15:51, Fernando Gont = wrote: >=20 > It may have been my failure. If that was the case, please accept my > apologies. We are all busy and I understand that things do sometimes fall through cracks. So long as we can apply the agreed edits now, I=E2=80=99m quite = happy. > SECTION "3.4.1.5. Advice" >>=20 >> EXISTING: >>=20 >> For legacy nodes, the recommended configuration for the processing of >> these packets depends on the features and capabilities of the = underlying platform. >>=20 >> PROPOSED NEW: >>=20 >> For legacy nodes, the recommended configuration for the processing of >> these packets depends on the features and capabilities of the = underlying platform, >> the configuration of the platform, and also the deployment = environment >> of the platform. >>=20 >> REASONS: >>=20 >> Which configuration for processing of HBH options is reasonable = depends >> not only on the features/capabilities, but also how the system has = actually >> been configured (e.g. it might have enabled some feature that BREAKS >> proper operation if all packets with HBH headers are dropped) and = also >> what kind of deployment environment it is in. RSVP remains fairly >> widely deployed and used today, although obviously it is not deployed >> or used everywhere; RSVP would break. Similarly, in an MLS = deployment >> environment, transmitting packets containing the CALIPSO HBH is >> critical (more later on this). >=20 > Makes sense. Maybe we could add your paragraph on "REASONS" as a > parenthetical (indented) note? I=E2=80=99m flexible about editing text. I supplied candidate text = primarily to be clear about what edits I hope to see. Feel free to add it as a note or simply to edit the key points into the candidate text to create suitable new text. > Also makes sense. Unless somebody screams agains, I will apply the > suggested edit. Thank you very much - and a Happy Thanksgiving [1] to all. Yours, Ran [1] A quaint North American holiday, celebrated today in the US and=20 celebrated last month in Canada. From nobody Fri Nov 23 08:20:39 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625F130E44; Fri, 23 Nov 2018 08:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Yz1JuKSSbH8D; Fri, 23 Nov 2018 08:20:18 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629CD130E3E; Fri, 23 Nov 2018 08:20:17 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E8F40123DB2; Fri, 23 Nov 2018 11:20:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=udPBFRPXb30q7hwdZkcPqQdMa4E=; b=x3Mt+x rZg965Qse4vRQUeuXLWZBdbGGyYOpAAmzvnJ/TrZK0H3IkstX635+PohIPTnQ82a V3e/mC/+Xp8bIGPoUkmEg+9sjz47C13cWwiyTC/AIfaHXwbRgodG/sJnWGNB8VIg yciloVuJoJHtv1wCvfyuQVGPvQcOTgDBpmDp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=dlUOOQNKYcAiuhoWDgMqQtW4oZ1xvnD2 yfHwKucg9FuZo4rFAyhNutu4GSRHhZ6JC5OreCle43n7ArqiNEtfyf6bk6dx2dMv VSbLM3++TwZ2YMjk3SeZnLzvbeV7lPsR8uriGylDNv8/g6Pg5WLXwzELfyW5ikh3 5l7qcvIGIsE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id DF162123DB0; Fri, 23 Nov 2018 11:20:15 -0500 (EST) Received: from mail-it1-f178.google.com (unknown [209.85.166.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 3E946123DAE; Fri, 23 Nov 2018 11:20:15 -0500 (EST) Received: by mail-it1-f178.google.com with SMTP id v11so18653268itj.0; Fri, 23 Nov 2018 08:20:15 -0800 (PST) X-Gm-Message-State: AGRZ1gK8HwzmAikdHiTuAok2Gf90f7CMib3PU9+QQonCloG250lfyMJa tbvVjeel4fjSVyXMhlK9ArAwPGyVeccMAcy+fpg= X-Google-Smtp-Source: AFSGD/V3HaMwc5ERra6KaMh7Gw0XDT/IRiUZ48w1dcjFV4TAM0gc2nzaKrTuVe5c2KltkANeLujqj+npG15u+uarseE= X-Received: by 2002:a24:ee83:: with SMTP id b125mr14385678iti.151.1542990014619; Fri, 23 Nov 2018 08:20:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "C. M. Heard" Date: Fri, 23 Nov 2018 08:20:00 -0800 X-Gmail-Original-Message-ID: Message-ID: To: IETF Cc: OPSEC Content-Type: multipart/alternative; boundary="000000000000b6a5e0057b575b6d" X-Pobox-Relay-ID: A906A59A-EF3B-11E8-9CCE-063AD72159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 16:20:22 -0000 --000000000000b6a5e0057b575b6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings, IMHO, this document is NOT READY for publication in its current form. In the introduction it says: The filtering policy typically depends on where in the network such policy is enforced: when the policy is enforced in a transit network, the policy typically follows a "black-list" approach, where only packets with clear negative implications are dropped. On the other hand, when the policy is enforced closer to the destination systems, the policy typically follows a "white-list" approach, where only traffic that is expected to be received is allowed. *The advice in this document is aimed only at transit routers that may need to enforce a filtering policy based on the EHs and IPv6 options a packet may contain, following a "black-list" approach, and hence is likely to be much more permissive that a filtering policy to be employed e.g. at the edge of an enterprise network.* The advice in this document is meant to improve the current situation of the dropping of packets with IPv6 EHs in the Internet [RFC7872 ]. while promoting a ***default deny*** policy with respect to unknown extension headers, experimental extension headers, and experimental options. If every transit router followed that advice, it would be impossible to transmit packets containing these things across the open Internet. It is especially egregious to dispense that advice for unknown extension headers, since that would severely impede deployment of any new extension headers OR any new transport protocols in the open Internet (as the document itself notes, unknown extension headers are indistinguishable from unknown upper-layer protocol headers). This part of the document's advice does nothing to improve the situation reported in RFC 7872; if anything, it makes the situation worse. It certainly will not make the Internet work better. While I would prefer to advise operators of transit routers just to be transparent to everything other than the Hop-by-Hop extensions header, as discussed in the trailing message thread, adapting the more nuanced advice in Section 4.4.5 regarding the handling of unknown options to the cases of unknown EHs and experimental EHs and options would be an acceptable alternative. Specific text to that effect follows below. OLD: 3.5.3 . Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs. However, from security standpoint, a device should discard IPv6 extension headers for which the security implications cannot be determined. We note that this policy is allowed by [RFC7045 ]. 3.5.4 . Operational and Interoperability Impact if Blocked As noted in [RFC7045 ], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry ([IANA-PROTOCOLS ]) should be monitored such that filtering rules are updated as new IPv6 EHs are standardized. We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded. 3.5.5 . Advice Intermediate systems should discard packets containing unknown IPv6 EHs. NEW: 3.5.3 . Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs. 3.5.4 . Operational and Interoperability Impact if Blocked As noted in [RFC7045 ], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry ([IANA-PROTOCOLS ]) should be monitored such that filtering rules are updated as new IPv6 EHs are standardized. We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded. 3.5.5 . Advice Enterprise intermediate systems should discard packets that contain unknown IPv6 EHs. Other intermediate systems should permit packets that contain unknown IPv6 EHs. We note that this policy is allowed by [RFC7045 ]. OLD: 3.4.10.5 . Advice Intermediate systems should discard packets containing these EHs. Only in specific scenarios in which RFC3692 -Style experiments are to be performed should these EHs be permitted. NEW: 3.4.10.5 . Advice Enterprise intermediate systems should discard packets that contain these EHs except in specific environments in which RFC3692 -Style are meant to be performed. Other intermediate systems should permit permit packets with these EHs. OLD: 4.3.18.5 . Advice Intermediate systems should discard packets that contain these options. Only in specific environments where RFC3692 -style experiments are meant to be performed should these options be permitted. NEW: 4.3.18.5 . Advice Enterprise intermediate systems should discard packets that contain these options except in specific enviromments in which RFC3692 -Style are meant to be performed. Other intermediate systems should permit permit packets with these options. NITS: in some places the abbreviations RHT0 and RHT1 are used, while in other places RTH0 and RTH1 are used. The usage should be consistent. IMHO the former abbreviations seem to be more correct. Thanks and regards, Mike Heard ---------- Forwarded message --------- From: C. M. Heard Date: Thu, Oct 5, 2017 at 9:01 PM Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03 To: Ron Bonica Cc: OPSEC , Joe Touch , Bob Hinden < bob.hinden@gmail.com>, Brian E Carpenter Hello Ron, I think that the direction you propose will make this a much better document. Modulo details it would certainly address my concerns. I do however have come comments to make about router self-protection. RFC 6192 is all about a router filtering traffic addressed to itself, i.e., what it should process in its role as a host. A very restrictive "white list" policy ( as outlined in RC 6192) is quite in order there. If there is no need or use for extension headers for traffic destined to the control plane, a very restrictive policy of dropping all packets addressed to the control place hat have extension headers may indeed be in order. It's a very different story, I think, for what a router does to protect itself in its role as forwarding device. There, if it complies with RFC 8200, the Hop-by-Hop Options header is the only one that can hurt it, if it is able to forward at line rate at all. The choice boils down to whether to process all, some, or no packets with Hop-by-Hop options. I think that we need to loudly broadcast that ignoring all HbH Options headers is a legitimate policy for this purpose, but dropping all packets with HbH Options is not. If we can sell this to the world, it may be possible to actually use the HbH options header, and get rid of abominations such as the CONEX Destination Option. The way you characterize the proposed second section sounds right on the money to me. I support your proposed way forward. Thank you. Mike Heard On Thu, Oct 5, 2017 at 11:04 AM, Ron Bonica wrote: > Mike, > > > > I think that you just struck the note that Fernando and I missed. Transit > routers filter extension headers for one of the following reasons: > > > > - To protect themselves (as in RFC 6192) > > - To protect downstream devices > > > > Therefore, the document should contain two clearly marked sections, one > regarding EH filtering policies that protect the transit router and one > regarding EH filtering policies that protect downstream devices. > > > > The first section can: > > > > - Be very short (2 pages max) > > - Be guided largely by RFC 8200 > > - Speak with some degree of authority (while still INFORMATIONAL= ) > > > > The second section should begin with a discussion of the relationship > between the transit router and the downstream devices. Let=E2=80=99s assu= me that > the transit router belongs to an ISP, while downstream devices fall into > the following three classes: > > > > 1) Belong to the ISP > > 2) Belong to parties who want to be protected by the ISP (e.g., its > customers) > > 3) Belong to other parties > > > > Therefore, the transit router MAY discard packets that pose a threat to > the first two classes of downstream device, but MUST NOT discard packets > that are required by the third class of downstream device. > > > > From this point, we formulate a policy that **might** satisfy the above > mentioned requirement. We mark this policy with the following caveats: > > > > - It is a best guess > > - If the policy is too permissive, downstream devices belonging > to the ISP and those who it protects will not receive all of the protecti= on > possible > > - If the policy is too restrictive, downstream devices belonging > to other parties will experience collateral damage > > - One size doesn=E2=80=99t fit all > > > > If we were to rework the document into this shape, would it address your > concerns. > > > > Ron > > > > > > > > *From:* OPSEC [mailto:opsec-bounces@ietf.org] *On Behalf Of *C. M. Heard > *Sent:* Wednesday, October 4, 2017 11:08 PM > *To:* OPSEC > *Subject:* Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03 > > > > On Thu, 5 Oct 2017 11:10:06 +1300, Brian E Carpenter wrote: > > > On 05/10/2017 02:12, Joe Touch wrote: > > > > > >> On 9/29/2017 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > > >>> > > >>> This is to open a two week WGLC > > >>> for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03 > > . > > >>> > > >> > > >> I do not agree with the claims of this document. It "informationally" > > >> advises against support for key IPv6 capabilities and undermines the > > >> extensibility of IPv6 by making recommendations about discarding > > >> currently unassigned codepoints. > > > > > > Here's the problem, Joe. It's a fact of life that many firewalls > > > discard a lot of stuff that they shouldn't - that's why we wrote > > > RFC 7045 - but in the real world, operators blunder around based > > > on folklore and vendors' defaults. We can't change any of that, but > > > we can try to issue sensible advice that, overall, will limit the > > > resulting breakage. IMHO this document, positioned correctly as > > > Informational, will do that: on balance, it makes the world a better > > > place. > > > > I am afraid that I do not agree that the document, in its present form, > > will do that. It says: > > > > The filtering policy typically depends on where in the network such > > policy is enforced: when the policy is enforced in a transit network, > > the policy typically follows a "black-list" approach, where only > > packets with clear negative implications are dropped. On the other > > hand, when the policy is enforced closer to the destination systems, > > the policy typically follows a "white-list" approach, where only > > traffic that is expected to be received is allowed. *The advice in* > > * this document is aimed only at transit routers that may need to* > > * enforce a filtering policy based on the EHs and IPv6 options a packet= * > > * may contain, following a "black-list" approach, and hence is likely* > > * to be much more permissive that a filtering policy to be employed* > > * e.g. at the edge of an enterprise network.* The advice in this > > document is meant to improve the current situation of the dropping of > > packets with IPv6 EHs in the Internet [RFC7872 ]. > > > while at the same time promoting a ***default deny*** policy with > > respect to unrecognized options and unrecognized extension headers. > > That is antithetical to the mission of a ***transit router***, which > > is to get packets transparently from point A to point B. It is > > especially egregious to dispense this advice for unrecognized > > extension headers, since they are indistinguishable from unrecognized > > transport protocols. If these things are blocked by ***transit routers*** > > it becomes impossible to deploy any new options or transport protocols. > > But we already know that, don't we? > > > > If we want to give constructive advice that really will make the > > world a better place, we should: > > > 1.) Advise operators of ***transit routers*** to be transparent to > > everything other than the Hop-by-Hop extensions header, and provide > > detailed advice on what to do (based on the updates in RFC 8200) > > about Hop-by-Hop options. The default should be IGNORE unless there > > is an option you need to process. > > > 2.) Reserve all the detailed filtering advicee for operators of > > firewalls, enterprise routers, and other systems whose mission it > > is to protect the end systems behind them (or to prevent misbehavior > > by said end systems). A default deny for unrecognized stuff is not > > unreasonable for such systems. > > > 3.) Remind implementors of the following requirement from RFC 7045: > > > Forwarding nodes MUST be configurable to allow packets containing > > unrecognised extension headers, but the default configuration MAY > > drop such packets. > > > and add similar advice for options. > > > Thanks and regards, > > > Mike Heard > > --000000000000b6a5e0057b575b6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">

Greetings,


IMHO, this document is NOT R= EADY for publication in its current form.=C2=A0 In

the introduction it says:

=
The filtering pol= icy typically depends on where in the network such policy is enforced: when the policy is enforced in a transit network, the policy typically follows a "black-list" approach, where on= ly packets with clear negative implications are dropped. On the other hand, when the policy is enforced closer to the destination systems, the policy typically follows a "white-list" approach, where on= ly traffic that is expected to be received is allowed. The advice in this document is aimed only at transit routers that may need to enforce a filtering policy based on the EHs and IPv6 options a packet may contain, following a "black-list" approach, and hence is l= ikely to be much more permissive that a filtering policy to be employed e.g. at the edge of an enterprise network. The advice in this document is meant to improve the current situation of the dropping of packets with IPv6 EHs in the Internet [RFC7872].

=

wh= ile promoting a **default deny** policy with respect to unknown

extension headers, experimental extension headers=
, and experimental
options.  If every transit router followed that advice, it would be=

impossible=
 to transmit packets containing these things across the open
Inter=
net.  It is especially egregious to dispense that advice for
unknown extension headers, si=
nce that would severely impede deployment
of any n=
ew extension headers OR any new transport protocols in the open
<=
pre class=3D"gmail-m_767066958984525011gmail-newpage" style=3D"font-size:13=
.3333px;margin-top:0px;margin-bottom:0px;page-break-before:always">
Internet (as the document itself notes, unknown extension headers =
are
indistinguishable from unknown upper-layer pr=
otocol headers).  This part
of the document's=
 advice does nothing to improve the situation reported
in RFC 7872; if anything, it makes the situation worse.  It certain=
ly
will not make the Internet work better.
<=
p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt;color:rgb(0,0,0)">
While I would prefer to advise operators of transit r=
outers just to be
transparent to everything other than the Hop-by-Hop =
extensions header,
as discussed in the trailing message thread, adapti=
ng the more nuanced
advice in Section 4.4.5 regarding the handling of unknown options to=

the cases of unknown EHs and experimental EHs and=
 options would be an
acceptable alternativ=
e.  Specific text to that effect follows below.

=

OLD: 
3.5.3.  Specific Security Impl=
ications


   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.  However, from security standpoint,
   a device should discard IPv6 extension headers for which the security
   implications cannot be determined.  We note that this policy is
   allowed by [RFC7045=
].


3.5.4<=
/a>.  Operational and Interoperability Impact if Blocked


   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

   We note that since IPv6 EHs and upper-layer protocols share the same
   numbering space, discarding unknown IPv6 EHs may result in packets
   encapsulating unknown upper-layer protocols being discarded.


3.5.5.  Advice


   Intermediate systems should discard packets containing unknown IPv6
   EHs.


= 
NEW:
3.5.3.  Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.


3.5.4<=
/a>.  Operational and Interoperability Impact if Blocked


   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

   We note that since IPv6 EHs and upper-layer protocols share the same
   numbering space, discarding unknown IPv6 EHs may result in packets
   encapsulating unknown upper-layer protocols being discarded.


3.5.5.  Advice



   Enterprise intermediate systems should discard packets that contain
   unknown IPv6 EHs. Other intermediate systems should permit packets
=
   =
that contain unknown IPv6 EHs.  We note that this policy is allowed<=
/pre>
   by=
 [RFC7045].=C2=A0


OLD:
3.4.10.5.  Advice


   Intermediate systems should discard packets containing these EHs.
   Only in specific scenarios in which RFC3692=
-Style experiments are to
   be performed should these EHs be permitted.

NEW:
3.4.10.5.  Adv=
ice


   Enterprise intermediate systems should discard packets that contain
   these EHs except in specific environments in which RFC3692-Style
   are meant to be performed.  Other intermediate systems should permit
   permit packets with these EHs.<=
font color=3D"#000000">


OLD:
4.3.18.5.  Advice


   Intermediate systems should discard packets that contain these
   options.  Only in specific environments where RFC3692-style
   experiments are meant to be performed should these options be
   permitted.

NEW:
<=
h5 style=3D"line-height:0pt;display:inline;font-size:1em">4.3.18.5.  Advice

=


   Enterprise intermediate systems should discard packets that contain
   these options except in specific enviromments in which RFC3692-Style
   are meant to be performed.  Other intermediate systems should permit
   permit packets with these options.

= 

NITS: in some places the=
 abbreviations RHT0 and RHT1 are used, while
i=
n other places RTH0 and RTH1 are used.  The usage should be consistent.
IMHO the former abbreviations seem to be more cor=
rect.

Thanks and regards,

Mike Heard


---------- Forwarded message ---------
From: C. M. Heard <heard@pobox.com>
Date: Thu, Oc= t 5, 2017 at 9:01 PM
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6= -eh-filtering-03
To: Ron Bonica <rbonica@juniper.net>
Cc: OPSEC <opsec@ietf.org>, Joe Touch <touch@strayalpha.com>, Bob Hinden <bob.hinden@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com= >


Hello Ron,

I thin= k that the direction you propose will make this a much better document. Mod= ulo details it would certainly address my concerns.

I do however have come comments to make about router self-protection. RFC= 6192 is all about a router filtering traffic addressed to itself, i.e., wh= at it should process in its role as a host. A very restrictive "white = list" policy ( as outlined in RC 6192) is quite in order there. If the= re is no need or use for extension headers for traffic destined to the cont= rol plane, a very restrictive policy of dropping all packets addressed to t= he control place hat have extension headers may indeed be in order.

It's a very different story, I think, for what a rout= er does to protect itself in its role as forwarding device.=C2=A0 There, if= it complies with RFC 8200, the Hop-by-Hop Options header is the only one t= hat can hurt it, if it is able to forward at line rate at all. The choice b= oils down to whether to process all, some, or no packets with Hop-by-Hop op= tions. I think that we need to loudly broadcast that ignoring all HbH Optio= ns headers is a legitimate policy for this purpose, but dropping all packet= s with HbH Options is not. If we can sell this to the world, it may be poss= ible to actually use the HbH options header, and get rid of abominations su= ch as the CONEX Destination Option.

The way you ch= aracterize the proposed second section sounds right on the money to me.

I support your proposed way forward. Thank you.
=

Mike Heard

On Thu, Oct 5, 2017 at 11:04 AM, Ron Bon= ica <rbonica@juniper.net> wrote:

Mike,

=C2=A0

I think that you just struck the note that F= ernando and I missed. Tr= ansit routers filter extension headers for one of the following reasons:=

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 To protect themselves (as in RFC 6192)<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 To protect downstream devices=

=C2=A0

Therefore, the document should contain= two clearly marked sections, one regarding EH filtering policies that prot= ect the transit router and one regarding EH filtering policies that protect do= wnstream devices.

=C2=A0

The first section can:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Be very short (2 pages max)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Be guided largely by RFC 8200=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Speak with some degree of authority (wh= ile still INFORMATIONAL)

=C2=A0

The second section should begin with a= discussion of the relationship between the transit router and the downstre= am devices. Let=E2=80=99s assume that the transit router belongs to an ISP, w= hile downstream devices fall into the following three classes:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Belong to the ISP<= /span>

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Belong to parties who want to be protec= ted by the ISP (e.g., its customers)

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Belong to other parties

=C2=A0

Therefore, the transit router MAY disc= ard packets that pose a threat to the first two classes of downstream devic= e, but MUST NOT discard packets that are required by the third class of downs= tream device.

=C2=A0

From this point, we formulate a policy= that *might* satisfy the above mentioned requirement. We mark this = policy with the following caveats:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 It is a best guess=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 If the policy is too permissive, downst= ream devices belonging to the ISP and those who it protects will not receiv= e all of the protection possible

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 If the policy is too restrictive, downs= tream devices belonging to other parties will experience collateral damage<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 One size doesn=E2=80=99t fit all=

=C2=A0

If we were to rework the document into= this shape, would it address your concerns.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0

=C2=A0

=C2=A0

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of C. M. Heard
Sent: Wednesday, October 4, 2017 11:08 PM
To: OPSEC <op= sec@ietf.org>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03<= u>

=C2=A0

On Thu, 5 Oct 20= 17 11:10:06 +1300, Brian E Carpenter wrote:

> On 05/10/20= 17 02:12, Joe Touch wrote:

>=C2=A0

>> On 9/29= /2017 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

>>>=C2=A0

>>> Thi= s is to open a two week WGLC

>>> for= =C2=A0https://tools.ietf.o= rg/html/draft-ietf-opsec-ipv6-eh-filtering-03.<= /u>

>>>=C2=A0

>><= u>=C2=A0

>> I do no= t agree with the claims of this document. It "informationally"

>> advises= against support for key IPv6 capabilities and undermines the=

>> extensi= bility of IPv6 by making recommendations about discarding<= /u>

>> current= ly unassigned codepoints.

>=C2=A0

> Here's = the problem, Joe. It's a fact of life that many firewalls=

> discard a l= ot of stuff that they shouldn't - that's why we wrote=

> RFC 7045 - = but in the real world, operators blunder around based<= /p>

> on folklore= and vendors' defaults. We can't change any of that, but<= /u>

> we can try = to issue sensible advice that, overall, will limit the=

> resulting b= reakage. IMHO this document, positioned correctly as

> Information= al, will do that: on balance, it makes the world a better<= /u>

> place.

=C2=A0=

I am afraid that I do not agree that the document, in its present form,=

will do that. It says:

=C2=A0

=C2=A0=
=C2=A0 The filtering policy typically depends on where in the network such<=
u>
=C2=A0=
=C2=A0 policy is enforced: when the policy is enforced in a transit network=
,
=C2=A0=
=C2=A0 the policy typically follows a "black-list" approach, wher=
e only
=C2=A0=
=C2=A0 packets with clear negative implications are dropped.=C2=A0 On the o=
ther
=C2=A0=
=C2=A0 hand, when the policy is enforced closer to the destination systems,=

=C2=A0=
=C2=A0 the policy typically follows a "white-list" approach, wher=
e only
=C2=A0=
=C2=A0 traffic that is expected to be received is allowed.=C2=A0 The advice in
=C2=A0=C2=A0 this document is aimed only at trans=
it routers that may need to
=C2=A0=C2=A0 enforce a filtering policy based on =
the EHs and IPv6 options a packet
=C2=A0=C2=A0 may contain, following a "black=
-list" approach, and hence is likely

=C2=A0=C2=A0 to be much more permissive that a fi=
ltering policy to be employed


=C2=A0=C2=A0 e.g. at the edge of an enterprise ne=
twork.=C2=A0 The advice in this<=
u>


=C2=A0=
=C2=A0 document is meant to improve the current situation of the dropping o=
f


=C2=A0=
=C2=A0 packets with IPv6 EHs in the Internet [RFC7872].





while at the same tim=
e promoting a **default deny** policy with


respect to unrecogniz=
ed options and unrecognized extension headers.


That is antithetical =
to the mission of a **transit router**, which=



is to get packets tra=
nsparently from point A to point B. It is


especially egregious =
to dispense this advice for unrecognized


extension headers, si=
nce they are indistinguishable from unrecognized


transport protocols. =
If these things are blocked by=C2=A0**transit routers**


it becomes=C2=A0 impo=
ssible to deploy any new options or transport protocols.=



But we =
already know that, don't we?


=
=C2=A0


If we w=
ant to give constructive advice that really will make the<=
/u>


world a=
 better place, we should:




1.) Adv=
ise operators of **transit routers** to be transparent to


everything other than the Hop-by-Hop extensions header=
, and provide


detailed advice on what to do (based on the updates in=
 RFC 8200)


about Hop-by-Hop options. The default should be IGNORE=
 unless there


is an option you need to process.=






2.) Reserve all the detailed filtering advicee for ope=
rators of


firewalls, enterprise routers, and other systems whose=
 mission it


is to protect the end systems behind them (or to preve=
nt misbehavior


by said end systems). A default deny for unrecognized =
stuff is not


unreasonable for such systems.




3.) Remind implementors of the following requirement f=
rom RFC 7045:





=C2=A0=
=C2=A0 Forwarding nodes MUST be configurable to allow packets containing=



=C2=A0=
=C2=A0 unrecognised extension headers, but the default configuration MAY=



=C2=A0=
=C2=A0 drop such packets.





and add similar advice for options.





Thanks =
and regards,




Mike He=
ard

=
--000000000000b6a5e0057b575b6d-- From nobody Fri Nov 23 11:53:51 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5E412DD85; Fri, 23 Nov 2018 11:53:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Michael Scharf To: Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154300282321.9639.11604402305352742547@ietfa.amsl.com> Date: Fri, 23 Nov 2018 11:53:43 -0800 Archived-At: Subject: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 19:53:43 -0000 Reviewer: Michael Scharf Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent transport issues. The proposed filtering could slow down the deployment of experimental protocols that use IPv6 options, but the tradeoffs are explained in the document. Thanks Michael From nobody Sat Nov 24 07:37:13 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B527128B14; Sat, 24 Nov 2018 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 EZS-dfqFYm-X; Sat, 24 Nov 2018 07:37:04 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68731286E7; Sat, 24 Nov 2018 07:37:03 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAOFaxRv059593 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2018 15:36:59 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: "C. M. Heard" Cc: IETF , OPSEC References: From: Nick Hilliard Message-ID: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> Date: Sat, 24 Nov 2018 15:36:58 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 15:37:07 -0000 C. M. Heard wrote on 23/11/2018 16:20: > while promoting a **/_default deny_/** policy with respect to unknown > extension headers, experimental extension headers, and experimental > options. If every transit router followed that advice, it would be > impossible to transmit packets containing these things across the open > Internet. It is especially egregious to dispense that advice for > unknown extension headers, since that would severely impede deployment > of any new extension headers OR any new transport protocols in the open > Internet (as the document itself notes, unknown extension headers are > indistinguishable from unknown upper-layer protocol headers). This part > of the document's advice does nothing to improve the situation reported > in RFC 7872; if anything, it makes the situation worse. It certainly > will not make the Internet work better. transit operators would generally take the view that any data-plane packet which needs to be put through a slow path will be rate limited up to 100% loss. We can argue endlessly at the IETF about the pros and cons of this from a protocol development and management point of view but at the end of the day, transit operators have networks to run, and there is a jarring disparity between data-plane forwarding speed and control-plane processing capacity. If you expect one to bleed into the other, something needs to give. This is often going to be silicon-specific; what is slow-pathed on one platform may not be slow-pathed on another, so generalised statements are difficult in this situation. Transit operators are going to make their own decisions about what to do about packet filtering, and take any specific recommendation in an ID like this with a grain of salt. In that respect, this document needs to be seen as a store of information to help people make informed decisions about what to do rather than being a prescriptive list. Nick From nobody Sat Nov 24 08:15:03 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5BA130E2D; Sat, 24 Nov 2018 08:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 WPsPxZDIj61f; Sat, 24 Nov 2018 08:14:54 -0800 (PST) Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11CEA130E09; Sat, 24 Nov 2018 08:14:53 -0800 (PST) Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 829FB27602; Sat, 24 Nov 2018 11:14:52 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=HjkvufqCkF2PvNOEx4Lot46kdxw=; b=My580z qFllu5BrwZAVFH90+2brSDkTDBG0A3M66JfPxOH3/35OmtEs97h5YJUu1Ajl9rsh Wz3I0eqDYONEZKnWajCbJrTOVgkMqaF22skJPHyz3n33PWz1hhAcKLwKflrjC7Cy D3EbmwEbrAL9Yt1qDM98SVW7tObOz+VjnED+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=pWKCh/Zy01f8owrK7Mc0wLOWxznZBIC/ D5Q7FKlT5N9dwWqKROmtqXHVVu+xOsJyNUIM9wq8uQ9SjclmzfoXE8rWhMlwMFQ9 jQcfEhNPvuIsPkK1jFhjMl7Uwq1qD80dnaOm2SRBFWxKHx7G38O1JZVz8pNFGGzm Yf4/KNWUCdw= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 7BA6F27601; Sat, 24 Nov 2018 11:14:52 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-it1-f179.google.com (unknown [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 07989275FD; Sat, 24 Nov 2018 11:14:50 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-it1-f179.google.com with SMTP id h65so21609822ith.3; Sat, 24 Nov 2018 08:14:50 -0800 (PST) X-Gm-Message-State: AA+aEWate7Moch++kBbvqDNVXnRnPoz3p2tDa6ZDrvgrnB6iN2pzgZNB yKoot0cWl+rA1RRhBoYwkA6d8rLAU8KUwdGYuJ0= X-Google-Smtp-Source: AJdET5eCun11zKfs1BelhKBPBGqwAJpGPOR+U1UCbN2q64/t9jO+Zq7US2lGbCC8KeUh60lYZfHpADAAWWv37/9Djd8= X-Received: by 2002:a02:b529:: with SMTP id l38mr16300721jaj.25.1543076088744; Sat, 24 Nov 2018 08:14:48 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> In-Reply-To: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> From: "C. M. Heard" Date: Sat, 24 Nov 2018 08:14:35 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Nick Hilliard Cc: IETF , OPSEC Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 1196E05C-F004-11E8-9473-CC883AD79A78-06080547!pb-smtp21.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 16:14:56 -0000 On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard wrote: > C. M. Heard wrote on 23/11/2018 16:20: > > while promoting a **/_default deny_/** policy with respect to unknown > > extension headers, experimental extension headers, and experimental > > options. If every transit router followed that advice, it would be > > impossible to transmit packets containing these things across the open > > Internet. It is especially egregious to dispense that advice for > > unknown extension headers, since that would severely impede deployment > > of any new extension headers OR any new transport protocols in the open > > Internet (as the document itself notes, unknown extension headers are > > indistinguishable from unknown upper-layer protocol headers). This part > > of the document's advice does nothing to improve the situation reported > > in RFC 7872; if anything, it makes the situation worse. It certainly > > will not make the Internet work better. > > transit operators would generally take the view that any data-plane > packet which needs to be put through a slow path will be rate limited up > to 100% loss. We can argue endlessly at the IETF about the pros and > cons of this from a protocol development and management point of view > but at the end of the day, transit operators have networks to run, and > there is a jarring disparity between data-plane forwarding speed and > control-plane processing capacity. If you expect one to bleed into the > other, something needs to give. This is often going to be > silicon-specific; what is slow-pathed on one platform may not be > slow-pathed on another, so generalised statements are difficult in this > situation. It's not clear to me what that has to do with the specific comments that I made (and that you elided). I would understand if I had brought up handling of, say, HbH options rather than default drop policies for unknown (and experimental) header types. Perhaps you could clarify. > Transit operators are going to make their own decisions about what to do > about packet filtering, and take any specific recommendation in an ID > like this with a grain of salt. In that respect, this document needs to > be seen as a store of information to help people make informed decisions > about what to do rather than being a prescriptive list. Agreed, that's the most useful part of the document. But it does in addition give specific advice, and that advice should be reasonable as a default. My primary objection is to the advice that says discard unknown EHs and upper-layer protocols by default. That advice needs to be more nuanced -- as is the advice for unknown option types given in Sec. 4.4.5, I see no reason why these cases should get different advice. Mike Heard From nobody Sat Nov 24 09:04:32 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1391012D84C; Sat, 24 Nov 2018 09:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 xhPMMjjSFNhW; Sat, 24 Nov 2018 09:04:28 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 9DBA3126CB6; Sat, 24 Nov 2018 09:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lBjyll1JdQdpRUh6sM5lKLFDlS8ZLDMf7y74rsjGU2k=; b=4nNVLxfDFgxiojSfvxxVQi1l8 sreFZbtegh0N/CtR/CHMDzec7JO8Atgpn0kQ75Gu0ugoXywaNW9XtJSiw3pc6HDksR0/ysDmTdefx wLWVTZQtYC9Z45lORjK6TtnlXTO6gPFVjUsO1KkxA2ixnWggLCnb6x0hjts/rE6FuFGWUrekxKGYh AaN55Kw73cNuDVACLOm+2Xqll5NS7HW/TfZgQ9yX4k+WAlIlLtXl9Be/rVqU6HlOjHF3N55K0yCqH IQIvt1J73PZpvU7S2oES7VDjIfsGsr9dcevAVEYNwJJdrE+n2hEzrUy+VMI0l0Yvmun+sCgcjA3xd jKg9lWfQA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55984 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gQbLw-001W3a-Nh; Sat, 24 Nov 2018 12:04:24 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <154300282321.9639.11604402305352742547@ietfa.amsl.com> Date: Sat, 24 Nov 2018 09:04:19 -0800 Cc: tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> To: Michael Scharf X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 17:04:30 -0000 Equally worrisome that this doc appears to make recommendations that = imply BCP, when it is merely informational. IMO, it=E2=80=99s overstepping to do so. Joe > On Nov 23, 2018, at 11:53 AM, Michael Scharf = wrote: >=20 > Reviewer: Michael Scharf > Review result: Ready >=20 > This document has been reviewed as part of the transport area review = team's > ongoing effort to review key IETF documents. These comments were = written > primarily for the transport area directors, but are copied to the = document's > authors and WG to allow them to address any issues raised and also to = the IETF > discussion list for information. >=20 > When done at the time of IETF Last Call, the authors should consider = this > review as part of the last-call comments they receive. Please > always CC tsv-art@ietf.org if you reply to or forward this review. >=20 > I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no = apparent > transport issues. The proposed filtering could slow down the = deployment of > experimental protocols that use IPv6 options, but the tradeoffs are = explained > in the document. >=20 > Thanks >=20 > Michael >=20 From nobody Sat Nov 24 12:09:20 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D8130F65; Sat, 24 Nov 2018 12:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 zA73Gxb6iBAo; Sat, 24 Nov 2018 12:09:09 -0800 (PST) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A719D130E70; Sat, 24 Nov 2018 12:09:09 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 57C6212B47E; Sat, 24 Nov 2018 15:09:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=gdM vOBchSL3W6iIjhpNiFTfUKA8=; b=xEdcQxsYk73TZEhOnx7pQwyl2l9060IwTIV wgeSvJC7aYY48pJNodnxBpiINgUmIvoSUNtBR/Y2WdapunEFKe43QQ1/Te59RtzG RDPy7SKMshq64NKBK2l2bJbivI5aNevCSaDANHgFr95F7uv0PAi2jw2oRGPeEEeY Y4iCDWrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= D28woXB5Nwbilg7/7YVciXGyrVLEpebF7LuUjwHh382kzIIOTgkzxRrRdfd7IdZ6 qTyGaZQ7DW4MmWWrQUn6WHyeMP3RPVL/uDYwD48+GS9n1ND/RVjzX7BvbThJg0iJ sbhOEU7s5f0mpvu8JEsnNHQpRuzNdxLC3u39RYIEYlE= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 514D112B47A; Sat, 24 Nov 2018 15:09:05 -0500 (EST) Received: from mail-it1-f173.google.com (unknown [209.85.166.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id BF50212B476; Sat, 24 Nov 2018 15:09:04 -0500 (EST) Received: by mail-it1-f173.google.com with SMTP id x124so20533164itd.1; Sat, 24 Nov 2018 12:09:04 -0800 (PST) X-Gm-Message-State: AGRZ1gIi3WX0FJjNtbI3s1yqOHSGnQtJTrWjpjTmotAhGPTGBCA1uzB2 a1C93A1tGMCfrqItvIKbZqMDrVBoIyM1MQFBpIo= X-Google-Smtp-Source: AJdET5c6wslu/UJoGZguTWhz6g+PC5HMRa25KET0TLQegEqbe6tRW0pRvnhdqTrO/NJRNw3wzSJ1iXP9Q8SLC/6YfnQ= X-Received: by 2002:a24:d84:: with SMTP id 126-v6mr18424418itx.163.1543090144236; Sat, 24 Nov 2018 12:09:04 -0800 (PST) MIME-Version: 1.0 From: "C. M. Heard" Date: Sat, 24 Nov 2018 12:08:52 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Michael Scharf Cc: TSV-ART , OPSEC , IETF , draft-ietf-opsec-ipv6-eh-filtering@ietf.org Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: CAE14082-F024-11E8-AD61-BFB3E64BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: [OPSEC] (no subject) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:09:11 -0000 > On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote: > > Reviewer: Michael Scharf > Review result: Ready > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please > always CC tsv-art at ietf.org if you reply to or forward this review. > > I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent > transport issues. The proposed filtering could slow down the deployment of > experimental protocols that use IPv6 options, but the tradeoffs are explained > in the document. Did you notice that Section 3.5.5 advises discarding IPv6 packets whose Next Header value is unknown -- i.e., IPv6 packets with unknown EHs **or** unknown transport protocols? Even for an IPv6 core router in the open Internet? If not, would that fact change your assessment of this document? As I noted in my own last call comments, I think that a more nuanced approach is called for (e.g., as set forth in Section 4.4.5 for unknown option values). Mike Heard From nobody Sat Nov 24 12:13:46 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23AE130F56 for ; Sat, 24 Nov 2018 12:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 xszC0t8ymHgr for ; Sat, 24 Nov 2018 12:13:36 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4CB130F65 for ; Sat, 24 Nov 2018 12:13:36 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 5932B12BE46 for ; Sat, 24 Nov 2018 15:13:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:cc :content-type; s=sasl; bh=gdMvOBchSL3W6iIjhpNiFTfUKA8=; b=dImxfV l0tY9hnBIxkWKXMf+vYAPyKg0M5Iy7QEu8p/QOtwtEfj11LgoCxL/ULR/3sSKst4 7NOoX8xhaHmev0ITJiI/flHdtm3oZan2hQgP/WLqRjOQhbnxHR/gB0qSOtYOquuK TwzuQw/HY31MdarqhKTeXUoftSQWkF67Wg0GQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:cc :content-type; q=dns; s=sasl; b=XUvmj20wM194G95jBlAcrzbdLzhY+Yqi awvIS0Pm4JvRD/SBcEKNzJB3dmfHVLrIiCLxFz/gatvcOOwO75VgiSy9WfkPN0ry QY0O087bdY6v9STFXzjdPPjovFViWl6fRpVUCln1+n/8PHRhWu0Ew7r7m7EhT7f8 z5qxb0f2f+s= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 4A6AB12BE45 for ; Sat, 24 Nov 2018 15:13:35 -0500 (EST) Received: from mail-it1-f169.google.com (unknown [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id CC88D12BE40 for ; Sat, 24 Nov 2018 15:13:34 -0500 (EST) Received: by mail-it1-f169.google.com with SMTP id m15so22085610itl.4 for ; Sat, 24 Nov 2018 12:13:34 -0800 (PST) X-Gm-Message-State: AGRZ1gIQH/dsWrNr+bYKwx3ShEgQzxxnho95k6FsR6NuGB+jP6MEYyxJ Mnfqux/71WRFoL0CT7Q3YWGwTlFmEVM5+RKNzgA= X-Received: by 2002:a02:b14c:: with SMTP id s12mt19258521jah.40.1543090414177; Sat, 24 Nov 2018 12:13:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "C. M. Heard" Date: Sat, 24 Nov 2018 12:13:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Cc: Michael Scharf , TSV-ART , OPSEC , IETF , draft-ietf-opsec-ipv6-eh-filtering@ietf.org Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 6BD73596-F025-11E8-98D0-063AD72159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:13:38 -0000 > On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote: > > Reviewer: Michael Scharf > Review result: Ready > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please > always CC tsv-art at ietf.org if you reply to or forward this review. > > I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent > transport issues. The proposed filtering could slow down the deployment of > experimental protocols that use IPv6 options, but the tradeoffs are explained > in the document. Did you notice that Section 3.5.5 advises discarding IPv6 packets whose Next Header value is unknown -- i.e., IPv6 packets with unknown EHs **or** unknown transport protocols? Even for an IPv6 core router in the open Internet? If not, would that fact change your assessment of this document? As I noted in my own last call comments, I think that a more nuanced approach is called for (e.g., as set forth in Section 4.4.5 for unknown option values). Mike Heard From nobody Sat Nov 24 12:18:02 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA09E130F59; Sat, 24 Nov 2018 12:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cvXLag-L2Ptq; Sat, 24 Nov 2018 12:17:59 -0800 (PST) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53C0130F56; Sat, 24 Nov 2018 12:17:59 -0800 (PST) Received: by mail-pl1-x644.google.com with SMTP id x21-v6so12014114pln.9; Sat, 24 Nov 2018 12:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JJwa+28a2PNLnZCXGOziq+zhOj0z/iTpBuDztU9ZCy0=; b=ltdBCTLjLN4Eyb2ks9Cbz0xG6/X/4nDDNX/ym7WaoZ/90Z2fjgwBL8ekhX0SQh+lCq JxnF3uzF7rarOixQVKh7Rt7NeibR7XDxKKAyx+K7V4rsMxONFzwcQK3EtzGx1ZGi+x0R LL/tD6CHsSFnR6v0u9c1iDS9z+iR26XPMSrxcLTH8MFzdUJy4fxKWoGxci6GkOr9s7tV 4PkLIOth857GzCflZrNS3P0i+oQo0uRXuyaZzNgg5SSctgzR51IsJYvA3cb0c0wEb5Ux irb2v6vOcU/+6WEQ78xl68tQe/hlZsOZ8sDbxqc7YEyQCRj0RgO6yaTIrkMoAJMBPQ5Q V3Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JJwa+28a2PNLnZCXGOziq+zhOj0z/iTpBuDztU9ZCy0=; b=DYmbcJiwzgbjEeZGJu8QBMwS1dsC5bYmDXxikJQy+gVxEYj7knCd2V9tJhLknT5BPz gKLSWtoq4qIyokNWrQBquT7kI37ttx4Q7joAvhmJYhppyDzvDi5WqAEnLZ7EMhuKoBij ly20RLpOG7WYuEZVAHymcyVYH2CLUVl+ffDwUlAgyqfppNSNNIL7NbVbFKUxjPfLBgwL v8aIGGaAoU4Z2fWaLUnA89zGga/gRBg/ODsYz9PxWRX2QjsqR3vUZC9OlnvZ8qBWs9sX 9p7Mb28qZI8kR+wohQqgnE4luCFkebywkkNR021UVRm+OfZkJMEe1BMPCWUH278LY3Tj jofg== X-Gm-Message-State: AA+aEWZJrLs+uCqwWcpkh9s2Xq2S5N+w5hP0c8nnir648Bb/M8X1PO7Y ckkxHsln3aEmaO1glOynL6hDyYB0 X-Google-Smtp-Source: AFSGD/UzrhyU43xW4dyiR8WXLRxYlzotUwXNShisjmw+rX8nGT5F385R5Z3TeoIyLPlANzgN15sPfA== X-Received: by 2002:a17:902:7587:: with SMTP id j7mr21202499pll.191.1543090678691; Sat, 24 Nov 2018 12:17:58 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id s79sm197937pgs.50.2018.11.24.12.17.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Nov 2018 12:17:57 -0800 (PST) To: "C. M. Heard" , Nick Hilliard Cc: OPSEC , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> From: Brian E Carpenter Message-ID: <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> Date: Sun, 25 Nov 2018 09:17:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:18:02 -0000 On 2018-11-25 05:14, C. M. Heard wrote: > On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard wrote: >> C. M. Heard wrote on 23/11/2018 16:20: >>> while promoting a **/_default deny_/** policy with respect to unknown >>> extension headers, experimental extension headers, and experimental >>> options. If every transit router followed that advice, it would be >>> impossible to transmit packets containing these things across the open >>> Internet. It is especially egregious to dispense that advice for >>> unknown extension headers, since that would severely impede deployment >>> of any new extension headers OR any new transport protocols in the open >>> Internet (as the document itself notes, unknown extension headers are >>> indistinguishable from unknown upper-layer protocol headers). This part >>> of the document's advice does nothing to improve the situation reported >>> in RFC 7872; if anything, it makes the situation worse. It certainly >>> will not make the Internet work better. >> >> transit operators would generally take the view that any data-plane >> packet which needs to be put through a slow path will be rate limited up >> to 100% loss. We can argue endlessly at the IETF about the pros and >> cons of this from a protocol development and management point of view >> but at the end of the day, transit operators have networks to run, and >> there is a jarring disparity between data-plane forwarding speed and >> control-plane processing capacity. If you expect one to bleed into the >> other, something needs to give. This is often going to be >> silicon-specific; what is slow-pathed on one platform may not be >> slow-pathed on another, so generalised statements are difficult in this >> situation. > > It's not clear to me what that has to do with the specific comments > that I made (and that you elided). I would understand if I had brought > up handling of, say, HbH options rather than default drop policies for > unknown (and experimental) header types. Perhaps you could clarify. As background, the *end* of the discussion of HbH in the draft says: Finally, when packets containing a HBH Options EH are processed in the slow-path, and the underlying platform does not have any mitigation options available for attacks based on these packets, we recommend that such platforms discard packets containing IPv6 HBH Options EHs. I'm not sure what else a firewall recommendation could say (as a default configuration, because the whole document is really about defaults). But it's worth reading the preceding text at https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5 to get the context for that "Finally". >> Transit operators are going to make their own decisions about what to do >> about packet filtering, and take any specific recommendation in an ID >> like this with a grain of salt. In that respect, this document needs to >> be seen as a store of information to help people make informed decisions >> about what to do rather than being a prescriptive list. > > Agreed, that's the most useful part of the document. But it does in > addition give specific advice, and that advice should be reasonable > as a default. > > My primary objection is to the advice that says discard unknown > EHs and upper-layer protocols by default. That advice needs to > be more nuanced -- as is the advice for unknown option types > given in Sec. 4.4.5, I see no reason why these cases should > get different advice. Let's see. We have: 3.5.2. Specification The processing of unknown IPv6 EHs is specified in [RFC8200] and [RFC7045]. In fact RFC8200 doesn't discuss EH processing by intermediate nodes. RFC7045 does (see https://tools.ietf.org/html/rfc7045#section-2.1 ). Again, read the whole section for context, but the key sentence is: Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets. That was a careful compromise between the ideal (a transparent Internet) and reality (an Internet with security-aware operators). The current draft changes this MAY into a lower-case should: 3.5.5. Advice Intermediate systems should discard packets containing unknown IPv6 EHs. I'm with Mike Heard. This is an informational document attempting to override a Proposed Standard. That's not OK. That doesn't mean Nick Hilliard is wrong. Operators make their own decisions, so I think that is what the draft should say. Something like: 3.5.5. Advice Operators should determine according to their own circumstances whether to discard packets containing unknown IPv6 EHs. And at the same time, delete the 2nd and 3rd sentences of this: 3.5.3. Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs. However, from security standpoint, a device should discard IPv6 extension headers for which the security implications cannot be determined. We note that this policy is allowed by [RFC7045]. I don't expect these changes to have much impact in the real world, however. Brian > > Mike Heard > > From nobody Sat Nov 24 12:22:03 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905AB130E70; Sat, 24 Nov 2018 12:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FxjKVT3kJaxT; Sat, 24 Nov 2018 12:21:59 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAC6130DEE; Sat, 24 Nov 2018 12:21:59 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id 17so4388808pgg.1; Sat, 24 Nov 2018 12:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Zg6G9PK6R+s3aLo007rN67r6VI1U7RZ89NDdIEgvvwQ=; b=njVqQctto6HUegX2uj/6DO+swYmQLlJHd1F4h03XOlOjkBSRLiv87XmdmTT+qvTE9T GeKxDJyQDXfogqO0Ldmz0tN6A85PdXzi8iw1hlLs2s9x0SiVC/0FbecSe9ct8wVjAey7 IVDSDPpFc4MpB/W3BakNqIo5TcZKQ7rIAJfytA+y5rs7R+vtX7BqkvmO8zMVD+/8gM7g S46auU8A3KxGzY0/MNInnK3lbDunuWU5di4ZfPUd8QGLQAPChM3d04hktgwL2clgWuzO SOKnr1U1S8sbBU0tfaRO4ikxk0FjgRJ3G6S5VZ3IEh55haOfbVRL2iaMrjJ7H0Xuf/bq w8uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Zg6G9PK6R+s3aLo007rN67r6VI1U7RZ89NDdIEgvvwQ=; b=BzU7AZwxptpneibgEH+Lr1ykSb1BY+jKnIhEK/b8VLyk5V2o44wPQCmTMyo/achjkO mmX8GOJ9Rd6dr3wB2tJ/Q9kYmvUN26EQpsPfEgjincsWhTEmBjjTaWuXUoVcfJkL+pIb UqbJjwzVZ+5x/9bQL5nnMj70ImL/rsL/lT67nshstOFcTI8UYFxD/PBBbz5e/S+pjhUq A5+Y4YqbVVsKc0eG3d4DRHV8rLlus84GGIyy8r2wv05z92n5crMkXQFElhJT/vEavUm9 cbAvjRVDPfm7gGw4xqiVFJTiRt00Fl0Lei1utFqTRnfDV1fWxba4cFgqrgErIFChpQgV O5cg== X-Gm-Message-State: AGRZ1gJJQMQb8ceFFOB70PX32HbJZ2vo0vtEEcTIA1Pb/Cue5cmLR94X tlNnNZ5IKQudushlEfpiZCsrrQaZ X-Google-Smtp-Source: AJdET5fmDMy1EohCKE8DfKfUakpcDxDm+iInUDU/+aHU1hX9jLnK8n2GyiE5xu1bI5UgbWESCyU3Pg== X-Received: by 2002:a62:e044:: with SMTP id f65mr21135795pfh.208.1543090918944; Sat, 24 Nov 2018 12:21:58 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id v89sm35437536pfk.12.2018.11.24.12.21.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Nov 2018 12:21:58 -0800 (PST) To: Joe Touch , Michael Scharf Cc: tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> Date: Sun, 25 Nov 2018 09:21:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:22:02 -0000 On 2018-11-25 06:04, Joe Touch wrote: > Equally worrisome that this doc appears to make recommendations that im= ply BCP, when it is merely informational. >=20 > IMO, it=E2=80=99s overstepping to do so. Possibly, but it's not forbidden by rule, as far as I know. However, the draft is inconsistent in its use of SHOULD vs should (see my previous message for an example of a lower case should which might or might not be intended pseudo-normatively). Brian >=20 > Joe >=20 >> On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote: >> >> Reviewer: Michael Scharf >> Review result: Ready >> >> This document has been reviewed as part of the transport area review t= eam's >> ongoing effort to review key IETF documents. These comments were writt= en >> primarily for the transport area directors, but are copied to the docu= ment's >> authors and WG to allow them to address any issues raised and also to = the IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider t= his >> review as part of the last-call comments they receive. Please >> always CC tsv-art@ietf.org if you reply to or forward this review. >> >> I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no ap= parent >> transport issues. The proposed filtering could slow down the deploymen= t of >> experimental protocols that use IPv6 options, but the tradeoffs are ex= plained >> in the document. >> >> Thanks >> >> Michael >> >=20 >=20 From nobody Sat Nov 24 12:30:10 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38644130DEE; Sat, 24 Nov 2018 12:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 TrTUYiUUtXYe; Sat, 24 Nov 2018 12:29:59 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F5A130DE8; Sat, 24 Nov 2018 12:29:58 -0800 (PST) X-Envelope-To: opsec@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAOKTuQx093730 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2018 20:29:56 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Brian E Carpenter Cc: "C. M. Heard" , OPSEC , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> From: Nick Hilliard Message-ID: Date: Sat, 24 Nov 2018 20:29:55 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:30:01 -0000 Brian E Carpenter wrote on 24/11/2018 20:17: > Operators make their own > decisions, so I think that is what the draft should say. Something like: > > 3.5.5. Advice > > Operators should determine according to their own circumstances > whether to discard packets containing unknown IPv6 EHs. > > And at the same time, delete the 2nd and 3rd sentences of this: > > 3.5.3. Specific Security Implications > > For obvious reasons, it is impossible to determine specific security > implications of unknown IPv6 EHs. However, from security standpoint, > a device should discard IPv6 extension headers for which the security > implications cannot be determined. We note that this policy is > allowed by [RFC7045]. This looks like a sensible approach. > I don't expect these changes to have much impact in the real world, > however. Indeed. The real world is more complex than can be easily encapsulated in a draft like this, and it changes more quickly than rfcs. Nick From nobody Sat Nov 24 12:38:13 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E01130DE8; Sat, 24 Nov 2018 12:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 SEckASQxLbuo; Sat, 24 Nov 2018 12:38:11 -0800 (PST) Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE20012DD85; Sat, 24 Nov 2018 12:38:10 -0800 (PST) Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id ABB153A702; Sat, 24 Nov 2018 15:38:10 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=p0sNXcoO24kZjvZGGEDbJnaa3FQ=; b=fQw+iM LBql0jK0ef9BGx3WfzuZ+2pzoqYp5c1w6kwbKhoGsOK6vqtWXx6wNjIh0/aneW7o lqF2pH+p4IMUkgROx7ElYazlMD3CnPry8ej2EWC/4x3t98unQm8zact1biX8RCxY 5R+yKWs9tRbykmLwoyBPIdweXNmxo5PJ3AVN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=qM7YNeGg4C0ciQD32qcuqPJwC9dxPF8b WrnK9F/WcLwlVAM5R8Ek1m6zO8zT+L3oqJFA+Vi+Z2/8w2JW6W4/5KZFSNYv9EEq 2hduel0AmKGXI/eF97dyUd51fvDqXqKsPs1Ht1dpHqkn3kQ/VWEp1X9UJkG3PTlU itgaK3LYW0I= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id A6B7E3A701; Sat, 24 Nov 2018 15:38:10 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-io1-f52.google.com (unknown [209.85.166.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 41F363A6FF; Sat, 24 Nov 2018 15:38:08 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-io1-f52.google.com with SMTP id u19so11075563ioc.2; Sat, 24 Nov 2018 12:38:08 -0800 (PST) X-Gm-Message-State: AA+aEWZIpE2OPOWcgA71qjICuPOEuVcMdlYOYwKjF/AONvTHbwpJ4ZpX g31dWvsZIldd5+uj6iYCyA2xynZcER9hUimCeNw= X-Google-Smtp-Source: AFSGD/UYgDYEL0G8OwsYWfEaZH4ZjX9HrKJMljyW0DPeBvuOt4WTWLsdHYPgXbyNxjukqyoPF/OG/0CZoC8kRpsixW8= X-Received: by 2002:a6b:7307:: with SMTP id e7-v6mr9957920ioh.94.1543091887073; Sat, 24 Nov 2018 12:38:07 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> In-Reply-To: From: "C. M. Heard" Date: Sat, 24 Nov 2018 12:37:55 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Nick Hilliard , Brian E Carpenter Cc: OPSEC , IETF Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: DA12633E-F028-11E8-B1D8-F5C31241B9FE-06080547!pb-smtp20.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:38:12 -0000 On Sat, Nov 24, 2018 at 12:30 PM Nick Hilliard wrote: > Brian E Carpenter wrote on 24/11/2018 20:17: > > Operators make their own > > decisions, so I think that is what the draft should say. Something like: > > > > 3.5.5. Advice > > > > Operators should determine according to their own circumstances > > whether to discard packets containing unknown IPv6 EHs. > > > > And at the same time, delete the 2nd and 3rd sentences of this: > > > > 3.5.3. Specific Security Implications > > > > For obvious reasons, it is impossible to determine specific security > > implications of unknown IPv6 EHs. However, from security standpoint, > > a device should discard IPv6 extension headers for which the security > > implications cannot be determined. We note that this policy is > > allowed by [RFC7045]. > > This looks like a sensible approach. I could live with that. Similar changes might be considered for Sec. 4.4.5. Mike Heard From nobody Sat Nov 24 12:44:20 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7956E12E7C1; Sat, 24 Nov 2018 12:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LQ7HU-wyVSQC; Sat, 24 Nov 2018 12:44:10 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305CA12426E; Sat, 24 Nov 2018 12:44:09 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAOKi777095380 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2018 20:44:07 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: "C. M. Heard" Cc: IETF , OPSEC References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> From: Nick Hilliard Message-ID: <84ee1f5f-f88e-8288-58fa-b820624b57e7@foobar.org> Date: Sat, 24 Nov 2018 20:44:06 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:44:13 -0000 C. M. Heard wrote on 24/11/2018 16:14: > On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard wrote: >> C. M. Heard wrote on 23/11/2018 16:20: >> transit operators would generally take the view that any data-plane >> packet which needs to be put through a slow path will be rate limited up >> to 100% loss. We can argue endlessly at the IETF about the pros and >> cons of this from a protocol development and management point of view >> but at the end of the day, transit operators have networks to run, and >> there is a jarring disparity between data-plane forwarding speed and >> control-plane processing capacity. If you expect one to bleed into the >> other, something needs to give. This is often going to be >> silicon-specific; what is slow-pathed on one platform may not be >> slow-pathed on another, so generalised statements are difficult in this >> situation. > > It's not clear to me what that has to do with the specific comments > that I made (and that you elided). I would understand if I had brought > up handling of, say, HbH options rather than default drop policies for > unknown (and experimental) header types. Perhaps you could clarify. hm yes, it was a bit obtuse. What I was trying to get at (and completely failed to achieve) was: 1. that EHs are largely unusable anyway, so if this draft makes some types slightly more unusable, that isn't going to make much of a practical difference. RFC7872 suggests failure rates of ~30% - 50% for fragment headers. Once you're in this territory, nothing you can do will make things any worse. 2. transit operators don't like filtering stuff. They will filter traffic if and only if that traffic is a nuisance or forms a threat to the operation of their networks, and: > My primary objection is to the advice that says discard unknown > EHs and upper-layer protocols by default. That advice needs to > be more nuanced -- as is the advice for unknown option types > given in Sec. 4.4.5, I see no reason why these cases should > get different advice. ...3. Any recommendation that the IETF makes in this area may, or may not, be taken as input into a decision machine, the result of which will be to filter, or rate limit, or to forward. From this perspective, the documentation needs to observe and make suggestions. Nick From nobody Sat Nov 24 12:46:59 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7382130E02; Sat, 24 Nov 2018 12:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 8Gs2Sy8N_hrn; Sat, 24 Nov 2018 12:46:41 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E413A130DFD; Sat, 24 Nov 2018 12:46:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E5B2825A18; Sat, 24 Nov 2018 21:46:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1543092398; bh=Wrdh6ea+oPayL7HaejiUrM8gx3gnerwYjuH7bv9HiQE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ypR6Pnp3BvhKbwf99vJqdpIt2NE9yIqFGey61p3DmXtLo0HdgtS1stl/ZL9kxG3ks PhzKIFckgqSAegWo7vryFlb+lq0N9mEDUbY1vybpMGhVJdh88PQTqIWsDJVlLfrdEQ +3e8I08MerXpl89xCgRR8bdduGoCdqFIs3MOxxpE= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0LADy48aa5w; Sat, 24 Nov 2018 21:46:38 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sat, 24 Nov 2018 21:46:38 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.98]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Sat, 24 Nov 2018 21:46:38 +0100 From: "Scharf, Michael" To: "C. M. Heard" CC: TSV-ART , OPSEC , IETF , "draft-ietf-opsec-ipv6-eh-filtering@ietf.org" Thread-Index: AQHUhDGQD38gsZx+UEa4BhlPkM4YfaVfXQkg Date: Sat, 24 Nov 2018 20:46:37 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D172160@rznt8114.rznt.rzdir.fht-esslingen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] (no subject) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 20:46:44 -0000 PiA+IFJldmlld2VyOiBNaWNoYWVsIFNjaGFyZg0KPiA+IFJldmlldyByZXN1bHQ6IFJlYWR5DQo+ ID4NCj4gPiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQgb2YgdGhlIHRy YW5zcG9ydCBhcmVhIHJldmlldw0KPiB0ZWFtJ3MNCj4gPiBvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21tZW50cyB3ZXJlDQo+IHdyaXR0ZW4NCj4g PiBwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUgY29w aWVkIHRvIHRoZQ0KPiBkb2N1bWVudCdzDQo+ID4gYXV0aG9ycyBhbmQgV0cgdG8gYWxsb3cgdGhl bSB0byBhZGRyZXNzIGFueSBpc3N1ZXMgcmFpc2VkIGFuZCBhbHNvIHRvDQo+IHRoZSBJRVRGDQo+ ID4gZGlzY3Vzc2lvbiBsaXN0IGZvciBpbmZvcm1hdGlvbi4NCj4gPg0KPiA+IFdoZW4gZG9uZSBh dCB0aGUgdGltZSBvZiBJRVRGIExhc3QgQ2FsbCwgdGhlIGF1dGhvcnMgc2hvdWxkIGNvbnNpZGVy DQo+IHRoaXMNCj4gPiByZXZpZXcgYXMgcGFydCBvZiB0aGUgbGFzdC1jYWxsIGNvbW1lbnRzIHRo ZXkgcmVjZWl2ZS4gUGxlYXNlDQo+ID4gYWx3YXlzIENDIHRzdi1hcnQgYXQgaWV0Zi5vcmcgaWYg eW91IHJlcGx5IHRvIG9yIGZvcndhcmQgdGhpcyByZXZpZXcuDQo+ID4NCj4gPiBJIGhhdmUgcmV2 aWV3ZWQgZHJhZnQtaWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZy0wNi4gVGhlcmUgYXJlIG5v DQo+IGFwcGFyZW50DQo+ID4gdHJhbnNwb3J0IGlzc3Vlcy4gVGhlIHByb3Bvc2VkIGZpbHRlcmlu ZyBjb3VsZCBzbG93IGRvd24gdGhlDQo+IGRlcGxveW1lbnQgb2YNCj4gPiBleHBlcmltZW50YWwg cHJvdG9jb2xzIHRoYXQgdXNlIElQdjYgb3B0aW9ucywgYnV0IHRoZSB0cmFkZW9mZnMgYXJlDQo+ IGV4cGxhaW5lZA0KPiA+IGluIHRoZSBkb2N1bWVudC4NCj4gDQo+IERpZCB5b3Ugbm90aWNlIHRo YXQgU2VjdGlvbiAzLjUuNSBhZHZpc2VzIGRpc2NhcmRpbmcgSVB2NiBwYWNrZXRzIHdob3NlDQo+ IE5leHQNCj4gSGVhZGVyIHZhbHVlIGlzIHVua25vd24gLS0gaS5lLiwgSVB2NiBwYWNrZXRzIHdp dGggdW5rbm93biBFSHMgKipvcioqDQo+IHVua25vd24NCj4gdHJhbnNwb3J0IHByb3RvY29scz8g IEV2ZW4gZm9yIGFuIElQdjYgY29yZSByb3V0ZXIgaW4gdGhlIG9wZW4NCj4gSW50ZXJuZXQ/DQoN CkdpdmVuIHRoZSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgb2YgTkFUL05BUFQgYW5kIGZpcmV3YWxs cywgd2hpY2ggd2lsbCB0eXBpY2FsbHkgZHJvcCBwYWNrZXRzIHdpdGggdW5rbm93biB0cmFuc3Bv cnQgcHJvdG9jb2xzIGJ5IGRlZmF1bHQgKEFGQUlLVCksIEkgaGF2ZSBkb3VidHMgdGhhdCBpbXBs ZW1lbnRpbmcgdGhlIHN1Z2dlc3RlZCBwb2xpY3kgaW4gSVB2NiBjb3JlIHJvdXRlcnMgY2hhbmdl cyB0aGUgb3ZlcmFsbCBzaXR1YXRpb24gc2lnbmlmaWNhbnRseS4gDQoNClVuZm9ydHVuYXRlbHks IHRoZSByZWFsaXR5IGlzIHRoYXQgaXQgaXMgdG9kYXkgY2hhbGxlbmdpbmcgdG8gZGVwbG95IG5l dyB0cmFuc3BvcnQgcHJvdG9jb2xzIGluIHRoZSBJbnRlcm5ldCwgbm8gbWF0dGVyIHdoYXQgdGhp cyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHdyaXRlcy4NCg0KPiBJZiBub3QsIHdvdWxkIHRoYXQg ZmFjdCBjaGFuZ2UgeW91ciBhc3Nlc3NtZW50IG9mIHRoaXMgZG9jdW1lbnQ/DQoNCkkgc2hvdWxk IHBlcmhhcHMgaGF2ZSBiZXR0ZXIgaGlnaGxpZ2h0ZWQgdGhlIGltcGFjdCBvbiB1bmtub3duIHRy YW5zcG9ydCBwcm90b2NvbHMuIFlldCwgdGhlIHJlYWwtd29ybGQgaW1wYWN0IG9uIHRyYW5zcG9y dCBwcm90b2NvbHMgaXMgSU1ITyBzbWFsbC4NCg0KQXMgYSBzaWRlIG5vdGUsIGlmIHRoZSBkb2N1 bWVudCBoZWFkZWQgZm9yIEJDUCwgSSB3b3VsZCBiZSBtb3JlIGNvbmNlcm5lZC4NCiANCj4gQXMg SSBub3RlZCBpbiBteSBvd24gbGFzdCBjYWxsIGNvbW1lbnRzLCBJIHRoaW5rIHRoYXQgYSBtb3Jl IG51YW5jZWQNCj4gYXBwcm9hY2gNCj4gaXMgY2FsbGVkIGZvciAoZS5nLiwgYXMgc2V0IGZvcnRo IGluIFNlY3Rpb24gNC40LjUgZm9yIHVua25vd24gb3B0aW9uDQo+IHZhbHVlcykuDQoNCkkgd2ls bCBub3QgZGlzYWdyZWUgd2l0aCB1c2luZyBhIG1vcmUgbnVhbmNlZCBhcHByb2FjaC4NCg0KTWlj aGFlbA0K From nobody Sat Nov 24 13:00:14 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C692130FB4; Sat, 24 Nov 2018 13:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 2y8mjjMjg9ln; Sat, 24 Nov 2018 13:00:04 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 EA534130DF5; Sat, 24 Nov 2018 13:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+MoP7R2+a04+i3n9p6SbNoqws5HPUEwM+qCHV09lihk=; b=ZXMZ5FApn/pMbUGyIpT/rZ5sE MhAXNBHCCn67QDEo73LXopCHLnkThb3FqEJsxEnFQVJraMSsNTrIKl1aPV6UwwVpP/U/bNNK7kI9M ojcDkbyfoCgO3g9WWYU46e2jmzALKi3KSYzUXusIdbEj5Askzm3gYVNdCUf6y9YBCwb/T+OqbPukj v+AqNm+3/MdwzXdo9JYH7mb/YmS/rksEloGfpxzt+Fx8KlPzubmhiMbAzYlSrIICMjQBsxw8E1Rt/ chn1ie+vGjxtuHAA0cT0B7oXjEOr2YnyQ6jciREzdCYcP7mwOTDJXRPxn1VeatWzq8L1ma+oUcUPH 3f2t0jecg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50414 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gQf1z-000PZt-7o; Sat, 24 Nov 2018 16:00:01 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> Date: Sat, 24 Nov 2018 12:59:58 -0800 Cc: Michael Scharf , tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 21:00:06 -0000 The problem is operators using this advice as if it were BCP - and later doc= s treating the suggestions as recommended advice.=20 This treats everything unknown as an attack (a disease I=E2=80=99ve noted in= many similar docs for years), where it should also consider that doing so i= s *itself* an attack on the very flexibility we design in as standard.=20 We really need to do a better job of not letting informational docs get out o= f hand this way.=20 Joe=20 > On Nov 24, 2018, at 12:21 PM, Brian E Carpenter wrote: >=20 >> On 2018-11-25 06:04, Joe Touch wrote: >> Equally worrisome that this doc appears to make recommendations that impl= y BCP, when it is merely informational. >>=20 >> IMO, it=E2=80=99s overstepping to do so. >=20 > Possibly, but it's not forbidden by rule, as far as I know. However, the > draft is inconsistent in its use of SHOULD vs should (see my previous > message for an example of a lower case should which might or might not > be intended pseudo-normatively). >=20 > Brian >>=20 >> Joe >>=20 >>> On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote: >>>=20 >>> Reviewer: Michael Scharf >>> Review result: Ready >>>=20 >>> This document has been reviewed as part of the transport area review tea= m's >>> ongoing effort to review key IETF documents. These comments were written= >>> primarily for the transport area directors, but are copied to the docume= nt's >>> authors and WG to allow them to address any issues raised and also to th= e IETF >>> discussion list for information. >>>=20 >>> When done at the time of IETF Last Call, the authors should consider thi= s >>> review as part of the last-call comments they receive. Please >>> always CC tsv-art@ietf.org if you reply to or forward this review. >>>=20 >>> I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no appa= rent >>> transport issues. The proposed filtering could slow down the deployment o= f >>> experimental protocols that use IPv6 options, but the tradeoffs are expl= ained >>> in the document. >>>=20 >>> Thanks >>>=20 >>> Michael >>>=20 >>=20 >>=20 >=20 From nobody Sat Nov 24 17:14:19 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F98126F72; Sat, 24 Nov 2018 17:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 sXbe962HIDCj; Sat, 24 Nov 2018 17:14:08 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AC31271FF; Sat, 24 Nov 2018 17:14:07 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:210c:d1bb:a94d:4108] (unknown [IPv6:2001:470:5:ac9:210c:d1bb:a94d:4108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 292F888EC9; Sun, 25 Nov 2018 02:13:57 +0100 (CET) To: "C. M. Heard" Cc: Michael Scharf , TSV-ART , OPSEC , IETF , draft-ietf-opsec-ipv6-eh-filtering@ietf.org References: From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <89aea476-6a06-5d06-f43f-b9e71b9fb546@si6networks.com> Date: Sat, 24 Nov 2018 22:07:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 01:14:11 -0000 On 24/11/18 17:13, C. M. Heard wrote: >> On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote: >> >> Reviewer: Michael Scharf >> Review result: Ready >> >> This document has been reviewed as part of the transport area review team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the document's >> authors and WG to allow them to address any issues raised and also to the IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider this >> review as part of the last-call comments they receive. Please >> always CC tsv-art at ietf.org if you reply to or forward this review. >> >> I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent >> transport issues. The proposed filtering could slow down the deployment of >> experimental protocols that use IPv6 options, but the tradeoffs are explained >> in the document. > > Did you notice that Section 3.5.5 advises discarding IPv6 packets whose Next > Header value is unknown -- i.e., IPv6 packets with unknown EHs **or** unknown > transport protocols? Even for an IPv6 core router in the open Internet? The document gos in line with RFC7045. Not sure what the issues is here... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Nov 24 17:14:33 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF921310A2; Sat, 24 Nov 2018 17:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 p7CYTE6iAlK2; Sat, 24 Nov 2018 17:14:12 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48397128C65; Sat, 24 Nov 2018 17:14:12 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:210c:d1bb:a94d:4108] (unknown [IPv6:2001:470:5:ac9:210c:d1bb:a94d:4108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B397D88F03; Sun, 25 Nov 2018 02:14:07 +0100 (CET) To: Brian E Carpenter , Joe Touch , Michael Scharf Cc: tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <7306f52b-5960-d305-aaca-5026b5d33051@si6networks.com> Date: Sat, 24 Nov 2018 22:08:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 01:14:26 -0000 On 24/11/18 17:21, Brian E Carpenter wrote: > On 2018-11-25 06:04, Joe Touch wrote: >> Equally worrisome that this doc appears to make recommendations that imply BCP, when it is merely informational. >> >> IMO, it’s overstepping to do so. > > Possibly, but it's not forbidden by rule, as far as I know. However, the > draft is inconsistent in its use of SHOULD vs should (see my previous > message for an example of a lower case should which might or might not > be intended pseudo-normatively). Ack. We will make sure there's consistent use. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Nov 24 17:14:59 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7A21310B9; Sat, 24 Nov 2018 17:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iu75JeYKA6E0; Sat, 24 Nov 2018 17:14:20 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF071310B4; Sat, 24 Nov 2018 17:14:19 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:210c:d1bb:a94d:4108] (unknown [IPv6:2001:470:5:ac9:210c:d1bb:a94d:4108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9805C88EF3; Sun, 25 Nov 2018 02:14:13 +0100 (CET) To: Joe Touch , Brian E Carpenter Cc: Michael Scharf , tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sat, 24 Nov 2018 22:13:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 01:14:33 -0000 Joe, On 24/11/18 17:59, Joe Touch wrote: > The problem is operators using this advice as if it were BCP - and later docs treating the suggestions as recommended advice. > > This treats everything unknown as an attack (a disease I’ve noted in many similar docs for years), where it should also consider that doing so is *itself* an attack on the very flexibility we design in as standard. This is the reality: RFC7872. We should consider claiming vitory if somehow people were to follow the advice in this draft. This is what happens in the operations camp: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03- Ironically, the possible harm you apparently see behind this document is, from an operations-reality pov, kind of a very idealistic take. -- the situation right now is that you cannot use EHs reliably on the Internet. If if you even expect non-standardized EHs to go through, then, while nice, that expectation really needs a reality-check. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Nov 24 18:49:22 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D081912D4E9; Sat, 24 Nov 2018 18:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 6CPRU9oWlD0I; Sat, 24 Nov 2018 18:49:12 -0800 (PST) Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C980128CF3; Sat, 24 Nov 2018 18:49:12 -0800 (PST) Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 969D12B114; Sat, 24 Nov 2018 21:49:11 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=/TVQ0hmRctD7oLFNHx/laslBKlA=; b=DDSCdE jwmpDOLt/peBTQ7dVZ7WI1rgYzDYngeEKz5U0WLcwLvOJAEjknJMGgRf/qCeNKeE 3/L5o4I3J1CetGocqrNwQOtbZnoCXevWoGFdiUmh0ygEVCbhPK5PWPxuHQMy4ur6 3wn6+32XhgfIRjgnTqramLRHCwEMIdnWHec4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=gFgYCreN8DmfQsjjfs9Ae09IMkIE7vXJ 7Q7Xy5IspV1ZaUdNEz32JQmzE6+j9dYpuwCZ6itwbSnclnJ/bq0EXuYooHhG+RbW uUh2qelIV6qZpOm8sEm3fksSt2cE843VKZSE3O1T0KjRDe7NGR3HlyuSkwIdaR8g nJm72L61Fmw= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 8EB2C2B113; Sat, 24 Nov 2018 21:49:11 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-io1-f44.google.com (unknown [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 15CE92B110; Sat, 24 Nov 2018 21:49:09 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-io1-f44.google.com with SMTP id s22so11331381ioc.8; Sat, 24 Nov 2018 18:49:09 -0800 (PST) X-Gm-Message-State: AA+aEWZLZYSoVJR2Kp4Ds2DWMVp4YTyBSLS5ucqKOkPY7xnh5VYssiU8 qXTbo+HzvOyLuXufoJFblXe7HGTLsB1BKqShC7w= X-Google-Smtp-Source: AFSGD/VBGWMjPSm47mQjqp7p6UEY2UU7UZFUF8qxQKXS8hKQ4r6d04SzJ4Rsn0s3zu5g6j5NFKl/ISAGPf/JvhmYrz8= X-Received: by 2002:a6b:7307:: with SMTP id e7-v6mr10527449ioh.94.1543114147790; Sat, 24 Nov 2018 18:49:07 -0800 (PST) MIME-Version: 1.0 References: <89aea476-6a06-5d06-f43f-b9e71b9fb546@si6networks.com> In-Reply-To: <89aea476-6a06-5d06-f43f-b9e71b9fb546@si6networks.com> From: "C. M. Heard" Date: Sat, 24 Nov 2018 18:48:55 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: Michael Scharf , TSV-ART , OPSEC , IETF , draft-ietf-opsec-ipv6-eh-filtering@ietf.org Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: AE8EBCBA-F05C-11E8-94A8-CC883AD79A78-06080547!pb-smtp21.pobox.com Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 02:49:14 -0000 On Sat, Nov 24, 2018 at 5:14 PM Fernando Gont wrote: > On 24/11/18 17:13, C. M. Heard wrote: > >> On Nov 23, 2018, at 11:53 AM, Michael Scharf wrote: > >> > >> Reviewer: Michael Scharf > >> Review result: Ready > >> > >> This document has been reviewed as part of the transport area review team's > >> ongoing effort to review key IETF documents. These comments were written > >> primarily for the transport area directors, but are copied to the document's > >> authors and WG to allow them to address any issues raised and also to the IETF > >> discussion list for information. > >> > >> When done at the time of IETF Last Call, the authors should consider this > >> review as part of the last-call comments they receive. Please > >> always CC tsv-art at ietf.org if you reply to or forward this review. > >> > >> I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent > >> transport issues. The proposed filtering could slow down the deployment of > >> experimental protocols that use IPv6 options, but the tradeoffs are explained > >> in the document. > > > > Did you notice that Section 3.5.5 advises discarding IPv6 packets whose Next > > Header value is unknown -- i.e., IPv6 packets with unknown EHs **or** unknown > > transport protocols? Even for an IPv6 core router in the open Internet? > > The document gos in line with RFC7045. Not sure what the issues is here... RFC 7045 requires that treatment of unknown Next Header codepoints be configurable and says that the default configuration MAY be to discard. The draft advises all operators to select the discard option. As Brian Carpenter pointed out in his response to the thread started by my last call comments, that effectively trumps the MAY in RFC 7045 with a lower case should. So it really is not in line with RFC 7045. That's one problem. And as Joe Touch said, treating every unknown codepoint as an attack is itself an attack. Remember, the advice in the draft is directed to operators of **transit routers**, including core routers in the open Internet, and applies to traffic not directed to the router. So the purpose is to protect downstream infrastructure and customers. But customers who want to use new transport protocols will be harmed, not protected, by the discarding of packets with Next Header values that are unknown to the operator of the router. Biasing the advice in this way exacerbates the very protocol ossification issues that the draft purports to want to solve. That's a much bigger problem. I think that you and your co-author did a good job in Section 4.5 with unknown options; there the advice is much more nuanced, instead of being biased toward the blanket default-deny policy that got us into the ossification mess in the first place. Why not give the same advice for unknown Next Header codepoints, as I suggested in my last call comments? Or leave the advice neutral, as Brian suggested? Mike Heard From nobody Sat Nov 24 22:25:10 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3743A129BBF; Sat, 24 Nov 2018 22:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 fJeOHJyxqOxq; Sat, 24 Nov 2018 22:25:02 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 261A7123FFD; Sat, 24 Nov 2018 22:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cS+Qa8755rBbpCtk9mN5mFw+CkFWzva2apyjLz6VoME=; b=db9Tcu/mIlqYO/L1u4rOpJ+gF CKXmw58uWuIPc5rJ7uhNDRHz/3mWMN7wOqxJstp+8EvnBKPY4GMJNGAprrmHzPlzImSAnd0vGFApJ tI2NB6IUxlrS3FAyGOmSyvH+Iy7zrodDspgUXTMcyUjt4uAqgmMghkiXUVlM1IhATxjMhrMV7zQI2 dnOCocpWilG7bXGE6/XDNRBjdmQruIUJUZtRZ8rGAJoU0JUCLZp2K3+m++dZUbKjO7jNhxTy9dfZa hqCmj9oB7BhkX3xT+gEnhONLE0l8uhnwqG6gbBKi1yYhOcFs/c8rnrUwoa/MQOvdlC2knhcha0tIp SO9sl+Pmg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52871 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gQnqh-003Awk-Kc; Sun, 25 Nov 2018 01:24:59 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: Date: Sat, 24 Nov 2018 22:24:55 -0800 Cc: Brian E Carpenter , Michael Scharf , tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> To: Fernando Gont X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 06:25:04 -0000 The reality is that standards are not followed, agreed. That does not imply t= hat we need to relax those standards - instead, it can be reason to fix brok= en devices.=20 Working at the level of the most broken device is no way to run a production= Internet. And claiming that doing so is appropriate for security reasons is just as br= oken, as it always has been. Joe > On Nov 24, 2018, at 5:13 PM, Fernando Gont wrote: >=20 > Joe, >=20 >> On 24/11/18 17:59, Joe Touch wrote: >> The problem is operators using this advice as if it were BCP - and later d= ocs treating the suggestions as recommended advice.=20 >>=20 >> This treats everything unknown as an attack (a disease I=E2=80=99ve noted= in many similar docs for years), where it should also consider that doing s= o is *itself* an attack on the very flexibility we design in as standard.=20= >=20 > This is the reality: RFC7872. >=20 > We should consider claiming vitory if somehow people were to follow the > advice in this draft. >=20 > This is what happens in the operations camp: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03- >=20 > Ironically, the possible harm you apparently see behind this document > is, from an operations-reality pov, kind of a very idealistic take. -- > the situation right now is that you cannot use EHs reliably on the > Internet. If if you even expect non-standardized EHs to go through, > then, while nice, that expectation really needs a reality-check. >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Sun Nov 25 05:00:15 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9261288EB; Sun, 25 Nov 2018 05:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 c6LiscVU30Sv; Sun, 25 Nov 2018 05:00:03 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32961277BB; Sun, 25 Nov 2018 05:00:02 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAPCxvIx012227 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Nov 2018 12:59:59 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Joe Touch Cc: Fernando Gont , ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> From: Nick Hilliard Message-ID: <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> Date: Sun, 25 Nov 2018 12:59:55 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 13:00:06 -0000 Joe Touch wrote on 25/11/2018 06:24: > The reality is that standards are not followed, agreed. That does not > imply that we need to relax those standards - instead, it can be > reason to fix broken devices. > > Working at the level of the most broken device is no way to run a > production Internet. > > And claiming that doing so is appropriate for security reasons is > just as broken, as it always has been. Joe, another point of view would be that operator feedback should be welcomed because sometimes protocols are found to be difficult to implement fully, or when implemented fully cause unforeseen consequences. EHs are a good example of this. When originally conceived - for the best of intentions - the spec was sufficiently loose that they were not just unimplementable from a practical point of view, but the spec was open to protocol level security problems. RFC7112 describes some issues relating to EHs, but there are plenty of other examples. How, where and when to filter EH packets creates a bind, no doubt about it. Some EHs are intrinsically troublesome (e.g. anything with hbh processing requirements); others can be processed without issues. The IETF can choose to ignore this problem or get involved and have some influence about what might constitute best practice. If this happens, vendors might even fix some of their silicon. Declaring that the problem exists only on one side won't make the Internet better. Nick From nobody Sun Nov 25 07:53:58 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4E312E043; Sun, 25 Nov 2018 07:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 kdNWq6e51UYC; Sun, 25 Nov 2018 07:53:53 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 45A6D128766; Sun, 25 Nov 2018 07:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SlIthBMQn84W1Lzko9ITzfs9m96qw9dgqr3YzzNrmlE=; b=TNoYenUm17oc08SGvbHyl5UfD 5oZnQMygt4CFrMIeGcIo7GT+f3Or4cVmMlyPASw0WnnIjlbPCdTMYkRNm6vMvTS7zGKkT70zBxeCH eol0ByqoQTL7yqa3Q5Sv3SWsOw0EjTcWFAX+5w5bgWyAIWXeC0vbrXNSE8gBfRmTfFnuPUMDWRpPc 48sDCr9hJQHzcIKNeg7mPzJwyVU/9m8pXn73y3qKiM/mkXAtnzy5yXlKepDylk65IQcdDeS/1wfFv tfCIvGNXagF7JGrZkaZYM7D3nNer0Wb7ZqKyI0o3EfX13P6j9MT4eMzFpmm4hX+YfLWJy7NTGe8Vj pgqu6Eg7g==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58013 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gQwjA-001rdL-7b; Sun, 25 Nov 2018 10:53:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> Date: Sun, 25 Nov 2018 07:53:43 -0800 Cc: OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, tsv-art Content-Transfer-Encoding: quoted-printable Message-Id: <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 15:53:55 -0000 A reasoned discussion of the pros and cons would be useful. What we have is the perspective, often heavily represented by vendors = and operators, of the driving reality that: a) implementing extended features is an attack on profits b) properly configuring and monitoring extended features is an attack on = effort A reasoned argument would be useful. That is not what has been = repeatedly presented, IMO. Joe > On Nov 25, 2018, at 4:59 AM, Nick Hilliard wrote: >=20 > Joe Touch wrote on 25/11/2018 06:24: >> The reality is that standards are not followed, agreed. That does not >> imply that we need to relax those standards - instead, it can be >> reason to fix broken devices. >> Working at the level of the most broken device is no way to run a >> production Internet. >> And claiming that doing so is appropriate for security reasons is >> just as broken, as it always has been. > Joe, >=20 > another point of view would be that operator feedback should be = welcomed because sometimes protocols are found to be difficult to = implement fully, or when implemented fully cause unforeseen = consequences. EHs are a good example of this. When originally = conceived - for the best of intentions - the spec was sufficiently loose = that they were not just unimplementable from a practical point of view, = but the spec was open to protocol level security problems. RFC7112 = describes some issues relating to EHs, but there are plenty of other = examples. >=20 > How, where and when to filter EH packets creates a bind, no doubt = about it. Some EHs are intrinsically troublesome (e.g. anything with hbh = processing requirements); others can be processed without issues. The = IETF can choose to ignore this problem or get involved and have some = influence about what might constitute best practice. If this happens, = vendors might even fix some of their silicon. Declaring that the = problem exists only on one side won't make the Internet better. >=20 > Nick >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Sun Nov 25 11:40:44 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72653124BE5; Sun, 25 Nov 2018 11:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 P1uRae9jwOyy; Sun, 25 Nov 2018 11:40:33 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51137124C04; Sun, 25 Nov 2018 11:40:33 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id b7so5481753pfi.8; Sun, 25 Nov 2018 11:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xEfWtHQWPhP5rEavMQM8XLzb12zinNxjuNfpGSOhRGU=; b=k13oIopwFn/OLyrxLCtgMPGJ2jMWq6akyNLZsCAmuUwMoD22gTOVxF+9FVexp5sDYJ iaapaDJXg8ILuEpjAI6ui04GRdn90fYSj5WWIFssSPkgmTW3oCK2zVo0xDOJ1XJnDf5s CWMtZjlyIZFhZKWzKeV1Yi0RjvOnopRZp/Q9bQ+hZxQQB2HCErUxXSAz6uam0eazfutK sd0DMq1ITupdQGmkG5ZZ7YaVTVKCGbKUbPEibq1YETNKsS3UKht0wg9nXX+RGoTRRogy ixPrO4cSjZTy9+xaldXEUxyqBA2s3nLUKcEQcg1tRoVjdeBWC/ST6pGeAliDeWEvXu+m 2CUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xEfWtHQWPhP5rEavMQM8XLzb12zinNxjuNfpGSOhRGU=; b=PjOINDkCDw3xLriEShRpgbEK7zifJ+BMA52Z3YecGDnGhZNEp9dhSp7PKUkGbyGPVB uvVTQZrvwaQdqwKD3Mj3qT3TF/GeV16sgB8tVma8dfMQpUPcPVMTCeiiYtDv7GwOHJ1P tTUXcs9Pvs7f8YAnVDcG8BIgE5P4hjjXs4i2skpxQyf2Ro3Ox6KvZlVd+pHB/2mTFbye uHg8eP02Ae6ss6K25pJyRWh2IYf+toPSXtWi4iDxY8ip2f9FkWsda/boyV1ZHEwsmGMg zkwHz6D8iNynC9DfIqPY+SSzLtOtSN3J4XjAc/asVNnukyKwM3A90tCQfQo0GUtcXpSf DxQw== X-Gm-Message-State: AGRZ1gKWaKKEYdtk9AKlFLGNG/XFpOnNGSHimMNH1PG8Zlwi2dO6knrz 48aK48ojZsc5Tq7TCeTIEuy1KoxP X-Google-Smtp-Source: AJdET5cyauuVbR4H2orFdKEcYTInh7bcXu4ZlHhby/RqjQNJ9hfA60BBqOPD6YH3s0sewsDTsBe97g== X-Received: by 2002:a62:d504:: with SMTP id d4mr24623957pfg.38.1543174832641; Sun, 25 Nov 2018 11:40:32 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f193-v6sm89180383pfc.74.2018.11.25.11.40.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Nov 2018 11:40:31 -0800 (PST) To: Joe Touch , Nick Hilliard Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> From: Brian E Carpenter Message-ID: <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> Date: Mon, 26 Nov 2018 08:40:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 19:40:36 -0000 On 2018-11-26 04:53, Joe Touch wrote: > A reasoned discussion of the pros and cons would be useful. > > What we have is the perspective, often heavily represented by vendors and operators, of the driving reality that: > > a) implementing extended features is an attack on profits > b) properly configuring and monitoring extended features is an attack on effort > > A reasoned argument would be useful. That is not what has been repeatedly presented, IMO. I don't think that's entirely fair to RFC7045. But the fact is that there's a tussle here between the desire for the ability to deploy new protocols freely, and the desire for the ability to block potentially harmful or malicious traffic. The definition of "harmful or malicious" is not universally agreed. "Harmful to my business model" is certainly one possible interpretation. But then, we decided to implement the Internet as a largely unregulated competitive system, so we got tussles. As far as I can tell, there is nothing much that the IETF can do about this. Brian > > Joe > >> On Nov 25, 2018, at 4:59 AM, Nick Hilliard wrote: >> >> Joe Touch wrote on 25/11/2018 06:24: >>> The reality is that standards are not followed, agreed. That does not >>> imply that we need to relax those standards - instead, it can be >>> reason to fix broken devices. >>> Working at the level of the most broken device is no way to run a >>> production Internet. >>> And claiming that doing so is appropriate for security reasons is >>> just as broken, as it always has been. >> Joe, >> >> another point of view would be that operator feedback should be welcomed because sometimes protocols are found to be difficult to implement fully, or when implemented fully cause unforeseen consequences. EHs are a good example of this. When originally conceived - for the best of intentions - the spec was sufficiently loose that they were not just unimplementable from a practical point of view, but the spec was open to protocol level security problems. RFC7112 describes some issues relating to EHs, but there are plenty of other examples. >> >> How, where and when to filter EH packets creates a bind, no doubt about it. Some EHs are intrinsically troublesome (e.g. anything with hbh processing requirements); others can be processed without issues. The IETF can choose to ignore this problem or get involved and have some influence about what might constitute best practice. If this happens, vendors might even fix some of their silicon. Declaring that the problem exists only on one side won't make the Internet better. >> >> Nick >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art > > From nobody Sun Nov 25 12:00:00 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E301288EB; Sun, 25 Nov 2018 11:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 43ipZFMaYCjS; Sun, 25 Nov 2018 11:59:56 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 895BF130DD5; Sun, 25 Nov 2018 11:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+ROmmk6lAezTC1hWUjn1ICwRLKoES12Xh9Pobk0tuVo=; b=5x+LnNVzeJ4K0jKpBHnUL44pn 3aZAFI6rKmFzOC16BoNu+Y9kBB6Y7GDI+pXq/yF6/pSi61zMq4sglKKkKMpS9AGMKqpajT9irMdvu ObYg67yI8qRXehVyCXDoB13+Rfjh0C+qT/ZaSeqm5H6PSKZh6KAzM+bVCY/DgrqT/0PgG9MHV9tn5 5dPUZdbpMR7CHowfon6jvt8GJkzmbMYxZ5gCnjb8NQNptr9yupkd979TzGaZRWR8ltXWXAd4M4OoJ Tcpl6bSSYIT2Z7CcBLN9MvYKQGoWl6DTojvx6T4bZGDErsaZEaQ0X5xSdwQpMLbVw+sGxIj2gn5So SKfmvzYsg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58898 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gR0ZN-000vlS-FZ; Sun, 25 Nov 2018 14:59:54 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_C91DC369-1C49-485F-A182-2C93DEC670C7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> Date: Sun, 25 Nov 2018 11:59:51 -0800 Cc: Nick Hilliard , tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-Id: <23BAEC4E-218A-40EE-A814-EC73D7D7257D@strayalpha.com> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 19:59:58 -0000 --Apple-Mail=_C91DC369-1C49-485F-A182-2C93DEC670C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We can - and should - push back. Not all RFCs need to be published. Joe > On Nov 25, 2018, at 11:40 AM, Brian E Carpenter = wrote: >=20 > As far as I can tell, there is nothing much that the IETF can do about > this. >=20 > Brian --Apple-Mail=_C91DC369-1C49-485F-A182-2C93DEC670C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We = can - and should - push back. Not all RFCs need to be published.

Joe
On Nov = 25, 2018, at 11:40 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

As far as I can tell, there is = nothing much that the IETF can do about
this.

   Brian

= --Apple-Mail=_C91DC369-1C49-485F-A182-2C93DEC670C7-- From nobody Sun Nov 25 12:40:29 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C9F130DE9 for ; Sun, 25 Nov 2018 12:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 fwXBCzJq-P_f for ; Sun, 25 Nov 2018 12:40:23 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 C87B71277C8 for ; Sun, 25 Nov 2018 12:40:22 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gR1CU-0005Uy-Oz for opsec@ietf.org; Sun, 25 Nov 2018 21:40:21 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gR1CK-0000sm-5k for opsec@ietf.org; Sun, 25 Nov 2018 15:40:11 -0500 Received: (qmail 4314 invoked from network); 25 Nov 2018 20:40:03 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.25]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Nov 2018 20:40:03 -0000 To: Brian E Carpenter , Joe Touch , Nick Hilliard Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> Date: Sun, 25 Nov 2018 12:40:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> Content-Type: multipart/alternative; boundary="------------D59ADFBAB31468BBF2A117B1" Content-Language: en-US X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.29) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rB4yPWYUCSdtdMqNq5uX95602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO8xElEi180GZlZa73Jjp9N9Vjyn5UrUp4n4yKOOaq9AxJzSEoo0x3cYahtdaCv2Ys1Dj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5kOBMxD5VtLQHqGLqtq4lLk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMSgqww/sH3oqDsjN9lr2KdKojmX5u6QQ8A3tr7Vu+yOd0EhBVPMF2Hy 7YpI9X1VqRtG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t82t4C4SlaCuF6Oqyplz7a94E pv+Z3RfD+aRmwAVlEJHcERWeKKG4PAQYNyavp7c49PCP5Oeh0wumTJN3GP8dadTSGe3okMCcn14J 4XO+5ud/R1YD8d9BO0n0N9r2tzpuEp9PHdc2AGfUzj/Tvun6/2nRZ4YizZEe9VMcrJA1TtxdO4nN PsCHvSRYJiL/wE4eDk2AHKlQN6UeX0rDTzUF5HWi47L87arFMl038BorKljQ15Q6CZxYjafGpi3c b03a4ZFy04e73oo5Jp1iUunX3+VlFawbDxpzYifNwA/+CbHA2fz9gpiGyR7D15JIzS+z7i8K8WY4 szo4Gwow0vwlYMfpTQuMHNi5DO10BOGC1ZJT0NaIcaHtK0XZjSPnTTBX4w== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 20:40:26 -0000 This is a multi-part message in MIME format. --------------D59ADFBAB31468BBF2A117B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/25/2018 11:40 AM, Brian E Carpenter wrote: > On 2018-11-26 04:53, Joe Touch wrote: >> A reasoned discussion of the pros and cons would be useful. >> >> What we have is the perspective, often heavily represented by vendors = and operators, of the driving reality that: >> >> a) implementing extended features is an attack on profits >> b) properly configuring and monitoring extended features is an attack = on effort >> >> A reasoned argument would be useful. That is not what has been repeate= dly presented, IMO. > I don't think that's entirely fair to RFC7045. But the fact is that > there's a tussle here between the desire for the ability to deploy > new protocols freely, and the desire for the ability to block > potentially harmful or malicious traffic. The definition of "harmful > or malicious" is not universally agreed. "Harmful to my business model"= > is certainly one possible interpretation. But then, we decided to > implement the Internet as a largely unregulated competitive system, > so we got tussles. I am concerned that this draft is attempting to weight the scales and favor one side of this ongoing tussle, which leads to something like "ossification in the name of security". I think that's a huge overreach. I would like to have a very general caveat at the beginning of the draft, explaining that it is perfectly fine to deploy routers that do not perform any such filtering and simply forward the packets. We need something significantly more forceful than merely saying that the short statement in section 2.3. The policies that it describes are plausible for specialized filtering devices such as firewalls, but the draft proposes adopting these policies for "transit routers", an ill defined term that could cover pretty much every router in the the Internet. There is a big difference there. Security devices are engineered to implement specific policies, and come with management systems to update these policies over time. Nick made that point, probably unintentionally, when he wrote that "transit operators would generally take the view that any data-plane packet which needs to be put through a slow path will be rate limited up to 100% loss". Last I checked, data plane processing is implemented in specialized components that are designed for speed. I am quite concerned that filtering recommendations made by the IETF will end up deeply embedded in the hardware of at least some routers, and that changing them in the future would be quite hard. That's pretty much the recipe for ossification. I am also concerned that the filtering is justified by "security considerations", but that with the exception of the HBH header these considerations apply to end points, not to transit router. Take the example of the experimental options, described in section 3.4.10. The consideration says that "implications of these EHs will depend on their specific use." It fails to mention any security consequence for the transit router that would fail to filter these options. In the absence of filtering, the packets will arrive at the end system, where they will be processed if the end system is part of the experiment, or treated as unwanted traffic if the end system is not part of that experiment. There definitely will not be any harmful effect for the router that passed the traffic. I understand that unwanted traffic can be used in denial of service attacks. But then, any traffic profile can be used in such attacks. The attacker who can inject packets with EH=3D253 can also, for example, inject arbitrary TCP segments, or spoofed EH packets. I also understand the desire to protect end systems from unwanted traffic. There is a history of attacks performed by various kind of "magic packets" that cause a catastrophic failure in some target systems. But it does not follow that such protection should be implement by coarse policies hardwired in every router on the Internet. The definition of these attacks changes over time, and it would be folly to implement these rules in systems that lack management capabilities. The proper place for that is specialized security functions, not in general purpose routers. I am also concerned that the draft does not define the difference between EH options and IPv6 payload types. The IPv6 header contains a "payload type" field, that may legitimately contain any of the payload types defined in the IANA registry of protocol numbers (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml= ). Some of those payload types are flagged as IPv6 extension header types and listed in the corresponding registry (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml).= Discussing EH without discussing the other payload types seems bizarre. Do the reasons for blocking for the experimental payload type 253 also apply to, for example, the UDP Lite payload type? What about discussing ESP and not discussing L2TP or MANET? -- Christian Huitema -- Christian Huitema --------------D59ADFBAB31468BBF2A117B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/25/2018 11:40 AM, Brian E Carpenter wrote:
On 2018-11-26 04:53, Joe Touch wrote:

A reasoned discussion of the pros and cons would be useful.

What we have is the perspective, often heavily represented by vendors and operators, of the driving reality that:

a) implementing extended features is an attack on profits
b) properly configuring and monitoring extended features is an attack on effort

A reasoned argument would be useful. That is not what has been repeatedly presented, IMO.

I don't think that's entirely fair to RFC7045. But the fact is that
there's a tussle here between the desire for the ability to deploy
new protocols freely, and the desire for the ability to block
potentially harmful or malicious traffic. The definition of "harmful
or malicious" is not universally agreed. "Harmful to my business model"
is certainly one possible interpretation. But then, we decided to
implement the Internet as a largely unregulated competitive system,
so we got tussles.

I am concerned that this draft is attempting to weight the scales and favor one side of this ongoing tussle, which leads to something like "ossification in the name of security". I think that's a huge overreach. I would like to have a very general caveat at the beginning of the draft, explaining that it is perfectly fine to deploy routers that do not perform any such filtering and simply forward the packets. We need something significantly more forceful than merely saying that the short statement in section 2.3.

The policies that it describes are plausible for specialized filtering devices such as firewalls, but the draft proposes adopting these policies for "transit routers", an ill defined term that could cover pretty much every router in the the Internet. There is a big difference there. Security devices are engineered to implement specific policies, and come with management systems to update these policies over time.

Nick made that point, probably unintentionally, when he wrote that "transit operators would generally take the view that any data-plane packet which needs to be put through a slow path will be rate limited up to 100% loss". Last I checked, data plane processing is implemented in specialized components that are designed for speed. I am quite concerned that filtering recommendations made by the IETF will end up deeply embedded in the hardware of at least some routers, and that changing them in the future would be quite hard. That's pretty much the recipe for ossification.

I am also concerned that the filtering is justified by "security considerations", but that with the exception of the HBH header these considerations apply to end points, not to transit router. Take the example of the experimental options, described in section 3.4.10. The consideration says that "implications of these EHs will depend on their specific use." It fails to mention any security consequence for the transit router that would fail to filter these options. In the absence of filtering, the packets will arrive at the end system, where they will be processed if the end system is part of the experiment, or treated as unwanted traffic if the end system is not part of that experiment. There definitely will not be any harmful effect for the router that passed the traffic.

I understand that unwanted traffic can be used in denial of service attacks. But then, any traffic profile can be used in such attacks. The attacker who can inject packets with EH=253 can also, for example, inject arbitrary TCP segments, or spoofed EH packets. I also understand the desire to protect end systems from unwanted traffic. There is a history of attacks performed by various kind of "magic packets" that cause a catastrophic failure in some target systems. But it does not follow that such protection should be implement by coarse policies hardwired in every router on the Internet. The definition of these attacks changes over time, and it would be folly to implement these rules in systems that lack management capabilities. The proper place for that is specialized security functions, not in general purpose routers.

I am also concerned that the draft does not define the difference between EH options and IPv6 payload types. The IPv6 header contains a "payload type" field, that may legitimately contain any of the payload types defined in the IANA registry of protocol numbers (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Some of those payload types are flagged as IPv6 extension header types and listed in the corresponding registry (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml). Discussing EH without discussing the other payload types seems bizarre. Do the reasons for blocking for the experimental payload type 253 also apply to, for example, the UDP Lite payload type? What about discussing ESP and not discussing L2TP or MANET?

-- Christian Huitema


-- Christian Huitema



--------------D59ADFBAB31468BBF2A117B1-- From nobody Sun Nov 25 14:11:32 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7B130DD4; Sun, 25 Nov 2018 14:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 k1BJCWjoVtfV; Sun, 25 Nov 2018 14:11:21 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8E912D84D; Sun, 25 Nov 2018 14:11:20 -0800 (PST) X-Envelope-To: tsv-art@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAPMBErR076840 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Nov 2018 22:11:15 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Christian Huitema Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> From: Nick Hilliard Message-ID: <7225ddc0-7912-e985-ed18-796c7dddd45d@foobar.org> Date: Sun, 25 Nov 2018 22:11:12 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2018 22:11:24 -0000 Christian Huitema wrote on 25/11/2018 20:40: > Nick made that point, probably unintentionally, when he wrote that > "transit operators would generally take the view that any data-plane > packet which needs to be put through a slow path will be rate limited up > to 100% loss". Last I checked, data plane processing is implemented in > specialized components that are designed for speed. I was talking specifically about dfz transit routers, not edge devices or firewalls. There are exceptions to fast-path processing where data-plane packets are punted to management plane CPUs for generalised processing rather than being forwarded by the ASIC / NPU due to hardware inability to process the packets correctly (e.g. gigantic EH chains), or by protocol specification (e.g. hbh). What I said previously referred to control plane rate limiting of these types of data plane packets. Nick From nobody Sun Nov 25 17:31:39 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86F0130E71; Sun, 25 Nov 2018 17:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 It3i75L366Oj; Sun, 25 Nov 2018 17:31:36 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264FD130DC6; Sun, 25 Nov 2018 17:31:36 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id k8so2392441pls.11; Sun, 25 Nov 2018 17:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TNSncS/nArUhKCA/JocMcB9vVFTyzC76m0Ugi3T5sqM=; b=qhOaVcJ1aVxWn7SsA/m7zvjZULjh8m4FEKsbMMwFpqlm2zghGotG5NZYTRVT6C6L8n Rd4JlmPAKMZySJkkDVi6nxRLbRtMPMa3dCoPeAZ4iKzkJpMZKJneQ1BQgyhycUk4Vmyc II9Ntnj+q2W2PwA9El0uZOTlvvw/qSXQay1f19pxNllA9lmMvGBEID/2xv4hq5CSDU58 Kh5Iq0Vgky7ch4jTnFpXvj5fZg5ALGG5uALG+Q0XxRhipHvsAlKj2aGhUCfTm+hUnR/Q tr0UTQvDk2DemTThETlWlBRn9EnQb2rwH+576pt/Otz33IeDbtodNw5ybkQgUM13DeYw xv5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TNSncS/nArUhKCA/JocMcB9vVFTyzC76m0Ugi3T5sqM=; b=StMQXyD+zlCiWawZ4ytvQ1uPpLglRZ/kTXhgvLig1WrfKKt/XTnY640/bmTCG+1YHw 3331PxPqXad39GFKUryQ/6wDllY1PoOPONzSEz0JME2jx1zHqtwm+A7G2LJla2e4fgus 3N85bHFKUpnu8G7aCFdXKxpvceZBpEHyq7TEH1TnCIF8EI46uIc5KPlV3UfYbbOxrihS eOXNAC/eEeNF2jpuTmdq9darhhe+uOvYxYsk5E30izCrGl3OxB+U6yf0p8ALIcqlGlNI jIzlNbabo1skvlZEpfyM4LNcLG7IOUvUW8Z5eV/EV/pajdoz+czN3ZVTOaRxhfd+cwNN 07dg== X-Gm-Message-State: AA+aEWYrVChFpm6ACteuQAINfme6lgRSWw5wESqmoYPJy2pW+5KM6u8v rW1O1265jsK7KK7AifS2ks7Fjoxc X-Google-Smtp-Source: AFSGD/Wh7E+G/sZumbaYAbkguNtjxmWNgWnr2+x7K7lKAhpgDlXC5bHCrccTpsxK7Y0Qw60Wo6w6Lg== X-Received: by 2002:a17:902:7443:: with SMTP id e3mr22560162plt.304.1543195895328; Sun, 25 Nov 2018 17:31:35 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id z8sm36105176pgg.62.2018.11.25.17.31.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Nov 2018 17:31:34 -0800 (PST) To: Christian Huitema , Nick Hilliard Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <7225ddc0-7912-e985-ed18-796c7dddd45d@foobar.org> <10be961f-f2d1-5b8c-b859-18f6eba7429c@huitema.net> From: Brian E Carpenter Message-ID: <91094e34-6920-d169-dea8-9275989e6dba@gmail.com> Date: Mon, 26 Nov 2018 14:31:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <10be961f-f2d1-5b8c-b859-18f6eba7429c@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 01:31:38 -0000 On 2018-11-26 12:01, Christian Huitema wrote: >=20 > On 11/25/2018 2:11 PM, Nick Hilliard wrote: >> Christian Huitema wrote on 25/11/2018 20:40: >>> Nick made that point, probably unintentionally, when he wrote that >>> "transit operators would generally take the view that any data-plane >>> packet which needs to be put through a slow path will be rate limited= >>> up to 100% loss". Last I checked, data plane processing is >>> implemented in specialized components that are designed for speed. >> >> I was talking specifically about dfz transit routers, not edge devices= >> or firewalls. There are exceptions to fast-path processing where >> data-plane packets are punted to management plane CPUs for generalised= >> processing rather than being forwarded by the ASIC / NPU due to >> hardware inability to process the packets correctly (e.g. gigantic EH >> chains), or by protocol specification (e.g. hbh).=C2=A0 What I said >> previously referred to control plane rate limiting of these types of >> data plane packets. >=20 > I understand the limitation. My point is simply that a DFZ router with > such limitations has little business implementing filtering by payload > type. It is more likely to generate trouble tickets because > communication broke rather than praise because some unwanted traffic wa= s > filtered in transit, rather than at ingress or egress. In that case it seems that this section of the draft needs attention: 2.2. Applicability Statement This document provides advice on the filtering of IPv6 packets with EHs at transit routers for traffic *not* explicitly destined to such transit routers, for those cases in which such filtering is deemed as necessary. Brian From nobody Sun Nov 25 17:50:51 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE41130E71 for ; Sun, 25 Nov 2018 17:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 jkBLACxLx3yI for ; Sun, 25 Nov 2018 17:50:48 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5C2D0128AFB for ; Sun, 25 Nov 2018 17:50:47 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx61.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1gR3PN-0007wr-CJ for opsec@ietf.org; Mon, 26 Nov 2018 00:01:46 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gR3P3-0002LX-Tz for opsec@ietf.org; Sun, 25 Nov 2018 18:01:26 -0500 Received: (qmail 5517 invoked from network); 25 Nov 2018 23:01:24 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.25]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Nov 2018 23:01:23 -0000 To: Nick Hilliard Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <7225ddc0-7912-e985-ed18-796c7dddd45d@foobar.org> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <10be961f-f2d1-5b8c-b859-18f6eba7429c@huitema.net> Date: Sun, 25 Nov 2018 15:01:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <7225ddc0-7912-e985-ed18-796c7dddd45d@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 168.144.250.177 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5oOua6UwjJi58Wp/TH+FvE5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO8xElEi180GZlZa73Jjp9N9Vjyn5UrUp4n4yKOOaq9AxfUVEYaoMqb3A5ncYg4YWiFDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j52/TRjU7znIc9NYfKkdzfqE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMRfGK/Ioq0dRA5A4PDP/VsLPwUimsNGvJJilSn4u6QSZGuYHW1AXQxr HFyiEtlQSrAs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53hnWWE7pUS+axDCadwlynD/AMgFPp7+h3kLe NmBV53UGTeXkAoisBQkwclQC79NojzO2lR2/HyptV1hEplSxcGpRXxKF5tPxTxfD0dMN+t5ZAhpR IOiolR3/ONciC+CvY1eS4PDJI6jPaxiEMBYC07UoR+PypV5Z5Sfz/IlJBgJ66Y2WR4MiVFjj8UQT P/XooN40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 01:50:50 -0000 On 11/25/2018 2:11 PM, Nick Hilliard wrote: > Christian Huitema wrote on 25/11/2018 20:40: >> Nick made that point, probably unintentionally, when he wrote that >> "transit operators would generally take the view that any data-plane >> packet which needs to be put through a slow path will be rate limited >> up to 100% loss". Last I checked, data plane processing is >> implemented in specialized components that are designed for speed. > > I was talking specifically about dfz transit routers, not edge devices > or firewalls. There are exceptions to fast-path processing where > data-plane packets are punted to management plane CPUs for generalised > processing rather than being forwarded by the ASIC / NPU due to > hardware inability to process the packets correctly (e.g. gigantic EH > chains), or by protocol specification (e.g. hbh).  What I said > previously referred to control plane rate limiting of these types of > data plane packets. I understand the limitation. My point is simply that a DFZ router with such limitations has little business implementing filtering by payload type. It is more likely to generate trouble tickets because communication broke rather than praise because some unwanted traffic was filtered in transit, rather than at ingress or egress. -- Christian Huitema From nobody Sun Nov 25 21:16:52 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A74F130F28; Sun, 25 Nov 2018 21:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Yrs5VKR6NXaI; Sun, 25 Nov 2018 21:16:29 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 28564130F47; Sun, 25 Nov 2018 21:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HMVLuAV/d1OglGuuR7cqSI6rZy6nbUD5O1lGCxiraPU=; b=NSmzddPyvOnSAcJ74bYMGn4Mp jpi1kDQ2gtEXY9qyD9QNbKaBmLMMvSubEi0XVjMkznPmTB0m03Xcqt6t+bTWNPhGeAPQCMiVyADQp Ix1Wuyje+nwOzjv3vVgS3XegNsS44Jh6mS4qOZzIO75S62oDpiDhvyuwFcpwOHh/lERcXXivTsIjn BLiABHlBDu0S/uEXJno5MNKjiNyz/d3wMxIC+AypJybu2a5+3vPQPCO1zfm2kZi6s1GzzUU+TfzVa aile13JLlNdu02YGsGVdA+hoaq94+/j9DwoJrALcgvD4MWc05no7ZJ3SXNAOacGklgB9+RbYeji1z Q40W1MQDg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60108 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gR9Fw-004GyI-Ay; Mon, 26 Nov 2018 00:16:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_4D0C9849-2144-4A8B-AA42-CC93361B537B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> Date: Sun, 25 Nov 2018 21:16:23 -0800 Cc: Brian E Carpenter , Nick Hilliard , tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-Id: <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 05:16:37 -0000 --Apple-Mail=_4D0C9849-2144-4A8B-AA42-CC93361B537B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The core problem with this doc, IMO, is that: - packets that cannot be distinguished from legitimate traffic MUST NOT = be inferred as an attack - the use of resources appropriate for legitimate traffic MUST NOT be = interpreted as a vulnerability for that reason alone I.e., most of the analysis in this document is flat out incorrect in = assuming that merely because a packet could cause a router to do work = that it is a security risk to handle that packet as intended. Joe > On Nov 25, 2018, at 12:40 PM, Christian Huitema = wrote: >=20 >=20 > On 11/25/2018 11:40 AM, Brian E Carpenter wrote: >> On 2018-11-26 04:53, Joe Touch wrote: >>> A reasoned discussion of the pros and cons would be useful. >>>=20 >>> What we have is the perspective, often heavily represented by = vendors and operators, of the driving reality that: >>>=20 >>> a) implementing extended features is an attack on profits >>> b) properly configuring and monitoring extended features is an = attack on effort >>>=20 >>> A reasoned argument would be useful. That is not what has been = repeatedly presented, IMO. >> I don't think that's entirely fair to RFC7045. But the fact is that >> there's a tussle here between the desire for the ability to deploy >> new protocols freely, and the desire for the ability to block >> potentially harmful or malicious traffic. The definition of "harmful >> or malicious" is not universally agreed. "Harmful to my business = model" >> is certainly one possible interpretation. But then, we decided to >> implement the Internet as a largely unregulated competitive system, >> so we got tussles. > I am concerned that this draft is attempting to weight the scales and = favor one side of this ongoing tussle, which leads to something like = "ossification in the name of security". I think that's a huge overreach. = I would like to have a very general caveat at the beginning of the = draft, explaining that it is perfectly fine to deploy routers that do = not perform any such filtering and simply forward the packets. We need = something significantly more forceful than merely saying that the short = statement in section 2.3.=20 > The policies that it describes are plausible for specialized filtering = devices such as firewalls, but the draft proposes adopting these = policies for "transit routers", an ill defined term that could cover = pretty much every router in the the Internet. There is a big difference = there. Security devices are engineered to implement specific policies, = and come with management systems to update these policies over time.=20 > Nick made that point, probably unintentionally, when he wrote that = "transit operators would generally take the view that any data-plane = packet which needs to be put through a slow path will be rate limited up = to 100% loss". Last I checked, data plane processing is implemented in = specialized components that are designed for speed. I am quite concerned = that filtering recommendations made by the IETF will end up deeply = embedded in the hardware of at least some routers, and that changing = them in the future would be quite hard. That's pretty much the recipe = for ossification. >=20 > I am also concerned that the filtering is justified by "security = considerations", but that with the exception of the HBH header these = considerations apply to end points, not to transit router. Take the = example of the experimental options, described in section 3.4.10. The = consideration says that "implications of these EHs will depend on their = specific use." It fails to mention any security consequence for the = transit router that would fail to filter these options. In the absence = of filtering, the packets will arrive at the end system, where they will = be processed if the end system is part of the experiment, or treated as = unwanted traffic if the end system is not part of that experiment. There = definitely will not be any harmful effect for the router that passed the = traffic. > I understand that unwanted traffic can be used in denial of service = attacks. But then, any traffic profile can be used in such attacks. The = attacker who can inject packets with EH=3D253 can also, for example, = inject arbitrary TCP segments, or spoofed EH packets. I also understand = the desire to protect end systems from unwanted traffic. There is a = history of attacks performed by various kind of "magic packets" that = cause a catastrophic failure in some target systems. But it does not = follow that such protection should be implement by coarse policies = hardwired in every router on the Internet. The definition of these = attacks changes over time, and it would be folly to implement these = rules in systems that lack management capabilities. The proper place for = that is specialized security functions, not in general purpose routers. >=20 > I am also concerned that the draft does not define the difference = between EH options and IPv6 payload types. The IPv6 header contains a = "payload type" field, that may legitimately contain any of the payload = types defined in the IANA registry of protocol numbers = (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml = = ). Some of those payload types are flagged as IPv6 extension header = types and listed in the corresponding registry = (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml = ).= Discussing EH without discussing the other payload types seems bizarre. = Do the reasons for blocking for the experimental payload type 253 also = apply to, for example, the UDP Lite payload type? What about discussing = ESP and not discussing L2TP or MANET?=20 > -- Christian Huitema >=20 > -- Christian Huitema >=20 >=20 --Apple-Mail=_4D0C9849-2144-4A8B-AA42-CC93361B537B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = core problem with this doc, IMO, is that:

- packets that cannot be distinguished = from legitimate traffic MUST NOT be inferred as an attack

- the use of resources = appropriate for legitimate traffic MUST NOT be interpreted as a = vulnerability for that reason alone

I.e., most of the analysis in this = document is flat out incorrect in assuming that merely because a packet = could cause a router to do work that it is a security risk to handle = that packet as intended.

Joe


On Nov 25, 2018, at 12:40 PM, = Christian Huitema <huitema@huitema.net> wrote:

=20 =20


On 11/25/2018 11:40 AM, Brian E Carpenter wrote:
On 2018-11-26 04:53, Joe =
Touch wrote:

A reasoned discussion of =
the pros and cons would be useful.

What we have is the perspective, often heavily represented by vendors =
and operators, of the driving reality that:

a) implementing extended features is an attack on profits
b) properly configuring and monitoring extended features is an attack on =
effort

A reasoned argument would be useful. That is not what has been =
repeatedly presented, IMO.

I don't think that's =
entirely fair to RFC7045. But the fact is that
there's a tussle here between the desire for the ability to deploy
new protocols freely, and the desire for the ability to block
potentially harmful or malicious traffic. The definition of "harmful
or malicious" is not universally agreed. "Harmful to my business model"
is certainly one possible interpretation. But then, we decided to
implement the Internet as a largely unregulated competitive system,
so we got tussles.

I am concerned that this draft is = attempting to weight the scales and favor one side of this ongoing tussle, which leads to something like "ossification in the name of security". I think that's a huge overreach. I would like to have a very general caveat at the beginning of the draft, explaining that it is perfectly fine to deploy routers that do not perform any such filtering and simply forward the packets. We need something significantly more forceful than merely saying that the short statement in section 2.3.

The policies that it describes are plausible for = specialized filtering devices such as firewalls, but the draft proposes adopting these policies for "transit routers", an ill defined term that could cover pretty much every router in the the Internet. There is a big difference there. Security devices are engineered to implement specific policies, and come with management systems to update these policies over time.

Nick made that point, probably unintentionally, = when he wrote that "transit operators would generally take the view that any data-plane packet which needs to be put through a slow path will be rate limited up to 100% loss". Last I checked, data plane processing is implemented in specialized components that are designed for speed. I am quite concerned that filtering recommendations made by the IETF will end up deeply embedded in the hardware of at least some routers, and that changing them in the future would be quite hard. That's pretty much the recipe for ossification.

I am also concerned that the = filtering is justified by "security considerations", but that with the exception of the HBH header these considerations apply to end points, not to transit router. Take the example of the experimental options, described in section 3.4.10. The consideration says that "implications of these EHs will depend on their specific use." It fails to mention any security consequence for the transit router that would fail to filter these options. In the absence of filtering, the packets will arrive at the end system, where they will be processed if the end system is part of the experiment, or treated as unwanted traffic if the end system is not part of that experiment. There definitely will not be any harmful effect for the router that passed the traffic.

I understand that unwanted traffic can be used in = denial of service attacks. But then, any traffic profile can be used in such attacks. The attacker who can inject packets with EH=3D253 can = also, for example, inject arbitrary TCP segments, or spoofed EH packets. I also understand the desire to protect end systems from unwanted traffic. There is a history of attacks performed by various kind of "magic packets" that cause a catastrophic failure in some target systems. But it does not follow that such protection should be implement by coarse policies hardwired in every router on the Internet. The definition of these attacks changes over time, and it would be folly to implement these rules in systems that lack management capabilities. The proper place for that is specialized security functions, not in general purpose routers.

I am also concerned that the draft does not define the = difference between EH options and IPv6 payload types. The IPv6 header contains a "payload type" field, that may legitimately contain any of the payload types defined in the IANA registry of protocol numbers (https://www.iana.org/assignments/protocol-numbers/protocol-numbers= .xhtml). Some of those payload types are flagged as IPv6 extension header types and listed in the corresponding registry (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xht= ml). Discussing EH without discussing the other payload types seems bizarre. Do the reasons for blocking for the experimental payload type 253 also apply to, for example, the UDP Lite payload type? What about discussing ESP and not discussing L2TP or MANET?

-- Christian Huitema


-- Christian Huitema




= --Apple-Mail=_4D0C9849-2144-4A8B-AA42-CC93361B537B-- From nobody Sun Nov 25 23:55:02 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F32130DE5; Sun, 25 Nov 2018 23:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hTvbWDT6XzEI; Sun, 25 Nov 2018 23:54:51 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1C91271FF; Sun, 25 Nov 2018 23:54:50 -0800 (PST) Received: from [192.168.3.73] (unknown [186.137.76.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 32A24885A9; Mon, 26 Nov 2018 08:54:44 +0100 (CET) To: Christian Huitema , Brian E Carpenter , Joe Touch , Nick Hilliard Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Mon, 26 Nov 2018 04:21:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 07:54:54 -0000 Christian. On 25/11/18 17:40, Christian Huitema wrote: [.....] > > I am concerned that this draft is attempting to weight the scales and > favor one side of this ongoing tussle, which leads to something like > "ossification in the name of security". I think that's a huge overreach. Not really. If that was the case we'd probably say "drop all EHs you see no use for". If you look at the advice, it esentially argues in favor of passing everything unless the traffic is known to be harmful. > Nick made that point, probably unintentionally, when he wrote that > "transit operators would generally take the view that any data-plane > packet which needs to be put through a slow path will be rate limited up > to 100% loss". Last I checked, data plane processing is implemented in > specialized components that are designed for speed. I am quite concerned > that filtering recommendations made by the IETF will end up deeply > embedded in the hardware of at least some routers, and that changing > them in the future would be quite hard. That's pretty much the recipe > for ossification. PLease take a look at the advice: it essentially argues "pass everything that has been stadardizez and that will not cause you pain". And, again, this is in line with RFC7045. Compare that with what we have in the real world (RFC7872), and you'll probably agree that if folks were to implement this advice, it would be a *huge* improvement -- at the time of this writing you cannot even use ipsec reliably on the Internet(!). > I understand that unwanted traffic can be used in denial of service > attacks. But then, any traffic profile can be used in such attacks. The > attacker who can inject packets with EH=253 can also, for example, > inject arbitrary TCP segments, or spoofed EH packets. I also understand > the desire to protect end systems from unwanted traffic. There is a > history of attacks performed by various kind of "magic packets" that > cause a catastrophic failure in some target systems. But it does not > follow that such protection should be implement by coarse policies > hardwired in every router on the Internet. The definition of these > attacks changes over time, and it would be folly to implement these > rules in systems that lack management capabilities. The proper place for > that is specialized security functions, not in general purpose routers. RFC7872 seems to argue that there are folks filtering these in transit routers. > I am also concerned that the draft does not define the difference > between EH options and IPv6 payload types. You mean EH types and upoer layer payloads? > The IPv6 header contains a > "payload type" field, that may legitimately contain any of the payload > types defined in the IANA registry of protocol numbers > (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). > Some of those payload types are flagged as IPv6 extension header types > and listed in the corresponding registry > (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml). Discussing > EH without discussing the other payload types seems bizarre. Do the > reasons for blocking for the experimental payload type 253 also apply > to, for example, the UDP Lite payload type? What about discussing ESP > and not discussing L2TP or MANET? This document discusses EHs. THe considerations for filtering on upper payloads are rather different, and normally depend on the upper protocol details. (e.g. TCP ports). As noted in draft-gont-v6ops-ipv6-ehs-packet-drops, EHs can mess up with the ability of intermediate devices to do their work. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Nov 25 23:55:19 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFC8130F33; Sun, 25 Nov 2018 23:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aIyzYDcNxLXy; Sun, 25 Nov 2018 23:54:55 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6121B130DE5; Sun, 25 Nov 2018 23:54:55 -0800 (PST) Received: from [192.168.3.73] (unknown [186.137.76.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7EB4288600; Mon, 26 Nov 2018 08:54:51 +0100 (CET) To: "C. M. Heard" , Nick Hilliard , Brian E Carpenter Cc: OPSEC , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> Date: Mon, 26 Nov 2018 04:51:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 07:55:01 -0000 On 24/11/18 17:37, C. M. Heard wrote: > On Sat, Nov 24, 2018 at 12:30 PM Nick Hilliard wrote: >> Brian E Carpenter wrote on 24/11/2018 20:17: >>> Operators make their own >>> decisions, so I think that is what the draft should say. Something like: >>> >>> 3.5.5. Advice >>> >>> Operators should determine according to their own circumstances >>> whether to discard packets containing unknown IPv6 EHs. >>> >>> And at the same time, delete the 2nd and 3rd sentences of this: >>> >>> 3.5.3. Specific Security Implications >>> >>> For obvious reasons, it is impossible to determine specific security >>> implications of unknown IPv6 EHs. However, from security standpoint, >>> a device should discard IPv6 extension headers for which the security >>> implications cannot be determined. We note that this policy is >>> allowed by [RFC7045]. >> >> This looks like a sensible approach. > > I could live with that. FWIW, I can live with that, too. UNless somebody screams against it, I will apply the proposed change to the next rev. Thanks! > Similar changes might be considered for Sec. 4.4.5. Will do. Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Nov 25 23:55:33 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92809130F28; Sun, 25 Nov 2018 23:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Q0eYditU25RG; Sun, 25 Nov 2018 23:55:01 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97B6130F4D; Sun, 25 Nov 2018 23:55:00 -0800 (PST) Received: from [192.168.3.73] (unknown [186.137.76.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BEEF888667; Mon, 26 Nov 2018 08:54:56 +0100 (CET) From: Fernando Gont To: Joe Touch Cc: Brian E Carpenter , Michael Scharf , tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <4138e2eb-71e0-4c3d-36cb-38da8369a7c6@si6networks.com> Date: Mon, 26 Nov 2018 04:54:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 07:55:07 -0000 Joe, On 25/11/18 03:24, Joe Touch wrote: > The reality is that standards are not followed, agreed. That does not imply that we need to relax those standards - instead, it can be reason to fix broken devices. > > Working at the level of the most broken device is no way to run a production Internet. > > And claiming that doing so is appropriate for security reasons is just as broken, as it always has been. This document is a product of the opsec working group. As such, it talks about what you can do with what you have. Blaiming vendors, even if warranted, is not something that is going to change what an operator may do with these packets. If, e.g., what you want to is that vendors provide full (hardware) support for all EHs, then the way to go would probably be to have 6man publish a document saying that implementations without such support should not claim they support IPv6. In such case, I wonder how many of those "ipv6-enabled" boxes we'd have ... and then probably we'd decide that that would not be politically-convenient, and prefer to look elsewhere. What this doc tries to do is to analyze the possible effects of different types and options, and only advice to drop them when there is a clear reason to do so. If you go through all the types we discuss, you'll see that, for the vast majority, the advice is "pass it". -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Nov 25 23:58:06 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027621294D7 for ; Sun, 25 Nov 2018 23:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no 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 CwJTQBUUCqyN for ; Sun, 25 Nov 2018 23:57:53 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 DC309130FA6 for ; Sun, 25 Nov 2018 23:57:48 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1A18D41C45 for ; Mon, 26 Nov 2018 08:57:47 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0412E418E5; Mon, 26 Nov 2018 08:57:47 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id E84B174074; Mon, 26 Nov 2018 08:57:46 +0100 (CET) Date: Mon, 26 Nov 2018 08:57:46 +0100 From: Gert Doering To: Joe Touch Cc: Christian Huitema , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , OPSEC , tsv-art , Brian E Carpenter Message-ID: <20181126075746.GO72840@Space.Net> References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 07:57:54 -0000 Hi, On Sun, Nov 25, 2018 at 09:16:23PM -0800, Joe Touch wrote: > I.e., most of the analysis in this document is flat out incorrect in assuming that merely because a packet could cause a router to do work that it is a security risk to handle that packet as intended. And then IETF wonders why operators do not feel like time spent on providing their input to IETF WGs is well-spent. What else can it be, on a real-world device, in today's Internet? Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Nov 26 06:32:51 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D09130E01; Mon, 26 Nov 2018 06:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 7_CPny01sE0d; Mon, 26 Nov 2018 06:32:47 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 19A5D130DE0; Mon, 26 Nov 2018 06:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Xm0IvYTFIsuPiKrom54UGGEMm9aAirYYAWrYorcTHrs=; b=wuGUnGhffVDp2fE9itWdsN1Sh ndcD+43Vulrk0JH8Uq7vk0cYnEAXuzwABAXmyTYo7VqaExqYarz8shi5jDswDC2ujG2VBivYBskD3 pFnMfwjjcFW04SoXUpzsKALQQsG1PYZe4pYGaMOcFSbEZN7X+FSx38KSlunEhcr8P+IBEJZuXzmW2 UWPQPP5zb4p29PN0LVZLL3LlMBoYORWCWj4WQS0GXaSi2hqQzR7HtTVKtenaXVyUAnzJlSebSxOvU D4lrHDfMtgUgm+Xgc6xoovSPyn7jvmjB3spzrL8L2Wjq4X5z8kKXkfBgNKGKlUE+tElJQNfgxPVBm BzE4f5lIw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53435 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRHwJ-003gOc-Gh; Mon, 26 Nov 2018 09:32:45 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <20181126075746.GO72840@Space.Net> Date: Mon, 26 Nov 2018 06:32:43 -0800 Cc: Christian Huitema , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , OPSEC , tsv-art , Brian E Carpenter Content-Transfer-Encoding: quoted-printable Message-Id: <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> To: Gert Doering X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 14:32:49 -0000 > On Nov 25, 2018, at 11:57 PM, Gert Doering wrote: >=20 > Hi, >=20 >> On Sun, Nov 25, 2018 at 09:16:23PM -0800, Joe Touch wrote: >> I.e., most of the analysis in this document is flat out incorrect in assu= ming that merely because a packet could cause a router to do work that it is= a security risk to handle that packet as intended. >=20 > And then IETF wonders why operators do not feel like time spent on > providing their input to IETF WGs is well-spent. >=20 > What else can it be, on a real-world device, in today's Internet? The failure of a device to run as advertised or the failure of an operation t= o select the an appropriate device. Operators that want to conserve resources without cause are welcome to run t= heir routers inside glass boxes in museums. Routers do work. Packets cause t= hat work. That work is not an attack unless it is *disproportionate*. That i= s not shown for nearly any of the cases in this document. Joe From nobody Mon Nov 26 06:36:21 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00866130DE0; Mon, 26 Nov 2018 06:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 FpkIPVVPI4aS; Mon, 26 Nov 2018 06:36:13 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 59C55130E03; Mon, 26 Nov 2018 06:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/w8o1OLPZoU4c0AzLBhuV0y0jzoRBzzpXReN/MV0rlo=; b=Wc5Pzzkh5NiS4e69Tai+HkYV3 FoikH1Jkq2O8oyZ/iN9ccXICqpMWnwyktnrCQGisELyaEk4YGygLBRD2Ku/Cg8t3luxlvNrVQ2cs5 cELiTjp3VB5EHw3r0WtHyVFQGLV6tLLz3a4moltts/nQGeQe8+LDEGJmSTZXjzWwQvguaB8CSiAS5 plAitSuTOWdJTo5mVYeajiRurQM8TLe24Fxc1uaJmRDswikQiCiJKpKhhk8aXGOeXFeI5RdfZyT8B e9uBbxnywqinXloSmwP7hcfg0L25LVu65W82eU1rIZMl2F7PF5acEcIW7r2Z4f+QCol13e2yEo1c3 NorLqSETw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53454 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRHze-003jhd-DG; Mon, 26 Nov 2018 09:36:12 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <4138e2eb-71e0-4c3d-36cb-38da8369a7c6@si6networks.com> Date: Mon, 26 Nov 2018 06:36:09 -0800 Cc: Brian E Carpenter , Michael Scharf , tsv-art@ietf.org, opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BEB4C2C-0873-4D08-8A7D-1C3E30AC374F@strayalpha.com> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <4138e2eb-71e0-4c3d-36cb-38da8369a7c6@si6networks.com> To: Fernando Gont X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 14:36:16 -0000 > On Nov 25, 2018, at 11:54 PM, Fernando Gont wrote:= >=20 > What this doc tries to do is to analyze the possible effects of > different types and options, and only advice to drop them when there is > a clear reason to do so. It claims those actions based on security. This is not a security issue. It i= s a revenue preservation issue. There is a big difference between using a protocol feature and abusing it. T= he implication that merely using some of these features is a security issue a= nd an abuse is the problem with this document - and the approach of similar d= ocuments. Joe= From nobody Mon Nov 26 06:46:55 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECF5126BED; Mon, 26 Nov 2018 06:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 KP2ClkpcWbF8; Mon, 26 Nov 2018 06:46:45 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED243130E8F; Mon, 26 Nov 2018 06:46:44 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 0D4CE1155B7; Mon, 26 Nov 2018 09:46:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=rsEx/g9D/BfNMrnP6WCpHJwreHA=; b=ijm9RS //eTufSpQSVfZbx24Sdv/BppaknuRlYeP+yAFFh26KG1hnMuyY11LnWufrZtt+vM wUoyh9E2HZz+TP2XgBalXobvz0UJWJVHDVjFZp+cBq3kVbmAn0iizQk6eOQnqEvZ HjC30Cxt7zYHzPFRYV9Et4gn3oi7mXWqpaCCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=vYH1yvOmxG3EAoqKMwH0fC8d7noVhBt7 rxl7eGdmIXvvN0CQorF/GgXTjRYGMNi0uaga5h0ABA561Qe/x/QCSCzBTDSoUhoE zHaP/BK2SB+ufsCYalCQJQwIwMcn60sZEGCV1Re8+6pwG2REFKVm8fTd8AIxPEGr X7gD1YEkwDo= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 0564D1155B4; Mon, 26 Nov 2018 09:46:43 -0500 (EST) Received: from mail-it1-f176.google.com (unknown [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 8B8C21155B2; Mon, 26 Nov 2018 09:46:42 -0500 (EST) Received: by mail-it1-f176.google.com with SMTP id h65so27985705ith.3; Mon, 26 Nov 2018 06:46:42 -0800 (PST) X-Gm-Message-State: AA+aEWaMKJnqpQ0lzdpBj0YVv4aDjFr/cFJaOXDd7rDMkCa3DqHVfHC4 KdQ6NU/ktHD50nOtnoESv2qPU2T6gtfKlvUSF/c= X-Google-Smtp-Source: AJdET5eiO6j6yxJTUobDga1q5ylDcXexg5fQufg6Q0RZQdSEd+bzW7nSAAurl5+LAbeAc8dmQ3kCdYf69lgBLtvKLIc= X-Received: by 2002:a02:b529:: with SMTP id l38mr22703089jaj.25.1543243601929; Mon, 26 Nov 2018 06:46:41 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> In-Reply-To: <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> From: "C. M. Heard" Date: Mon, 26 Nov 2018 06:46:29 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: Nick Hilliard , Brian E Carpenter , OPSEC , IETF Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 16D7ED68-F18A-11E8-B332-063AD72159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 14:46:47 -0000 On Sun, Nov 25, 2018 at 11:55 PM Fernando Gont wrote: > On 24/11/18 17:37, C. M. Heard wrote: > > On Sat, Nov 24, 2018 at 12:30 PM Nick Hilliard wrote: > >> Brian E Carpenter wrote on 24/11/2018 20:17: > >>> Operators make their own > >>> decisions, so I think that is what the draft should say. Something like: > >>> > >>> 3.5.5. Advice > >>> > >>> Operators should determine according to their own circumstances > >>> whether to discard packets containing unknown IPv6 EHs. > >>> > >>> And at the same time, delete the 2nd and 3rd sentences of this: > >>> > >>> 3.5.3. Specific Security Implications > >>> > >>> For obvious reasons, it is impossible to determine specific security > >>> implications of unknown IPv6 EHs. However, from security standpoint, > >>> a device should discard IPv6 extension headers for which the security > >>> implications cannot be determined. We note that this policy is > >>> allowed by [RFC7045]. > >> > >> This looks like a sensible approach. > > > > I could live with that. > > FWIW, I can live with that, too. UNless somebody screams against it, I > will apply the proposed change to the next rev. Thanks! > > > Similar changes might be considered for Sec. 4.4.5. > > Will do. Thank you. There is also related advice in the note to Section 3.1 that needs similar changes and the matter of experimental EHs and experimental options that I raised in my original comments. These are all cases where the security implications cannot be determined. Proposed text for Sections 3.1, 3.4.10.5, 3.5.3 et. seq., 4.3.18.5, and 4.4.5 follows below. --- OLD: NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments MUST contain the entire IPv6 header chain [RFC7112]. Therefore, intermediate systems can enforce the filtering policies discussed in this document, or resort to simply discarding the offending packets when they fail to comply with the requirements in [RFC7112]. We note that, in order to implement filtering rules on the fast path, it may be necessary for the filtering device to limit the depth into the packet that can be inspected before giving up. In circumstances where there is such a limitation, it is recommended that implementations discard packets if, when trying to determine whether to discard or permit a packet, the aforementioned limit is encountered. NEW: NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments MUST contain the entire IPv6 header chain [RFC7112]. Therefore, intermediate systems can enforce the filtering policies discussed in this document, or resort to simply discarding the offending packets when they fail to comply with the requirements in [RFC7112]. We note that, in order to implement filtering rules on the fast path, it may be necessary for the filtering device to limit the depth into the packet that can be inspected before giving up. In circumstances where there is such a limitation, it is recommended that implementations provide a configuration option that specifies whether to discard packets if the aforementioned limit is encountered. Operators may then determine according to their own circumstances how such packets will be handled. --- OLD: 3.4.10.5. Advice Intermediate systems should discard packets containing these EHs. Only in specific scenarios in which RFC3692-Style experiments are to be performed should these EHs be permitted. NEW: 3.4.10.5. Advice Operators should determine according to their own circumstances whether to discard packets containing experimental IPv6 EHs. --- OLD: 3.5.3. Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs. However, from security standpoint, a device should discard IPv6 extension headers for which the security implications cannot be determined. We note that this policy is allowed by [RFC7045]. 3.5.4. Operational and Interoperability Impact if Blocked As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored such that filtering rules are updated as new IPv6 EHs are standardized. We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded. 3.5.5. Advice Intermediate systems should discard packets containing unknown IPv6 EHs. NEW: 3.5.3. Specific Security Implications For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs. 3.5.4. Operational and Interoperability Impact if Blocked As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored such that filtering rules are updated as new IPv6 EHs are standardized. We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded. 3.5.5. Advice Operators should determine according to their own circumstances whether to discard packets containing unknown IPv6 EHs. --- OLD: 4.3.18.5. Advice Intermediate systems should discard packets that contain these options. Only in specific environments where RFC3692-style experiments are meant to be performed should these options be permitted. NEW: 4.3.18.5. Advice Operators should determine according to their own circumstances whether to discard packets containing experimental IPv6 options. --- OLD: 4.4.5. Advice Enterprise intermediate systems that process the contents of IPv6 EHs should discard packets that contain unknown options. Other intermediate systems that process the contents of IPv6 EHs should permit packets that contain unknown options. NEW: 4.4.5. Advice Operators should determine according to their own circumstances whether to discard packets containing unknown IPv6 options. EDITORIAL: I believe that the following is simply mis-worded: --- OLD: 4.3.10.5. Advice Intermediate system should discard packets that contain this option. NEW: 4.3.10.5. Advice Intermediate systems that are not within a MANET domain should discard packets that contain this option. NITS: These should be fixed prior to publication. --- OLD: 4.3.1.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would potentially break any protocol that relies on IPv6 EHs. NEW: 4.3.1.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options. --- OLD: 4.3.2.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would potentially break any protocol that relies on IPv6 EHs. NEW: 4.3.2.4. Operational and Interoperability Impact if Blocked Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options. In some places the abbreviations RHT0 and RHT1 are used, while in other places RTH0 and RTH1 are used. The usage should be consistent; IMHO the former abbreviations seem to be more correct. Mike Heard From nobody Mon Nov 26 07:19:36 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D1130F17 for ; Mon, 26 Nov 2018 07:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 seyCrYDbw-aC for ; Mon, 26 Nov 2018 07:19:29 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086D5130E31 for ; Mon, 26 Nov 2018 07:19:28 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id f23so13791569lfc.13 for ; Mon, 26 Nov 2018 07:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qcwOUtv5YF3G9YJ7eKo+qk7fBdWL2E16FSzzvZ2tRp4=; b=X5BdNh3YO+ypAImAj7Hd08trvUAS5pIY1dcIqKrl38UKprdOvzgV53AEKspyfyCkEK Jn1VdxmrKeCiK4XPPvtlTsllirwk1qj0AhVbRa+0+9JAC/Ya3pbDD3bTNt5gy0trAuCC pk/P+XlOKlnSmo2C3Hp3R+B4FLGPE9jmJtsPPM7GiNA6quGWhtZPawf2f3k0VyEtTZya oezJ/VbjdkKFkghBBtJq7ku5XDnGvV+vihvPIwKuZXwCFygqo/vqlSSGGXAUljXI7n4H 8q1x3O30yeGWXIXT2Yfz1wdARu7CuskHkkz/eEapKkuvspfd8DA6ONWHk2Fg5Xxcqo4E 8v+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qcwOUtv5YF3G9YJ7eKo+qk7fBdWL2E16FSzzvZ2tRp4=; b=izAdjD3GbOA8dWQ+i+qc9qQELPPhJO+A+JqpuBHLXtiR0G12qX/EoanDEAKf3gKZiY tKWK7KBCh9p0sEmGZmo9eUhwxgFi+fF/Myj7vms7Ia082CGFDInVvfboXHnE+8hrGJ9s B6i/dEjaBjU+NqZkLtOoEJkYxPMSrJ/CpPuClnKdiYrWpGFiiK/joU6QGqBuahT+KY6K w/LfeKfK4Dz1jgEvbFsqIi1tHV8ay51zqnk4BkCIYEf32hsmZ+khg/M12dtYBfS2jx56 Yvppt/805sLzavnxjozIQ1gWcKyUMlOyp8MgU0UllCkDrOQsQS7gxa9TJ9ZA1J9VRyQC TGdA== X-Gm-Message-State: AGRZ1gLMn1MhWslyPaloeISPrfJkbQY0680bEHqJGnhnr+/2T3MYKuu7 +yssr+6VZ6S5UaVn4B5Ap9we2AKJ/YMYBvJy0lGO1g== X-Google-Smtp-Source: AJdET5fOZR4mEgx0Mib415v6oZpy+dCRCL1ylXk5mhlHiidWr0JdzV9oqNdtJEFe+IV/tXiv59IMoLxz/oNko4hWQCM= X-Received: by 2002:a19:54d7:: with SMTP id b84mr15436259lfl.131.1543245566174; Mon, 26 Nov 2018 07:19:26 -0800 (PST) MIME-Version: 1.0 References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <4138e2eb-71e0-4c3d-36cb-38da8369a7c6@si6networks.com> <1BEB4C2C-0873-4D08-8A7D-1C3E30AC374F@strayalpha.com> In-Reply-To: <1BEB4C2C-0873-4D08-8A7D-1C3E30AC374F@strayalpha.com> From: Eric Rescorla Date: Mon, 26 Nov 2018 07:18:49 -0800 Message-ID: To: Joe Touch Cc: Fernando Gont , IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org Content-Type: multipart/alternative; boundary="000000000000c6049f057b92db2f" Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 15:19:32 -0000 --000000000000c6049f057b92db2f Content-Type: text/plain; charset="UTF-8" Picking a random message to reply to. I'm not any kind of IPv6 expert, so I'm not taking a position on the goodness or badness of extension headers. With that said, we do have a fair amount of experience with trying to deploy new protocols in the face of significant levels of network-level filtering; TLS 1.3 was delayed by a year or so when we discovered that there were middleboxes which made incorrect assumptions about our extension points. At the end of the day, we got things working, but at the cost of some not very attractive hacks, and if you look at QUIC, a lot of the design is motivated by concealing extension points from network intermediaries in order to avoid a replay of this scenario. Otherwise, we're worried that we won't be able to extend the protocol in the future. So, at least from the endpoint's perspective, a situation in which network intermediaries block any new protocol features they don't recognize is not really great. -Ekr On Mon, Nov 26, 2018 at 6:36 AM Joe Touch wrote: > > > > On Nov 25, 2018, at 11:54 PM, Fernando Gont > wrote: > > > > What this doc tries to do is to analyze the possible effects of > > different types and options, and only advice to drop them when there is > > a clear reason to do so. > > It claims those actions based on security. This is not a security issue. > It is a revenue preservation issue. > > There is a big difference between using a protocol feature and abusing it. > The implication that merely using some of these features is a security > issue and an abuse is the problem with this document - and the approach of > similar documents. > > Joe > --000000000000c6049f057b92db2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Picking a random message to reply to.

<= /div>
I'm not any kind of IPv6 expert, so I'm not taking a posi= tion on the goodness or badness of extension headers.

<= div>With that said, we do have a fair amount of experience with trying to d= eploy new protocols in the face of significant levels of network-level filt= ering; TLS 1.3 was delayed by a year or so when we discovered that there we= re middleboxes which made incorrect assumptions about our extension points.= At the end of the day, we got things working, but at the cost of some not = very attractive hacks, and if you look at QUIC, a lot of the design is moti= vated by concealing extension points from network intermediaries in order t= o avoid a replay of this scenario. Otherwise, we're worried that we won= 't be able to extend the protocol in the future.

So, at least from the endpoint's perspective, a situation in which n= etwork intermediaries block any new protocol features they don't recogn= ize is not really great.

-Ekr

=





On Mon, Nov 26, 2018 at 6:36 AM Joe = Touch <touch@s= trayalpha.com> wrote:


> On Nov 25, 2018, at 11:54 PM, Fernando Gont <fgont@si6networks.com> wrote: >
> What this doc tries to do is to analyze the possible effects of
> different types and options, and only advice to drop them when there i= s
> a clear reason to do so.

It claims those actions based on security. This is not a security issue. It= is a revenue preservation issue.

There is a big difference between using a protocol feature and abusing it. = The implication that merely using some of these features is a security issu= e and an abuse is the problem with this document - and the approach of simi= lar documents.

Joe
--000000000000c6049f057b92db2f-- From nobody Mon Nov 26 09:53:58 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7512D4E8 for ; Mon, 26 Nov 2018 09:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no 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 JlddJ4uvMTmF for ; Mon, 26 Nov 2018 09:53:43 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 4A3CE12F1A2 for ; Mon, 26 Nov 2018 09:53:40 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3D68F41135 for ; Mon, 26 Nov 2018 18:53:37 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 29BA540D75; Mon, 26 Nov 2018 18:53:37 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1956774A97; Mon, 26 Nov 2018 18:53:37 +0100 (CET) Date: Mon, 26 Nov 2018 18:53:37 +0100 From: Gert Doering To: Joe Touch Cc: Gert Doering , Christian Huitema , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , OPSEC , tsv-art , Brian E Carpenter Message-ID: <20181126175336.GW72840@Space.Net> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZqYDZSN9O5ZeiDmL" Content-Disposition: inline In-Reply-To: <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 17:53:45 -0000 --ZqYDZSN9O5ZeiDmL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 26, 2018 at 06:32:43AM -0800, Joe Touch wrote: > > And then IETF wonders why operators do not feel like time spent on > > providing their input to IETF WGs is well-spent. > >=20 > > What else can it be, on a real-world device, in today's Internet? >=20 > The failure of a device to run as advertised or the failure of an=20 > operation to select the an appropriate device. This is where the "real-world" bit comes into play. > Operators that want to conserve resources without cause are welcome > to run their routers inside glass boxes in museums. Routers do > work. Packets cause that work. That work is not an attack unless > it is *disproportionate*. That is not shown for nearly any of the > cases in this document. As people have explained in great detail, there's work that the routers are built to do, where the number of packets they can handle is nearly arbitrarily high. Then there's packets that are seen as an exception, and handled in a not-as-powerful path. Back then, when the Internet was new, these=20 exceptional packets were considered "something we'll handle when the=20 need arises", and it mostly worked. Today, whenever anything is connected to the real Internet has a weakness, it will be abused. Thus, these=20 packets will have to be rate-limited, up to the point of uselessness. =20 Of course you can build a box that can do everything with the same=20 speed. I would recommend to the reader to make himself familiar with current market realities, though, regarding "cost", "power consumption", "feasibility to build in time before the increase in bandwidth has them obsoleted again" and "willingness of customers to pay serious money for=20 their Internet access". Gert Doering -- Operator --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ZqYDZSN9O5ZeiDmL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlv8Mx4ACgkQ31bAZeTO f8UUmBAArPiH9p6WxPrze45j0cpwK3Fjq9pZW+RmvPa79FxGB2FtRkWYWzKyhvl3 xcIJF9z6e8l00YVtowX/csrJe7b92Bva49plMzkK9xJRkepgBQUF2a9+90J7rYQN yWgviUOn8fcMO3Ew1wDMS7RPUTPmjhDIRMUo+KCpiWbqTEZNVGgP3xh0SkKent9a cYtca7Ew7CftpO7G0aQQsYEhgf5Nd2uLb6+Y3TskqsTzktkJfOEfKp6/hmA3WARP 66q11/1hf3Q0SiMC+UXmv17DfP2tHw/kQNZbi8nsyxxLWRdz5CyzZ+cNmTaS31aP m3hff9YeoKJGRzs/0d5LozAxxVai34aLj+CZ4nT8uwmRfNfKkJaGKFa00Grf6Guq kfZb6G86FaSCxu0DnTfPKKwa0l5XI+4UFz0G9SsKDTeIb7ppXnzrROPYHidw/+RB pJdpcJWLki0pUXPtmcZqMWfiQo1aGHYx045Mdujn49erelQIrJsgD1sABbrICFk1 bjMu46cWfozNf9FV84vfOnbXHf08Q4rMIVUv/3walvkgFXFbRLkZ+bBdljLf9BPV 5j5j2a+lVgkmvdnePMvh9g7yh78MXIzpoBlitOfdtJ39UFl/7POjGlsBm9l03c5/ O79+GTdLJRlKWxMYh0CLGBNgk7bLBlfVcqJfUpT8D1hEmYXLp/I= =v3vW -----END PGP SIGNATURE----- --ZqYDZSN9O5ZeiDmL-- From nobody Mon Nov 26 10:03:05 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D423B12D4E8; Mon, 26 Nov 2018 10:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YLdY3W0eehf7; Mon, 26 Nov 2018 10:03:02 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7F5124D68; Mon, 26 Nov 2018 10:03:01 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 5C627FECC00D; Mon, 26 Nov 2018 18:03:01 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 455D2A4E475; Mon, 26 Nov 2018 19:02:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: <20181126175336.GW72840@Space.Net> Date: Mon, 26 Nov 2018 19:02:54 +0100 Cc: Joe Touch , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , Christian Huitema , tsv-art Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 18:03:04 -0000 >>> And then IETF wonders why operators do not feel like time spent on >>> providing their input to IETF WGs is well-spent. >>>=20 >>> What else can it be, on a real-world device, in today's Internet? >>=20 >> The failure of a device to run as advertised or the failure of an=20 >> operation to select the an appropriate device. >=20 > This is where the "real-world" bit comes into play. >=20 >> Operators that want to conserve resources without cause are welcome >> to run their routers inside glass boxes in museums. Routers do >> work. Packets cause that work. That work is not an attack unless >> it is *disproportionate*. That is not shown for nearly any of the >> cases in this document. >=20 > As people have explained in great detail, there's work that the = routers > are built to do, where the number of packets they can handle is nearly > arbitrarily high. >=20 > Then there's packets that are seen as an exception, and handled in a > not-as-powerful path. Back then, when the Internet was new, these=20 > exceptional packets were considered "something we'll handle when the=20= > need arises", and it mostly worked. Today, whenever anything is = connected > to the real Internet has a weakness, it will be abused. Thus, these=20= > packets will have to be rate-limited, up to the point of uselessness. =20= >=20 > Of course you can build a box that can do everything with the same=20 > speed. I would recommend to the reader to make himself familiar with > current market realities, though, regarding "cost", "power = consumption", > "feasibility to build in time before the increase in bandwidth has = them > obsoleted again" and "willingness of customers to pay serious money = for=20 > their Internet access=E2=80=9D. While I agree with what you say here, this draft recommends the = opposite. It recommends that routers should do more work, not less. Filtering out extension headers and options inside of extension headers, = is not only costly, it also violates basic Internet Architecture = principles. Ole From nobody Mon Nov 26 14:00:11 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D377A131068; Mon, 26 Nov 2018 13:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Lec8459mlphI; Mon, 26 Nov 2018 13:59:45 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A0F86131056; Mon, 26 Nov 2018 13:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PFD7aRFGKEtz2fY2ZsI8hpiUfuZk4pFrIVhCXirsIuU=; b=ml8SFTJUy59UkXuZrsFNjcc+H 0MZ/dqud62jiI1Tm2XO8pKA7lxmthzqlSrlK90WMtvSQh40wrW2lbe5S17cIcEfaw2ohp8EMm5Khy sKFVDT3T5vuWoi89uGC5lyxWn4GDwZuFudvIyhmMKMCe/kNYuBMfyUDgiNB1HpbAJSUqyIuhPCaW8 cefg0kb5zn9B7zYB5kxavQza22lmTTUlTvHvtkrO5TgqQibtXb6pqE1ZyXFlQrAJgPPxXOkvJiiXy DcGoDE6ukzRaCNOmhtKaFjAjjZ83ekC5lBVZCzxv3W1RbX3NNaoDCwmvR9QZXVZEENQrT16XlElWr Z8ppGLU5w==; Received: from [::1] (port=58768 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1gROuo-001FTP-BI; Mon, 26 Nov 2018 16:59:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_24da51290c5183e9c24919a3935b50a2" Date: Mon, 26 Nov 2018 13:59:38 -0800 From: Joe Touch To: Gert Doering Cc: Christian Huitema , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , OPSEC , tsv-art , Brian E Carpenter In-Reply-To: <20181126175336.GW72840@Space.Net> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 21:59:56 -0000 --=_24da51290c5183e9c24919a3935b50a2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-11-26 09:53, Gert Doering wrote: > Hi, > > ... > As people have explained in great detail, there's work that the routers > are built to do, where the number of packets they can handle is nearly > arbitrarily high. > > Then there's packets that are seen as an exception, and handled in a > not-as-powerful path. Back then, when the Internet was new, these > exceptional packets were considered "something we'll handle when the > need arises", and it mostly worked. Translation - "we cheated", and that's not working anymore. Agreed. > Today, whenever anything is connected > to the real Internet has a weakness, it will be abused. Thus, these > packets will have to be rate-limited, up to the point of uselessness. Rate limiting is quite different from 100% discards. When abuse happens, it's clearly safe to react. But reacting to the mere presence of this additional - unexpected - work is not itself abuse. And frankly it's only abuse because vendors claim IPv6 compliance by cheating and operators go along with the game. > Of course you can build a box that can do everything with the same > speed. I would recommend to the reader to make himself familiar with > current market realities, though, regarding "cost", "power consumption", > "feasibility to build in time before the increase in bandwidth has them > obsoleted again" and "willingness of customers to pay serious money for > their Internet access". If you sold this as "partial IPv6" or "incomplete support for RFC8200", then sure. If most of the time these options are not used, then fine - rate limit when they come up. But say that's what you're doing. And don't pretend that this is for security purposes. Joe --=_24da51290c5183e9c24919a3935b50a2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-11-26 09:53, Gert Doering wrote:

= Hi,

...
As people have explained in great detail, there's = work that the routers
are built to do, where the number of packets th= ey can handle is nearly
arbitrarily high.

Then there's pa= ckets that are seen as an exception, and handled in a
not-as-powerful= path.  Back then, when the Internet was new, these
exceptional= packets were considered "something we'll handle when the
need arise= s", and it mostly worked.
=  
= Translation - "we cheated", and that's not working anymore. Agreed.
=  
=  
=  Today, whenever anything is connected
to the real Internet has = a weakness, it will be abused.  Thus, these
packets will have t= o be rate-limited, up to the point of uselessness.  
=  
=  
= Rate limiting is quite different from 100% discards. When abuse happens, it= 's clearly safe to react.
=  
= But reacting to the mere presence of this additional - unexpected - work is= not itself abuse. And frankly it's only abuse because vendors claim IPv6 c= ompliance by cheating and operators go along with the game.
=  

= Of course you can build a box that can do everything with the same
s= peed.  I would recommend to the reader to make himself familiar with current market realities, though, regarding "cost", "power consumption= ",
"feasibility to build in time before the increase in bandwidth has= them
obsoleted again" and "willingness of customers to pay serious m= oney for
their Internet access".
=  
=  
= If you sold this as "partial IPv6" or "incomplete support for RFC8200", the= n sure.
=  
= If most of the time these options are not used, then fine - rate limit when= they come up. But say that's what you're doing.
=  
= And don't pretend that this is for security purposes.
=
Joe


--=_24da51290c5183e9c24919a3935b50a2-- From nobody Mon Nov 26 14:50:02 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804E712E036; Mon, 26 Nov 2018 14:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lT1hIVN43BT1; Mon, 26 Nov 2018 14:49:52 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39E7126CB6; Mon, 26 Nov 2018 14:49:52 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id t13so6845682pgr.11; Mon, 26 Nov 2018 14:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eoXSqKO6Z/LmoQWAvmyd3n4PoxZmFLfzxh61zFO4BP4=; b=qf/SEWoFuJLLJ13hW9aWQ0RM9kB7Enoo519Lia0Fl0nIG2dlMvojUIxbYY0cKz8Ndr Bi7+oDb8ra1gjVi3VNwd9IejkYyceYgIeoRn2tR4VyfAjN0IKiL72QVcCkR4Csk0ToA7 YHky4MnVMsEDwN5dZw37INZOyXuMHovPIPKZLsudA5BICdEX679LjGB0aCWKK2EKlcsS kNE8KvdVbQgHAo/cnjZBP7dlW4r3ZHgF6em9Ck6VrF0IHhlhSi47Op0UMCreaOwatf33 jG1bAqIu8aLbIaMhe9A/TvLzAiJEonWqEM0NsNKQ2MEELWNSkW5vBHrhN4G7VefSzyTb eZ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eoXSqKO6Z/LmoQWAvmyd3n4PoxZmFLfzxh61zFO4BP4=; b=E3eoU2ESuDh+udIuKk7Durp03uUj/0Mi1O/4dWdUS36VNdI5NdmriHci4P5779ifrH 9BWPjhi4Z9WW2X5TKD1oBObCiaYL8+yMJpEvqfU/hwxqZOqfydGbOCaZGbNJV9W14WdT JPw4scQ9jCEMbbxm/XuUhpbSefX1/6hHDNu2ZLf/TxQoiNNSM0a6rTZqyGhQ2lI68rZ0 rOt6GkBzxp86O7znP4k9z+dQRpScXaBJD8j6G+uJphblhbic8LnQJw1jDzbXdEjSX+Wu 9n278OEyMxt0A5/1IVAtWbajPfgAYq5jy0UsGwbslztVnf7V9VKWF7BtwtAsdaakynRy TSwA== X-Gm-Message-State: AA+aEWYo4AYyglzljReYKNIG3rDnQo1gJNKiaecFHqD5qsDBg9qtX/zr 1x6U43I1Slvs+m8ljz33FgQ= X-Google-Smtp-Source: AFSGD/XfPKQ5EPyXedtOS+dyUF68/zmds2hBssKxk6PRqk05f19jERzu9VpbPkeI9gKf11ScY8a/lw== X-Received: by 2002:a63:5026:: with SMTP id e38mr26910433pgb.123.1543272592189; Mon, 26 Nov 2018 14:49:52 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 144sm1903025pfz.149.2018.11.26.14.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 14:49:51 -0800 (PST) From: Bob Hinden Message-Id: <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9D739C7C-F327-4910-B221-F25F07778EF6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Nov 2018 14:49:49 -0800 In-Reply-To: Cc: Bob Hinden , OPSEC , IETF To: "C. M. Heard" References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 22:49:55 -0000 --Apple-Mail=_9D739C7C-F327-4910-B221-F25F07778EF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mike, =46rom your email: > On Nov 26, 2018, at 6:46 AM, C. M. Heard wrote: >=20 . . . . > NEW: > . . . . >=20 > 3.5.5. Advice >=20 > Operators should determine according to their own circumstances > whether to discard packets containing unknown IPv6 EHs. >=20 =46rom reading the email thread, this sentence seems to me to be a good = summary of the draft. I wonder if this is something the IETF needs to tell operators. Based = on the discussion, I suspect it is not. Bob --Apple-Mail=_9D739C7C-F327-4910-B221-F25F07778EF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlv8eI0ACgkQrut0EXfn u6gZDwf/TYjp4UaoB8JM2M0BP/7ZK9UPfSTdj9WmHhnn/QJgE+lYtEzvrwuekI5/ Yn42mtPDMeaCSOiP7nov3DjKYkdAGWLKFesJD3QUoYnr709RMM8cQl1p6EIU/U66 sq+/6xPm16QHOqU1BaJ3IH8WOhTIyi0YlB9KkOVb61fFb8ne/77aPMZmojq21BLC maccFNU/gDpgLLEtzCcu83btJ0E6uPahHapDOR70YLeotESwkHciOHUgYsyl/dvf lQReXtHeZkHxLEW/Df+Baf//0/xlAYhRYWGAXDR/U5RVOG7DkTYkF0YX+2kgaZTl p+qlg+wqlgBZLxkBX5ZK5qw+aWC+8A== =7Txv -----END PGP SIGNATURE----- --Apple-Mail=_9D739C7C-F327-4910-B221-F25F07778EF6-- From nobody Mon Nov 26 15:10:08 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5CD13103C; Mon, 26 Nov 2018 15:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2MHCSa7DAZgO; Mon, 26 Nov 2018 15:10:00 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6B2126CB6; Mon, 26 Nov 2018 15:09:59 -0800 (PST) X-Envelope-To: opsec@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAQN9uNv063715 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2018 23:09:57 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Bob Hinden Cc: "C. M. Heard" , OPSEC , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> From: Nick Hilliard Message-ID: Date: Mon, 26 Nov 2018 23:09:55 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 23:10:02 -0000 Bob Hinden wrote on 26/11/2018 22:49: > I wonder if this is something the IETF needs to tell operators. > Based on the discussion, I suspect it is not. The draft is useful and should be published with Brian's and Mike's wording suggestions: some operators will read it and use it to inform themselves. It's also useful to document how protocol specification choices can cause implementation difficulties. Nick From nobody Mon Nov 26 15:18:47 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DE0130DFA; Mon, 26 Nov 2018 15:18:39 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YqB_bud1p4nV; Mon, 26 Nov 2018 15:18:37 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 1E604126CB6; Mon, 26 Nov 2018 15:18:37 -0800 (PST) X-AuditID: 1209190c-25fff700000049ea-7f-5bfc7f4b14e9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 68.28.18922.B4F7CFB5; Mon, 26 Nov 2018 18:18:35 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wAQNIXhg007991; Mon, 26 Nov 2018 18:18:34 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAQNIR3n001207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Nov 2018 18:18:31 -0500 Date: Mon, 26 Nov 2018 17:18:26 -0600 From: Benjamin Kaduk To: Fernando Gont Cc: Christian Huitema , tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181126231826.GD10033@kduck.kaduk.org> References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrOtd/yfaYMtnbYu7ew6wWjxZ9YbN YnLjbHaLZxvns1h82HqXzWLWnkUsDmwet2acYvFYsuQnk8eHQz3sAcxRXDYpqTmZZalF+nYJ XBkvXx5mKrgmXnFmjnUDY59wFyMnh4SAicSJSRsYuxi5OIQE1jBJTNnzgBXC2cgo8fB8DzOE c5dJYsORi0wgLSwCqhIrr3aygNhsAioSDd2XmUFsEQFNibnPjzCBNDAL7GCUaF/9ghEkISwQ KfHh82q2LkYODl6gfW235SCGrmKR+HniLFgNr4CgxMmZT8CGMgtoSdz495IJpJ5ZQFpi+T8O kDCngLPE9nnf2EBsUQFlib19h9gnMArMQtI9C0n3LITuBYzMqxhlU3KrdHMTM3OKU5N1i5MT 8/JSi3QN9XIzS/RSU0o3MYIDW5JnB+OZN16HGAU4GJV4eCO+/o4WYk0sK67MPcQoycGkJMrr 8RcoxJeUn1KZkVicEV9UmpNafIhRgoNZSYTXdwlQjjclsbIqtSgfJiXNwaIkzvtb5HG0kEB6 YklqdmpqQWoRTFaGg0NJgvd97Z9oIcGi1PTUirTMnBKENBMHJ8hwHqDhp0FqeIsLEnOLM9Mh 8qcYjTluHPg/nZmjY92yOcxCLHn5ealS4rw7QUoFQEozSvPgpoGSk0T2/ppXjOJAzwnzfgGp 4gEmNrh5r4BWMQGtujYR5I/ikkSElFQDY9p6P9PLJpafn5fwKJ3N/tw9eaZ3jY7z6zPbL+/u evflt0vjTvWFul6ntWyc+Gyro225J1787mI7SfDEi+CMtaHB/fqv9LT0Kizq7vXL30+KunFh kwz3naU7llcvmzDt7IQwgUO3ltfqtMv/fSG7ICVBdNXk6928639/vPO3+I1K1/N85fnhEUos xRmJhlrMRcWJACM0m4spAwAA Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 23:18:40 -0000 On Mon, Nov 26, 2018 at 04:21:06AM -0300, Fernando Gont wrote: > Christian. > > On 25/11/18 17:40, Christian Huitema wrote: > [.....] > > > Nick made that point, probably unintentionally, when he wrote that > > "transit operators would generally take the view that any data-plane > > packet which needs to be put through a slow path will be rate limited up > > to 100% loss". Last I checked, data plane processing is implemented in > > specialized components that are designed for speed. I am quite concerned > > that filtering recommendations made by the IETF will end up deeply > > embedded in the hardware of at least some routers, and that changing > > them in the future would be quite hard. That's pretty much the recipe > > for ossification. > > PLease take a look at the advice: it essentially argues "pass everything > that has been stadardizez and that will not cause you pain". And, again, How is this better than "pass everything that will not cause you pain"? Why should the transit care if something is standardized or just an experiment running over the internet? > this is in line with RFC7045. Compare that with what we have in the > real world (RFC7872), and you'll probably agree that if folks were to > implement this advice, it would be a *huge* improvement -- at the time > of this writing you cannot even use ipsec reliably on the Internet(!). One can agree that folks implementing this advice would be an improvement over the current state of affairs, without agreeing that the IETF should advocate against using our protocols as they were designed. > > > > The IPv6 header contains a > > "payload type" field, that may legitimately contain any of the payload > > types defined in the IANA registry of protocol numbers > > (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). > > Some of those payload types are flagged as IPv6 extension header types > > and listed in the corresponding registry > > (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml). Discussing > > EH without discussing the other payload types seems bizarre. Do the > > reasons for blocking for the experimental payload type 253 also apply > > to, for example, the UDP Lite payload type? What about discussing ESP > > and not discussing L2TP or MANET? > > This document discusses EHs. THe considerations for filtering on upper > payloads are rather different, and normally depend on the upper protocol > details. (e.g. TCP ports). Perhaps I am confused, but IIUC this document discusses values placed in the IPv6 "Next Header" field, some of which are EHs and some of which are not. Values not recognized to the processing entity may be EHs or may be "next protocol"s, and if the value is not recognized there is no way to know which is the case. Ergo, filtering out unknown values that might be EHs is also filtering out unknown next-protocols, which seems really bad for the future flexibility of the internet. -Ben From nobody Mon Nov 26 15:38:49 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEA4130FD0; Mon, 26 Nov 2018 15:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 RBJmSMkU00E1; Mon, 26 Nov 2018 15:38:38 -0800 (PST) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EA512DF72; Mon, 26 Nov 2018 15:38:38 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1C2B2115F0B; Mon, 26 Nov 2018 18:38:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=l91tbgbrX/LhKxegQW5x5Ol0NJE=; b=upSRdd 5E2NAqKRVGxxRP72gqLnbhzq0/2VPyi9Fvrh4GB34XpIWya3KiFOZAPEZmAP+M9R olGwZXsDX0ydCsMpXbnRW2/ZhkCVxyle3b/+egr57aBDfdaHHud8SAC2gwlnu2TI Tp8RV6uVXGLLKg45MuN+5KXwQICW4GJkcySaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=eY8eTHTCgkxc2J2RTQBkUaj9DoU4Gbzq nYnlgxadPB3uVEdDpKse1C9s05uqUVFhIFVPvch9gN67AiTle/k6OSj0SSeuxc8x slRgIDdsVf3BCllFQ2nGpWwAAinDXnm8HLrDRXMDGPI2PbX8Rub3PEqQGz6I3wlp oHkLO5OC7W0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 153F6115F0A; Mon, 26 Nov 2018 18:38:37 -0500 (EST) Received: from mail-it1-f177.google.com (unknown [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 9EEEB115F07; Mon, 26 Nov 2018 18:38:36 -0500 (EST) Received: by mail-it1-f177.google.com with SMTP id h193so30873129ita.5; Mon, 26 Nov 2018 15:38:36 -0800 (PST) X-Gm-Message-State: AA+aEWYRBap+S3NO1gqtYrHlbJeR6kbP9Y3o2kNh4+V+7E7sO+NTh2HC jWAZJUj1fW90gpAX72qJm7lesUKYYLzEL86Q4Zs= X-Google-Smtp-Source: AFSGD/VtEy61CGyAcjupuZyT3Ytb323TcB7/6an4rXdjr0U40eD5ksK4Lso0RoA46rdsKdCpqfR0zyLXP6K9SO+j18o= X-Received: by 2002:a24:eb0b:: with SMTP id h11mr25442297itj.138.1543275515875; Mon, 26 Nov 2018 15:38:35 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> In-Reply-To: From: "C. M. Heard" Date: Mon, 26 Nov 2018 15:38:24 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Nick Hilliard Cc: Bob Hinden , OPSEC , IETF Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 651DE500-F1D4-11E8-B4C8-BFB3E64BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 23:38:40 -0000 Bob Hinden wrote on 26/11/2018 22:49: > I wonder if this is something the IETF needs to tell operators. > Based on the discussion, I suspect it is not. Probably not :-) On Mon, Nov 26, 2018 at 3:10 PM Nick Hilliard replied: > The draft is useful and should be published with Brian's and Mike's > wording suggestions: some operators will read it and use it to inform > themselves. Indeed, I think that the document does a pretty good job of setting forth operational impacts of filtering policies, and that (rather than any specific filtering advice) is where most of the utility lies. > It's also useful to document how protocol specification choices can > cause implementation difficulties. That would be a good thing to document. However, since the document is aimed at operators, not equipment implementors, that would probably be considered out of scope. Thanks, Mike Heard From nobody Mon Nov 26 16:07:54 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6712813106F; Mon, 26 Nov 2018 16:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Twvu8lv1f-d6; Mon, 26 Nov 2018 16:07:46 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 4D6BF12DF72; Mon, 26 Nov 2018 16:07:46 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9DCB13AC858; Tue, 27 Nov 2018 00:07:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EF6EA160067; Tue, 27 Nov 2018 00:07:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CDBF1160082; Tue, 27 Nov 2018 00:07:11 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PBlGRuhJbzyS; Tue, 27 Nov 2018 00:07:11 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2E3A8160067; Tue, 27 Nov 2018 00:07:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Tue, 27 Nov 2018 11:06:51 +1100 Cc: Joe Touch , opsec@ietf.org, IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <01CACB34-C018-4EC5-A437-90F745856549@isc.org> References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <4138e2eb-71e0-4c3d-36cb-38da8369a7c6@si6networks.com> <1BEB4C2C-0873-4D08-8A7D-1C3E30AC374F@strayalpha.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 00:07:48 -0000 The same is true in DNS. Recursive servers end up having to probe with = different extensions set. Such probing is being turned off for basic EDNS because it leads to false = positives about what the remote server support which in turn breaks DNSSEC which depends on EDNS and = being able to set the DO flag bit. One source vendors are so fed up with this stupidity by firewall vendors = that they are collectively going to stop shipping code that automatically attempts to work around = this breakage. The big open recursive resolver operators are also turning off work arounds. This at = least will mean that DNSSEC will become more reliable. https://dnsflagday.net https://ednscomp.isc.org/compliance/summary.html has lots of time series = showing how different extension mechanisms are blocked / mis-handled. EDNS has stated from day 1 that unknown EDNS flags are to be ignored yet = there are firewall vendors that seem to think it is a good idea to block them. It took years for DO to = be allow through by most firewalls. EDNS has stated from day 1 that unknown EDNS versions are supposed to be = responded to by BADVERS with the highest version supported but we still have firewall vendors block EDNS = version !=3D 0 requests. EDNS also says that unknown EDNS options are to be ignored by the server = yet there are firewalls that block them by default. There are those that block NSID options in the request = by default, but it something the DNS operator has to enable in the server for there to be a NSID in the = response. None of this blockage provides any real security. Name servers handle = all of these extensions and don=E2=80=99t fall over. There really is too much paranoia by firewall and other vendors. Just = because something is using a extension mechanism it doesn=E2=80=99t mean that it is dangerous or abuse. Getting back to IPv6 headers ASIC=E2=80=99s that can=E2=80=99t skip over = fragmentation headers are just plain broken. ASIC=E2=80=99s that can=E2=80=99t generate PTB responses are just plain = broken. These are part of basic IPv6. Neither should require hitting the slow path. Mark > On 27 Nov 2018, at 2:18 am, Eric Rescorla wrote: >=20 > Picking a random message to reply to. >=20 > I'm not any kind of IPv6 expert, so I'm not taking a position on the = goodness or badness of extension headers. >=20 > With that said, we do have a fair amount of experience with trying to = deploy new protocols in the face of significant levels of network-level = filtering; TLS 1.3 was delayed by a year or so when we discovered that = there were middleboxes which made incorrect assumptions about our = extension points. At the end of the day, we got things working, but at = the cost of some not very attractive hacks, and if you look at QUIC, a = lot of the design is motivated by concealing extension points from = network intermediaries in order to avoid a replay of this scenario. = Otherwise, we're worried that we won't be able to extend the protocol in = the future. >=20 > So, at least from the endpoint's perspective, a situation in which = network intermediaries block any new protocol features they don't = recognize is not really great. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Nov 26, 2018 at 6:36 AM Joe Touch = wrote: >=20 >=20 > > On Nov 25, 2018, at 11:54 PM, Fernando Gont = wrote: > >=20 > > What this doc tries to do is to analyze the possible effects of > > different types and options, and only advice to drop them when there = is > > a clear reason to do so. >=20 > It claims those actions based on security. This is not a security = issue. It is a revenue preservation issue. >=20 > There is a big difference between using a protocol feature and abusing = it. The implication that merely using some of these features is a = security issue and an abuse is the problem with this document - and the = approach of similar documents. >=20 > Joe --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 26 16:34:01 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E477012D7EA; Mon, 26 Nov 2018 16:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L1u5cLlc32lX; Mon, 26 Nov 2018 16:33:50 -0800 (PST) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4227C12D4E8; Mon, 26 Nov 2018 16:33:50 -0800 (PST) Received: by mail-pl1-x642.google.com with SMTP id p8so4406331plo.2; Mon, 26 Nov 2018 16:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Kfp/Qpq41pdlLiPrL6lVc+7VIxeQBA/KdDvy4Cd6OGg=; b=ppzDU0DKaHW3IjKuPVe7jjE+zse4L8XGAFa01vLCG9D2dBrExFQZqDToMcC4eueCG9 GVb2IjL5VcF7Dcyv39+4HNHelgKVb4Klb2ygAItl+1y8rKiesRrnsKHyPpKvGQB6kIkp OYSKWkvkGWuWrWySv/YogEPCh9j5iTeEvLuWAHILyg29Iv7dGcDIgGhmqZrIchJmMI9E aOMPfTfxAu7jRxCr5miq25StICruosHmlRyWlUvCFYjN8gGSdpRn/xNFUXTEaa/ksnxf Ok6jJIEb9bn3LnbMj4SVTWUlX30+QkaLCG/q9bCXBfxR5FW8lbjLJwIC7qgXP8AhpP8N pN4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Kfp/Qpq41pdlLiPrL6lVc+7VIxeQBA/KdDvy4Cd6OGg=; b=nTT7AOpTA/Z0Y8njhFGM4sTI780iOSuYy6DER5+62jwxU5cshKhd07Bv7LrwWjep8d al6sfbCdKIdJynSyi7gm3/eQO44BZO4LYSv4Trgg3kQKdqwWCheQp8kMn5rF+zFVFqOm XpTSnraex0q6SF0s9FoqFDBrrjKsTtJCIbJMwlbzh94Mz5EklD/yO3TxC7JvBuerSzdJ IjNUdxVjFZDBKUyJNdwDHsTEKij9NAuyuuKhSPX+/yPtO9pjPoF9iNUtJ+2akNk/dW2D ssSLrDbUhiU+NDXQfzi1hbL+dNUA4kRApBlMA7XRUienr7tbQApuA0JvhKbearhR/Y6T POXw== X-Gm-Message-State: AA+aEWbRc9KRcNMQSJcQ0lswfMuB7xBZIlPtoa1858kR/MZPm/YUcwr/ Op1FndXf/cymtX58RnUAZTPu4gM3 X-Google-Smtp-Source: AFSGD/WN6eENI+elEDhmDGfS+nDWDHBSaTe6C7yQCoBFNULxLROxwmcc9IpdM/+4WFPug5didBn4CQ== X-Received: by 2002:a17:902:bf49:: with SMTP id u9mr29795158pls.4.1543278829546; Mon, 26 Nov 2018 16:33:49 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id j197sm2720084pgc.76.2018.11.26.16.33.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 16:33:48 -0800 (PST) To: Benjamin Kaduk , Fernando Gont Cc: tsv-art , OPSEC , Christian Huitema , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <20181126231826.GD10033@kduck.kaduk.org> From: Brian E Carpenter Message-ID: Date: Tue, 27 Nov 2018 13:33:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181126231826.GD10033@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 00:33:52 -0000 On 2018-11-27 12:18, Benjamin Kaduk wrote: > Perhaps I am confused, but IIUC this document discusses values placed in > the IPv6 "Next Header" field, some of which are EHs and some of which are > not. Values not recognized to the processing entity may be EHs or may be > "next protocol"s, and if the value is not recognized there is no way to > know which is the case. Ergo, filtering out unknown values that might be > EHs is also filtering out unknown next-protocols, which seems really bad > for the future flexibility of the internet. You are not at all confused. That's one of the reasons we wrote RFC7045. But for a paranoid firewall, it doesn't matter. The logic is unrecognized -> drop in either case. (This is part of the chain of reasoning that led to draft-carpenter-limited-domains, but that's another story.) Brian From nobody Mon Nov 26 17:18:32 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A320130DD4; Mon, 26 Nov 2018 17:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dNQ2LnjW_fhK; Mon, 26 Nov 2018 17:18:23 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058A41277CC; Mon, 26 Nov 2018 17:18:22 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAR1IJqY080177 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2018 01:18:20 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Joe Touch Cc: ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> From: Nick Hilliard Message-ID: <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> Date: Tue, 27 Nov 2018 01:18:18 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 01:18:25 -0000 Joe Touch wrote on 26/11/2018 21:59: > Rate limiting is quite different from 100% discards. When abuse > happens, it's clearly safe to react. data plane speeds are measured in terabits/sec. Control plane capacity for dealing with punted packets is measured in kilobits. As end user and data plane speeds increase, rate-limiting for problematic packets will tend towards towards 100% loss. It doesn't matter if your packet stream is subject to 20% loss, or 100%, or 100% for 20% of the time - beyond a certain point, the end user experience will languish in an indistinguishable morass of unusability. Nick From nobody Mon Nov 26 17:47:49 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2F12F1A5; Mon, 26 Nov 2018 17:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 jHUW8BxUEp6z; Mon, 26 Nov 2018 17:47:33 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 86088129A87; Mon, 26 Nov 2018 17:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HjRET45+xlkPJcpWhthsSHCSBD7U4KGxHOqjFWSA9Jg=; b=MCOninpclzc43wGZj2zunnQhF wZVsLh//3a47qCERVhPTynthvyi7yVV1azMqlDeYoE54wTxFrtbSmVhIBldIVieSY134nVRNU3XTi iBd98z0QLrAAzPT2HgLORAons+Wc03LRfuHAwiV4f7LsN1BYWkXYFiTxou1fVPKnow1Qfxyjp3zMp EDg929BHeUfrru/nssUP/LCG1O9VKaJVymGQ43WkjeTltfcvqeoGQCFkl7Dp9oCAaCRDbOAQyjADe cg4+q30fNiPJnq0GXCiUYoU8lEUzsrF7XkvdiELj8nXXrw7BVxSAQFZFEW/+RIyZqWnyOPLLQ1+tv 4vvnl9BbA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60446 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRSTK-000F3N-Fv; Mon, 26 Nov 2018 20:47:32 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> Date: Mon, 26 Nov 2018 17:47:28 -0800 Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 01:47:35 -0000 If you can=E2=80=99t handle options, then you=E2=80=99re just lying = about the tbps. Joe > On Nov 26, 2018, at 5:18 PM, Nick Hilliard wrote: >=20 > Joe Touch wrote on 26/11/2018 21:59: >> Rate limiting is quite different from 100% discards. When abuse >> happens, it's clearly safe to react. > data plane speeds are measured in terabits/sec. Control plane = capacity for dealing with punted packets is measured in kilobits. As = end user and data plane speeds increase, rate-limiting for problematic = packets will tend towards towards 100% loss. >=20 > It doesn't matter if your packet stream is subject to 20% loss, or = 100%, or 100% for 20% of the time - beyond a certain point, the end user = experience will languish in an indistinguishable morass of unusability. >=20 > Nick >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Mon Nov 26 22:50:48 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A7130E25; Mon, 26 Nov 2018 22:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vINhMLZFjblR; Mon, 26 Nov 2018 22:50:39 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC83130E6E; Mon, 26 Nov 2018 22:50:39 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:8824:35b:e633:a327] (unknown [IPv6:2001:470:5:ac9:8824:35b:e633:a327]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A5DD787742; Tue, 27 Nov 2018 07:50:32 +0100 (CET) To: Bob Hinden , "C. M. Heard" Cc: OPSEC , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> Date: Tue, 27 Nov 2018 03:36:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 06:50:47 -0000 On 26/11/18 19:49, Bob Hinden wrote: > Mike, > > From your email: > >> On Nov 26, 2018, at 6:46 AM, C. M. Heard wrote: >> > > .. . . . > >> NEW: >> . . . . >> >> 3.5.5. Advice >> >> Operators should determine according to their own circumstances >> whether to discard packets containing unknown IPv6 EHs. >> > > From reading the email thread, this sentence seems to me to be a good summary of the draft. Most of the content of this document is about analyzing the implications of each EH and option, to help folks with the aforementioned analysis -- regardless of what the outcome of scuh analysis is. THanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Nov 26 23:35:17 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2095B1241F6 for ; Mon, 26 Nov 2018 23:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no 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 6AQZ14GK2C8p for ; Mon, 26 Nov 2018 23:35:02 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 DC4CB130E77 for ; Mon, 26 Nov 2018 23:34:58 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CF42F41C37 for ; Tue, 27 Nov 2018 08:34:56 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id BC11741B3A; Tue, 27 Nov 2018 08:34:56 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id B7A6A74581; Tue, 27 Nov 2018 08:34:56 +0100 (CET) Date: Tue, 27 Nov 2018 08:34:56 +0100 From: Gert Doering To: Joe Touch Cc: Gert Doering , Christian Huitema , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , OPSEC , tsv-art , Brian E Carpenter Message-ID: <20181127073456.GB72840@Space.Net> References: <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="crKL6RA0ItB9/v2W" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 07:35:03 -0000 --crKL6RA0ItB9/v2W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 26, 2018 at 01:59:38PM -0800, Joe Touch wrote: > > Of course you can build a box that can do everything with the same=20 > > speed. I would recommend to the reader to make himself familiar with > > current market realities, though, regarding "cost", "power consumption", > > "feasibility to build in time before the increase in bandwidth has them > > obsoleted again" and "willingness of customers to pay serious money for= =20 > > their Internet access". >=20 > If you sold this as "partial IPv6" or "incomplete support for RFC8200", > then sure.=20 >=20 > If most of the time these options are not used, then fine - rate limit > when they come up. But say that's what you're doing.=20 >=20 > And don't pretend that this is for security purposes.=20 So your advice would be to turn off IPv6 support in our network, then? Because customers are not going to pay money for it, and "no money for it" is not going to buy me a "full featured and IETF-approved" set of routers. Reality can be fairly uncomfortable. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --crKL6RA0ItB9/v2W Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlv8858ACgkQ31bAZeTO f8U0fxAAm+kgw4RdbHbM2b8hLA8HnsXX9YqJ37M1SQS1IzxkdugaFegaISQ5NxE7 7Ltvdcb3TYpxibroZw6jsLEN26zEC0CoNb+Pye8FnDdZ8puYXHyjuszuYaz51xMd UDx4m2x/f5rPWKBfspns1TCM6HYWpW5GT6oUa85Rrz1pd+FBBrd33qXwLet15u0T lj+dVmA/ps4AN1odBGrPSW1XRJ5q0ogwhqiZUSrtKpId0tEW7NTVPkrZCqo64dxQ CpxqPTkPKybP8bPRx/MWQVzBoJIBOPmafrnPanlUfuLrPz7jBV7INc2Bd4luvT3j O2o4Ro1J1vb2B4aOenfIY1HZh5jS+8lxCLbZ1VuNR4WKnG0B3MGX3Qa3DRsBQn87 36WlJB7nIbioGYWRXDpUcpa/lMgLWNR4gyP9MO6GZY1KMusSxDVaQCxaN5abBKom 0MCDS19773VUUKlGZCZv+o/ulJFILIRNe90Tf195eyQgiX6lAfP5U+jYFCCSG7ii K15JEqsJmPQzjGyuIM/gHBnHQTS3U7ge/62SpSnE3kN3kZhB5gMru6HraqiXXAgG Rm95AgzMZKQdu1sUDLYfYjl0OljWsnHk8t+5ckp8YkdNEGWDHvGnpIJeV/cKQMIg b89ILtRDX5+BgwGQzRyfYEyTQv6moMgkvruwXgjfdk/Q3ScNvI8= =B5CS -----END PGP SIGNATURE----- --crKL6RA0ItB9/v2W-- From nobody Tue Nov 27 00:28:17 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D405B12872C; Tue, 27 Nov 2018 00:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tWCS6VYpUUHj; Tue, 27 Nov 2018 00:28:15 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14B6130DE9; Tue, 27 Nov 2018 00:28:14 -0800 (PST) Received: from astfgl.hanazo.no (77.16.223.47.tmi.telenormobil.no [77.16.223.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id A3C49FECBF17; Tue, 27 Nov 2018 08:28:12 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 38483A527CC; Tue, 27 Nov 2018 09:28:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> Date: Tue, 27 Nov 2018 09:28:06 +0100 Cc: Bob Hinden , "C. M. Heard" , OPSEC , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 08:28:17 -0000 Fernando, et al, >> =46rom reading the email thread, this sentence seems to me to be a = good summary of the draft. >=20 > Most of the content of this document is about analyzing the = implications > of each EH and option, to help folks with the aforementioned analysis = -- > regardless of what the outcome of scuh analysis is. OK, that=E2=80=99s good to hear. If that=E2=80=99s the case I would have liked to see more text on = explaining the background, give reasons why filtering in the middle of = the network is harmful (protocol extensions, ossification, violates = Internet arc hitecture principles, packet parsing is costly, might = required symmetric paths, etc). A very unfortunate consequence of this work, is that the IETF appears to = send a message that routers in the Internet is now expected to parse = deep into packets and perform filtering actions. That=E2=80=99s a big = change of the Internet architecture, and our view of layering. A few comments on the actual advice: The HBH advice (3.4.1.5) is fine and reflects that I think. Likewise for the RH advice (3.4.2.5), FH (3.4.3.5) and DestOpt = (3.4.6.5). * Protocol numbers 253/254 OLD: 3.4.10.5. Advice Intermediate systems should discard packets containing these EHs. Only in specific scenarios in which RFC3692-Style experiments are to be performed should these EHs be permitted. NEW: 3.4.10.5. Advice Intermediate systems should permit packets that contain these EHs. * New protocol types / extension headers OLD 3.5.5. Advice Intermediate systems should discard packets containing unknown IPv6 EHs. NEW: 3.5.5. Advice Intermediate systems should permit packets containing unknown IPv6 EHs. * MLD 4.3.7.5. Advice Intermediate systems should discard packets that contain this option. Only in specific environments where support for RSVP, multicast routing, or similar protocols is desired, should this option be permitted. Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links = must generally be multicast capable. A recommendation of a blanket kill of MLD can=E2=80=99t be right. I don=E2=80=99t know how this recommendation should be formed, perhaps = say something to separate MLD as used on-link with hop-limit =3D 1? Unknown options types: OLD: 4.4.5. Advice Enterprise intermediate systems that process the contents of IPv6 EHs should discard packets that contain unknown options. Other intermediate systems that process the contents of IPv6 EHs should permit packets that contain unknown options. NEW: 4.4.5. Advice Intermediate systems should not discard packets based on the presence of unknown options. Ole From nobody Tue Nov 27 02:10:34 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A0D130E14; Tue, 27 Nov 2018 02:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2FWz1nkthtKv; Tue, 27 Nov 2018 02:10:18 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46409130DF9; Tue, 27 Nov 2018 02:10:18 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id k198so21602976wmd.3; Tue, 27 Nov 2018 02:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0wUuE/ImMUYx4d3jyw0ITs5YFdSgdv2zo3JJDOwA9Ok=; b=nhLzcpOskmWUOLh3Ybcmq1+VVP9UxvUAzbV8Ma1mnE3PZgAcQHMhEoRZ2lIU1cupDs xb7NFFdQ5x5N3+1/7SEm/dZ0M30SBesxnY1T0C2KKeuoS/B0mFxDqJ8EqEHa6tsjSfLP ZCOnvWUhippNLo2CU6GDIemha05BOc7Q+pH64iRCQ2uw6FYUQwKVaFYrkQmyimKpqDef l5zcpmmL9yLFtTzgE0fsX1haGecanO5j85Wm/3VYhar6ekezasDsP4fXKS7mE7eSDRR7 7efrtuVodkBUyX+fM8+nvGWw52ZjBIqKI114m3zw73miQA2uBjucuVeKvH7S2i/QfM3V 2yNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0wUuE/ImMUYx4d3jyw0ITs5YFdSgdv2zo3JJDOwA9Ok=; b=OJZtNsOiHLuLZHVqN06KUa3jDXRkvTIVJKLk1bAc0m+zvMx1vH6B571k8thdAbWsoq WxbnjUd2jEAyHV/6wkiY5xoHT/OICdcX+OfYn5EEbgwI5oHMG7ESRkIMh/56eAxP2zIn Jr9DqEF7R/kvysZtIxb95qmhEA7LX1+AKaYhntRBrqEa5eotFP7KR05Oa+fGE0qdKNRx Fvfu+5wZq5gNyBK52uV6hFkPE0o5ExlDYnICFL07O4iGaGp28WCI4olW0BvL249QeWOW n7evR4sPn09Dp8xiy39YOtH2meQR25WbqB2heYfAEielL/Fi1dnxUb9URUIx4AY8bzwY THIQ== X-Gm-Message-State: AA+aEWb8PUV+SQcwX9rtYhXgdsGyNXVK0Y4Ah9rLY3sVI3sMbNk/B7h/ n1YQRBCKvISB4HNK2iiKzEb/FfYY X-Google-Smtp-Source: AFSGD/Vk6BPK1Ww/3iznZQyptv7xLYWxS7L6e96NndMQRM9uUp9nqkdr4EmOcRrdfOnbDa8e831ckQ== X-Received: by 2002:a1c:7209:: with SMTP id n9mr26078933wmc.5.1543313416375; Tue, 27 Nov 2018 02:10:16 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e16sm3289717wrn.72.2018.11.27.02.10.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 02:10:15 -0800 (PST) To: Joe Touch , Gert Doering Cc: ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , Christian Huitema , tsv-art References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> From: Stewart Bryant Message-ID: <30b55539-3765-3f60-057c-728e2f3e6751@gmail.com> Date: Tue, 27 Nov 2018 10:10:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------88C0DBCC63058A5436FD4E8B" Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:10:20 -0000 This is a multi-part message in MIME format. --------------88C0DBCC63058A5436FD4E8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 26/11/2018 21:59, Joe Touch wrote: > > > > On 2018-11-26 09:53, Gert Doering wrote: > >> Hi, >> >> ... >> As people have explained in great detail, there's work that the routers >> are built to do, where the number of packets they can handle is nearly >> arbitrarily high. >> >> Then there's packets that are seen as an exception, and handled in a >> not-as-powerful path.  Back then, when the Internet was new, these >> exceptional packets were considered "something we'll handle when the >> need arises", and it mostly worked. > Translation - "we cheated", and that's not working anymore. Agreed. Fundamentally it is about economics. Doing complex processing in the fast path is expensive. It is expensive to have the cycles available. In designs that use fixed logic assistance it is pretty much infeasible to cope with multiple options as the combinatorial complexity explodes on you. As the packet size increases this is also expensive in terms of the fast packet caching memory needed. In the days when the fast path/slow path decision was first taken, there were also fundamental limits on what could be implemented at any price thus pushing the cost from equipment to physical infrastructure. There are some use cases that say that we need to get 1Tb/s to the host for some applications, so we cannot be sure that the fundamental parsing limit problem will not re-occur. In any case, fast feature = silicon = cost and whilst you can or at least could ride More's law, at the end of the day you have to trade features against port density against power against capex against opex. ... and all this is without the issue of the internet carbon footprint coming under scrutiny. So what this came down to at the time the feature split was taken was a decision on economics, i.e. is the cost of the additional feature worth the price paid? That is still true and  I think that we need to remember that as we add non-optional features into the fast path. - Stewart --------------88C0DBCC63058A5436FD4E8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 26/11/2018 21:59, Joe Touch wrote:


 


On 2018-11-26 09:53, Gert Doering wrote:

Hi,

...
As people have explained in great detail, there's work that the routers
are built to do, where the number of packets they can handle is nearly
arbitrarily high.

Then there's packets that are seen as an exception, and handled in a
not-as-powerful path.  Back then, when the Internet was new, these
exceptional packets were considered "something we'll handle when the
need arises", and it mostly worked.
 
Translation - "we cheated", and that's not working anymore. Agreed.

Fundamentally it is about economics.

Doing complex processing in the fast path is expensive. It is expensive to have the cycles
available. In designs that use fixed logic assistance it is pretty much infeasible to cope with
multiple options as the combinatorial complexity explodes on you.

As the packet size increases this is also expensive in terms of the fast packet caching memory
needed.

In the days when the fast path/slow path decision was first taken, there were also fundamental
limits on what could be implemented at any price thus pushing the cost from equipment
to physical infrastructure. There are some use cases that say that we need to get 1Tb/s
to the host for some applications, so we cannot be sure that the fundamental parsing limit
problem will not re-occur.

In any case, fast feature = silicon = cost and whilst you can or at least could ride More's law,
at the end of the day you have to trade features against port density against power against
capex against opex. ... and all this is without the issue of the internet carbon footprint
coming under scrutiny.
 
So what this came down to at the time the feature split was taken was a decision on economics,
i.e. is the cost of the additional feature worth the price paid? That is still true and  I think that
we need to remember that as we add non-optional features into the fast path.

- Stewart

--------------88C0DBCC63058A5436FD4E8B-- From nobody Tue Nov 27 02:12:48 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D9D128CE4; Tue, 27 Nov 2018 02:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3D1vF6hO0Czk; Tue, 27 Nov 2018 02:12:37 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C662128CF3; Tue, 27 Nov 2018 02:12:37 -0800 (PST) X-Envelope-To: opsec@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wARACV92046722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2018 10:12:31 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Ole Troan Cc: Fernando Gont , "C. M. Heard" , OPSEC , Bob Hinden , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> From: Nick Hilliard Message-ID: <28d771c1-4530-fb48-1b2d-9809c8900574@foobar.org> Date: Tue, 27 Nov 2018 10:12:30 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:12:40 -0000 Ole Troan wrote on 27/11/2018 08:28: > A very unfortunate consequence of this work, is that the IETF appears > to send a message that routers in the Internet is now expected to > parse deep into packets and perform filtering actions. That’s a big > change of the Internet architecture, and our view of layering. quite the opposite: parsing deep inside packets has been a prerequisite of ipv6 EHs from the beginning and a serious row-back from this position was previously standardised in rfc7112. At least this puts us in a position that routers now only need to inspect a single packet to determine the full ipv6 header chain - previously you would have had to inspect all subsequent fragments too, which created the requirement for core devices to track packet state. In practice, most routers will inspect a specific distance - hardware dependent - into a packet and will ignore anything following that. There's really no point building silicon which will do arbitrary length inspection because you end up optimising your hardware for corner cases. Nick From nobody Tue Nov 27 02:18:04 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA63D128CF3; Tue, 27 Nov 2018 02:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1VhOoiEiyDMw; Tue, 27 Nov 2018 02:17:48 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71446126F72; Tue, 27 Nov 2018 02:17:48 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id s11so21609956wmh.1; Tue, 27 Nov 2018 02:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KFaKg72mO8shOeSCoQRJ/mym/evxA5VdytlbHJ9ADJ4=; b=W7dH4Hr2elv4L22euGsuPhcia26E6G1iNfwf4Gcz2CwszZf0JU01Nwfw7p2rq3Ky/u eUQoJaBo4qs2Zt49WwWQqftTniUzvoL9FR1dz/OE+R3zFm2eFuj/NM5wJyoL4fqmwjcJ Fdg+BYC4rtTM1Mc4R92Cq+77IhVl9kJJlZB3+YrpUi//kezBV34JLYmkskZj1hJpVU+x watvmCcoTvNeMcftfaKS510qvhebX//46uVVjuTgewggyZhVH9EPGKagzkbrUiUsojgy 6NHAhIK87oHtb95hRLUTE7WEEuirXPlu4oMX3WJC/UdviNjLGSpTO8db8ebzhV1tjlcP NxTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KFaKg72mO8shOeSCoQRJ/mym/evxA5VdytlbHJ9ADJ4=; b=S+3CREeXys9KU/5gUO+q3YLEk8Y9LekwAPW4EfnO3eXmHG4bTxMAwp8VXFjETZtpzP ilcPVAlR9ZUHSJgRbOMsr3waXFRPHoptTEJZSmx2zKF6OuByPLcSWVKof3VxY52zAX/M 0/VQ7sGJG/PQ8CXQrdsCaYKprt9PiUwyc7GkREqWNyafeoS0leLi4WiY7zkwFZsx5ul8 x3wuIniytihstSxaLNHG+x4NuDU1qo30zC9TyvrIdZO1OyChe+IzQHPhPhLuu498jteo 1Qw5U7z2LCAk5NpqsD7+Pz0h7lWBn7Dv4ImgZ5MbV3FWySdR0iKxnl3oiZW6svxFNaLn wO7Q== X-Gm-Message-State: AA+aEWazivPSMliVB7n59GVaYgf4WL/B+tbcRbAgolZLqkHY5sAUY29B X50dUHbCV/45dKOU/26VYi559pwq X-Google-Smtp-Source: AFSGD/UuLJnkV9vFZ7+zsaPr+5F83kMBh3XKJCQMuwTtBaCNLNuTUkoui4bP75EyyWU/j+1u4FGXDw== X-Received: by 2002:a1c:1b95:: with SMTP id b143mr9171014wmb.3.1543313866470; Tue, 27 Nov 2018 02:17:46 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b13sm3956175wrn.28.2018.11.27.02.17.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 02:17:45 -0800 (PST) To: Joe Touch , Nick Hilliard Cc: tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> From: Stewart Bryant Message-ID: <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> Date: Tue, 27 Nov 2018 10:17:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:17:51 -0000 On 27/11/2018 01:47, Joe Touch wrote: > If you can’t handle options, then you’re just lying about the tbps. When the required application performance exceeds the ability of the hardware designers to deliver it economically (or may be at any price) something has to give. At that point either the protocol gets modified, or it goes end of life. - Stewart > Joe > >> On Nov 26, 2018, at 5:18 PM, Nick Hilliard wrote: >> >> Joe Touch wrote on 26/11/2018 21:59: >>> Rate limiting is quite different from 100% discards. When abuse >>> happens, it's clearly safe to react. >> data plane speeds are measured in terabits/sec. Control plane capacity for dealing with punted packets is measured in kilobits. As end user and data plane speeds increase, rate-limiting for problematic packets will tend towards towards 100% loss. >> >> It doesn't matter if your packet stream is subject to 20% loss, or 100%, or 100% for 20% of the time - beyond a certain point, the end user experience will languish in an indistinguishable morass of unusability. >> >> Nick >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Nov 27 02:40:36 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9FF130E1E; Tue, 27 Nov 2018 02:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 9st38DChIqzF; Tue, 27 Nov 2018 02:40:32 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 291B3130E8D; Tue, 27 Nov 2018 02:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iVf3MnIa+od3W3uwKs+YUnY6fTnXVJFY5u3LD8j2Adg=; b=BLO8NLQuUV4oi3kTD18D4anZk 0+gvlufEWc1GgVwZlpI5a1fsQop5gUpz3ZSIfJFu2b22aDL/+Bk9fHYS9y2og8sMqCeB4YvcKKBuu PK8GamFY1ZMdU1oiZzB6JvN1uGjSR3aU7NRqJga6dJ6G+vvuN/Fu1b3elu5vbVZ3ybYRfEiyk813T VkUDRpnbCRrrOQSQPcANHwMn68yHOj3snMko9wOQaz0s74NL+HuyVhbs5Taw3QMQuE/l1LAgxPArT Xfmr1ABvt0fn+KPSMob3NrXAM4ontOug2ZpRXwN+CJ9rJxXZ/wm0hDlIKIWK/DhBd/2hmL6flraiT o8qAqm9aQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53867 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRan5-000B9w-EP; Tue, 27 Nov 2018 05:40:30 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> Date: Tue, 27 Nov 2018 02:40:26 -0800 Cc: Nick Hilliard , tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> To: Stewart Bryant X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:40:34 -0000 Take that to the standards wg. Don=E2=80=99t stick your head in the sand and= try to do an end run in ops. And don=E2=80=99t call any of this a security i= ssue that it isn=E2=80=99t.=20 Joe > On Nov 27, 2018, at 2:17 AM, Stewart Bryant wro= te: >=20 >=20 >=20 >> On 27/11/2018 01:47, Joe Touch wrote: >> If you can=E2=80=99t handle options, then you=E2=80=99re just lying about= the tbps. >=20 > When the required application performance exceeds the ability of the hardw= are > designers to deliver it economically (or may be at any price) something ha= s to give. > At that point either the protocol gets modified, or it goes end of life. >=20 > - Stewart >=20 >> Joe >>=20 >>> On Nov 26, 2018, at 5:18 PM, Nick Hilliard wrote: >>>=20 >>> Joe Touch wrote on 26/11/2018 21:59: >>>> Rate limiting is quite different from 100% discards. When abuse >>>> happens, it's clearly safe to react. >>> data plane speeds are measured in terabits/sec. Control plane capacity f= or dealing with punted packets is measured in kilobits. As end user and dat= a plane speeds increase, rate-limiting for problematic packets will tend tow= ards towards 100% loss. >>>=20 >>> It doesn't matter if your packet stream is subject to 20% loss, or 100%,= or 100% for 20% of the time - beyond a certain point, the end user experien= ce will languish in an indistinguishable morass of unusability. >>>=20 >>> Nick >>>=20 >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art >=20 From nobody Tue Nov 27 02:52:07 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C891128CE4; Tue, 27 Nov 2018 02:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KlXhBa5HcOLe; Tue, 27 Nov 2018 02:52:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBA61288EB; Tue, 27 Nov 2018 02:52:02 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:8824:35b:e633:a327] (unknown [IPv6:2001:470:5:ac9:8824:35b:e633:a327]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A9FC186FCA; Tue, 27 Nov 2018 11:51:58 +0100 (CET) To: Ole Troan Cc: Bob Hinden , "C. M. Heard" , OPSEC , IETF References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <16202e21-bda7-e72f-5a8a-b3d8c61b7c53@si6networks.com> Date: Tue, 27 Nov 2018 07:42:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:52:06 -0000 Ole, On 27/11/18 05:28, Ole Troan wrote: > Fernando, et al, > >>> From reading the email thread, this sentence seems to me to be a >>> good summary of the draft. >> >> Most of the content of this document is about analyzing the >> implications of each EH and option, to help folks with the >> aforementioned analysis -- regardless of what the outcome of scuh >> analysis is. > > OK, that’s good to hear. If that’s the case I would have liked to see > more text on explaining the background, give reasons why filtering in > the middle of the network is harmful (protocol extensions, > ossification, violates Internet arc hitecture principles, packet > parsing is costly, might required symmetric paths, etc). As noted by a number of folks on this thread already, and as discussed in https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops, folks may have reasons to filter packets. I don't think this document is the place to educate folks on whether packet filtering is a good or a bad thing to do. > A very unfortunate consequence of this work, is that the IETF appears > to send a message that routers in the Internet is now expected to > parse deep into packets and perform filtering actions. That's certainly not the message this document tries to convey, at least. > That’s a big > change of the Internet architecture, and our view of layering. > > A few comments on the actual advice: > > The HBH advice (3.4.1.5) is fine and reflects that I think. Likewise > for the RH advice (3.4.2.5), FH (3.4.3.5) and DestOpt (3.4.6.5). > > * Protocol numbers 253/254 > > OLD: 3.4.10.5. Advice Intermediate systems should discard packets > containing these EHs. Only in specific scenarios in which > RFC3692-Style experiments are to be performed should these EHs be > permitted. > > NEW: 3.4.10.5. Advice Intermediate systems should permit packets > that contain these EHs.> > * New protocol types / extension headers > > OLD 3.5.5. Advice Intermediate systems should discard packets > containing unknown IPv6 EHs. > > NEW: 3.5.5. Advice Intermediate systems should permit packets > containing unknown IPv6 EHs. So far, the change proposed (and agreed upon) for unknown EHs, is: "Operators should determine according to their own circumstances whether to discard packets containing unknown IPv6 EHs." thoughts? > * MLD 4.3.7.5. Advice Intermediate systems should discard packets > that contain this option. Only in specific environments where support > for RSVP, multicast routing, or similar protocols is desired, should > this option be permitted. > > Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links > must generally be multicast capable. A recommendation of a blanket > kill of MLD can’t be right. I don’t know how this recommendation > should be formed, perhaps say something to separate MLD as used > on-link with hop-limit = 1? For packets that you ND and such, wouldn't those packets be directed to the router, rather than requested to be forwarded? > Unknown options types: > > OLD: 4.4.5. Advice Enterprise intermediate systems that process the > contents of IPv6 EHs should discard packets that contain unknown > options. Other intermediate systems that process the contents of > IPv6 EHs should permit packets that contain unknown options. > > NEW: 4.4.5. Advice Intermediate systems should not discard packets > based on the presence of unknown options. Will do. Thanks! Fernando -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Nov 27 02:53:14 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7A128CE4; Tue, 27 Nov 2018 02:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L5rMvLTE_w9v; Tue, 27 Nov 2018 02:52:55 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A06A130E77; Tue, 27 Nov 2018 02:52:55 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id q26so21588734wmf.5; Tue, 27 Nov 2018 02:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FVV2kUHMoLuSvC0Dd0GZUx7UJpP3jE4Ru4xj/CVXCOI=; b=q0TiXzozq2IUncuVeGduDY7xAm7rGcIds9lMXDJtXo/beqBskjotAOraPw3idaxQRh zHO4I9quHP/4hsprRf6l9isYjTS18UQ8aZghmEUaxBhA785GtpK8lZ1ooes4rCMNvLD3 2HlGVZrsptZ1XMfzhC2RTf1fp+KB60fvLL6PAGNgy7q2pX34s2j1tBAsX1G9csoqPV5U 8XQC7nWe1kjWlfhPrjekXQwEcksQnjnnBZSRkk1bFSQLLzNMM5eL0G3M/dabgOAlIn+b 14hT9ypGJeJjyV/gN9zuMDE080swsDnixuN3FWg5Ldq311HpdkNjIfXowaUv3zEfeCP4 /1dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FVV2kUHMoLuSvC0Dd0GZUx7UJpP3jE4Ru4xj/CVXCOI=; b=lc65AfZBoGm5nGhnWcMynZi4dwO8+iJQdmU9PwcnGzfZx5MpfblTGYX3bQRmKiKY2j yne4GwhWF8amcw9CobFaWREXCkKd5sGbvhUCNAdmrDYVHpzwb8hAVTFt4eftCtQpFnTr QQNT/tjtoz0qcFPxD6Z06J/396nBbJ7+9DFlUVqOAxzyfCOLME2LiifSvLv2zf4aatJ/ d6GAop/1vhp4aQ7uAQAQKl0H21LnEal19J015ZKzwbwPnRl8bPKgLGEt5b+nSZepTle9 7lBYqtY+sAG/K6WPGrRxy1IB9Vfz254apLDwOBHZ+KvLH/m0Gwt/rQtW/3QWOhPlKnlu bY8g== X-Gm-Message-State: AGRZ1gJzz5JRHlEbvkoTOiXDMaARii1hk8/a5tLlWvYv9LfmizIh9YP3 PSd1DdqE+DxaFGVZL/THXwY= X-Google-Smtp-Source: AJdET5dV/So7xW/fPxAEJFiZvK4b4kmkUoynWIRitJzChOcvlRpF/V/hmSnfOg56nzHiiyzF6i115w== X-Received: by 2002:a1c:a183:: with SMTP id k125mr25957968wme.25.1543315973441; Tue, 27 Nov 2018 02:52:53 -0800 (PST) Received: from [10.6.218.142] (82-132-225-46.dab.02.net. [82.132.225.46]) by smtp.gmail.com with ESMTPSA id o81sm4294113wmd.10.2018.11.27.02.52.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 02:52:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Stewart Bryant X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Tue, 27 Nov 2018 10:52:51 +0000 Cc: Nick Hilliard , tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69A59AFC-CFE7-42AF-A1BC-4D3B6D1F0D24@gmail.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> To: Joe Touch Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:53:06 -0000 I was simply explaining forwarding engineering 101, which seemed to be being= forgotten in the tread. Beyond that I don=E2=80=99t much care on way or the other. Stewart > On 27 Nov 2018, at 10:40, Joe Touch wrote: >=20 > Take that to the standards wg. Don=E2=80=99t stick your head in the sand a= nd try to do an end run in ops. And don=E2=80=99t call any of this a securit= y issue that it isn=E2=80=99t.=20 >=20 > Joe >=20 >> On Nov 27, 2018, at 2:17 AM, Stewart Bryant wr= ote: >>=20 >>=20 >>=20 >>> On 27/11/2018 01:47, Joe Touch wrote: >>> If you can=E2=80=99t handle options, then you=E2=80=99re just lying abou= t the tbps. >>=20 >> When the required application performance exceeds the ability of the hard= ware >> designers to deliver it economically (or may be at any price) something h= as to give. >> At that point either the protocol gets modified, or it goes end of life. >>=20 >> - Stewart >>=20 >>> Joe >>>=20 >>>> On Nov 26, 2018, at 5:18 PM, Nick Hilliard wrote: >>>>=20 >>>> Joe Touch wrote on 26/11/2018 21:59: >>>>> Rate limiting is quite different from 100% discards. When abuse >>>>> happens, it's clearly safe to react. >>>> data plane speeds are measured in terabits/sec. Control plane capacity= for dealing with punted packets is measured in kilobits. As end user and d= ata plane speeds increase, rate-limiting for problematic packets will tend t= owards towards 100% loss. >>>>=20 >>>> It doesn't matter if your packet stream is subject to 20% loss, or 100%= , or 100% for 20% of the time - beyond a certain point, the end user experie= nce will languish in an indistinguishable morass of unusability. >>>>=20 >>>> Nick >>>>=20 >>>> _______________________________________________ >>>> Tsv-art mailing list >>>> Tsv-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tsv-art >>=20 >=20 From nobody Tue Nov 27 03:08:11 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0AF12E036; Tue, 27 Nov 2018 03:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 QccSkiB-VMKM; Tue, 27 Nov 2018 03:08:07 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 333A7128CE4; Tue, 27 Nov 2018 03:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=74jMPSI4G+zg8MjUedU7kYloS9BNKnmLQpUGIyXTtiQ=; b=r5C7/HFcmlrwl57pl8wYCs2wl ryTnYDEJVPD2VtFrfOZ8yKKM1p/Z6juFNo9uOnVht9mpsdHNz5OZVQ4OOsls5AnNxBlPx2GQX4Uve 9LpbFLfiibepTAqpFYevfvEInk8a1QQU8oMbhyzMsDhXNc6TX8ZFciDX7tb4wWkn7I6jqaAh35q2e 8l7igtVqdwC0WW4mdr8+SHc+22q/xr8XoBFe9nPdb58t21aGAe66QWsmOezXPi47y/I0EBO0d+MJL mQMj/ppFd6o6NsL+/lJAj8BxtWeo04VimWzGhoTbXK1pes8gBzMuxkwjegow6ziqnVjWEJ320czXZ FoONuNJQQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54047 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRbDn-000Xao-9v; Tue, 27 Nov 2018 06:08:06 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <69A59AFC-CFE7-42AF-A1BC-4D3B6D1F0D24@gmail.com> Date: Tue, 27 Nov 2018 03:08:02 -0800 Cc: Nick Hilliard , tsv-art , OPSEC , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <69A59AFC-CFE7-42AF-A1BC-4D3B6D1F0D24@gmail.com> To: Stewart Bryant X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 11:08:09 -0000 Standards 101 is either support the standard or revise it. The latter was tr= ied and rejected. Whatever you do, don=E2=80=99t fail to support it for false reasons. Joe=20 > On Nov 27, 2018, at 2:52 AM, Stewart Bryant wro= te: >=20 > I was simply explaining forwarding engineering 101, which seemed to be bei= ng forgotten in the tread. >=20 > Beyond that I don=E2=80=99t much care on way or the other. >=20 > Stewart >=20 >=20 >=20 >> On 27 Nov 2018, at 10:40, Joe Touch wrote: >>=20 >> Take that to the standards wg. Don=E2=80=99t stick your head in the sand a= nd try to do an end run in ops. And don=E2=80=99t call any of this a securit= y issue that it isn=E2=80=99t.=20 >>=20 >> Joe >>=20 >>> On Nov 27, 2018, at 2:17 AM, Stewart Bryant w= rote: >>>=20 >>>=20 >>>=20 >>>> On 27/11/2018 01:47, Joe Touch wrote: >>>> If you can=E2=80=99t handle options, then you=E2=80=99re just lying abo= ut the tbps. >>>=20 >>> When the required application performance exceeds the ability of the har= dware >>> designers to deliver it economically (or may be at any price) something h= as to give. >>> At that point either the protocol gets modified, or it goes end of life.= >>>=20 >>> - Stewart >>>=20 >>>> Joe >>>>=20 >>>>> On Nov 26, 2018, at 5:18 PM, Nick Hilliard wrote: >>>>>=20 >>>>> Joe Touch wrote on 26/11/2018 21:59: >>>>>> Rate limiting is quite different from 100% discards. When abuse >>>>>> happens, it's clearly safe to react. >>>>> data plane speeds are measured in terabits/sec. Control plane capacit= y for dealing with punted packets is measured in kilobits. As end user and d= ata plane speeds increase, rate-limiting for problematic packets will tend t= owards towards 100% loss. >>>>>=20 >>>>> It doesn't matter if your packet stream is subject to 20% loss, or 100= %, or 100% for 20% of the time - beyond a certain point, the end user experi= ence will languish in an indistinguishable morass of unusability. >>>>>=20 >>>>> Nick >>>>>=20 >>>>> _______________________________________________ >>>>> Tsv-art mailing list >>>>> Tsv-art@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tsv-art >>>=20 >>=20 From nobody Tue Nov 27 07:01:47 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AFC130EC2; Tue, 27 Nov 2018 07:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 T3HPoxJ6GPkp; Tue, 27 Nov 2018 07:01:26 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714B3130E34; Tue, 27 Nov 2018 07:01:25 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9FDD011F506; Tue, 27 Nov 2018 10:01:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=RexcyrCg9rgv amshVVrv3aXQ4bA=; b=chV2xenPUOBmzLGyQYcx/VxrSd3ZfiUBaE37MKHqpUMC cVl+YhUe4NAW37MqNr1kESCLM6b4jj6Gcuq+XRDy1joigfSIJnN3QsHAAyEjQ/Zq 1CGbEEkx1z/Q6jthn4n1gODI3ypKa68jY+CaqOG8NgjoMDzRxFc7ZjsR+rw1niE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=G5PVG1 zLoOekK1105TM0OrB8847FQrAdAZg7BV+z5PXTSjfXvpjuBD78at6MaxKgEKmlmE EXlzkD+SL8+6HER7Q28M6liEIJp5VMg0WxZgLQ1jz/MAQJKCNyHdE6BsjiYT4VIE epHvEpCvkH93dmuNDJaDpj1JHzUv2jDX8ozSg= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8948111F505; Tue, 27 Nov 2018 10:01:22 -0500 (EST) Received: from mail-it1-f169.google.com (unknown [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 04C7A11F501; Tue, 27 Nov 2018 10:01:22 -0500 (EST) Received: by mail-it1-f169.google.com with SMTP id g85so34615609ita.3; Tue, 27 Nov 2018 07:01:22 -0800 (PST) X-Gm-Message-State: AGRZ1gJMtiVlBn23A+iwL93Ix6HLvStAQqJg+T/aRkYnpichFNOjO2wv v8TTaQuxr4oknWwAu6FSBAHb/QPbuwIyRkbbsPE= X-Google-Smtp-Source: AFSGD/WWCURm2tjM0bm2mtOGNVcv+D2XpgsfxJ6evs+PKsZVOIgELlIC7dRgWEwuyDCGGVvLCQG1ajFPeudBcMAY8rQ= X-Received: by 2002:a24:ee83:: with SMTP id b125mr29126454iti.151.1543330881511; Tue, 27 Nov 2018 07:01:21 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> <28d771c1-4530-fb48-1b2d-9809c8900574@foobar.org> In-Reply-To: <28d771c1-4530-fb48-1b2d-9809c8900574@foobar.org> From: "C. M. Heard" Date: Tue, 27 Nov 2018 07:01:08 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Nick Hilliard Cc: Ole Troan , Fernando Gont , OPSEC , Bob Hinden , IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 4D7316B0-F255-11E8-87DD-063AD72159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 15:01:39 -0000 On Tue, Nov 27, 2018 at 2:12 AM Nick Hilliard wrote: > > Ole Troan wrote on 27/11/2018 08:28: > > A very unfortunate consequence of this work, is that the IETF appears > > to send a message that routers in the Internet is now expected to > > parse deep into packets and perform filtering actions. That=E2=80=99s a= big > > change of the Internet architecture, and our view of layering. > > quite the opposite: parsing deep inside packets has been a prerequisite > of ipv6 EHs from the beginning Just to be historically accurate, looking past the Hop-by-Hop Options header (which is required to occur first) was not part of the IPv6 architecture at the beginning (RFC 2460 and predecessors). > and a serious row-back from this position > was previously standardised in rfc7112. Which was acknowledgment of the reality that intermediate devices do for many reasons inspect headers up to and including the upper layer protocol header. Mike Heard From nobody Tue Nov 27 11:47:12 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52E11241F6; Tue, 27 Nov 2018 11:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 W7ulxDhEh7OA; Tue, 27 Nov 2018 11:46:57 -0800 (PST) Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41E8130DC0; Tue, 27 Nov 2018 11:46:57 -0800 (PST) Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 3B27C2DF8B; Tue, 27 Nov 2018 14:46:57 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=XuBBovtinCIV gjUMxUntb3bmzI0=; b=P1S26EYef8yebAzvvors5yhzQ+pauJiFcyn+kdzx2AaF FerMmwsvN/2wckuSodWo8Smk/aoS7mBqPNMnuVrUY5bvwuSFUDMBqlSiwJVtVuch dLu69o3FCdnbpCd3xFKXwCiFfJOCRp6u7l+VGfGIBZRD7EsIF+xWJbf/vMsP8y4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=leEai0 IDB+55NJ9w8p32lMIqLOOoAyZTzcEL9iNX9LP7us3gzfaifDqkaGju0U4SvbsepR +psaIL8xIqJziGrIqMFJDdYfCKcPHQhtabgwEJNUSNoWZunNwt1c2EmqodWTzQ19 iAPTq+niOv2VtY1iFUnvjDQJbLZx2Vgcy8pcY= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 33F722DF89; Tue, 27 Nov 2018 14:46:57 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-it1-f172.google.com (unknown [209.85.166.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 9BFCE2DF87; Tue, 27 Nov 2018 14:46:54 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-it1-f172.google.com with SMTP id b5so445494iti.2; Tue, 27 Nov 2018 11:46:54 -0800 (PST) X-Gm-Message-State: AA+aEWZbFkgFu7t6XbAdOEmDCZDUmqOSemA5yI7jFVm/6kWocaA8N4T8 9+p+PdAJrtwMqUMt2qfGi6NdtdMJKhQUNyCitME= X-Google-Smtp-Source: AJdET5d6NculCUimHjJOums4N2APMc6A/XK+HB66hCqH35V5TVrlPkU0FNpzohAyVKdpKljTOG2vIOLhudrzfcB8J+8= X-Received: by 2002:a02:b529:: with SMTP id l38mr27874600jaj.25.1543348013395; Tue, 27 Nov 2018 11:46:53 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> In-Reply-To: <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> From: "C. M. Heard" Date: Tue, 27 Nov 2018 11:46:41 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Ole Troan Cc: Fernando Gont , Bob Hinden , OPSEC , IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 31495C06-F27D-11E8-B57F-F5C31241B9FE-06080547!pb-smtp20.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 19:47:04 -0000 On Tue, Nov 27, 2018 at 12:28 AM Ole Troan wrote: > Fernando, et al, > >>> From reading the email thread, this sentence seems to me to be a >>> good summary of the draft. >> >> Most of the content of this document is about analyzing the >> implications of each EH and option, to help folks with the >> aforementioned analysis -- regardless of what the outcome of [such] >> analysis is. > > OK, that=E2=80=99s good to hear. > > If that=E2=80=99s the case I would have liked to see more text on explain= ing > the background, give reasons why filtering in the middle of the > network is harmful (protocol extensions, ossification, violates > Internet architecture principles, packet parsing is costly, might > required symmetric paths, etc). > > A very unfortunate consequence of this work, is that the IETF appears > to send a message that routers in the Internet is now expected to > parse deep into packets and perform filtering actions. That=E2=80=99s a b= ig > change of the Internet architecture, and our view of layering. > > A few comments on the actual advice: > > The HBH advice (3.4.1.5) is fine and reflects that I think. > Likewise for the RH advice (3.4.2.5), FH (3.4.3.5) and DestOpt (3.4.6.5)= . > > * Protocol numbers 253/254 > > OLD: > 3.4.10.5. Advice > Intermediate systems should discard packets containing these EHs. > Only in specific scenarios in which RFC3692-Style experiments are to > be performed should these EHs be permitted. > > NEW: > 3.4.10.5. Advice > Intermediate systems should permit packets that contain these EHs. > > * New protocol types / extension headers > > OLD > 3.5.5. Advice > Intermediate systems should discard packets containing unknown IPv6 > EHs. > > NEW: > 3.5.5. Advice > Intermediate systems should permit packets containing unknown IPv6 > EHs. Ole, you are in effect saying that the proposed text for Section 3 in https://mailarchive.ietf.org/arch/msg/opsec/5SF7Q1dNnikQ23sx0nn6Iah1hMU should have the "operators should determine ..." text replaced by "intermediate systems should permit ..." (note that I include a portion of Section 3.1 dealing with the "unable to determine" case, in addition to the cases you mention above). I have to admit that I think the Internet would be better served by the choices that you propose, but the current consensus position of the IETF, as expressed in RFC 7045 (PS), acknowledges that some systems will parse deep into packets to perform filtering actions. In levying requirement on systems that do so, it is neutral on what the default action is in the above cases. Since the status of the current draft is informational, it seems inappropriate to push the advice one way or another and thereby turn "MAY" into "should" or "should not." Hence, I think "operators should determine ..." is probably the way to go. To make the point about RFC 7045 steering the advice perfectly clear, I'd actually like to see Section 2.3 expanded along the following lines: --- OLD: 2.3. Conventions This document assumes that nodes comply with the requirements in [RFC7045]. Namely (from [RFC7045]), o If a forwarding node discards a packet containing a standard IPv6 EH, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. o The discard policy for each standard type of EH MUST be individually configurable. o The default configuration SHOULD allow all standard IPv6 EHs. NEW: 2.3. Conventions This document assumes that nodes comply with the requirements in [RFC7045]. Namely (from [RFC7045]), o Any forwarding node along an IPv6 packet's path that forwards the packet for any reason SHOULD do so regardless of any extension headers that are present. Exceptionally, if a forwarding node is designed to examine extension headers for any reason, such as firewalling, it MUST recognise and deal appropriately with all standard IPv6 extension header types and SHOULD recognise and deal appropriately with experimental IPv6 extension header types. o If a forwarding node discards a packet containing a standard IPv6 EH, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. o The discard policy for each standard type of EH MUST be individually configurable. o The default configuration SHOULD allow all standard IPv6 EHs. o Experimental IPv6 extension headers SHOULD be treated in the same way as standard extension headers, including an individually configurable discard policy. However, the default configuration MAY drop experimental extension headers. o Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets. Do you think that this would help? > * MLD > 4.3.7.5. Advice > Intermediate systems should discard packets that contain this option. > Only in specific environments where support for RSVP, multicast > routing, or similar protocols is desired, should this option be > permitted. > > Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links > must generally be multicast capable. A recommendation of a blanket kill > of MLD can=E2=80=99t be right. I don=E2=80=99t know how this recommendati= on should be > formed, perhaps say something to separate MLD as used on-link with > hop-limit =3D 1? As I look at the advice for specific options more carefully, I find some inconsistencies in the advice for certain cases, and the Router Alert option (which is the one that applies to MLD) is one of those. My general take for Hop-by-Hop options would be: - If the "act" bits are set to "00" (ignore if you don't support it), then the advice should probably be to pass packets with that option unless there is vulnerable equipment that needs to be protected (e.g., legacy routers that could be subject to DOS attacks from Router Alert) - if the "act" bits are set to anything else, then the advice should probably be to drop such packets unless part of a domain where the feature is used (which is what RFC 8200 says anyway) > Unknown options types: > > OLD: > 4.4.5. Advice > Enterprise intermediate systems that process the contents of IPv6 EHs > should discard packets that contain unknown options. Other > intermediate systems that process the contents of IPv6 EHs should > permit packets that contain unknown options. > > NEW: > 4.4.5. Advice > Intermediate systems should not discard packets based on the presence > of unknown options. I see that Fernando subsequently agreed to this, and I do not object; but I do questions why unknown options would be permitted while the ones set aside for RFC3692-style are to be filtered unless such an experiment is known to be ongoing. Consistent advice seems to be in order for these two cases. I will follow up after doing a more thorough review of the specific advice for each option. Mike Heard From nobody Fri Nov 30 06:46:52 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6881200B3; Fri, 30 Nov 2018 06:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 4YjNax-dH0Ew; Fri, 30 Nov 2018 06:46:41 -0800 (PST) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630CA126CC7; Fri, 30 Nov 2018 06:46:40 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id AB495115BE5; Fri, 30 Nov 2018 09:46:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=ov94pdnocaH0WIUghb2J2zZcGsM=; b=Og1IHb 2z+B6AJsS8oIXuwTOj9G7cmdW12e+ab+4+UCkN9BsNbMwb50xehQ9DNp+UG7SafX xzZc/cScMLNYIfxsOvYBsdjDA6USF0+WLVk7tTKCGgXTcx2yAswHG7Vztf//atZU np1hU2ln5ukEaccmA/65QZWqbCrYLUt2kjALM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=HrQwEFOMjVX8vakJ71Yx+ocQm6iYoh5y or9fIez6wW+y2qvTLhNY/pQ5+9u+Zw+y9Dxno6/t8uEspF0QAnxQqYO8Y5oE43ly wbDMH0nqQzu14uGmolPvjQnBInXlj+YbR8s3HQeiWalxsAxjCJ8GCwGvED4im84U /yhWZ3ABP+g= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A3FCE115BE4; Fri, 30 Nov 2018 09:46:38 -0500 (EST) Received: from mail-io1-f43.google.com (unknown [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 393E2115BE0; Fri, 30 Nov 2018 09:46:38 -0500 (EST) Received: by mail-io1-f43.google.com with SMTP id m19so4721309ioh.3; Fri, 30 Nov 2018 06:46:38 -0800 (PST) X-Gm-Message-State: AA+aEWZqXfvcnz0ki0Rbi+8TgYZJMT3oI/oWHc2DOydwqMamjWf5AYJj wiEo+FpIJhrbBUqX5gqrTyknVN7Qbatgn1RiV0w= X-Google-Smtp-Source: AFSGD/WroL1YygQhaCstD6c6vhqhr7V4WV/jmR5pEThFB6sMVO50wvb2eUtFgM3ESFyk27UHy5SZPzH9wPrI6MQ7umA= X-Received: by 2002:a6b:d618:: with SMTP id w24mr3580258ioa.24.1543589197652; Fri, 30 Nov 2018 06:46:37 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> In-Reply-To: From: "C. M. Heard" Date: Fri, 30 Nov 2018 06:46:26 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: OPSEC , IETF Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: BDE8ED9C-F4AE-11E8-B629-BFB3E64BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 14:46:44 -0000 On Tue, Nov 27, 2018 at 11:46 AM C. M. Heard wrote: > As I look at the advice for specific options more carefully, I find > some inconsistencies in the advice for certain cases [...]. > > I will follow up after doing a more thorough review of the specific > advice for each option. Here is the promised/threatened follow up. Section 3.4.1.2, Specification of the Hop-by-Hop Options extension header: the deprecated Endpoint Identification Option (Type 0x8A) should not be listed here. The reference cited for this option states that it is a Destination Option to convey Nimrod EIDs. Section 3.4.6.2, Specification of the Destination Options extension header: the Performance and Diagnostic Metrics (PDM) Option should be listed here. The reference is RFC 8250. Section 4: A subsection documenting the PDM Option needs to be added. Insofar as this is a standard option that is to be ignored by systems that do not implement it, the advice "should not discard" would be an appropriate default. Section 4: The advice for specific options is not conditioned upon whether they are found in a Hop-by-Hop Options header or a Destination Options header. However, every defined option (other than padding and experimental types) is intended to appear in only one of those headers. At a minimum this needs to be pointed out. It may be appropriate to advise that packets with defined options that appear within the "wrong" header should be discarded. Section 4: The advice for Router Alert (Type=0x05, Proposed Standard) and SMF_DPD (Type=0x08, Experimental) is "should discard", while the advice for Quick-Start (Type=0x26, Experimental) is "should not discard". All of these Hop-by-Hop options are applicable only in limited domains (RFC 6398 says so for Router Alert), and Quick Start and Router Alert have substantial security implications. Thus, I have a hard time wrapping my head around the fact that they do not all get the same advice. How about something like "intermediate systems should discard packets that contain this option, except when deployed in an administrative domain where the option is in use" for all of them? Section 4: Randall Atkinson has provided detailed comments on CALIPSO. I support those comments. Note that systems compliant with RFC 8200 that do not implement RFC 5570 would simply ignore the option. Sections 4.3.18.5 and 4.4.5: as I previously stated, I think the right strategy is to remain neutral and say that operators should determine according to their own circumstances whether to discard packets containing these options. Reiterated only for completeness. Unused reference: I-D.ietf-6man-hbh-header-handling Mike Heard