Re: IPv6 header insertion in a controlled domain

Gyan Mishra <hayabusagsm@gmail.com> Sun, 08 December 2019 17:17 UTC

Return-Path: <hayabusagsm@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 B189812004F for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=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 L-zdK6uwSiYv for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:17:27 -0800 (PST)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 4C9FE120025 for <ipv6@ietf.org>; Sun, 8 Dec 2019 09:17:27 -0800 (PST)
Received: by mail-il1-x12d.google.com with SMTP id r81so10652188ilk.0 for <ipv6@ietf.org>; Sun, 08 Dec 2019 09:17:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mn1aWqCcyXm8BglwVkNqzVGo3VvGJoo/wMgpuo/ChAs=; b=UsqbqZr7Hll94sdo/Kgo8vO9mOk+EEONgAc8bQDxh1ws8O/O4Yc86+ZQOx9gCz9tpW bPnvZCXDQuBU1nQ9uKm7GxEoaX3FemEDdH6hSVjyOOMxZJi9DGxM4gOwytInQCYs18As 78Wp9emAPw9g51EVsqMwSG4Bnhh+ot+BMOHlPC0viFVsRkqhzWKtZmqktIhG619t67Ad PoMcLSCFxR2j5b4SBqGhy3iI80xRaxIbFDn1mZ4M391Vngwrhv4RYoejRQldjK9sVJkX fXg7dQzqQep/SCg4bToAJajHS1lNacJTECmcxqkUkP7VV7LG5nZIyLVhl0TtpDUSjq63 LKvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mn1aWqCcyXm8BglwVkNqzVGo3VvGJoo/wMgpuo/ChAs=; b=Cs3XnnYYjVnH/tX7cCIs3Rpj4WQA8Z/EPmPrMxcN++zujzM8oSG1ZKpox2KKzZd6FH UBZ5X/vhsPmm+NJFvZXKjg2hFx2z8SHhLyv7DRwZPi8jvVQd3XwTTSf5d+RsxDN/br2u PftaOvq8VAGo5wtZgNPEDczWGo8Sw5fABaVI0iW+BPStxZRA3n1j4PeUX6ZpQKKv00vF 5p5VkG2cUyy2iee49c0xrepW9ehxCnDFstzw+uHX2vU687kCxye3F2M33sOlGXSY2hRW S5YMja9l+/IeQKy8nsDsnjpFzKwIAb8IJbJ8UMrYIFC8ZjJWQkpXNo+bmS03OL7a6EOY gHog==
X-Gm-Message-State: APjAAAXrGwV1qWK4Y+AylG0lfrpiHlVhvj+PDaKnURmEcFUho7vmaDdn nkAOVCN96FR9W7FJoQxWpHM6EiBTTEg3RlhIGPR3PA==
X-Google-Smtp-Source: APXvYqwdrVkaeqhKtlvs6ktvPSve45Avz9BatydWdbjL8hDsqoK/sI8LK9Exaum4fe7JMk/xqVON2mEQteJ1g7cZ+lM=
X-Received: by 2002:a92:1547:: with SMTP id v68mr23322197ilk.58.1575825446535; Sun, 08 Dec 2019 09:17:26 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CABNhwV1Jdw3xwfGSJbQbF1e7ZtfL_pEsmSRC6KkRbdK+4EAygQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 08 Dec 2019 12:17:15 -0500
Message-ID: <CABNhwV20zhoOimhWQUCDBc3t=MVZ4awMN4yp18+OTobq+QAvXQ@mail.gmail.com>
Subject: Re: IPv6 header insertion in a controlled domain
To: otroan@employees.org
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f808d105993473f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1GIbctldnCuDKvuuX92zm7_ENz0>
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:17:30 -0000

On Sun, Dec 8, 2019 at 12:12 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
>
> On Sun, Dec 8, 2019 at 11:24 AM <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. ;-)
>
>
>     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.

>
>>
>> Cheers,
>> Ole
>
> --
>
> Gyan S. Mishra
>
> IT Network Engineering & Technology
>
> Verizon Communications Inc. (VZ)
>
> 13101 Columbia Pike FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
> www.linkedin.com/in/networking-technologies-consultant
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com

www.linkedin.com/in/networking-technologies-consultant