Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 03 Jan 2011 15:40:14 -0500

FWIW, I'm sympathetic to Tony's basic sense that it is unclear that we
need to do this work/document.

I'm still not clear on exactly what *real* problem it solves.

Suresh Krishnan <[email-masked]> writes:

> Since RFC2460 came out, four new extension headers have been defined.

> 135 - Mobility header
> 139 - HIP
> 140 - Shim6
> 141 - WESP

2 of the above code points are used by IPv4, so having a generic
extension header mechanism for IPv6 would have saved only 2 code
points. No need to panic folks...

> The idea of burning one protocol number right now was suggested by the 
> WG in order to limit further exhaustion of the protocol number space. 
> Would it be more acceptable to you, if we do not ask for an IANA 
> allocation for a protocol number at this point, and wait till the first 
> "Specific Type" request comes up?

My general sense is that this work is mostly just good common sense
advice to someone who has a need to define a new extension type. But
until we see such a concrete proposal, I am not convinced (yet) that
we should define anything new that suggests people go change
implementations or allocate code points. Both are premature.

As one concrete example, RFC 5175 defines extensions for adding future
RA flags. But, none have been defined yet, so the work really isn't
needed yet and implementations certainly don't need to do anything
yet. However, that has not stopped NIST and DoD from citing these
documents recommendations to implement.

Upleveling a bit, and thinking about routing headers and destination
options, my general sense is about such options is:

1) Destination options are the preferred route. Any other kind of
option will be extremely hard to deploy, has all kinds of barriers,
etc. (This proposal will have no impact on future destination
options. Right?)

2) The routing header is essentially deprecated, and we probably won't
define any more. We've already deprecated RHO. RH1 was never used, is
now deprecated, and arguably shouldn't even count as ever having been
defined.  RH2 is the MIP routing header. RH2 was originally a regular
type 0 option, but was changed because of the fear that firewalls
would block packets with such options by default, preventing MIPv6
from being deployed. If we had to do it all over again, MIPv6 arguably
should have used a destination option, since by definition RH2 is only
processed if the two addresses in the routing header are on the same
node, which is much more in line with the intention behind destination
options.

Which leads me to ask, exactly what kinds of future options do we
think will take advantage of this new format?

Note, my bias on this general topic is based on experience that unless
we have something concrete driving this sort of work, we risk getting
it wrong. So, I'm still trying to be convinced we need to do this sort
of work *now*. If there was an actual proposal for a new option that
solved some sort of real problem, things might be different.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jan 2011 10:25:20 +1300

> define any more.

The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header,
is active.

However, isn't the real question whether we want to change the
implied intention that adding a new extension header should be
hard? Section 4 of RFC 2460 makes this intention pretty clear:
unknown extension headers should lead to packet discard and
ICMP Parameter Problem, so this is intended for consenting adults
only. Skipping over unknown extension headers was definitely
not intended to work.

The basic motivation for the present draft is clear:

>    However,
>    some intermediate nodes such as firewalls, may need to look at the
>    transport layer header fields in order to make a decision to allow or
>    deny the packet.  

That is, help middleboxes to violate e2e transparency and, furthermore,
allow unknown headers to cross those middleboxes. If I was a paranoid
security person, I would definitely not be happy with this. On the
contrary - if I saw an unknown IP header in a packet, I would want
to discard it. A legacy firewall wouldn't recognize the Next Header
value for draft-ietf-6man-exthdr, so would discard the packet. If my
firewall had been updated, and saw a draft-ietf-6man-exthdr, header,
it would need to look at the embedded "Specific Type" and then decide
whether to discard it. Just a bit more deep packet inspection.

So the one thing this proposal will *not* do is allow new extension headers
to cross the Internet transparently. All it might do is cause the firewalls
to dig one layer deeper before discarding the packet.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jan 2011 18:43:05 -0300

On 03/01/2011 06:25 p.m., Brian E Carpenter wrote:

> allow unknown headers to cross those middleboxes. 

