Subject: RE: [Capwap] Question on LWAPP-03 draft

From: "Changming Liu" <[email-masked]>
Date: Thu, 5 Jan 2006 17:22:02 -0800

Put CAPWAP on a side for a moment, it sounds so strange when hearing the claim that " middleboxes are commonly configured to drop IP fragments.", especially after several time.  Is there any data to support this claim? If so, we may have a broken internet. How many of us use one type of tunnel or another to access the company network from home or on the road, not mention the side to side VPN? If this is the case, and "it is almost certain that fragmentation will need to occur on xyz tunneled data packets", and "most middle boxes are commonly configured to drop IP fragments", how can we access the company's network from home?

It is not a big deal whether CAPWAP supports fragmentation or not. Either way will work. But the underneath assumptions need to be convincing.

Changming

-----Original Message-----
From: Darren Loher [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 4:07 PM
To: Puneet Agarwal; Changming Liu; Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury; [email-masked]
Subject: RE: [Capwap] Question on LWAPP-03 draft

Opps, dumb me, the 'fragment offset' in the standard IP header let's one reassemble IP fragments in the proper order.  

So the only reason for fragmenting at the LWAPP/CAPWAP layer is avoid IP layer fragments because middleboxes are commonly configured to drop IP fragments.  In addition, since it is almost certain that fragmentation will need to occur on CAPWAP/LWAPP tunneled data packets, it is better to fragment the packets before they reach the IP layer.

I will be quiet now.  :)

-Darren

