Subject: Re: [Fwd: I-D Action: draft-ietf-6man-ext-transmit-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 May 2013 14:44:47 +1200

Hi,

I haven't noticed a single comment on this version, so is it
fair to assume everybody has read it and is in agreement? If so,
we'll ask the WG Chairs to move it towards WGLC. If there are
more comments, we still have to time to update the draft before
Berlin.

Regards
   Brian Carpenter

On 30/03/2013 05:11, Brian E Carpenter wrote:
> Hi,
> 
> This version is intended to include the results of the discussion
> in Orlando.
> 
> Review and comments welcome!
> 
>    Brian & Sheng
> 
> -------- Original Message --------
> Subject: I-D Action: draft-ietf-6man-ext-transmit-00.txt
> Date: Fri, 29 Mar 2013 08:56:33 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
> 
> 	Title           : Transmission of IPv6 Extension Headers
> 	Author(s)       : Brian Carpenter
>                           Sheng Jiang
> 	Filename        : draft-ietf-6man-ext-transmit-00.txt
> 	Pages           : 9
> 	Date            : 2013-03-29
> 
> Abstract:
>    Various IPv6 extension headers have been defined since the IPv6
>    standard was first published.  This document updates RFC 2460 to
>    clarify how intermediate nodes should deal with such extension
>    headers and with any that are defined in future.  It also specifies
>    how extension headers should be registered by IANA, with a
>    corresponding minor update to RFC 2780.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>

---

From: Ray Hunter <[email-masked]>
Date: Fri, 24 May 2013 08:52:43 +0200

> more comments, we still have to time to update the draft before

I think this version still contains a large element of King Cnut
commanding the tide to stop.

End users have different perspectives: one will see a firewall as evil
because it hinders innovation, whilst another will see a firewall as
absolutely necessary because innovation leads to bugs and
vulnerabilities in end nodes, which need to be protected until they are
patched. I'm not sure the current text is entirely balanced in this respect.

I would also like to see some text on whether it is possible/desirable
for a middleware box to strip unknown headers, or even some known
headers, rather than making a binary decision to drop or transmit the
entire packet. If (new) headers are truly optional or experimental, the
residual stripped packet may still have value e.g. stripping hop by hop
extension headers on entry to/ egress from a corporate network or
transit AS. That way the (new) extension headers could be usefully
deployed in an AS that supports them, but the end to end traffic would
not be blocked further along the path by firewalls in an AS that does not.

regards,
RayH

---

From: John Leslie <[email-masked]>
Date: Fri, 24 May 2013 08:40:05 -0400

> not be blocked further along the path by firewalls in an AS that does not.

   I had a similar thought -- even going so far as to posit a way to
notate that a header had been stripped...

   I think the answer is we don't want to do that in this document;
nonetheless some folks are likely to try it. I think a mention of the
issue, and a reference to RFC(s) stating the current rules, would help.

   (The prime purpose of this document is creating an IANA registry;
that purpose should not be clouded by discussion of what firewalls
"should" do.)

--
John Leslie <[email-masked]>

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 15:43:11 +0100

> notate that a header had been stripped...

For that you need a new header... ;)

> that purpose should not be clouded by discussion of what firewalls

Yes, the doc should focus on its primary reason for existence. 

A couple of additional comments.

One is that from time to time there may be security issues raised with certain headers, e.g. RH0. These may obviously be raised over time. Is there a mechanism to catch these in the IANA registry somehow?

Another is whether there is any use of the "null" header type 59?  Or has that been deprecated?  If not, should it be so, given Brian doesn't list it.  Or is this viewed in the same category as TCP, etc as header types?

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 May 2013 08:50:29 +1200

> issue, and a reference to RFC(s) stating the current rules, would help.

What rules? As far as I know, no such mechanism is defined or allowed,
so there is nothing to refer to. I would object (as a WG participant)
to even mentioning such a mechanism. (As a document editor, I would
of course edit the document according to WG consensus.)
> that purpose should not be clouded by discussion of what firewalls

Not so. The prime purpose of this document is to make extension headers
useable. The registry is a means to that end; describing precisely how
middleboxes should treat them is another means to that end. We can make
that clearer in the text, of course.

