Hi Mike, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > C. M. Heard > Sent: Tuesday, August 27, 2013 7:08 PM > To: IPv6 > Subject: Re: [6MAN] UDP+Fragmentation (was: "Deprecate") > > On Tue, 27 Aug 2013, Warren Kumari wrote: > > Apologies if I missed it and this was already discussed -- for > > some reason my MUA is refusing to thread this conversation > > correctly and so I'm reading thing all out of order? > > Ah, an operations person joining the discussion! Thank you! > > > I have some issue / concerns with draft-andrews-6man-fragopt > > > > The whole problem is that I cannot look at the fragment and know > > what protocol and port it is actually destined to (I also have > > concerns about past issues with reassembly / overlapping frags, > > but we'll skip those for now). > > > > I am unclear how I am supposed to be able to trust the port > > information in the new header? > > It is indeed possible to forge the option with upper-layer header > information that is proposed to be passed in the option. > > > Lets say that I only allow traffic to 192.0.2.1 port 80. > > What is to stop a malicious party from: > > 1: Generating a packet to 192.0.2.1 port 22. > > 2: Fragmenting it into two parts. > > 3: Adding a few junk headers for padding (I think that this is > optional) > > 4: Putting in this new header and listing the destination port as 80? > > In http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html > (which you may not have seen yet) I suggested that the upper-layer > header option should not be allowed in the initial fragment, which > contains the real upper-layer header. If it's there, your firewall > (if it's been updated as proposed) should drop the datagram. If > it's not, the datagram should be dropped because it has port 22 in > the upper-layer header, in violation of the configured policy. > > Mark Andrews emphatically disagreed with my suggestion; but in that > case, the initial fragment would have both the option and the > upper-layer header, and they would not match (the option has port 80 > and actual upper-layer header has port 22). That should make your > firewall recognize that the initial fragment is bogus and drop it. > > In any case, the initial fragment should get dropped. > > Now, your firewall (if it's updated per either variation of the > proposal) would allow the non-initial fragments to pass on (since > the option says they are destined to port 80). But those won't > reassemble to a complete datagram on the destination host. > > I imagine that your next question (and one that I _should_ have > asked myself) is: how is this different from what we get from the > combination of draft-ietf-6man-oversized-header-chain and > draft-ietf-6man-ext-transmit, _without_ the upper-layer header > option? The answer is that it's not different, at least not in a > significant way. This is what would happen today if one applied > stateless ACLs at layer 4 to initial fragments that contain a > complete header chain but allowed non-initial fragments to go > through unimpeded. > > Your firewall could do some checks like looking at the length of the > upper-layer PDU claimed in the copy of the upper-layer header in the > option (for protocols like UDP that have a length field, and if the > option is formatted as I proposed) and then discard any non-initial > fragments that have offsets past the end of the upper-layer data. > However, it would still be possible for someone to send a bunch of > non-initial fragments whose reassembly would never complete on the > destination end host. > > > I *guess* if *all* of the devices on the inside of my network know > > to check that the new header attributes match the reassembled pack > > then I have *some* protection, but this isn't (that I could see) > > specified in the draft. > > Actually, no. I suggested that end systems (where reassembly is > done) should do this check if they can process the upper-layer > header option. But that would not prevent them from getting a > series fragments whose reassembly would never complete: all that an > attacker needs to do is send an incomplete series of fragments. > The gap can occur anywhere, and the upper-layer header option need > not be forged (i.e., it could match the contents of the header in > the initial fragment and pass all ACL checks). > > FWIW, the UDP segmentation proposal that I floated earlier in this > thread suffers from the exact same problem. > > One of the other the issues mentioned in draft-taylor-v6ops-fragdrop > is the problem of stateless load balancers that use the 5-tuple in > initial fragments and (say) the 2-tuple in non-initial fragments. > To the extent that it is considered trustworthy, the proposed > upper-layer header option (with appropriate middlebox modifications) > would fix this problem (as would the UDP segmentation proposal, at > least for UDP), but then again, so would the use of the flow label > as described in RFC 6437. > > OK, it seems that the ideas floated in this thread don't go really > beyond what's already been standardized or (apparently) agreed upon > here in 6man, and as far as I can see, the problem of an attacker > being able to send a series of fragments whose reassembly will never > complete is basically unsolvable.
If each fragment contains a Message Authentication Code (MAC), the destination can discard fragments that are either missing or contain an incorrect MAC value. (Yes, this opens up other issues such as attacks on performance for running the MAC algorithm.) > So let me ask a question: is this > a sufficiently serious problem to be worth breaking fundamental > connectivity for those protocols that don't have a good alternative > to fragmentation? Tunnels need fragmentation to meet the 1280 IPv6 minimum MTU, and preferably also to meet the 1500 legacy Internet cell size. Thanks - Fred fred.l.temp...@boeing.com > > There are some comments about NATs changing things "both the > > source and destination ports may have been changed so the ports > > may appear to be completely unrelated. The source port is changed > > by a client NAT and the destination port is changed by a NAT > > acting a load balancer." > > Just out of curiousity -- is this actually an issue in operational > IPv6 networks? > > Thanks, > > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