> -----Original Message-----
> From: Puneet Agarwal [mailto:[email-masked]]
> Sent: Thursday, January 05, 2006 2:55 PM
> To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay; Vishwas
> Manral; Abhijit Choudhury; [email-masked]
> Subject: RE: [Capwap] Question on LWAPP-03 draft
> 
> Hi Changming,
> 
> 1) Each transport tunnel has an MTU. If you know that you are going to be
> exceeding that MTU when encapsulating the wireless frame, then it is
> better to fragment at the LWAPP/CAPWAP level to avoid IP fragments (when
> UDP/IP is the transport). It is not a question of whether middleboxes (eg:
> firewalls) can handle IP fragments or not (I assume that most can but
> there are of course legacy issues) - but the most common configuration of
> these deployed middleboxes is to drop IP fragments.
> 
> If routers in the path of the WTP and AC want to IP fragment, then that is
> definitely allowed and valid (with the caveat that some middleboxes might
> drop these fragmented pkts). Even if path MTU discovery is not done, one
> could argue that setting the UDP/IP transport MTU to (1500-20-8)= 1472
> would work under most circumstances without the packet getting further IP
> fragmented by intervening routers (assuming you don't have any other VPN
> tunnels etc in the path).
> 
> 2) Packet/fragment reordering is not really an issue for CAPWAP (and I
> agree with you).
> 
> Thanks.
> 
> -Puneet
> 
> -----Original Message-----
> From: Changming Liu [mailto:[email-masked]]
> Sent: Thursday, January 05, 2006 12:51 PM
> To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas
> Manral; Abhijit Choudhury; [email-masked]
> Subject: RE: [Capwap] Question on LWAPP-03 draft
> 
> A couple of questions about the benefits of this application fragmentation
> just out of my ignorance.
> 
> 1) Most commercial firewalls handles IP fragments well to an acceptable
> degree (I don't think anybody will buy one which does not) since
> fragmentation is common norm in IPv4. I guess it needs to be handled one
> way or another even by the non-commercial ones. Not sure why this issue is
> particular different for CAPWAP? If AC and APs are connected via routers
> in several hops (this may be a likely case that a firewall exists between
> the AC and APs), IPv4 fragmentation may still be encountered because IPv4
> path MTU is not used widely as we'd like to.
> 
> 2) Packet and fragment re-ordering are two different issues and should be
> handled differently. Packet re-ordering is an issue that application needs
> to handle if the order is important to it like RTP stream. The IP
> fragmentation is an IP layer issue and should be dealt with at IP layer.
> There should some solution today at IP layer. Not sure this is
> particularly important to CAPWAP.
> 
> Do I miss anything?
> 
> Changming
> 
> -----Original Message-----
> From: Darren Loher [mailto:[email-masked]]
> Sent: Thursday, January 05, 2006 11:05 AM
> To: Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit
> Choudhury; [email-masked]
> Subject: RE: [Capwap] Question on LWAPP-03 draft
> 
> Thanks for the full explanation Puneet.  With fragmentation done at the
> application (CAPWAP/LWAPP) layer this means every frame must have a LWAPP
> header.
> 
> I agree that this is especially important to get right as Pat pointed out
> that tunneled data packets will commonly need to be fragmented.
> 
> I another reason it's important not to have a standard IP stack reassemble
> frames is due to possible packet/fragment reordering.  If the network were
> to reorder the CAPWAP/LWAPP UDP tunnel packets for any reason, it would
> result in corrupting the data frames inside the tunnel.  We need the
> FragID field of the LWAPP/CAPWAP header to help us there.
> 
> -Darren
> 
> > -----Original Message-----
> > From: Puneet Agarwal [mailto:[email-masked]]
> > Sent: Thursday, January 05, 2006 10:52 AM
> > To: Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury;
> > [email-masked]
> > Subject: RE: [Capwap] Question on LWAPP-03 draft
> >
> > Hi All,
> >
> > Just to remove any confusion, by application level fragmentation, I
> > mean the LWAPP level fragmentation (as LWAPP is the application from
> > the UDP/IP transport perspective). Hopefully this answers your question
> Sujoy.
> >
> > Hence the proposal is to fragment the wireless frame at the LWAPP
> > level (F, L, Frag-Id would be valid - even for UDP/IP transport)
> > before encapsulating the wireless frame in the transport (UDP/IP)
> > headers (just like it is proposed in the spec for L2 transport).
> >
> > So conceptually LWAPP/CAPWAP should be agnostic of transport and
> > assumes that the transport does not support fragmentation. This gets
> > rid of the middlebox problem (for IP fragments) and is architecturally
> clean too.
> >
> > Thanks.
> >
> > -Puneet
> >
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > Sent: Thursday, January 05, 2006 8:28 AM
> > To: sujay; Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;
> > [email-masked]
> > Subject: RE: [Capwap] Question on LWAPP-03 draft
> >
> > If we let IP handle fragmentation, then we do not have control over
> > adding LWAPP headers to it. It is true that having LWAPP perform
> > fragmentation, and add an independent header, would allow for any
> > middlebox (including
> > firewall) traversal. Given the likelihood of fragmentated frames is
> > certain (given we are tunneling MTU sized frames), I agree with
> > Puneet's recommendation.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: sujay [mailto:[email-masked]]
> > > Sent: Wednesday, January 04, 2006 10:45 PM
> > > To: 'Vishwas Manral'; 'Puneet Agarwal'; 'Abhijit Choudhury';
> > > [email-masked]
> > > Subject: RE: [Capwap] Question on LWAPP-03 draft
> > >
> > >
> > > Hi Vishwas,
> > >
> > > The F, L and Frag-id fields should be of use only for L2 transport.
> > >
> > > Fragmentation causes issues at the firewalls, essentially because
> > > the lwapp header is carried in the first fragment alone.
> > >
> > > If the MTU is pre-determined for IPv4/6, the application has to take
> > > care of re-assembly.
> > > There the F, L and Frag- id fields could be of use.
> > > Additionally a few more fields may be required !
> > >
> > > Puneet,
> > > IMO there is no advantage by pushing the fragmentation/ assembly to
> > > the application.
> > >
> > > If firewall is the issue, is it possible to add the lwapp header  in
> > > all fragments..??
> > >
> > > Regds,
> > > Sujay
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Vishwas Manral [mailto:[email-masked]]
> > > Sent: Thursday, January 05, 2006 10:09 AM
> > > To: Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;
> > > [email-masked]
> > > Subject: RE: [Capwap] Question on LWAPP-03 draft
> > >
> > >
> > > Hi Puneet,
> > >
> > > One small typo!! I had stated "I guess for IPv6 it is already stated
> > > that we do not do fragmentation at LWAPP level" I meant at
> > > "IPv6 level"
> > > I meant.
> > >
> > > Thanks,
> > > Vishwas
> > > -----Original Message-----
> > > From: Vishwas Manral [mailto:[email-masked]]
> > > Sent: Thursday, January 05, 2006 9:54 AM
> > > To: Puneet Agarwal; Abhijit Choudhury; [email-masked]
> > > Subject: RE: [Capwap] Question on LWAPP-03 draft
> > >
> > > Hi Puneet,
> > >
> > > I think you mean all middleboxes and not just firewalls.
> > >
> > > I guess for IPv6 it is already stated that we do not do
> > > fragmentation at LWAPP level because we have to do MTU discovery and
> > > hence fragments can be done at the application level itself. I think
> > > only if Path MTU discovery is done for IPv4 too, can we avoid
> fragmentation.
> > >
> > > Are you saying that the F, L and Fragment Id fields were only valid
> > > for
> > > Layer-2 transport and not for Layer-3 transport earlier?
> > >
> > > Thanks,
> > > Vishwas
> > > ________________________________________
> > > From: Puneet Agarwal [mailto:[email-masked]]
> > > Sent: Thursday, January 05, 2006 4:16 AM
> > > To: Abhijit Choudhury; [email-masked]
> > > Subject: RE: [Capwap] Question on LWAPP-03 draft
> > >
> > > The main issue is passing IP fragments via firewalls. Most firewalls
> > > drop fragmented packets (in fact the note is section 3.3.4 also
> > > refers to that). Hence the question.
> > >
> > > Hope this helps.
> > >
> > > Thanks.
> > >
> > > -Puneet
> > >
> > > ________________________________________
> > > From: Abhijit Choudhury [mailto:[email-masked]]
> > > Sent: Wednesday, January 04, 2006 11:42 AM
> > > To: Puneet Agarwal; [email-masked]
> > > Subject: RE: [Capwap] Question on LWAPP-03 draft For L3 transport,
> > > as the spec says, only the first IP fragment would have an LWAPP
> header.
> > > Standard IP reassembly is used to put the fragments together.  F, L,
> > > and FragID fields in the LWAPP header are not neeed for reassembly.
> > >
> > > Am I missing something ?
> > >
> > > Thanks,
> > >    Abhijit
> > > -----Original Message-----
> > > From: Puneet Agarwal [mailto:[email-masked]]
> > > Sent: Tuesday, January 03, 2006 7:57 PM
> > > To: [email-masked]; Pat Calhoun (pacalhou)
> > > Subject: [Capwap] Question on LWAPP-03 draft Question of IPv4
> > > frag/reassembly (Section 3.3.4):
> > >
> > > There was some talk in the past about performing the
> > > fragmentation/reassembly at the application level to avoid IP
> > > fragments.
> > > In that case, the F,L and FragID bits would need to be used even for
> > > L3 transport. Did we ever reach a consensus on this one?
> > >
> > > My recommendation would be to do the frag/reassembly at application
> > > level.
> > >
> > > Thanks.
> > >
> > > -Puneet
> > >
> > >
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > >
> > >
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > >
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > >
> >
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Raouf Eldeeb" <[email-masked]>
Date: Thu, 05 Jan 2006 17:43:29 -0800

It is probably an exaggeration to say that that firewalls are commonly 
set to drop all IP fragmented packets.
It is however common in the particular case of dealing with teardrop 
attacks.
These attacks break up the malevolent packet in tiny fragments that the 
content of the packet cannot be determined.
If the firewall does not have enough data to classify the first fragment 
of a packet then it will drop it (firewalls cannot assemble).

Raouf