Describing how middleboxes might block or destroy them is antithetical
to the purpose of the document. That's why Ray says "I'm not sure the
current text is entirely balanced in this respect." He's right. Again
speaking as a WG participant, I'm happy with that.

> One is that from time to time there may be security issues raised with certain headers, e.g. RH0. These may obviously be raised over time. Is there a mechanism to catch these in the IANA registry s…

Shouldn't this just be part of the Security Comsiderations for
the definition of each header? The registry will always contain a pointer
to the relevant RFCs. IANA can't do much if the Security Considerations
are insufficient.

> Another is whether there is any use of the "null" header type 59?  Or has that been deprecated?  If not, should it be so, given Brian doesn't list it.  Or is this viewed in the same category as TCP…

I think we included that in an earlier draft, but then removed it
because it appears to function as a null transport header. It's
a judgment call, and only needs a few keystrokes to put it back in the
list.

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Sat, 25 May 2013 11:55:06 +0200

> Brian E Carpenter <mailto:[email-masked]>
> 24 May 2013 22:50
It's a clear answer that you feel stripping of headers from the chain is
not allowed, and stating that in the draft this would give clear
direction to middlebox developers.

But equally, and without wanting to appear confrontational, I thought
that the point of the header chain and the fact the header chain was
excluded from checksums, was to allow various middleware boxes to
process portions of the packet on the fly en route as appropriate, thus
fostering innovation.

As an example, the flow label has certain limitations and DSCP is
limited, so inclusion of an extra header with a tag to be used for
traffic engineering purposes (and which only has significance within a
single AS) might prove useful in the future, without having to resort to
tunnels and wrappers. On the other hand, transmitting that tag over an
AS boundary might prove harmful.

So inserting and stripping headers at various points on the path could
conceivably provide useful innovation IMHO. So wouldn't it be a bit
self-inconsistent for this draft to block that if the stated aim is to
foster innovation?

> speaking as a WG participant, I'm happy with that.

So you're asking the WG to make a consensus call that a default drop
policy in firewalls is harmful because the need for innovation on the
Internet always outweighs any benefit from devices shipping with such a
default drop policy?

Is that not akin to demanding that every Linux and BSD distribution
always ships with "experimental" repositories enabled, because we might
have some cool new kernel hack or network code that everyone must try?

Speaking entirely personally, I think the market has already clearly
decided on that point.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 May 2013 08:36:10 +1200

Ray,

> direction to middlebox developers.

It seems completely clear to me from the words in RFC 2460 that the
only extension header that is to be inspected by intermediate nodes is
the hop-by-hop header, and that the design intention was that all
other headers were to be transmitted transparently. If we were being
strict, there's no need to do anything except bash middlebox implementers
over the head with those words. As far as I can tell, designers of
extension headers since RFC 2460 have relied completely on this.

But, in the real world we have firewalls that do *not* conform to 2460,
and we need to deal with them realistically.

> process portions of the packet on the fly en route as appropriate, thus

Where do you find any support for that in RFC 2460? I see exactly the
opposite, and I'm not aware of any IETF specification that suggests
modification of extension headers on the fly. (Routing headers may
be modified at routing hops, but that is after the packet has been
delivered to its next hop.)

> AS boundary might prove harmful.

If IPv6 had been designed that way, but it wasn't.

> self-inconsistent for this draft to block that if the stated aim is to

We'd have to invent a third form of extension header to do that (in addition
to HbH and E2E). It's an interesting idea, and I wouldn't want to exclude
it without debate, but I think it's on top of what this draft is trying to
do, which is to make E2E extension headers useable. (I assure you from experience
that they are not useable today, with off-the-shelf firewalls on the path).
> Internet always outweighs any benefit from devices shipping with such a

