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

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 01 November 2017 10:46 UTC

Return-Path: <swmike@swm.pp.se>
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 0B21913F6DD for <ipv6@ietfa.amsl.com>; Wed, 1 Nov 2017 03:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 Hx48FKP8J1vA for <ipv6@ietfa.amsl.com>; Wed, 1 Nov 2017 03:46:28 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDA513B10E for <ipv6@ietf.org>; Wed, 1 Nov 2017 03:46:27 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id ABFADB5; Wed, 1 Nov 2017 11:46:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1509533185; bh=TK/co7yQ3n1L/CKKiXAkVQqIAlCkjV7IGcV3uS/JgX4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=g9Zi/794BIQHrROpxBDx3ZSCJhXYnaM35tvyjmYiDum/0rdtvE3oBFw/ZP0S8xvpG ZjHGKY2nQlEJvnkkVeZjxOcsQxV9/8/7zPy4P9ycSwAza7cu7xbzsDnpWpljbNjzK/ pfh3VnFt9h1PSZYtPldUKac267eJ3ve9uVkG1dpo=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A7169B3; Wed, 1 Nov 2017 11:46:25 +0100 (CET)
Date: Wed, 1 Nov 2017 11:46:25 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Michael Richardson <mcr+ietf@sandelman.ca>
cc: 6man WG <ipv6@ietf.org>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: <6286.1509408085@obiwan.sandelman.ca>
Message-ID: <alpine.DEB.2.20.1711011139390.16389@uplift.swm.pp.se>
References: <CAOSSMjUVCSBjbYu3bc7DU+edz2+0+RvU_AMi4FNn2n2075kk9g@mail.gmail.com> <6286.1509408085@obiwan.sandelman.ca>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qL4DElWZpTiziB5SUpWfjNMCZhY>
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: Wed, 01 Nov 2017 10:46:30 -0000

On Mon, 30 Oct 2017, Michael Richardson wrote:

> And I think that most host stacks discard such things unless configured to
> expect a tunnel from D.

Agreed.

> What to do?
>
> I'd like to make it clear that the above construct is valid and that hosts
> SHOULD process it to remove the first IPIP hader and then process the packet
> as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard)

Ok. If it's configured to expect this kind of IPIP tunnel, agreed. 
Automatically, I don't think it should do this. It should not be default 
behaviour. Otoh I agree that ripping of a header isn't "forwarding" and 
shouldn't count as such. A 6to4 enabled host with forwarding disabled, 
receiving a 6to4 packet addressed to itself, should indeed take off the 
header and then process the inner packet.

If the OS comes by default with 6to4 enabled, then I expect it to be able 
to handle 6to4 packets coming to it. I wouldn't expect it to behave this 
way if 6to4 is turned off, then it should just drop the packet.

> As an aside, it would also be nice if we could say that an IPsec AH 
> header with an unknown SPI should be skipped as if it wasn't even there 
> (including any subsequent IP header as above..)  This is essentially a 
> similar situation.  I suspect that this statement is even more 
> controversial.

If the device isn't configured to do IPsec (even by default), then I don't 
think it should do what you describe.

It just seems weird to have end nodes strip off headers to try to gain 
access to whatever might be in there, at all costs, because it might be 
relevant to it (or not). If it receives an MPLS labeled packet and the 
device understands MPLS, should it start ripping off labels even if MPLS 
has been turned off on the device?

I believe users and admins would be very astonished if end systems started 
doing these things.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se