Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 05 November 2017 01:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5E4D613FC39 for <ipv6@ietfa.amsl.com>; Sat, 4 Nov 2017 18:32:35 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 R1C5YG4pmMy5 for <ipv6@ietfa.amsl.com>; Sat, 4 Nov 2017 18:32:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD91913FC38 for <ipv6@ietf.org>; Sat, 4 Nov 2017 18:32:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 24D91200F4; Sat, 4 Nov 2017 21:33:35 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BFADF81F0B; Sat, 4 Nov 2017 21:32:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Mikael Abrahamsson <swmike@swm.pp.se>
cc: "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: <alpine.DEB.2.20.1711021747310.16389@uplift.swm.pp.se>
References: <CACL_3VETxNVQ+YD5j6ZiWjycQ=ojAuWwB23offNdVKm+S9c_7A@mail.gmail.com> <23308.1509623865@obiwan.sandelman.ca> <CACL_3VFrcombGczXU6Zz=Pk1u2GE=wGG-r+yEefdHai1REqXmQ@mail.gmail.com> <alpine.DEB.2.20.1711021747310.16389@uplift.swm.pp.se>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 04 Nov 2017 21:32:29 -0400
Message-ID: <6851.1509845549@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dA_1xqQS-v5Jn6W3c3DD8vFo3Tc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Nov 2017 01:32:35 -0000

Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    >>> Right. I forgot that IPSEC is an extension header in IPv6, I tought
    >>> of it as something that was encapsulated. So I take back what I said.
    >> 
    >> No, you were right the first time. Unknown extension headers are not
    >> skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).

    > Sure, but if the device understands IPSEC but has it turned off, what
    > should it do?

    > I don't know.

Exactly.
Depends entirely on what "turned off" means.
Probably it means that the SPI# is not configured.
For ESP, dropping the packet makes sense, because you can't decrypt and you
can't know what's "beyond" the ESP without knowing the parameters (so even
ESP_NULL encryption can't be skipped).

But, AH has the property that we *know* it's not encrypted, and we know the
size of everything, and so we can just skip things if the integrity check is
not for us.

If we can gotten that right, we could have used AH for multicasted traffic,
and even for some interesting uses where we want to authenticate that things
went through certain routers.


-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-