I don't think this I-D will make a difference.

>From the POV of a firewall, unless it really wants a packet to
pass-through, it will block it.

So, whether the Extension Header is unknown, or whether
draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is
unknown will lead to the same result: the packet will be discarded.

This proposal would only be useful to firewalls that implement a
"default allow", and that simply want to somehow ignore an unknown
extension header and base their decision on the upper-layer protocol
(only). -- But we all know that firewalls operate (or should operate) in
"default deny" rather than "default allow".

So IMHO this proposal won't be useful for such firewalls.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 03 Jan 2011 16:53:20 -0500

If we take the view that a firewall will block anything it does not 
know, without question or limit, then
1) We have no way to extend our basic protocols that will pass through 
firewalls (we have to tunnel / encapsulate)
2) you are correct that this document does not help.

Also, if we assume that no one will ever define any new extension 
headers, then this work does not matter.

(If we want that prohibition to be the case, we should say so, and 
remove the hook for new extension headers that was left in 2460.)

On the other hand, if we think that there will be new extension headers, 
and we think that firewalls block things if they can not find enough 
information to allow them through, then it can be helpful if the 
firewalls (and other devices) can parse pass these new extensions 
without knowing them.  (Remember, these are for end-point consumption only.)

It seems to me a disservice to simultaneously let people use new 
extension headers and not give them a way to use them that can be parsed 
past by the common devices that could easily want to do such parsing.

My own preference would probably be to say that all end-to-end IP 
information should be in the destination options.  But if we do not want 
to go there, then we should own up to the implications thereof.  (In 
particular, there might be corner cases that can't use destination 
options.  We should tell people to use destination options first.  And 
tell them what to do if they can't.)

Yours,
Joel

---

From: "Rosomakho, Yaroslav" <[email-masked]>
Date: Tue, 4 Jan 2011 00:48:04 +0000

Generally I support the draft, but I also agree with comments about
firewalls.

To make this idea work, I would suggest changing word "must" to word
"SHOULD" in definition of Hdr Options parameters.
Designers of these additional headers have to acknowledge the fact that
there is no guarantee of delivery of unknown headers over firewalls in any
case.

I also have concern about mandatory "ICMP Parameter problem" message
required by second bit in the Hdr Options. While generally this is a nice
idea, it could be abused to start a reflection attack. Obviously in real
life this will be mitigated by control plane policing and other
traditional security measures, but draft does not permit that.
Replacing "must" with a "SHOULD" will fix this problem as well.

Have you considered an option to allow a device that does not understand
extension header to remove just the unknown header and continue processing
the packet?

Best Regards,
Yaroslav

On 4/1/11 12:43 AM, "Fernando Gont" <[email-masked]> wrote:

>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 04 Jan 2011 02:24:13 -0300

Hi, Joel,

> 2) you are correct that this document does not help.

I think we're talking about different issues here.

The goal of this document is to "help" firewalls such that they can get
to the transport protocol (*assuming* that the firewalls do not care
about extension headers). -- and my point is that you don't need to do
this. -- if the extension header is unknown, the firewall should not
allow the packet through (i.e., default deny). The fact that the
firewall cannot *parse* the header is a secondary issue. -- And all this
has little or nothing to do with our ability to extend our protocols.

Now, you may argue that a "default" deny limits our ability to extend
our protocols. Strictly speaking, it doesn't -- it limits our ability to
*deploy* them. But then, there's no reason (security-wise) for which an
admin should allow a protocol to be deployed in his network without his
prior consent.

Yep... usability vs. security....

> headers, then this work does not matter.

Even then, why not just mandate that new extension headers (if they ever
need to be defined) should be TLV? -- why do we need the extra header, etc.?

> without knowing them.  

Just mandating that future extension headers have a syntax of TLV would
suffice.

Anyway, the rationale is that a firewall will allow stuff that it
*needs* to allow. -- Why should a firewall allow an extension header
that has not been deemed as necessary?

