On Mon, 26 Aug 2013, C. M. Heard wrote: > Upon reflection, I have come to the conclusion that the proposal > in draft-andrews-6man-fragopt (or a variant thereof) is a much > better solution to the problems with IPv6 fragmentation than the > UDP segmentation scheme I proposed. > > The huge advantage of putting a skippable IPv6 option with > higher-layer header information into IPv6 fragments is that it is > much easier to deploy incrementally than the UDP segmentation > scheme. New end systems could begin inserting the option as soon > the format is standardized, and they would still be able to > communicate with older end systems that comply with existing IPv6 > specifictions, at least on paths where fragments are not discarded > by firewalls. That's not true of the UDP segmentation scheme (or > of more complex alternatives such as SEAL).
Upon further reflection, prompted by Warren Kumari's comments (see http://www.ietf.org/mail-archive/web/ipv6/current/msg18858.html and http://www.ietf.org/mail-archive/web/ipv6/current/msg18862.html), it becomes clear that the very thing that makes this alternative (relatively) easy to deploy incrementally can make it unattractive to security-conscious operators. There are two issues that Warren's comments brought to the fore: 1.) One of the reasons why operators block fragments is that if fragments are allowed into one's network, it is relatively easy for an attacker to make a DOS attack on end systems by sending an incomplete series of fragments. This ties up resources until the end system's reassembly timer expires. 2.) The proposed skippable upper-layer header option is easily forged. It is therefore still relatively easy to mount the above attack on end systems that do not recognize the option, even if firewalls have been updated to require that option in all fragments. The problem is that end systems that don't recognize the skippable option will ignore it and process fragments in the IP layer as they do now. This is good for incremental deployment, but it also leaves such systems just as vulnerable as they were without the option. In order to avoid that problem, it seems that we need to ensure: (a) that end systems that don't understand the option drop any packets that contain it, and (b) that end systems that do accept the option use it to filter out packets that are unwanted or invalid. Condition (a) can be achieved by choosing the two high-order bits of the option code to specify that the packet must be discarded if the option is unrecognized (and whether or not to send an ICMP Parameter Problem message). Condition (b) can be achieved by requiring that packets containing this option be kicked up to the transport layer for processing prior to reassembly, in lieu of doing reassembly at the IPv6 layer prior to transport layer processing. In particular, end-system implementations would need to discard fragments directed at a port with no listener. Other validity checks could be made, such as discarding fragments that specify a length in excess of the port's receive buffer or that have inconsistent upper-layer headers. This does not block all conceivable attacks, but it reduces the severity to something equivalent to what an attacker could do by forging TCP segments -- and that is a risk that end systems deal with today. What I have described in the paragraph above is different ONLY IN DETAIL from the other alternatives we've been discussing in this thread, namely modifying UDP so that it supports segmentation of long payloads or creating a new UDP-like protocol that supports segmentation of long payloads. The information carried in the IPv6 and transport layer headers would be equivalent, and the processing would be quite similar. Obviously the header formats would differ; in addition, so would the kind of ICMP message, if any, that would be returned by systems that don't recognize the new option/protocol (Parameter Problem/Unrecognized Option or silent drop for the proposed option, Parameter Problem/Unrecognized Next Header for a new protocol, or silent drop for a modified UDP as suggested in http://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html). If the above reasoning is correct, then my inclination is to deal with the issue explicitly in the transport layers that need to deal with it (which would put the problem in the domain of TSVWG). That seems cleaner than intertwining the IP and transport layers (though in practice these layers are often tightly coupled anyway). If there are any operations people listening in, it would be helpful to get some feedback on whether this reasoning is correct. It would also be helpful to get some indication on whether a modified UDP or a new UDP-like protocol that supports transport layer payload segmentation solves enough problems to be worth the effort to specify, implement, and deploy. At the moment, the only compelling use case seems to be DNS (and more particularly DNSSEC). There is already a work-around in that case, namely TCP, which was made mandatory in 2010 by RFC 5966 to work around firewalls that "routinely block fragmented IP packets" and "network devices [that] deliberately refuse to handle DNS packets containing EDNS0 options." Clearly, making a new or modified UDP-like transport protocol is not sufficient; applications that want to use it would need a means to signal that they support it and/or a means to query whether their peers support it. In the case of DNS that would presumably mean something like a new EDNS0 option. The question arises whether the effort involved in making these changes would be worthwhile, given that TCP is already available as a workaround. Thanks and regards, Mike Heard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
