Hi Ron, There is a technique known as "Virtual Fragmentation Reassembly" where the middlebox gathers all fragments of a datagram, performs any necessary checks and then releases the fragments without reassembling them so that the destination host still has to reassemble. Is this one of the techniques you are referring to?
Thanks - Fred > -----Original Message----- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Ron Bonica > Sent: Monday, October 15, 2018 1:39 PM > To: Fred Baker <fredbaker.i...@gmail.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt > > Hi Fred, > > The first iteration of Section 7.3 actually included the word "reassemble". > That is one possible implementation. > > I dropped the word when I realized that there may be other ways to get the > desired behavior. While they don't all require > reassembly, that all require the maintenance of a little more state. > > > Ron > > > > -----Original Message----- > > From: Fred Baker <fredbaker.i...@gmail.com> > > Sent: Monday, October 15, 2018 3:50 PM > > To: Ron Bonica <rbon...@juniper.net> > > Cc: int-area@ietf.org > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt > > > > > > > > > On Oct 15, 2018, at 12:11 PM, Ron Bonica <rbon...@juniper.net> wrote: > > > > > > So, the spirit of the robustness principle, all parties should be > > > conservative in > > what they do and liberal in what they accept. > > > > > > - Application developers should avoid reliance on IP Fragmentation. (Don't > > trip on the bad behavior or middle boxes if you can avoid it). > > > - Middle box developers should produce devices that don't behave badly in > > the presence of fragmentation. This may mean that middle boxes should > > become more stateful to support fragmentation. > > > > I might add one thought to 7.3: recommend that middle boxen reassemble a > > datagram before operating on it. The attacks that happen with fragmentation > > result in issues with reassembly, and the obvious solution is to detect the > > situation and drop the datagram in question. > > > > I would also comment that the first fragment created (the one at offset > > zero) > > might not be the first fragment received. The second bullet in 7.3, the one > > about selecting a next-hop, assumes that the first fragment is also the > > first one > > received. However, if the datagram were reassembled before operating on it, > > that wouldn't be an issue. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