>(Remember, these are for end-point consumption only.)

NIDS, firewalls, and other middle-boxes consume these things.. even when
they are not meant for them....

> past by the common devices that could easily want to do such parsing.

Just mandate TLV, and that's it -- actually, not sure why this is not
part of RFC 2460 alreay...

> particular, there might be corner cases that can't use destination

Such as?

Thanks!

Kind regards,

---

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Jan 2011 09:20:24 -0500

> The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header,

Oh, right. But I view that as (essentially) an L2 usage. It will be
used within one RPL domain, which is essentially its own link layer.
Within an RPL, all IPv6 datagrams that come from outside the domain
are encapsulated within a new IPv6 packet, so the outer IPv6 packet
(with the RH4 header) is like a link-layer encapsulation.

> only. Skipping over unknown extension headers was definitely

I don't think it's right to say 2460 intends to make defining new
options "hard". Or more to the point, this document doesn't make
defining new options any easier (from what I can see).

The text in Section 4 is about how the intended recipient of an option
is supposed to process it. If the intended recipient doesn't
understand an option, that's arguably a bad situation. And the various
2460 definitions provide a way for the sender to get predictable (and
reasonable) behavior in such situations.

The alleged purpose of this document is to provide a way for devices
that are NOT the intended recipient of an option to do "sensible
things" with on option they don't understand, which is a sort of
oxymoron.

> whether to discard it. Just a bit more deep packet inspection.

But it is a very open question whether any middlebox will bother to
do this.

> to dig one layer deeper before discarding the packet.

This is at best poorly phrased. :-)

If the firewall will just dig one layer deeper and then discard
anyway, what is the point?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Jan 2011 09:29:08 -0500

> pass-through, it will block it.

I think this is the crux of the problem. firewalls, by default,
discard stuff. They don't like the idea of allowing unknown or
"uncommon" things through.  Defining new options and expecting
firewalls to give them a blank check to go through I suspect is
wishful thinking.

And look at this from the perspective of someone who wants to deploy a
new option. If 80% of the firewalls allow the new option through, will
this be good enough for deployment? Doubtful. What about 98%
cooperation from firewalls? Again, quite possibly not.

Unless this document is widely implemented in practice, it's far from
clear it is useful. We've seen time and time again that deploying
something new is a non-starter if there are key parts of the
infrastructure that don't support or allow it.

I remain skeptical that this draft solves a real problem in a
meaningful way.

Thomas

---

From: Steven Blake <[email-masked]>
Date: Tue, 04 Jan 2011 10:20:46 -0500

> anyway, what is the point?

+1

I still don't understand what this draft solves that couldn't be solved
more easily by just encoding future header extensions as either
Destination options or Hop-by-Hop options?  Both of these are easy to
parse and have well defined rules for how to handle unknown options.

Regards,

// Steve

---

From: Fernando Gont <[email-masked]>
Date: Tue, 04 Jan 2011 14:17:50 -0300

Hi, Thomas,

> cooperation from firewalls? Again, quite possibly not.

I fully agree with you.

> clear it is useful. 

Whether it's widely deployed is, IMHO, irrelevant. Two cases:

* The I-D is not deployed (firewalls can't go past new extension
headers). -- but the very presence of the unknown headers is what causes
the fw to block the packets.
* The I-D is deployed. The presence of an "uncommon" extension header
causes the fw to block the packet (even when it could, *if* it wanted go
past the "uncommon" extension header).

As you correctly stated it, the crux of the problem is that this
document assumes that firewalls are willing to allow stuff that they
don't understand. -- but they aren't. They are meant to only allow stuff
that is needed.

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Jan 2011 12:26:29 -0500

Then what about if we forget firewalls for the moment?

A lot of routers look for the TCP/UDP Port numbers for LAG/ECMP computation.
Many of them can cope with having a destination options extension, and 
therefore that is clearly the better way to handle such information. 
And anything we do should make that strong preference clear.

