Re: SRH insertion vs SRH insertion + encapsulation

Fernando Gont <fgont@si6networks.com> Mon, 09 September 2019 17:54 UTC

Return-Path: <fgont@si6networks.com>
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 6AF6B120876; Mon, 9 Sep 2019 10:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 PttUsZ0Um3Qk; Mon, 9 Sep 2019 10:54:00 -0700 (PDT)
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 A508D120892; Mon, 9 Sep 2019 10:53:59 -0700 (PDT)
Received: from [192.168.1.29] (178-9-170.dynamic.cyta.gr [178.59.9.170]) (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 729C6864F4; Mon, 9 Sep 2019 19:53:53 +0200 (CEST)
Subject: Re: SRH insertion vs SRH insertion + encapsulation
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: 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>
References: <BYAPR05MB5463306B3328F460C2417764AEB50@BYAPR05MB5463.namprd05.prod.outlook.com> <32ED6621-3D17-4EC8-AC11-AFE64F05E6A9@employees.org> <72256cfe-755d-861a-2a0c-558311bc70b4@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <b968a1ba-7797-e796-de4b-70947711baf2@si6networks.com>
Date: Mon, 09 Sep 2019 20:08:42 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <72256cfe-755d-861a-2a0c-558311bc70b4@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bkSEzE8HpY0dpqbUHm9HGRgN-Hc>
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 17:54:05 -0000

On 8/9/19 06:37, Brian E Carpenter wrote:
> Ole,
> 
> On 08-Sep-19 15:02, Ole Troan wrote:
>> Ron,
>> 
>>> 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.

Well, that's IPv6. The question really is if we want (or can) deviate
from that.


> 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.
> 
> 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.) 

There's even more trivial questions to be answered, like "what problem
are you trying to solve?". The whole EH insertion thing is motivated by
trying to save 40 bytes for a mechanism that already introduces a lot of
overhead. EH-insertion doesn't allow you to do anything you can't do
with encap/decap.



> Or the IETF decides
> to declare AH dead. In any case, it's wider than a 6man decision.

Agreed. Inserting EHs in the middle of the network is certainly not
"IPv6 maintenance".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492