> Brian E Carpenter <mailto:[email protected]> > 27 May 2013 06:47 > On 26/05/2013 20:51, Ray Hunter wrote: >>> Brian E Carpenter <mailto:[email protected]> >>> 25 May 2013 22:36 >>> 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. >> I guess we could always use a hop by hop option for that use case, so >> that's no big deal to me. >>> 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.) >> 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. > > Correct, that's why it's a standards track update. We are clarifying > the meaning. > >> 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." > > I'm not sure if it's really a MAY or simply a statement of what > occurs in the real world. > >>>> 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. >> 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" > > 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. > >> (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. > > 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. Agreed. > >> 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." > > 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. ACK. >> 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. > > 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?
I have no problem if load balancers always forward. > 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. > >> Hence my comment about enabling all "experimental" repositories by >> 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. 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. >> 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. > > 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 Agreed for boxes that do not explicitly perform filtering functions. Filtering functions need to be left in the hands of the network administrator. > >> regards, >> RayH >>>> 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 --------------------------------------------------------------------