Nothing we can do can change the way routers with silicon already 
deployed handle unknown extension headers.

Given that, one option is to just say that new extension headers should 
not be used.

If we think that there will be some new extension headers, that we want 
to support, designed for the general Internet, then it would seem to 
make sense to try to get new behavior defined, supported, and then used, 
that will allow for such extensions.  In that case, requiring and 
documenting the requirement for new extension headers to use TLV 
encoding would seem to have applicability and utility.

Yours,
Joel

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Jan 2011 18:36:09 +0100

Le 4 janv. 2011 à 16:20, Steven Blake a écrit :

> Destination options or Hop-by-Hop options?

1.
let's assume a new routing extension is found useful.
Without a skippable extension format, it won't ever  be deployable:
- All FWs will have no option but rejecting all packets having it.

With this extension format, FWs can first be upgraded to support it, i.e. so that they ignore unknown extensions marked as "to be ignored if unknown".
Then it becomes realistic to create, for example, a new routing option.

2.
Attached is a copy of a previous mail, still relevant I believe.

Regards,
RD

> Le 3 janv. 2011 à 14:20, Suresh Krishnan a écrit :
>> ...
>> The draft contains three independent components
>> 
>> a) Specifying a uniform format for all future IPv6 extension headers to
>> make them easier to parse/process.
>> b) Requesting a single IP protocol number codepoint for all future
>> extension headers and multiplexing them using a Specific Type field
>> inside the generic header.
>> c) Specifying error-handling and drop behavior for dealing with unknown
>> extension headers.
> 
>> From what I have seen there seems to be no opposition to a)
> 
> No opposition AND positive support:
> 
> Skipping unknown extension headers can be useful not only in FWs but also in some other places (e.g. in some variants of load balancers) 
> 
> As Fernando noted, FWs that do "default deny" shouldn't be concerned.
> However, not all FWs are necessarily default deny in the strict sense (i.e. with all fields of accepted packets having to be described)
> It may be useful to say, for example, "accept all incoming connections to address X and port 80" without concern for extension headers.
> 
> Besides, someone, Mark Townsley I believe, described a FW behavior where:
> - packets known to be good are accepted
> - packets known to be bad are discarded
> - unknown packets are rate limited
> This is IMHO an interesting possibility that differs from just "default deny".
> 
> Points b and c are more debatable.
> I don't find them necessary.
> The draft would IMHO be better without them,  but I don't object.
> 
> The proposed addition in the "Meta question" seems useful => +1
> (But the document remains acceptable without it.)

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 02:15:55 -0500

Hi Thomas,
  Please see responses inline. 

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Monday, January 03, 2011 3:40 PM
> To: Suresh Krishnan
> Cc: Tony Li; [email-masked]
> Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt
> 
> FWIW, I'm sympathetic to Tony's basic sense that it is 
> unclear that we need to do this work/document.
> 
> 2 of the above code points are used by IPv4, so having a 
> generic extension header mechanism for IPv6 would have saved 
> only 2 code points. No need to panic folks...
> 
> > allocation for a protocol number at this point, and wait till the 
> > first "Specific Type" request comes up?
> 
> My general sense is that this work is mostly just good common 
> sense advice to someone who has a need to define a new 
> extension type. But until we see such a concrete proposal, I 
> am not convinced (yet) that we should define anything new 
> that suggests people go change implementations or allocate 
> code points. Both are premature.

OK.

> 
> As one concrete example, RFC 5175 defines extensions for 
> adding future RA flags. But, none have been defined yet, so 
> the work really isn't needed yet and implementations 
> certainly don't need to do anything yet. However, that has 
> not stopped NIST and DoD from citing these documents 
> recommendations to implement.
> 
> Upleveling a bit, and thinking about routing headers and 
> destination options, my general sense is about such options is:
> 
> 1) Destination options are the preferred route. Any other 
> kind of option will be extremely hard to deploy, has all 
> kinds of barriers, etc. (This proposal will have no impact on 
> future destination options. Right?)

