Re: IPv6 header insertion in a controlled domain

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 08 December 2019 19:30 UTC

Return-Path: <brian.e.carpenter@gmail.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 545941200B1 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 11:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hMEYKc8Ye8Px for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 11:30:47 -0800 (PST)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 734F6120020 for <ipv6@ietf.org>; Sun, 8 Dec 2019 11:30:47 -0800 (PST)
Received: by mail-pg1-x544.google.com with SMTP id b1so5921860pgq.10 for <ipv6@ietf.org>; Sun, 08 Dec 2019 11:30:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6NJNHjdeEHJzdFtPhy7qlNbY6CZ+fNz7OzE3n5Vd88k=; b=idEepFne5QWxrir5PYt2ij+msVTfX3fGyGBx+o2vKWr0vpDPDEV/F38N5+EA5cJpVB p4kPi6mUQovyXFijerMYX4x06/GD1LKbCeeISkE5W7ToQ/qYJ4BN9jadJU85YaGmkUZQ GUAiRjfEpxrAldFc9OenY07UhMU16yVaHskw3CI/hiUH+x3tLfYkjuzWB1ax+R7rTZhN xQs4yTN/l+TNm28v8PyOqxyGtYErAbNqTEfLx8eUSIkHzTOBmK3EczBn8L80Pifn+vP7 CJ2glOqmLIhvXgowN6x4ryt2WZAio56xvVLhwmiYi2GDToR+cyKcPDWL5sTl9yh4WSgT pahA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6NJNHjdeEHJzdFtPhy7qlNbY6CZ+fNz7OzE3n5Vd88k=; b=ArdV/j3iwfWZJDokKkj9fI3uY3vrXnjUkas3bkHEHaLUOR85+f1+EryQoCu9yJBOnG JAaJFr7PGK4/YHoteQSsJv7/G9NxDGUKIZN3Ojc0jx5ddcGtx2wD3yK+hJKB8SMMgOyQ Hif4u3mxctE0vWTjObHGuUQ9VvPQGFMJvs8to+fgmzFoWZuhD/nZBvBYRCu8Wn8ftq2j Lhq5d3lQ657n159ffgxx+eoOCWeS7zAZ2Aojcx6G749T3yqplvMHV9l1fjYM8EzIDZX+ jPOY4B0SZldwa4OOU3Mft4NCYVkh4M5dVvs4QTgYfu8fMRdhNkR8vvUy4au7v4oWYIVu mqwA==
X-Gm-Message-State: APjAAAWt3qw0YawshofxOapgbGXn7pC0bN+9zwKeIvRJxUDO4870uCfx 0Y58+EbiumQ3bF+6oVB/l3eIdw+k
X-Google-Smtp-Source: APXvYqz8v7gTlDuleXCmnX1XuWJlvVhkjeQ3vrt647hLMyAiwuCVBBV9NkGQDG0JDd2mJKWiQF7qlg==
X-Received: by 2002:a63:3404:: with SMTP id b4mr14876625pga.438.1575833446418; Sun, 08 Dec 2019 11:30:46 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id e27sm24642674pfm.26.2019.12.08.11.30.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Dec 2019 11:30:45 -0800 (PST)
Subject: Re: IPv6 header insertion in a controlled domain
To: otroan@employees.org
Cc: 6man WG <ipv6@ietf.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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <2ecefe0e-14c1-b991-754f-c2724e3fe198@gmail.com>
Date: Mon, 09 Dec 2019 08:30:42 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <160F2740-7571-44D9-8995-5D2F23989DF6@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/s7i9iPhvmHVzGcOa0iA97o-wPBc>
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 19:30:49 -0000

On 09-Dec-19 05:24, otroan@employees.org wrote:
> 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?
>>
>>      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. ;-)
> 
> Any other security issues you see?

Two comments on this thread:

1) It isn't just AH that is broken; any form whatever of cryptographic authentication of the packet header or the packet as a whole between A and C is impossible unless the key is shared between A and B. But whether that matters or not is a domain-specific decision. If I'm outside the domain, why would I care?

2) For me the test that matters is not whether this all works, but whether the fact that it's happening can in principle be detected from outside the domain. If it can't be detected from outside, why would I care?

Note that NAT fails test 2. I'm not convinced that SRH insertion inside a tunnel does so.

    Brian