On Mon, Oct 15, 2018, 3:11 PM Fred Baker <fredbaker.i...@gmail.com> wrote:
> > > > On Oct 15, 2018, at 1:50 PM, Ron Bonica <rbon...@juniper.net> wrote: > > > > Exactly, but I didn't want to introduce and define the term "Virtual > Fragment Reassembly". So, I just described the output. The middle box: > > > > - makes a decision on that first fragment > > The one at offset 0 (and therefore containing the transport header), or > the first one it receives (which might be at the final offset or any > other)? What if they're not the same? > For instance, a while back Linux always sent the first fragment last when fragmenting. This wreaked havoc on middle boxes trying to reassemble. That was changed to send first fragment first. But even so, I think there might be some ECMP implementations that could route first fragment (off=0) differently to create ooo packets relative to fragment train. Tom > > - applies that decision to the first fragment and all subsequent > fragments > > > > Ron > > > > > >> -----Original Message----- > >> From: Templin (US), Fred L <fred.l.temp...@boeing.com> > >> Sent: Monday, October 15, 2018 4:46 PM > >> To: Ron Bonica <rbon...@juniper.net>; 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 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > >>> man_listinfo_int-2Darea&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > >> ndb3voD > >>> TXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > >> AWF2EfpHcAwrDThKP8&m=9LgfnIl19MFJu > >>> > >> utKdbF3K8gh03dGa8ysrFnSrEVkXoE&s=mLM6w6j83V7i_S2wdo_SdtsOfd6Td > >> b_XiWnb_ > >>> HigsBQ&e= > > > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > _______________________________________________ > 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
