In message <[email protected]>, "C. M. Heard " writes: > 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.
Actually before making statements like this we really need a audit of current stacks and how they behave when subject to a flooding fragmentation attack. These attacks are *old* and OS have strategies to deal with them. Additionally is the firewalls DoS be dropping the packets worse than the flooding DoS? A stateful firewall also doesn't let through 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. Only if they are vulnerable to begin with and only if the firewall is letting through all packets with 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 Or fix the underlying problem that the filter was put in place to address in the first place. > (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). Which makes it no longer incrementally deployable. > 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 > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