No. Please read the draft very closely. What it intends to say is
that brainless default-deny is the wrong approach, that firewalls must
recognize all valid extensions (most of them don't) and allow
tailored drop rules per extension type (some of them don't). If the
draft doesn't say that, we'd be glad to adjust the wording to meet
the intent.

> have some cool new kernel hack or network code that everyone must try?

No, the draft also contains words intended to explain that newly
defined extension headers will take time to be recognized by firewalls,
as well as providing a registry where firewall developers can find them
(which is not the case today). Again, if the words don't meet the
intent, please suggest new words.

> Speaking entirely personally, I think the market has already clearly

The draft is intended to deal with the real world, but if the IETF
doesn't specify how things should work, who else is going to?
Firewall developers are not deaf and blind to innovation, and in my
experience are open to this discussion.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Sun, 26 May 2013 10:51:34 +0200

> 25 May 2013 22:36

I guess we could always use a hop by hop option for that use case, so
that's no big deal to me.
> delivered to its next hop.)
With the danger of being unnecessarily pedantic, RFC2460 says "With one
exception, extension headers are not examined or processed by any node
along a packet's delivery path, until the packet reaches the node (or
each of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header."

And we're now defining how a middlebox along the path examines and
processes headers other than the hop by hop header. So pointing at 2460
alone wouldn't seem to be adequate to conclude that intermediate nodes
MUST either pass a packet unmodified or discard it.

I think that is worth pointing out in the draft that "Contrary to
RFC2460 Section 4, middleboxes, such as firewalls, load balancers or
packet classifiers, MAY examine and process the entire IPv6 packet
before making a decision to either forward or discard the packet."
> draft doesn't say that, we'd be glad to adjust the wording to meet
I've read the draft several times.

The two portions that lead me to conclude "default drop policy is evil" are:

1. "RFC 2460 requires destination hosts to discard packets containing
   unrecognised extension headers.  However, intermediate forwarding
   nodes MUST NOT do this by default, since that might cause them to
   inadvertently discard traffic using a recently defined extension
   header, not yet recognised by the intermediate node."

I do not see how this demand to forward unknown headers is in any way
consistent with a middlebox node being able to implement a "drop by
default" policy. It seems counter-intuitive from a security perspective
that an intermediate node, whose job it is to protect end nodes from
zero day exploits, MUST allow "unknown headers" to transit, whilst the
node they are supposed to be protecting MUST drop "unknown headers"
(which may well be the same ones crafted in some way to form an
exploit). It seems to me that this sentence implies that the danger of
false positives in firewall code (caused by innovation) are more harmful
than false negatives (firewall code and end node code has not yet caught
up with new standards or new exploits). I don't share that view and I'm
sure I'm not alone.

Also the above text would seem to be in direct contradiction to the
following text later in the draft:

Quote: "Forwarding nodes MUST be configurable to allow packets
containing unrecognised extension headers, and such packets MAY be
dropped by default."

I have no problem with that text.

2. "The default configuration SHOULD allow all defined extension headers. "

That, in my reading, is directly contrary to recommending that a
manufacturer ship a middlebox to run a "drop unless" policy out of the
shrinkwrap, which is de facto market behaviour. Market behaviour might
change, but attempting to reverse it via this draft undermines the rest
of the draft IMHO.

Hence my comment about enabling all "experimental" repositories by
default in Linux distributions. I'm also sure that I'm not alone in
believing that some existing headers and any new optional headers may
prove controversial from a security perspective. Previous operational
experience with extension headers has proven that a prudent approach to
introducing changes may be necessary for many customers.

I therefore suggest deleting this text.

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 May 2013 16:47:03 +1200

> MUST either pass a packet unmodified or discard it.

Correct, that's why it's a standards track update. We are clarifying
the meaning.

> before making a decision to either forward or discard the packet."

I'm not sure if it's really a MAY or simply a statement of what
occurs in the real world.

> node they are supposed to be protecting MUST drop "unknown headers"

Well, the IPv6 design was, I suspect, intended to make layer 3
firewalls unnecessary. (I am not claiming that has succeeded.) However,
the aim here was to write a spec that treads the narrow path between
making the Internet transparent to well-defined extension headers
and allowing firewalls to defend a perimeter. I think you're correct
that the present version is still slightly inconsistent, and needs
a bit more fine-tuning of the normative language.

> up with new standards or new exploits). I don't share that view and I'm

No, it's a common view in some security circles. I don't happen to agree
with it as far as layer 3 attacks go; and not all sites would set the
risk vs innovation tradeoff at the same point. We really need this to
be under IT managers' control, I think.

> containing unrecognised extension headers, and such packets MAY be

Yes, this is why the internal consistency of the draft probably
needs tuning. That sentence should take priority over the earlier
MUST NOT that you quoted. We missed that.

> change, but attempting to reverse it via this draft undermines the rest

