Re: Next steps on Extension Header Insertion

Mark Smith <markzzzsmith@gmail.com> Thu, 03 November 2016 21:19 UTC

Return-Path: <markzzzsmith@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 1302D129AAD for <ipv6@ietfa.amsl.com>; Thu, 3 Nov 2016 14:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 6Dtp77ISNkfc for <ipv6@ietfa.amsl.com>; Thu, 3 Nov 2016 14:19:33 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 2C17612995D for <ipv6@ietf.org>; Thu, 3 Nov 2016 14:19:33 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id 51so50709866uai.1 for <ipv6@ietf.org>; Thu, 03 Nov 2016 14:19:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4IfUr9bz8aGbi1+bfgJUfAKxH0NCEZZehmus1mDPSqI=; b=GNecNaWW8LcXZlSdrk3v+kENWwl4vtuD3FGVxwAbZGEsg/mgeSGmLM6w80nokj2H0Y p/a5APNwggtKIZNYPIf629EbBECwy+tQf98tuJcTLCqy47XZv+C79kzG+vH0IA+R266j 0xe60Tq1DJ1ByEBndxPnjULg4CUUr4DsdQV0XzBiZLFh2sS4PMkzAFQfAQ+kc6GDnbEV d2fyr/O3fsbABKneUDI3BhxtuhXVXal0xpy6cbD0Jlc1lsYKPqKFFG76woqqTbBrnQWP 1quryCu8cZ5ucQhNxYb+mwIOjHp4d46ol9pSb5jDo62Yl1m3pmvPYlQn8cK4OcbVrR3G e0Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4IfUr9bz8aGbi1+bfgJUfAKxH0NCEZZehmus1mDPSqI=; b=AuzjSbzewoWT4DErXb3lTk4RfwN5cZ0skBnOtMXo3JpPMJLYI3uKZVlrxybJ4QGMQO QLCa8G2RXFSH5ez7Io5XSab72vDsiM+8ssTrV31Y63iNIS1swTXdIxoxoTLG4iFngm+J aDZNv6bWNwlQmFDBHIkvgjPmMInZufZQ9k1p9AvllPiAnItFGp4K2pU3jauUAnRP8oBb HVYY+qexqMy9lSDT/6oDGNS8GvWbw8AzebsqB3+gv2d5QTyrLHVR+CtSt2Sw5oveVdE+ v7jI3dVzT+9Av6UZVL8YrFUciWLmz5qRDrBCn0iq2vbg5HUP1ASDxxkpkQihjfVZ3q5U NhpQ==
X-Gm-Message-State: ABUngvd/LQ5eOyFy7W3X8gERib93qQJqhsk/V6JcWfGVhATg0hsh9fFORDlwVAxgKxj9moFvdbtEpQObJavCDQ==
X-Received: by 10.159.48.145 with SMTP id j17mr7636761uab.43.1478207972224; Thu, 03 Nov 2016 14:19:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.48.212 with HTTP; Thu, 3 Nov 2016 14:19:31 -0700 (PDT)
Received: by 10.159.48.212 with HTTP; Thu, 3 Nov 2016 14:19:31 -0700 (PDT)
In-Reply-To: <895e153b-ec5c-9f7a-4a5a-31cb7ddc8cc0@gmail.com>
References: <B291E9E6-A803-423F-BFA5-87A74DCFB784@gmail.com> <dfe00826-1bcd-80ae-e6dc-7763c506cbe4@si6networks.com> <9CA73891-B4FA-47DF-82E1-A4867DBC6A3F@steffann.nl> <3C56AA77-18E4-4254-BB6A-A447CE115392@employees.org> <CAG6TeAtJdUua3saSGz0SX7DW6hwf74yAexpnfYoP1bg6v1eywA@mail.gmail.com> <17984D1D-1A3C-4AA5-B2EC-BE5C645A272C@steffann.nl> <369FB219-9979-43CE-B83D-D7C422FC7711@employees.org> <53FE6D80-040F-42DA-BA51-F3A40ABF248F@steffann.nl> <5FA646CC-DD40-4D20-A6C5-AF1D5D90E563@employees.org> <7010E4D5-2A0E-4358-AD76-9996004ED642@steffann.nl> <895e153b-ec5c-9f7a-4a5a-31cb7ddc8cc0@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 04 Nov 2016 08:19:31 +1100
Message-ID: <CAO42Z2yZJ6vFEJHZbbfgPdCOi_YqGkg3Oz8XHm5syWD7uvsBzA@mail.gmail.com>
Subject: Re: Next steps on Extension Header Insertion
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="f403045dd99016b3d005406c1df2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gTyCEEqxDV7Tsv7kEz9SCvvka1k>
Cc: Fernando Gont <fgont@si6networks.com>, Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Nov 2016 21:19:35 -0000

On 4 Nov. 2016 6:36 am, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
wrote:
>
> On 04/11/2016 02:11, Sander Steffann wrote:
> > Hi,
> >
> >> What you are saying is something like:
> >>
> >> "The IPv6 header fields described as immutable in RFC4302 MUST NOT be
changed by the network. If within an administrative domain any of the
immutable fields are changed, they MUST be restored on exit from the
domain."
> >>
> >> Correct?
> >
> > Yes, thank you for coming up with a good short bit of text. As RFC4302
defines the next-header field as immutable that would lock down the EH
chain,
>
> Yes but... I understand that AH is more or less deprecated by the
security community.
> So while it has correctly identified what needs to be immutable, I'm not
sure it's
> a sound basis for a general requirement (much as I agree with that
requirement).
>

I'm pretty sure that is because they use tunneling between hosts and IPsec
gateways and between gateways and gateways to add information to the
original packet and use a form of encryption that also provides
authentication.

IPsec is one of the reasons I think encapsulation is the better method. It
preserves the structure and content of the original packet, there is a
clear boundary between the original packet and what was added somewhere in
the network, and the outer IP header source address unambiguously
identifies the node acting as the tunnel end-point that added the IPsec
information to the original packet. ("tunnel" mode IPsec)

The only time IPsec "inserts" ESP and/AH headers is end to end or host to
host IPsec sessions between the host that is the original packet source and
the host that is final packet destination. ("transport" mode IPsec.)

Regards,
Mark.

> Also, when we tried to write text for the flow label about restoring it
on exit
> from a domain, we were pretty much told to go away and stop being silly.
>
>     Brian
>
> >
> >> Cheers,
> >> Ole
> >>
> >> PS: As an operator would you be happy if I sent packets with NH=59,
SA=:: with an integrity check covering all fields apart from the HLIM
field, and everything else beyond the IPv6 header (40 bytes) was encrypted?
> >
> > Hmmmmm. Interesting question. As a network operator I'd probably drop
that packet because of BCP38. As a security engineer I would be scratching
my head and wondering what was going on. But effectively the payload
wouldn't be that different from ESP...
> >
> > Cheers,
> > Sander
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------