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

"C. M. Heard" <heard@pobox.com> Thu, 02 November 2017 20:55 UTC

Return-Path: <heard@pobox.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 32A5713F95F for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 13:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 5Mz6LzFuknEY for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 13:55:50 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ACE13F95E for <ipv6@ietf.org>; Thu, 2 Nov 2017 13:55:49 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5AA7EBD1B9 for <ipv6@ietf.org>; Thu, 2 Nov 2017 16:55:46 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=OSmzzT0vAKHsy73jkVEGBsfSH5Q=; b=Jj95FI 4c8M/aqh9QTxorwDLU0ENzcWLTntSh4a7a8w9VjXL91q4GecM+wOXJKydLjRQZqO /xECAdJjmDzeFrx71528uvneVBERI2HFokLPg6zrmvgnY77Pow7aseVjTybdzXYY 4zKwsUR33CnxFj1j1Bix3pY0FKjbSg80pgagE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=VnR03qTYlggNummxFzkGWkkukXhTn0co MOl8TI+WR3u2jK3gnUbZ+7rxD33aufiiTNE2tjwl9ZJoNAhf7sQrUl80tWF9b9JO k5r0ojC5XGrW7E7U6MO2+eUmQX2cHoUU8iWPMATvv0TEDCa7zh95Y0+87CUEg4Hc rGnse1QgAAo=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 522E2BD1B8 for <ipv6@ietf.org>; Thu, 2 Nov 2017 16:55:46 -0400 (EDT)
Received: from mail-qk0-f177.google.com (unknown [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id C5F00BD1B4 for <ipv6@ietf.org>; Thu, 2 Nov 2017 16:55:45 -0400 (EDT)
Received: by mail-qk0-f177.google.com with SMTP id o187so958737qke.7 for <ipv6@ietf.org>; Thu, 02 Nov 2017 13:55:45 -0700 (PDT)
X-Gm-Message-State: AJaThX4f3GL2ZBetY7sMZNcxC1dnm0elmGut/+7YH6Qf1mYEQrBaulrD bOFJp/gSWbwlpBwzb0TUJcSZSOYPqE9jtcMJ1MM=
X-Google-Smtp-Source: ABhQp+Qmfr429/5K/ktRBoFEs/hcPZYDErWXIiIpQS0H/tejYJiCPIoPcO89YvBrDKwLkKyx3NTUkjiOAfJFz2fd5co=
X-Received: by 10.55.97.202 with SMTP id v193mr6354959qkb.165.1509656144974; Thu, 02 Nov 2017 13:55:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.38.241 with HTTP; Thu, 2 Nov 2017 13:55:24 -0700 (PDT)
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>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 02 Nov 2017 13:55:24 -0700
X-Gmail-Original-Message-ID: <CACL_3VHY9Veidpv-hmkVDL_UJqWWa3UHkFCgpQwPJh-+fpr0cQ@mail.gmail.com>
Message-ID: <CACL_3VHY9Veidpv-hmkVDL_UJqWWa3UHkFCgpQwPJh-+fpr0cQ@mail.gmail.com>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: 6man WG <ipv6@ietf.org>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="94eb2c05b7d8411a4a055d063698"
X-Pobox-Relay-ID: 328F1966-C010-11E7-9FB9-575F0C78B957-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TQUkC7VpUs3tElkDudRdJowcwJA>
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: Thu, 02 Nov 2017 20:55:51 -0000

On Thu, Nov 2, 2017 at 9:48 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Thu, 2 Nov 2017, C. M. Heard 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.


Presumably, it should behave as if no SPIs were configured. It would the
treat every IPsec packet as if it had an unknown SPI and discard it. Of
course, an IPsec implementation could have an "AH Bypass" option, but that
would be non-standard behaviour.

--cmh