Why? It's a SHOULD, which means "there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications must
be understood and carefully weighed before choosing a different course."
Isn't that what firewall implementers do about every protocol feature
they consider?

Also, recall that the WG asked us to make the document applicable
to all kinds of middlebox, not just firewalls. Non-firewall boxes
certainly have no business censoring extension headers.

> default in Linux distributions. 

The word "defined" is supposed to mean "not experimental", at least in
my mind. Maybe the language needs to be more explicit on that point.
Perhaps we should be explicit that standards track action is needed.
That would update RFC 5237, which allows standards action *or*
IESG approval. No disrespect, but the latter seems very casual for
a new extension header.

> I'm also sure that I'm not alone in

Yes, certainly, and I think a few words on that would fit in the Security
Considerations, where it is already mentioned that deployment of a new
extension will be slow.

> I therefore suggest deleting this text.

But we're not defining firewall product specs here. We're defining
how to make IPv6 work. You are of course correct that firewall vendors
will do whatever they decide to do, but it seems to me that the IETF
position should always favour connectivity while pointing out
security risks and how to alleviate them.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Mon, 27 May 2013 09:32:17 +0200

> 27 May 2013 06:47
Agreed.
> MUST NOT that you quoted. We missed that.
ACK.
> Isn't that what firewall implementers do about every protocol feature

I have no problem if load balancers always forward.
> IESG approval. No disrespect, but the latter seems very casual for
Right.

What I explicitly don't want to happen (and I think this is entirely
likely reading the current text literally)

Firewall is explicitly configured by the user and is running v1.0 code.

 Allow hop-by-hop
 Deny unknown headers

Later, the IETF defines the XYZZY IPv6 extension header as standards track

XYZZY is considered OK by "everyone"
(but so were Type 0 Routing headers for 7 years.... and we already had
the same negative experience in IPv4 with source routing)

Much later the manufacturer's code catches up with the RFC for XYZZY.

Even later on, the end user considers the manufacturers code to no
longer be bleeding edge, and the box is updated to v2.0 code

Config automatically becomes

 Allow hop-by-hop
 Allow XYZZY
 Deny unknown headers

without human intervention.

We should respect that end users have the right to choose which
extensions they allow on their networks. Extensions, by definition, are
not part of the core protocol IMHO.

So my conclusion is that any automatic/default setting for a security
device to allow any headers (not available in a previous release, or
which do not already have an explicit configuration) SHOULD inherit the
explicit wish of the network administrator for treatment of unknown headers.

Or else my personal preference would really be a "deny all" terminal
rule, but I guess you would object to that, which I respect.

> security risks and how to alleviate them.
Agreed for boxes that do not explicitly perform filtering functions.
Filtering functions need to be left in the hands of the network
administrator.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 27 May 2013 08:02:37 -0700

> and we need to deal with them realistically.
We also have middleboxes which we call routers which are somewhat less 
functional if they can't find the L4 header, with all the attendant 
consequences that entails. That may not have been a big deal in 1994 but 
it's basically all of them now.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 27 May 2013 14:16:52 -0700 (PDT)

> occurs in the real world.

It should just be a statement of what occurs in the real world.  
The IETF should not endorse behaviours that violate IPv6 design 
assumptions with a standards-track MAY.  I would suggest that the 
text be modified along the following lines:

"Contrary to RFC2460 Section 4, middleboxes, such as firewalls, load 
balancers or packet classifiers, sometimes examine and process the 
entire IPv6 packet before making a decision to either forward or 
discard the packet."

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 May 2013 13:37:39 +1200

> entire IPv6 packet before making a decision to either forward or 

Yes, IMHO that's well phrased. I'm going to have a go at a new version
that includes that, and various other changes following Ray's comments.
Please watch this space.

     Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 May 2013 07:22:24 +0100

> to the relevant RFCs. IANA can't do much if the Security Considerations

Fair enough. It was just a question as to how it can be made as easy as possible for a developer to catch all the latest requirements/specs.

> a judgment call, and only needs a few keystrokes to put it back in the

OK, I have no strong preference, but you could maybe state in the draft that it is excluded and why, so readers don't wonder about it.

Overall I think the draft is in good shape, and the tweaks based on Ray's comments should make it even better.

Tim