Correct. And I proposed adding the following text to this draft 
to state this fact.

"RFC2460 allows the use of both extension headers and destination
options in order to encode optional destination information in an IPv6
packet. The use of destination options to encode this information,
provides more flexible handling characteristics and better backward
compatibility than using extension headers. Because of this,
implementations SHOULD use destination options as the preferred
mechanism for encoding optional destination information, and use a new
extension header only if destination options do not satisfy their needs.
The request for allocation of a Specific Type value MUST be accompanied
by an specific explanation of why destination options could not be used
to convey this information."

http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html

> 
> 2) The routing header is essentially deprecated, and we 
> probably won't define any more. We've already deprecated RHO. 
> RH1 was never used, is now deprecated, and arguably shouldn't 
> even count as ever having been defined.  RH2 is the MIP 
> routing header. RH2 was originally a regular type 0 option, 
> but was changed because of the fear that firewalls would 
> block packets with such options by default, preventing MIPv6 
> from being deployed. If we had to do it all over again, MIPv6 
> arguably should have used a destination option, since by 
> definition RH2 is only processed if the two addresses in the 
> routing header are on the same node, which is much more in 
> line with the intention behind destination options.
> 
> Which leads me to ask, exactly what kinds of future options 
> do we think will take advantage of this new format?

Not sure. The goal is to make sure that other wgs that define
ipv6 specific optional information do so in a consistent way.
I think the burden would be on them to prove that destination
options do not fit their need.

> 
> Note, my bias on this general topic is based on experience 
> that unless we have something concrete driving this sort of 
> work, we risk getting it wrong. So, I'm still trying to be 
> convinced we need to do this sort of work *now*. If there was 
> an actual proposal for a new option that solved some sort of 
> real problem, things might be different.

The "concrete" thing was the need for firewalls to differentiate
between unknown extension headers and unknown transport 
protocols. There were two firewall vendors who spoke up for this
at a 6man wg meeting. It is possible that they no longer care.
That is why I am trying to see if there is any reason to continue
with the draft, and if so what it should contain. I would 
Appreciate your comments on this mail.

http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 02:27:12 -0500

Hi Brian, 
  Please see response inline.

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Monday, January 03, 2011 4:25 PM
> To: Thomas Narten
> Cc: Suresh Krishnan; [email-masked]
> probably won't 
> However, isn't the real question whether we want to change 
> the implied intention that adding a new extension header 
> should be hard? Section 4 of RFC 2460 makes this intention 
> pretty clear:
> ICMP Parameter Problem, so this is intended for consenting 
> adults only. Skipping over unknown extension headers was 
> definitely not intended to work.
> 
> That is, help middleboxes to violate e2e transparency and, 
> furthermore, allow unknown headers to cross those 
> middleboxes. If I was a paranoid security person, I would 
> definitely not be happy with this. On the contrary - if I saw 
> an unknown IP header in a packet, I would want to discard it. 
> A legacy firewall wouldn't recognize the Next Header value 
> for draft-ietf-6man-exthdr, so would discard the packet. If 
> my firewall had been updated, and saw a 
> draft-ietf-6man-exthdr, header, it would need to look at the 
> embedded "Specific Type" and then decide whether to discard 
> it. Just a bit more deep packet inspection.
> 
> So the one thing this proposal will *not* do is allow new 
> extension headers to cross the Internet transparently. All it 
> might do is cause the firewalls to dig one layer deeper 
> before discarding the packet.

Correct. But the reason that this part got added to the draft 
was that firewall vendors wanted to differentiate between 
unknown extension headers and unknown transport protocols and
possibly treat them in a different way. E.g. Section  3.2.2 of

http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16

Specifies one such need.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 02:34:46 -0500

Hi Fernando,

