Ray,
On 25/05/2013 21:55, Ray Hunter wrote:
Brian E Carpenter <mailto:[email protected]>
24 May 2013 22:50
On 25/05/2013 00:40, John Leslie wrote:
Ray Hunter <[email protected]> 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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
