Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Fred Baker <fredbaker.ietf@gmail.com> Mon, 22 February 2021 19:40 UTC

Return-Path: <fredbaker.ietf@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 3765D3A1F4F; Mon, 22 Feb 2021 11:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 3kK-4rjrUzhk; Mon, 22 Feb 2021 11:40:19 -0800 (PST)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 7F5403A1EC0; Mon, 22 Feb 2021 11:40:19 -0800 (PST)
Received: by mail-pf1-x429.google.com with SMTP id q20so7221455pfu.8; Mon, 22 Feb 2021 11:40:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=7M6wAMYWvqQ8HaxZ+Ge4bu0VAsQyaAFo8954UYdBcbM=; b=ULbn8dD8Y0R/67CDuzYjDcEdOp/sMKtj6YnZRZemKrPUyClIQJ2IYOMvwXqCEWL1P7 6Qg5gHLgJrbccpP8IK/5dbqUUpy1Tk2pArmHlbEU1CguGezZDAAwuvPhWLfM3Cyh1rsZ +fKDSEhujJ9b80s5+vVDJkGXBqLSZDqBZAcbJr69ACvG1ZtT7ZAZAdLnRbf5JR6juxbm GVP6mPy+eoJo//LOmRD8IVcEX6gyAJPJs7gtsTnh1ll82cMiSF+LJRHb/v105zrp/Cd6 Cb1fKKvvXggBOhWQkI0owTid2U/zRBWJ4XFAY84KGGtnj8+b/kfgOeN30aQgyC3Xe1QC l0Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=7M6wAMYWvqQ8HaxZ+Ge4bu0VAsQyaAFo8954UYdBcbM=; b=FUMptx1C9KkZLs5lt5FsSnLCHmbyMlb/tAcH0FW2fcwg65SvEuD5/77eQ/s+QFXBqE 9458iRkiiGrf49Zx9coUw0runTKXnLpcvUoBDokpqtPmVABX5nTBLJoRhMJOmIygEI9U w05Usi30sDhshR1SRk3Qk8Emy/C52Mpc1Z5VcU150vRwKY/vDlCwKvDAZhIbHaO3C+uD iSluR8n11ZuwbjFyF7nsGx19UVAeRa5vsk3kpdj0ln4mh+6uCjczb9oR31c+OVbabuOM PC34KtHcLAYh94WJElWwmB51M1i1iKhkoxwA7B/dqTWiACqRaGaZWR+nnlCwtCFtHKAK wp0g==
X-Gm-Message-State: AOAM533fDKyjX3hA7/SF58UNjqxRzghXSsSOmENc6gwxdFo1133Bmsl5 tRtv57AnsBcNBu2srvIX7R432jOOAO2WfQ==
X-Google-Smtp-Source: ABdhPJyNzW/hsjz6sXKWm58x341mYVXsd8SqMiPck0UUYNTvfF0fS6+/L8U6CvaX314RjWG5b5IUvA==
X-Received: by 2002:aa7:80cc:0:b029:1da:689d:2762 with SMTP id a12-20020aa780cc0000b02901da689d2762mr23532533pfn.3.1614022819047; Mon, 22 Feb 2021 11:40:19 -0800 (PST)
Received: from smtpclient.apple ([2600:8802:5800:567::100a]) by smtp.gmail.com with ESMTPSA id u22sm19664095pfn.62.2021.02.22.11.40.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Feb 2021 11:40:18 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Google-Original-From: Fred Baker <FredBaker.IETF@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Mon, 22 Feb 2021 11:40:17 -0800
Message-Id: <0F105024-BCAA-4A98-8739-E9739C13A434@gmail.com>
References: <CALx6S36vPEFiYgsCcBw4N06zYZU6c8=cfG7XK0PFm-nwjMuhwg@mail.gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, Nick Hilliard <nick@foobar.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsv-art@ietf.org, last-call@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, IPv6 Operations <v6ops@ietf.org>
In-Reply-To: <CALx6S36vPEFiYgsCcBw4N06zYZU6c8=cfG7XK0PFm-nwjMuhwg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: iPad Mail (18E5140k)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/dYFWnEpBn-IQpSf9_IHv1JwzPUA>
Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
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: Mon, 22 Feb 2021 19:40:24 -0000

Happy to be wrong, but I think we already have those. From the security header on, any network device should assume that the message content is (or may be) encrypted, and make no policy requirements beyond that point. If a message contains no security header but policy makes a network device stop where it might be found, I think we have achieved the goal.

Sent from my iPad

> On Feb 22, 2021, at 11:17 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Mon, Feb 22, 2021 at 11:14 AM Fernando Gont <fgont@si6networks.com> wrote:
>> 
>> Tom,
>> 
>>> On 22/2/21 13:29, Tom Herbert wrote:
>>> On Mon, Feb 22, 2021 at 8:23 AM Nick Hilliard <nick@foobar.org> wrote:
>>>> 
>> [....]
>>> I understand the purpose of the draft, however, IMO, for the problems
>>> that are described there is insufficient detail and scope to draw any
>>> meaningful conclusions or take away any new insights.
>> 
>> Then I guess we disagree. One of the most commonly questions asked in
>> this contact is "But... why do routers look inside packets?" -- and this
>> document answers that question, along with the challenges it represents.
>> 
>> Note: in a thread on specific transports you also asked what information
>> routers process. And this document also answers such question.
>> 
> Fernando,
> 
> If you recall, I specifically asked for the _normative_ requirements
> about what a host must expose to the network beyond just the IP
> headers. If the normative requirements are such that that hosts MUST
> expose transport ports (assuming consensus is achieved for that), then
> it follows that we'll need the normative requirements for how deep in
> the packet those transport headers can be.
> 
> Tom
>> 
>> 
>>> When the draft
>>> mentions that routers might drop packets because packets are too long,
>>> then the obvious question is what exactly is too long.
>> 
>> And the obvious answer is that that depends on a vendor/model basis. If
>> the router only copies the mandatory header to a buffer, then "too long"
>> might be "1 EH".
>> 
>> 
>>> Since this
>>> draft is discussing real implementation and not theory, it seems like
>>> measuring the extent and determining the real operational parameters
>>> of the problems, like what a useful minimum length of header chains
>>> is, seems straightforward either by experimentation or simply polling
>>> router vendors to see what they support.
>> 
>> It performs a qualitative analysis of the problem.
>> 
>> What you ask seems to be either RFC7872bis, or a document that would
>> complement RFC7872.
>> 
>> ... but certainly out of the scope of this document.
>> 
>> 
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
>>