> From: Fernando Gont 
> [mailto:[email-masked]] On Behalf Of 
> Fernando Gont
> Sent: Monday, January 03, 2011 4:43 PM
> To: Brian E Carpenter
> Cc: Thomas Narten; [email-masked]; Suresh Krishnan
> > furthermore, allow unknown headers to cross those middleboxes.
> 
> From the POV of a firewall, unless it really wants a packet 
> to pass-through, it will block it.
> 
> draft-ietf-6man-exthdr-01.txt is implemented and the Specific 
> type is unknown will lead to the same result: the packet will 
> be discarded.
> 
> This proposal would only be useful to firewalls that 
> implement a "default allow", and that simply want to somehow 
> ignore an unknown extension header and base their decision on 
> the upper-layer protocol (only). -- But we all know that 
> firewalls operate (or should operate) in "default deny" 
> rather than "default allow".
> 

Yes. You are correct. This proposal will not be useful for such
firewalls. On the other hand 

allows a class of firewalls that can put application transparency
over strict filtering (see REC-11). In such case differentiating 
an unknown transport layer protocol from an unknown extension 
header would be useful. Whether or not such firewall would exist
in the wild is an interesting question, but I do not see how to 
answer that conclusively.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 05:08:16 -0500

Hi Steve, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven Blake
> Sent: Tuesday, January 04, 2011 10:21 AM
> To: [email-masked]
> I still don't understand what this draft solves that couldn't 
> be solved more easily by just encoding future header 
> extensions as either Destination options or Hop-by-Hop 
> options?  Both of these are easy to parse and have well 
> defined rules for how to handle unknown options.

One of the drivers of the draft was that firewall vendors wanted to differentiate between unknown extension headers and unknown transport protocols and possibly treat them in a different way. E.g. Section  3.2.2 of

specifies one such need.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 5 Jan 2011 05:25:04 -0500

Hi Joel, 

> Behalf Of Joel M. Halpern
> Sent: Tuesday, January 04, 2011 12:26 PM
> To: Fernando Gont
> Cc: [email-masked]
> Many of them can cope with having a destination options 
> extension, and therefore that is clearly the better way to 
> handle such information. 
> Nothing we can do can change the way routers with silicon 
> already deployed handle unknown extension headers.
> 
> Given that, one option is to just say that new extension 
> headers should not be used.
> 
> If we think that there will be some new extension headers, 
> that we want to support, designed for the general Internet, 
> then it would seem to make sense to try to get new behavior 
> defined, supported, and then used, that will allow for such 
> extensions.  In that case, requiring and documenting the 
> requirement for new extension headers to use TLV encoding 
> would seem to have applicability and utility.

I agree with you completely. This seems to be the very least we need to do. I would appreciate your response to 

Thanks
Suresh

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 05 Jan 2011 07:44:40 -0500

For clarity, in terms of the pieces of your original note:

I consider (a), specifying the format at least to the level of requiring 
TLV encoding, to be a good idea.

I do not see any particular advantage in (b), allocating a code point, 
but I can live with it if the WG wants it.

And (c), changing the RFC 2460 mandate on error and drop handling, and 
replacing it with the details used in destination option bothers me.  It 
seems to me we should have a strong reason for changing what was agreed. 
  Also, any usage of such bits will have to allow for existing 
destinations, which will ignore such bits.  Still, if we want to make 
using the extension headers easy, we should add the flag bits.  But I 
don't know that we want to make it easy.  Just possible, if we really, 
badly, need to do it.

Yours,
Joel

On 1/5/2011 5:25 AM, Suresh Krishnan wrote:
...
> I would appreciate your response to
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 5 Jan 2011 18:26:56 +0530

> TLV encoding, to be a good idea.

I agree to this.

I think there is value in specifying a format that all subsequent extension headers MUST use.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 5 Jan 2011 18:34:53 +0530

I see another application of this extension. Assume you are the end host that wants to prioritize certain packets or wants to implement Access control lists (ACLs). In the absence of this extension a router cannot apply ACLs as it will never know how to parse the packet in case it comes across an unknown extension header. It can, if it supports this extension. ALso note that the default action of an ACL may not necessarily be "deny all".

