Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 02 December 2020 23:04 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9D3A15C7; Wed, 2 Dec 2020 15:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 1Hm7LJDFU3Vp; Wed, 2 Dec 2020 15:04:41 -0800 (PST)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 D9DF33A15BC; Wed, 2 Dec 2020 15:04:40 -0800 (PST)
Received: by mail-pj1-x1036.google.com with SMTP id j13so20977pjz.3; Wed, 02 Dec 2020 15:04:40 -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=O7pjGyN9bxW6+cJjaIok0+VDVMvS1/ESAqZCwpI9Ufc=; b=sF3U9ZGPWSy54KP2a8F+cUllPhm/b0zeuQHgMoEUzpOm4Hsz2WQ9WmjVbgIj0LPJYq k0XWMiQ5+H0I11BUGD9NtpyNiCNT95GIZiKHncur6QbUXsaGvv9VRRuCivjZ690qnLIg 4tFKJANXzPNNBvH0v9zPEUavXgygO0LnLZpxnQJGnN6ZKLFDiLerkzWkWu1rQx9e30F+ iR8B4TrmaT+DUbygvL1ct4uLbNeRmYZONjCPEmVQWIHKMIQ4/7WBv7AYYyylsAF4LmUN NOPHBwMmUDq5ygYHMYbSPnyJsPDqKmc7SBr5TgO2Pp/jcRuDFusMgOSQjkfoTNpospG0 Uc2w==
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=O7pjGyN9bxW6+cJjaIok0+VDVMvS1/ESAqZCwpI9Ufc=; b=nMZy4ikInanws997LemUD8Edk9Rgyb5/tsNFqng5BcrAy3OzzFVbDGIwIMklGruRMu qmpcDAMISKSNQ7BfZayypet3ASO0F572ugZ+BI/LZiP8RmDq/t1PBHa/oRM255cdzoN3 qRyg0lpopk27NP8fh8TtOLvKDw//Vq6ykV2riGhJrmnq3qiMqnBhkyKm1w0zlasqdxgy 7EVIKem5GLr4zNH+jC2C6JFcH26kPCSZdcL7QMunpHMKs5cT1Mrxaypsxud72ExM3CEp KHf6BIHxHseTw9OOhyTzhQEXjApawva/PaIQOpZVfq50z0/YP+ZQQSf1LsFVlurh7wGr LuaQ==
X-Gm-Message-State: AOAM533Uo80qeAOzpySqJo/4NUmzRnmtE4eroWwfhxMzVbfh0ZjRlozo LHY8htbc1Pd2OxqQGFHyl4XpWcT5g2okQw==
X-Google-Smtp-Source: ABdhPJxycl71aOwITimofVzAb2gOhZ5CjhwCLLRly6m+cVlGe5KpFD3wNEd1PfeJR/zQ4LHt0gOPKQ==
X-Received: by 2002:a17:90b:243:: with SMTP id fz3mr214861pjb.41.1606950279561; Wed, 02 Dec 2020 15:04:39 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id q5sm13557pjg.4.2020.12.02.15.04.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 15:04:38 -0800 (PST)
To: Fernando Gont <fgont@si6networks.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, v6ops@ietf.org
Cc: fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org
References: <d97ca0fd-776a-1525-50d1-3a62fd7edf5f@erg.abdn.ac.uk> <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <d1814cfd-d603-9cc0-f6ae-d37feafb62b8@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <25389c41-2f2a-19a3-5106-f64a8d81cdd3@gmail.com>
Date: Thu, 03 Dec 2020 12:04:34 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <d1814cfd-d603-9cc0-f6ae-d37feafb62b8@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uFHvT7kY887rIxn9J6CiMhYuxZY>
Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 23:04:43 -0000
On 03-Dec-20 06:52, Fernando Gont wrote: > Hello, Gorry, > > Thanks a lot for your feedback! -- We really appreciate it! > > In-line... > > On 1/12/20 13:30, Gorry Fairhurst wrote: > [...] >> >> * I have some concerns that some of the choices of words could >> (unintentionally) be taken as endorsing a best practice, which I don't >> think the IETF would generally promote. This is more about ensuring >> specific parts can not be quoted out of context. I did a careful read >> and hope I identified most of these and propose something that might be >> helpful (please see attached PDF - RTF is identical). I think it would >> be good to clarify in a few places this is the RFC8200 spec, since I >> have heard there could be new work to update that. > > I don't mind doing that. However, isn't it implicit in all RFCs that > they are referring to the current specifications (unless otherwise noted)? > > i.e., regardless of whether there is ongoing work, and whether one is > aware about it, a spec refers to the IETF status at the time the spec is > published (*). > > (*) Well, modulo RFC Ed processing times. > > > In any case, IIRC, RFC8200 is the current state of affairs when it comes > to EH processing, so I guess explicitly referencing RFC8200 wouldn't > hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my > head" assessment is not correct :-) Yes, although 8200 does give a polite nod to 7045 and does *not* obsolete it. Brian > > > > >> * On the measurement evidence: I have a slight concern that the results >> might not cover the wide variety of use cases and you may like to be >> more careful in the words you use to generalise these for the >> "internet". I think we should be aware that in some scenarios an EH >> might still be effectively used, where path can safely support this. > > We're targeting the general case here. As they say, "with sufficient > thrust, pigs fly just fine". You can, of course, build a network where > EHs can be used just fine. -- but what we're discussing is the general case. > > > >> In >> some other uses, the fact that packets with these options might be >> expected to be dropped by many paths - for good reasons, does not mean >> that the option is useless to set in general - it might merely be that >> for these paths it is not possible to use the option and then care is >> needed in deciding which packets set the EH and how this is used. > > We certainly don't mean that. We mean "if you EHs, the chances of your > packets being dropped increase, for the general case". As noted, you may > employ them within environments where everything is under your control > ("your network, your rules"), or, I guess, might try to use them and > have a fall-back mechanism (ala TCP ECN during 3WHS). > > > > Some additional comments/questions based on the PDF you've attached: > >> However, common implementation limitations suggest >> that EHs present a challenge for IPv6 packet routing equipment and >> middle-boxes, and evidence exists that IPv6 packets with EHs have been > > Doesn't this imply that this is no longer the case? (i.e. your proposed > change is "have been") > > > >> If an IPv6 header chain is sufficiently long that its header exceeds >> the packet look-up capacity of the router, then it would be dropped by >> hardware that is unable to determine how it should be handled. > > This seems rather confusing. It's the router that drops the packet. > > > > >> 5.1. >> Recirculation >> Although TLV chains are amenable to iterative processing on >> architectures that have packet look-up engines with deep inspection >>>>> is this /that/ ? > > Not sure what you mean.... > > >> As layer-4 port >> information increases the entropy of the hash, it is normally highly >> desirable to use it where possible. >>>>> I don’t agree with that actually, - but maybe others think so, please check >>>>> RFCs relating to ECMP or perhaps rephrase, something like: /Layer-4 port >> information can increase the entropy of the hash, and is often >> thought desirable to use it where it is available. >> /? > > Your suggested change seems fine to me. That said, what would you employ > for the hash if not the ports? > > >> We note that in the IPv6 world, flows are expected to be identified >> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >> Load-Sharing is possible without the need to process the entire >>>>> why /would be possible/ ... some networks do this, and many RFCs encourage this? > > Support for the FL is not widely deployed and implemented (see [Cunha-2020]) > > > >>>>> >> /also did not employ/ >> do you really need to claim that? I suggest we could write this >> in more neutral language, since some implementations recently >> changed this practice? >> Perhaps; >> /When many IPv6 >> implementations failed to set the Flow Label, many ECMP and Hash-based >> Load-Sharing devices also did not include the Flow Label [Cunha-2020], >> possibly as a result of issues that have been found >> in host implementations and middle-boxes [Jaeggli-2018]./ >> although it seems like > > The suggested change seems to imply that the situation has changed, but > I believe it hasn't. [Cunha-2020] provides evidence in this respect. SO > assuming that this is something from the past would be inaccurate. > > > >>>>> I suggest the section includes mention of the IETF recommendation, >>>>> and there the path with “clearly...” should be at the end! > > Ok with moving the para "Clearly.." to the end. That said, could you > elaborate on what IETF recommendation you're referring to? > > > >> Use of extension headers can result problematic for NIDS/IPS, since: >>>> /may/can/ ... not necessary, but might as well use /can/ in this case? > > Doesn't "may" imply possibility here? > > >> As a result, in order to increase the efficiency or effectiveness of >> these systems, packets employing IPv6 extension headers can be >>>>> /can/ or /have been/are being/ ... to follow the previous argument? >> dropped at the network ingress point(s) of networks that deploy these >> systems. > > (Must admit that since you're a native English speaker, I have a high > probability of being wrong :-), but, anyway): > > Packets can be drop, whether with EHs or anything else (i.e., the > contents of a packet does not affect the ability of a device dropping > them -- at the end of the day, a device can drop *all* packets if it > feels like). > > What we are meaning here is that dropping packets with EHs is indeed one > option to increase the efficiency and effectiveness of these systems. > We don't mean to "give permission" to operators, because, at the end of > the day, they don't need to ask :-) (they don't, and they shouldn't, > IMO!). That's why we use "may" -- it's an actual possible operational > policy to deal with the problem at hand. > > >> o Use of unknown extension headers can prevent an NIDS/IPS to >> process layer-4 information > > I this case, I think both are fine: -- "can" as in ability, and "may" as > in possibility > > > >> As a result, whether because of the challenges represented by >> extension headers or because the use of IPv6 extension headers has >> not been explicitly allowed, packets employing IPv6 extension headers >> can be dropped by network firewalls. >>>>> /can/ or /have been/are being/ ... to follow the previous argument? > > Same as before: I don't think you need reasons for an "ability". What we > mean is that firewalls may (as in "possibility of intended behaviour") > drop such packets. > > >> When such devices are unable to obtain the >> required information, they might simply resort to dropping the >>>>> /may/might/ ? > > "might" reads as a possibly imaginary situation. What we are meaning is > that some devices *do* this. > > >> Some router implementations lack fine-grained filtering of IPv6 >> extension headers. For example, an operator may want to drop packets >> containing Routing Header Type 0 (RHT0) but may only be able to >> filter on the extension header type (Routing Header). As a result, >> the operator would end up enforcing a more coarse filtering policy >> (e.g. "drop all packets containing a Routing Header" vs. "only drop >> packets that contain a Routing Header Type 0"). > > The proposed change seems to change the meaning of the paragraph. i.e., > these things *do* happen. > > > >> Additionally, implementation >> inconsistencies in packet forwarding engines can result in evasion of >> security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014] >> [BH-EU-2014]. > > The original text said "...may result in evasion". It would seem to me > that both are correct ("can" = ability, "may" = possibility)? Actually, > the later implies the former? > > > Same for this one: > >> Packets with attached IPv6 Extension Headers can impact performance >> on routers that forward them. > > > >> [Gont-Chown-IEPG89] >> Gont, F. and T. Chown, "A Small Update on the Use of IPv6 >> Extension Headers", IEPG 89. London, UK. March 2, 2014, >> <http://www.iepg.org/2014-03-02-ietf89/fgont-iepg-ietf89- >> eh-update.pdf>. >> [Gont-IEPG88] >> Gont, F., "Fragmentation and Extension header Support in >> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. >> November 13, 2013, <http://www.iepg.org/2013-11-ietf88/ >> fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. >>>>> These don’t seem great presentations, and seem like they were >>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? >>>>> I don’t know why these are useful as references? RC7872 also covers this? > > They are listed as they were part of the work that eventually resulted > in RFC7872, and as an indication of for how long the problem has been > looked into. At the time, we didn't even have tools to do the > measurements. For example, the path6 tool I implemented, and the support > in RIPE Atlas were triggered by these efforts. > > >>>>> Is it worth also seeing whether Hendriks et al, http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf >>>>> contains useful insight instead of these two? > > I will read it. Thanks for the pointer! -- I wasn't aware about this paper. > > Thanks! > > Regards, >
- [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-pac… Gorry Fairhurst
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Gorry Fairhurst
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Tom Herbert
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Brian E Carpenter
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Brian E Carpenter
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Tom Herbert
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Gorry Fairhurst
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Gorry Fairhurst
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Tom Herbert
- [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-pac… Fred Baker
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… Fernando Gont
- Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs… tom petch