Re: SRH insertion vs SRH insertion + encapsulation

Ole Troan <otroan@employees.org> Mon, 09 September 2019 06:08 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022711200A3; Sun, 8 Sep 2019 23:08:07 -0700 (PDT)
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_HELO_NONE=0.001, 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 V_4vY0g9GvAi; Sun, 8 Sep 2019 23:08:04 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C795B12004E; Sun, 8 Sep 2019 23:08:04 -0700 (PDT)
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 clarinet.employees.org (Postfix) with ESMTPSA id 366EF4E11B39; Mon, 9 Sep 2019 06:08:04 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id EBACE1BE8AEA; Mon, 9 Sep 2019 08:08:01 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: SRH insertion vs SRH insertion + encapsulation
From: Ole Troan <otroan@employees.org>
In-Reply-To: <72256cfe-755d-861a-2a0c-558311bc70b4@gmail.com>
Date: Mon, 09 Sep 2019 08:08:01 +0200
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Robert Raszuk <robert@raszuk.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <82C3DA17-00AF-4E2E-88F3-04F9F563E659@employees.org>
References: <BYAPR05MB5463306B3328F460C2417764AEB50@BYAPR05MB5463.namprd05.prod.outlook.com> <32ED6621-3D17-4EC8-AC11-AFE64F05E6A9@employees.org> <72256cfe-755d-861a-2a0c-558311bc70b4@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-Vczocq1-mTrH2GCqk--eO6J7nQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 06:08:07 -0000

Hi Brian,

>>> IMHO, EH insertion modifies the semantics of the IPv6 source address. Today, the IPv6 source address indicates the source of an IP packet and **ALL** of its contents. If transit routers are allowed to insert extension headers, downstream routers can no longer identify the source of a packet and all of its contents.
>>> 
>>>  
>>> 
>>> Granted, in some cases, transit routers are allowed to modify a packet (e.g., Hop Count, DHCP, mutable options). But there is a big difference between changing a field whose value is know to me mutable and inserting a new option.
>>> 
>> 
>> 6296?
>> 
>> And I am pointing that out because of what feels like moral righteousness and hypocrisy to me, not because I think header insertion is a good idea or even doable. 
> 
> I think the real question here is whether we want it to be possible *in principle* to verify that a packet has not been modified in transit, except for fields that are known to be mutable. NPTv6 is indeed a case where we consciously made this worse. ("NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header.") Addresses are not mutable as far as AH is concerned.

I am not quite sure if that's the real question. ;-)
Something like header insertion could only possibly work in a limited domain, e.g. inserted on ingress, removed on egress.
Thereby keeping the end to end transparency. Changing of the packet size breaks PMTUD.

AH is a neat lithmus test. At least in theory. And I think it should be kept for no other reason than that.
I believe ILNP makes changes in only binding to the identifier not the locator.
And as NAT has become such an integrated part of the Internet architecture you might argue if AH should bind to addresses at all, and that consideration applies to the transport protocols too of course.

> 
> If we are willing to say that a feature is useable only within a domain where AH is not used, that seems OK, but only if the concepts of a domain, its membership, and its boundary nodes, are well defined. (To be clear, I don't think draft-voyer-6man-extension-header-insertion-06 is anywhere near explaining how a domain is defined and managed.) Or the IETF decides to declare AH dead. In any case, it's wider than a 6man decision.

Indeed. I think what we are talking about here is only possible within a limited domain.
And no, I don't think draft-voyer is nearly done. I think we asked the authors to document the issues with header insertion and proposed mitigations or why those issues weren't applicable in the limited domain. I see only the PMTUD issue mentioned, and then without any mitigation.

Cheers,
Ole