Cheers, Manav

> Behalf Of Fernando Gont
> Sent: Tuesday, January 04, 2011 3.13 AM
> To: Brian E Carpenter
> furthermore,

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Jan 2011 14:20:09 +0100

Le 5 janv. 2011 à 13:44, Joel M. Halpern a écrit :
> ...
> I consider (a), specifying the format at least to the level of requiring TLV encoding, to be a good idea.

+1

---

From: james woodyatt <[email-masked]>
Date: Thu, 06 Jan 2011 10:28:20 -0800

On Jan 3, 2011, at 13:43, Fernando Gont wrote:
> 
> From the POV of a firewall, unless it really wants a packet to pass-through, it will block it.

That's an unwarranted assumption.  Consider the "firewall" described in I-D.ietf-v6ops-cpe-simple-security, which is intended to block only unsolicited inbound traffic.  Once residential gateways that implement IPv6 Simple Security are ubiquitous, it will not be practical to introduce any new extension headers that these firewall appliances do not recognize.  If they can't parse past the new extension header to inspect the upper-layer transport header, then they can't record state that will allow packets for the *solicited* return path.  In other words, they're still forwarded, but the return path they're meant to solicit cannot be recorded.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Sun, 16 Jan 2011 04:25:17 +0530

Fernando,

> unknown will lead to the same result: the packet will be discarded.

This is incorrect - The draft clearly says that if the Hdr Options is
00, then the packet will skip over this option and continue with the
remaining packet.

Kam

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Sun, 16 Jan 2011 04:27:41 +0530

> If we take the view that a firewall will block anything it does not know,
> without question or limit, then

I agree.

> 2) you are correct that this document does not help.

Disagree. If the Hdr Options is 00, then it will pass through.

>
> Also, if we assume that no one will ever define any new extension headers,
> then this work does not matter.
>
> (If we want that prohibition to be the case, we should say so, and remove
> the hook for new extension headers that was left in 2460.)
>
> On the other hand, if we think that there will be new extension headers, and
> we think that firewalls block things if they can not find enough information
> to allow them through, then it can be helpful if the firewalls (and other
> devices) can parse pass these new extensions without knowing them.

Yes.

>
> It seems to me a disservice to simultaneously let people use new extension
> headers and not give them a way to use them that can be parsed past by the
> common devices that could easily want to do such parsing.

Yes.

> information should be in the destination options.  But if we do not want to
> go there, then we should own up to the implications thereof.  (In
> particular, there might be corner cases that can't use destination options.
>  We should tell people to use destination options first.  And tell them what
> to do if they can't.)

This then could be added in the subsequent versions of this draft.

Kam

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Sun, 16 Jan 2011 04:29:55 +0530

> anyway, what is the point?

It wouldnt in all the cases - not when the Hdr type is 00.

Kam

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Jan 2011 13:28:47 +1300

> It wouldnt in all the cases - not when the Hdr type is 00.

If the firewall's policy is to dig deeper when the type is 00,
it will do so, regardless of what some RFC may say. Firewalls
are not known for obeying RFCs.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Jan 2011 10:27:15 +0100

> It wouldnt in all the cases - not when the Hdr type is 00.

If the draft is adopted, the more precise situation becomes:
- NEITHER that all FW's will "discard anyway"
- NOR that all FW's will accept  packets "in all cases" when Hdr type is marked as skippable (00)  
- BUT that FW's, load balancers, etc., MAY accept packets containing new header types marked as skippable.  

Without the draft, it is impossible to skip a header of a new type, and to process subsequent headers for whatever policy applies to them.

The draft introduces a new flexibility for those who are interested in using it, and it won't do any harm to others.
(In particular, vendors of FW's who prefer to always discard packets containing all unknown header types MAY continue to do so.)

Diversity and experience of authors of this draft shows that, even if some others aren't interested, there is a demand..
I therefore support quick adoption of this draft.

Regards,
RD