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, 3 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,
>