Re: IPv6 header insertion in a controlled domain

otroan@employees.org Sun, 08 December 2019 16:03 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 9018A120047 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:03:54 -0800 (PST)
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=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 wv36hP3o7f79 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:03:53 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::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 419F712001E for <ipv6@ietf.org>; Sun, 8 Dec 2019 08:03:53 -0800 (PST)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (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 9D9FA4E11AC6; Sun, 8 Dec 2019 16:03:51 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id DCA6F255438B; Sun, 8 Dec 2019 17:03:47 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: IPv6 header insertion in a controlled domain
From: otroan@employees.org
In-Reply-To: <CABNhwV0EGiMaX0Qkyk+_zqZfiaAS_RP_ewVEctgdSnMuJ3MBPw@mail.gmail.com>
Date: Sun, 08 Dec 2019 17:03:47 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AE06652-D6DB-444D-A8BB-7924181C83E4@employees.org>
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org> <CABNhwV0EGiMaX0Qkyk+_zqZfiaAS_RP_ewVEctgdSnMuJ3MBPw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wgJAUU-TZzyJAVLOMrBJWK6JSE8>
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: Sun, 08 Dec 2019 16:03:55 -0000

Gyan,

> I think the in flight eh insertion done on the node doing the encapsulation node A  is safer from a security perspective then an intermediate node adding a eh header without encapsulation.  I think even though you add an encapsulation but if the node doing the encapsulation is not the one adding the eh header it’s no different in my opinion then the node A not doing an encapsulation at all which was proposed initially by Spring.  
> 
> So we have to enforce that the EH insertion is only done by the node performing the encapsulation.

With regards to your comment that node B doing insertion on a packet with SA=A and DA=C, is equivalent to doing insertion on the original packet without encapsulation, I think the risks of that is defined in Mark's draft/8200.

Let me dig down on the security issue a bit.
Still given the simple example I gave earlier.
Can you ellaborate on what security issue you see, and why doing insertion at B is less secure than at A?

Best regards,
Ole