Subject: Fwd: New Version Notification for draft-herbert-6man-eh-attrib-03.txt

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Oct 2020 13:09:53 -0700

Hello,

I have posted a new version of the Extension Header Attribution Option
draft. The main goal of this option is to provide a feasible and safe
way to perform extension header insertion and removal from packets.
This version contains some clarifications and fixes for typos.

If you are interested, we are planning to look at this in IETF 109
hackathon as part of the IOAM project
(https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon).

6man chairs: I would like to request this draft be taken up as a
Working Group item.

Thanks,
Tom

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Oct 29, 2020 at 1:02 PM
Subject: New Version Notification for draft-herbert-6man-eh-attrib-03.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-6man-eh-attrib-03.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-6man-eh-attrib
Revision:       03
Title:          Attribution Option for Extension Header Insertion
Document date:  2020-10-29
Group:          Individual Submission
Pages:          18
URL:
https://www.ietf.org/archive/id/draft-herbert-6man-eh-attrib-03.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-6man-eh-attrib/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-attrib
Htmlized:       https://tools.ietf.org/html/draft-herbert-6man-eh-attrib-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-herbert-6man-eh-attrib-03

Abstract:
   This document defines an "Attribution Option" that provides
   attribution for IPv6 extension headers, Hop-by-Hop options, or
   Destination options that are inserted by intermediate nodes in the
   delivery path of a packet.  The purpose of this option is twofold:
   first it identifies the extension headers or options that have been
   inserted, secondly it attributes the inserted extension headers or
   options to the node responsible for inserting them.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mark Smith <[email-masked]>
Date: Fri, 30 Oct 2020 08:28:45 +1100

Hi,

Apologies for top posting, on a phone on the train.

So I think there needs to be a broader discussion of what IPv6 packet
fields are mutable in the absence of an AH EH.

I've become a particular fan of the quote "What you allow, you encourage."
by Michael Josephson, as often enough I've seen things permitted that
shouldn't have been, and then the first tolerance becomes the justification
for subsequent tolerances of the same or similar behaviour.

So, from my perspective, if this draft is adopted by the WG, and is
published, even as Experimental, it is 'encouraging' all IPv6 fields are
mutable unless immutability is enforced by the presence of an AH EH.

Regards,
Mark.

On Fri, 30 Oct 2020, 07:10 Tom Herbert, <[email-masked]> wrote:

> Status:
> https://datatracker.ietf.org/doc/draft-herbert-6man-eh-attrib/
> Htmlized:
> https://tools.ietf.org/html/draft-herbert-6man-eh-attrib-03
> Diff:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 29 Oct 2020 17:41:03 -0700

> Apologies for top posting, on a phone on the train.
Hi Mark,

Good to know you can post on a train! Can you post on a plane? :-)

> So I think there needs to be a broader discussion of what IPv6 packet fields are mutable in the absence of an AH EH.

We had much discussion on this topic in the context of SRv6 if you
recall, and it was a lot of effort to elicit the rules about
mutability for SRv6 fields. But even with that, AH still doesn't work
with SRv6.

>
> I've become a particular fan of the quote "What you allow, you encourage." by Michael Josephson, as often enough I've seen things permitted that shouldn't have been, and then the first tolerance becomes the justification for subsequent tolerances of the same or similar behaviour.
>
On the other hand "Everything which is not forbidden is allowed" is a
well established constitutional principle :-). Of course in this case,
it seems more apropos to say that unless a prohibition can be
enforced, people are going to assume it's allowed and do it anyway...

> So, from my perspective, if this draft is adopted by the WG, and is published, even as Experimental, it is 'encouraging' all IPv6 fields are mutable unless immutability is enforced by the presence of an AH EH.
>
Here's another way you might want to look at it... if intermediate
nodes do insert extension headers, which we know is already being done
regardless of what RFC8200 says, then by requiring the inserted
headers to be explicitly declared a receiver can implement policy as
to whether it accepts the inserted extension headers (receiver being
either the destination host or could be a firewall). AH is still
required for strict enforcement, but this makes acceptance of inserted
headers an explicit policy decision at the receiver. IMO, that's an
improvement of the current situation.

Tom