Ray,
On 25/05/2013 21:55, Ray Hunter wrote:
>> Brian E Carpenter <mailto:brian.e.carpen...@gmail.com>
>> 24 May 2013 22:50
>> On 25/05/2013 00:40, John Leslie wrote:
>>> Ray Hunter <v6...@globis.net> wrote:
>>>> 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.
>>> 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.
>> 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.)
> 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.
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.
>
> 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.
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 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.
If IPv6 had been designed that way, but it wasn't.
> 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?
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).
>
>
>>> (The prime purpose of this document is creating an IANA registry;
>>> that purpose should not be clouded by discussion of what firewalls
>>> "should" do.)
>> 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.
>
> 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?
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.
> 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?
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
> decided on that point.
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
>> On 25/05/2013 02:43, Tim Chown wrote:
>>
>>> 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?
>> 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, etc as header types?
>> 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
>>
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
