Re: IPv6 header insertion in a controlled domain

otroan@employees.org Sun, 08 December 2019 17:39 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 66BD71200A4 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:39:40 -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 9ehTZ3ZzHz_Q for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:39:37 -0800 (PST)
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 925A2120025 for <ipv6@ietf.org>; Sun, 8 Dec 2019 09:39:37 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:341c:af3f:45b:2496]) (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 B4D754E11AC6; Sun, 8 Dec 2019 17:39:36 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id 0D0AD255600D; Sun, 8 Dec 2019 18:39:35 +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: <CABNhwV20zhoOimhWQUCDBc3t=MVZ4awMN4yp18+OTobq+QAvXQ@mail.gmail.com>
Date: Sun, 08 Dec 2019 18:39:34 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <12AB31F1-5B8A-4572-B6C3-C5EE501B5AC3@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> <8AE06652-D6DB-444D-A8BB-7924181C83E4@employees.org> <CABNhwV1Ym5xtDY+vo8haaaObhMayE+ejkUbm4Sq9A5axCQwopA@mail.gmail.com> <160F2740-7571-44D9-8995-5D2F23989DF6@employees.org> <CABNhwV1Jdw3xwfGSJbQbF1e7ZtfL_pEsmSRC6KkRbdK+4EAygQ@mail.gmail.com> <CABNhwV20zhoOimhWQUCDBc3t=MVZ4awMN4yp18+OTobq+QAvXQ@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/HOr6-1LrNdpux7YDOnxOHVsMLUg>
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 17:39:40 -0000

> > > 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?
> > 
> >      I was thinking the obvious man in middle attack tampering with v6 header by intermediate node and possible impact to AH if used.
> 
> If AH is used, wouldn't A add the signature, and C when validating would know that B added the header and could do verification accordingly?
> For a controlled domain where all of A,B and C are acting in cohort, then that wouldn't be too far fetched to assume.
> At least a lot more probable than that AH would be used at all. ;-)
> 
>     With AH the hash signature has to match between source and destination so in this case with eh insertion it would not
> 
> 
> Any other security issues you see?
> 
>         I think in a controlled domain like an SP core I don’t see any other impact.  Also you would not have  AH in the outer headers and only in the payload so no impact really even with AH used by customers.
> 
> Is it possible if we don’t see any impact to make an exception to 8200 for controlled domains and give example of an SP core.

That's what draft-voyer suggest(s/ed).
Let's consider the consequences in draft-smith and any other we can think of before going there.
(Given that it's already deployed in the "real-world(tm), the discussion is really what status we want to give this in IETF documents,
and if we can give further guidance to how it can be deployed and what restrictions that must be put on it).

There are also other options that I don't think has been considered yet. E.g. the RFC791 record route option approach.
Node A leaves enough scratch space in header for node B to fill in. That way packet size does not need to change.

Best regards,
Ole