> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Lee, Yiu > Sent: Wednesday, October 27, 2010 9:38 AM > To: Rémi Després > Cc: Softwires > Subject: Re: [Softwires] > I-DAction:draft-lee-softwire-dslite-deployment-00.txt > > There are many recorded attacks about IP fragmentation > (search for Rose > Frag attack). Some firewalls are smart enough to identify > whether it is a > real attack or not. Some simply drop any fragmentation > packet. I am not > going to argue which is a better policy. My point is if we > can limit the > fragmentation only happening between b4 and AFTR, this will > save us a lot > of headache in future.
Hold on there. Fragmentation and reassembly is a fundamenal function of the IP service model - has been for decades. There are major Internet services that serve content while setting DF=0. Isolated large packets that must be delivered without being lost due to an MTU restriction use DF=0. End-to-end fragemntation and reassembly between consenting end systems is also available even if the network itself does not fragment. Are you saying we should disable a fundamental function of the IP service model? And trace down all of the places where things would break as result? Fred [email protected] > On 10/27/10 12:07 PM, "Rémi Després" <[email protected]> wrote: > > > > >Le 27 oct. 2010 à 17:50, Lee, Yiu a écrit : > > > >> Not the servers, but the firewall in front of the servers..... > > > >Well, that's different. > >But is it normal for a FW to refused fragmented IPv4 datagrams? > >It seems to me that would seriously limit connectivity. > > > >RD > > > >> > >>>> If B4 fragmented the v4 > >>>> packet, this is a possibility that the target server may drop the > >>>> fragmented v4 packet due to security concerns. > >>> > >>> I miss the point. > >>> I don't see why servers would refuse fragmented datagrams > for security > >>> reasons. > > > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
