Subject: draft-carpenter-6man-ext-transmit-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Feb 2013 09:11:37 +0000

https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/

There was some discussion of this draft when it came out, but nothing
that led to any specific changes. We should perhaps emphasise that
it's complementary to draft-ietf-6man-oversized-header-chain.

I'd like to ask for opinions about taking this draft forward.

I won't be in Orlando, but the other author (Sheng) will be.

Regards
   Brian

---

From: Ray Hunter <[email-masked]>
Date: Thu, 14 Feb 2013 22:15:19 +0100

> I won't be in Orlando, but the other author (Sheng) will be.
You can write what you like about firewalls needing to have an explicit
policy configured (manually) before dropping any packets.
And this standard will then (quite rightly) be ignored by every single
firewall manufacturer I know.

If an extension proves itself safe, easily parse-able, and useful, it
will be transported over the public Internet. If it doesn't, it will get
dropped.

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Feb 2013 08:24:00 +0000

> policy configured (manually) before dropping any packets.

Ray, the IETF is supposed to make the Internet work better. So we should
write down requirements for that to happen.

> firewall manufacturer I know.

That parenthesis is a value judgement, but in any case, the idea of the
draft is to push implementors in the direction of parsing all well-defined
extensions, and of making policy control possible.

> will be transported over the public Internet. If it doesn't, it will get

At the moment this is impossible. There is no place for firewall
implementors to find a master list of all well-defined extension headers
and no way for site IT managers to configure firewalls to block or allow
specific extension headers. So there is no way for a new extension
header to prove itself safe and viable. It's pure Catch 22.

Firewalls should be designed to make new extension headers subject
to user control, and the IETF should structure its designs, documents and
IANA registries to make life as easy as possible for both firewall
implementors and users.

That's what we need to fix. We can maybe state it more clearly in the draft;
thanks for pointing to the existing Catch 22.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 15 Feb 2013 10:31:34 +0100

> Brian E Carpenter <mailto:[email-masked]>
> 15 February 2013 09:24

Well IMHO I think the requirements are precisely the other way around:
extensions should be simple to parse, demonstrably not a security issue
or likely to cause harm, and useful:  not that firewalls should blindly
pass everything thrown at them. Hop by hop has already been labelled
potentially harmful in
http://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05. The market
is still deciding what headers are "good".
> extensions, and of making policy control possible.
Agreed. I'd support a draft with these goals, but let's keep it realistic.
> header to prove itself safe and viable. It's pure Catch 22.
Providing a clear list of extensions in a repository, what their
benefits are, and how they work, is a completely different matter to
mandating behaviour of  middleware boxes that is directly contradictory
to current industry best-practice.
> IANA registries to make life as easy as possible for both firewall
Agreed. Extensions should also clearly have been designed with firewalls
and other middleware boxes in mind. And new extensions should too.

Firewall code and other middleware box code will always significantly
lag IETF standards. I don't really see how the Uniform Format header
structure defined in http://tools.ietf.org/html/rfc6564 truly addresses
the firewall issue.

If we were starting from scratch I'd prefer that unknown extensions
should be easily "strippable", rather than having to drop the entire
packet if they cannot be parsed, or still having to traverse the full
chain without truly understanding the contents and then passing that
unknown content into a secure zone.

How you achieve that practically I don't really know.

Thinking out loud, we could potentially define yet another new extension
header that defines a fork in the header chain: next header field =
following(optional) header extensions,plus length to reach the next
header as per RFC6564; final header field (contained as header specific
data within the new header) =  top level protocol of the final header
value e.g. TCP= 6, plus offset to reach the final payload headerin
either octets or 8-octet units.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Hdr Ext Len  | FinalHeader  | offset to     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | final header  |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That in itself of course will not be fully backwards compatible. But at
least it would be a once-off action. And firewalls could strip out the
optional headers, whilst easily locating and parsing payload data.

regards,
RayH
> Ray Hunter <mailto:[email-masked]>
> 14 February 2013 22:15
> ------------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Feb 2013 14:46:16 +0000

Ray,

We have different prespectives. The next version of the draft will
try to make the case a bit clearer. On one specific point:

>> Thinking out loud, we could potentially define yet another new extension header 
>> that defines a fork in the header chain: next header field = following 
>> (optional) header extensions, plus length to reach the next header as per 
>> RFC6564; final header field (contained as header specific data within the new 
>> header) =  top level protocol of the final header value e.g. TCP= 6, plus offset 
>> to reach the final payload header in either octets or 8-octet units.

Please look at http://tools.ietf.org/id/draft-zhang-6man-offset-option-01.txt,
although it got no traction here.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Sun, 17 Feb 2013 13:37:53 +0200

> header to prove itself safe and viable. It's pure Catch 22.

My personal view is that it is very useful to have a single IANA registry that lists all IPv6 extension headers.  I would like to think I am fairly knowledgable about IPv6, and it's hard for me to find them all.  This is a win independent of what policy we recommend that firewall/middlebox/etc. vendors support.  Let's not loose that.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Feb 2013 12:16:12 +0000

> My personal view is that it is very useful to have a single IANA registry that lists all IPv6 extension headers.  I would like to think I am fairly knowledgable about IPv6, and it's hard for me to…

Indeed. That is one of the two proposals in the draft.

The other proposal is to specify what firewalls should do to make extension
headers deployable (subject to site policy). I think this is complementary to
the oversized-header-chain draft, which is necessary to remove some cases
that are unreasonable for any firewall to handle.

    Brian