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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 02 November 2017 19:33 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 AAF9F139504 for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 12:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_PASS=-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 NyYqi46fiCxQ for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 12:33:49 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 94940139612 for <ipv6@ietf.org>; Thu, 2 Nov 2017 12:33:49 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id a192so475818pge.9 for <ipv6@ietf.org>; Thu, 02 Nov 2017 12:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v6Y0rmm1+m7Y7sPK0vu5HCButAJfu/1sxzS1DNcsD9k=; b=Patxw0S7sB5lX3tjzoupLDXxwjC9j41TkM5lIVGZ1Qt75HKSB3m6tjodA42856ZQNj dA0gb/5Awc1OfsXdDSixFxgN0ZCAWEbNToPuk7DKq4doyG4/WfAWBgP8LaE0tj/IK8S1 iwOb5ZWGAJXI7fFriO9HAyw9pW8RaX6z+HMsLF7VyUfhe/poMcswm8AhtS/AN24EgXAm EBr5M3nYvnZEBi7dAnNgZPBT6OrQoU+nnYkx3TFcw9pIRP5vWAibQABJLmH3WQRTpKwl YAYCrKKkVt5Nm4x3xj8XQnZBDdUu2uv9lW9wIfGq/W3s6k00ZiABxclVE52mdWmmrMLX qZtA==
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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=v6Y0rmm1+m7Y7sPK0vu5HCButAJfu/1sxzS1DNcsD9k=; b=bEPp3mWo6zOlaoQ0ZbrhBlC3OPucBZvqcy7SyXxFr7vC2872kHcUns8sIt5nJRtNze KhPEfSPwrAPIAKl6v9jXeqL7s6SYOuO4lymXpKMAO3j2cGKdE4P8UcVaOLnw7XENtGUu tsRJ7NsHWIrEShTZOdrkWjQ8lk/QQKXQMtvTWdUbdquJogCGeEN6XOPLjdM9HttYyCOv 23zPG8i/JONRhB30OWLyTZYvhJsi9DtEbE1lA73oGcrGGGCrDS3T1Fetqm0rzPdn9LiG b1s1tZ/1p/XojeCigi/Q9GvHmUsIz7ijoSiOS5OsjFRsVdZeFIH3u6xoPweZtMn2jy4e usDw==
X-Gm-Message-State: AMCzsaWJ4JQAZKdjnAchJU7ZhvfUSBnSHw2OkKjyqvN8K1VZ4SKKewVF S3RN7XA3zrblw+d0Yg8+eNoOKQ==
X-Google-Smtp-Source: ABhQp+R1GFsY9iIUECRUY4S8M/FbNf3gNqMPz7+wciWtN/POKJKZdH/tH3hsmZ/KPF9KjgV5qDV/HQ==
X-Received: by 10.84.133.132 with SMTP id f4mr4323568plf.197.1509651228840; Thu, 02 Nov 2017 12:33:48 -0700 (PDT)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v190sm6666871pgv.25.2017.11.02.12.33.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 12:33:47 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
References: <CACL_3VETxNVQ+YD5j6ZiWjycQ=ojAuWwB23offNdVKm+S9c_7A@mail.gmail.com> <23308.1509623865@obiwan.sandelman.ca> <CACL_3VFrcombGczXU6Zz=Pk1u2GE=wGG-r+yEefdHai1REqXmQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <c8911f45-2afc-9d26-c0a8-1017d034a251@gmail.com>
Date: Fri, 3 Nov 2017 08:33:51 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CACL_3VFrcombGczXU6Zz=Pk1u2GE=wGG-r+yEefdHai1REqXmQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DBWKRYTVrsNPdcpmIqTEf6dtzfM>
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 19:33:52 -0000

On 03/11/2017 04:26, C. M. Heard wrote:
> On Thu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
>>
>> C. M. Heard <heard@pobox.com> wrote:
>>     > On Wed, 01 Nov 2017, Michael Richardson wrote:
>>     >> Yet we skip other extension headers in order to find the ULP.
>>
>>     > Not so. An end node that encounters an unrecognized extension header
>> is
>>
>> Both AH and IPIP are well known and recognized extension headers.

AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
RFC8200 doesn't specify what to do with an unrecognized upper-layer header.

    Brian

>>
> 
> Not to a node that does not have any IPsec code at all (or that has IPsec
> turned off).
> 
>  On Wed, 1 Nov 2017, Mikael Abrahamsson wrote:
> 
>>
>>    > If the device isn't configured to do IPsec (even by default), then I don't
>>    > think it should do what you describe.
>>
>> Yet we skip other extension headers in order to find the ULP.
>> In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
>> header....  Because we got this wrong, we couldn't use AH to secure ND or any
>> other multicast (like OSPF) without causing of a flag day.  AH became totally
>> USELESS.  It was sad.
>>
>>
>> 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).
> 
> Mike Heard
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>