Subject: [Capwap] Question on LWAPP-03 draft

From: "Puneet Agarwal" <[email-masked]>
Date: Tue, 3 Jan 2006 19:57:14 -0800

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

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Wed, 4 Jan 2006 11:41:55 -0800

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

	 
	My recommendation would be to do the frag/reassembly at
application level.
	 
	Thanks.
	 
	-Puneet

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 4 Jan 2006 14:46:02 -0800

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

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

	 
	 
	Thanks.
	 
	-Puneet

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 4 Jan 2006 20:24:15 -0800

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

________________________________________
 
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
 
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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 5 Jan 2006 08:27:48 -0800

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

> From: sujay [mailto:[email-masked]] 
> Sent: Wednesday, January 04, 2006 10:45 PM
> To: 'Vishwas Manral'; 'Puneet Agarwal'; 'Abhijit Choudhury'; 
> [email-masked]
> 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
> 
> 
> 
> 
> 
> 
> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Thursday, January 05, 2006 10:09 AM
> To: Vishwas Manral; Puneet Agarwal; Abhijit Choudhury; 
> [email-masked]
> 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
> From: Vishwas Manral [mailto:[email-masked]] 
> Sent: Thursday, January 05, 2006 9:54 AM
> To: Puneet Agarwal; Abhijit Choudhury; [email-masked]
> 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
> 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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 5 Jan 2006 09:51:37 -0800

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

Pat Calhoun

> 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.
> 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
> 
> 
> 
> 
> 
> 
> 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 
> Are you saying that the F, L and Fragment Id fields were only valid 
> for
> 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
> Subject: [Capwap] Question on LWAPP-03 draft Question of IPv4 
> frag/reassembly (Section 3.3.4):
>  
> 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?
>

---

From: "Darren Loher" <[email-masked]>
Date: Thu, 5 Jan 2006 12:04:51 -0700

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

> Sent: Thursday, January 05, 2006 10:52 AM
> To: Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury;
> [email-masked]
> 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
> 
> 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

---

From: "Changming Liu" <[email-masked]>
Date: Thu, 5 Jan 2006 12:51:04 -0800

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

-Darren

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 5 Jan 2006 13:54:32 -0800

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

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

-Darren

> 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
> 
> 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
> certain (given we are tunneling MTU sized frames), I agree with 
> Puneet's recommendation.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit Cisco Systems
> 
> 
> 
> > Fragmentation causes issues at the firewalls, essentially because 
> > the lwapp header is carried in the first fragment alone.
> >
> > 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.
> >
> > drop fragmented packets (in fact the note is section 3.3.4 also 
> > refers to that). Hence the question.
> >
> > Hope this helps.
> >
> > Thanks.
> >
> > -Puneet
> >
> > 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.

---

From: "Darren Loher" <[email-masked]>
Date: Thu, 5 Jan 2006 17:07:05 -0700

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

> Sent: Thursday, January 05, 2006 2:55 PM
> To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay; Vishwas
> Manral; Abhijit Choudhury; [email-masked]
> 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).
> 
> To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas
> Manral; Abhijit Choudhury; [email-masked]
> 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
> 
> 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
>

---

From: "Changming Liu" <[email-masked]>
Date: Thu, 5 Jan 2006 16:49:58 -0800

Hi Puneet,

Thanks for your quick reply. One thing I am confused about is the definition of a tunnel vs. a UDP application. Traditionally running an application on UDP/IP then over some kind of layer 2 is not defined as a tunnel rather just a  normal UDP application. Otherwise, DNS, RTP, SIP or any application on top of UDP will become a tunnel instead of an application. So is CAPWAP an application of UDP or UDP/IP is tunnel to CAPWAP? As a application, it is usually does not deal with fragmentation issue because it deems it as IP layer issue. Otherwise, each application will have its own built-in fragmentation algorithm and this will defeat the purpose of having fragmentation functionality at IP layer. As a tunnel, a MTU may be optionally defined to avoid tunneled packet fragmentation. But my experience with IPsec tunnel tells me that sometimes the pre and post encapsulation are both needed to be supported at the same time unless the MTU of entire path of a tunnel is known.  The "transport tunnel" is a definitely interesting definition. Not sure where this fits in.

The reason I talked about the tunnel vs application is that your answer to the fragmentation requirement is different from Pat's. His answer is about the middle box. Having worked on the firewall business for several years, I have hardly come across any middle box (firewall) to be configured to drop the fragmented IP packets. The customers or end users will screen at the IT if they chose to do that :-) Who knows how many layers of encap a packet will be subjected to after many layers of tunneling? Just for an example, IP over GRE over IPsec.... Whatever running on the inner IP may be encapsulated with its own layers of tunnels.... As having been pointed out, the fragmentation is not avoidable in today's networks, simply dropping it is usually not an option at all for any serious and real deployment. This may be true for some old stateless packet filtering firewalls. Not sure how many really still be deployed there.

Changming

-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 1: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,

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

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

-Darren

---

From: "Changming Liu" <[email-masked]>
Date: Thu, 5 Jan 2006 21:03:13 -0800

Teardrop is a special attack by overlaying the fragment offset to cause
the server reassembling buffer overflow. Thus this attack has its
"signature" and only fragments match its signature will be dropped
instead dropping all fragments blindly by the firewall.

There are other fragmentation attacks and stateful firewalls are usually
designed to be a little smarter to prevent such attacks other than just
simply dropping all the fragmented packets by keeping some states of the
fragments.  

Because this is not a firewall related working group, without getting
into more specific issues of fragment attack prevention techniques,
getting around the middle box may not be strong enough reason, if this
is the only one, why the fragmentation should be supported by the
CAPWAP. 

The real problem facing CAPWAP/LWAPP when dealing with the firewall
traversal is the " 6.2.4  WTP Manager Data IPv4 Address " option. To
support this option, an ALG on the firewall/NAT device is required
pretty much like FTP control/data case or SIP/RTP case. W/o it, this
option won't work. Are there any alternative proposals to this?

Changming
  
-----Original Message-----
From: Raouf Eldeeb [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 5:43 PM
To: Changming Liu
Cc: [email-masked]
Subject: Re: [Capwap] Question on LWAPP-03 draft

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

Changming Liu wrote:

>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.

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 9 Jan 2006 14:29:24 -0800

Hi Changming,

(a) For CAPWAP data frames (C=0), you are "tunneling" wireless client frames inside the CAPWAP hdr (between the AC and WTP). Hence from the perspective of the wireless client frames - they are tunneled inside a CAPWAP/UDP/IP between WTP<-->AC. This CAPWAP/UDP/IP could be called the "transport tunnel" from the perspective of the wireless client frames.

>From the perspective of UDP, the UDP port numbers generally defines the application (in this case CAPWAP). Hence from the perspective of UDP, CAPWAP is an application.

So tunnel and UDP application are not mutually exclusive (it is a question of which layer's perspective one is talking about).

(b) I took Pat's comments to agree with my statements. Both he and I seem to be talking about fragmenting at the CAPWAP level before attaching a UDP/IP header. Maybe Pat can elaborate more on this.

Thanks.

-Puneet 

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

Hi Puneet,

Changming

-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]]
Sent: Thursday, January 05, 2006 1: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,

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

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

-Darren

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 13 Jan 2006 11:54:24 -0500

A question about former tunneling protocols architectures (just out of my ignorance): what is the landscape and motivations of other tunneling protocol that adopted a fragmentation at application level solution?

Out of curiosity, would it be fair to assume that most of the CAPWAP installations would be confined by a localized mobility domain were intermediate firewall is not likely to reside?

Regards,
Emek

-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Monday, January 09, 2006 5:29 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,

Thanks.

-Puneet 

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

Hi Puneet,

Changming

-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]]
Sent: Thursday, January 05, 2006 1: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,

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

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

-Darren

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 13 Jan 2006 10:43:53 -0800

I'm aware of several of my customers using FWs to remote sites with WTPs.

Pat Calhoun

> From: Sadot, Emek (Emek) [mailto:[email-masked]] 
> Sent: Friday, January 13, 2006 8:54 AM
> To: Puneet Agarwal; Changming Liu; Darren Loher; Pat Calhoun 
> (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury; 
> [email-masked]
> A question about former tunneling protocols architectures 
> (just out of my ignorance): what is the landscape and 
> motivations of other tunneling protocol that adopted a 
> fragmentation at application level solution?
> 
> Out of curiosity, would it be fair to assume that most of the 
> CAPWAP installations would be confined by a localized 
> mobility domain were intermediate firewall is not likely to reside?
> 
> Regards,
> Emek
> 
> To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); 
> sujay; Vishwas Manral; Abhijit Choudhury; [email-masked]
> (a) For CAPWAP data frames (C=0), you are "tunneling" 
> wireless client frames inside the CAPWAP hdr (between the AC 
> and WTP). Hence from the perspective of the wireless client 
> frames - they are tunneled inside a CAPWAP/UDP/IP between 
> WTP<-->AC. This CAPWAP/UDP/IP could be called the "transport 
> tunnel" from the perspective of the wireless client frames.
> 
> >From the perspective of UDP, the UDP port numbers generally 
> defines the application (in this case CAPWAP). Hence from the 
> perspective of UDP, CAPWAP is an application.
> 
> So tunnel and UDP application are not mutually exclusive (it 
> is a question of which layer's perspective one is talking about).
> 
> (b) I took Pat's comments to agree with my statements. Both 
> he and I seem to be talking about fragmenting at the CAPWAP 
> level before attaching a UDP/IP header. Maybe Pat can 
> elaborate more on this.
> 
> Thanks.
> 
> -Puneet 
> 
> To: Puneet Agarwal; Darren Loher; Pat Calhoun (pacalhou); 
> sujay; Vishwas Manral; Abhijit Choudhury; [email-masked]
> Thanks for your quick reply. One thing I am confused about is 
> the definition of a tunnel vs. a UDP application. 
> Traditionally running an application on UDP/IP then over some 
> kind of layer 2 is not defined as a tunnel rather just a  
> normal UDP application. Otherwise, DNS, RTP, SIP or any 
> application on top of UDP will become a tunnel instead of an 
> application. So is CAPWAP an application of UDP or UDP/IP is 
> tunnel to CAPWAP? As a application, it is usually does not 
> deal with fragmentation issue because it deems it as IP layer 
> issue. Otherwise, each application will have its own built-in 
> fragmentation algorithm and this will defeat the purpose of 
> having fragmentation functionality at IP layer. As a tunnel, 
> a MTU may be optionally defined to avoid tunneled packet 
> fragmentation. But my experience with IPsec tunnel tells me 
> that sometimes the pre and post encapsulation are both needed 
> to be supported at the same time unless the MTU of entire 
> path of a tunnel is known.  The "transport tunnel" is a 
> definitely interesting definition. Not sure where this fits in.
> 
> The reason I talked about the tunnel vs application is that 
> your answer to the fragmentation requirement is different 
> from Pat's. His answer is about the middle box. Having worked 
> on the firewall business for several years, I have hardly 
> come across any middle box (firewall) to be configured to 
> drop the fragmented IP packets. The customers or end users 
> will screen at the IT if they chose to do that :-) Who knows 
> how many layers of encap a packet will be subjected to after 
> many layers of tunneling? Just for an example, IP over GRE 
> over IPsec.... Whatever running on the inner IP may be 
> encapsulated with its own layers of tunnels.... As having 
> been pointed out, the fragmentation is not avoidable in 
> today's networks, simply dropping it is usually not an option 
> at all for any serious and real deployment. This may be true 
> for some old stateless packet filtering firewalls. Not sure 
> how many really still be deployed there.
> 
> Changming
> 
> 
> To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); 
> sujay; Vishwas Manral; Abhijit Choudhury; [email-masked]
> 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).
> 
> To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); 
> sujay; Vishwas Manral; Abhijit Choudhury; [email-masked]
> 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 
> To: Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas 
> 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 
> application

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 13 Jan 2006 16:58:17 -0500

Using a firewall seems as a reasonable choice for a topology where the AC and WTP are in separate geographical sites. The immediate follow up question that came in mind would be: does your solution employ a fragmentation scheme at the application level or let the IP transport layer handle it?

Another point is the use of VPN gateway. I'd think that it's rational to assume that the remote WTP is probably the only topology in which firewall make sense, thus wouldn't the VPN gateway at both ends moot the issue?

Regards,
Emek

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

Pat Calhoun

> A question about former tunneling protocols architectures (just out of 
> my ignorance): what is the landscape and motivations of other 
> tunneling protocol that adopted a fragmentation at application level 
> solution?
> 
> Out of curiosity, would it be fair to assume that most of the CAPWAP 
> installations would be confined by a localized mobility domain were 
> intermediate firewall is not likely to reside?
> 
> Regards,
> Emek
> 
> To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay; 
> Vishwas Manral; Abhijit Choudhury; [email-masked]
> wireless client frames inside the CAPWAP hdr (between the AC and WTP). 
> Hence from the perspective of the wireless client frames - they are 
> tunneled inside a CAPWAP/UDP/IP between WTP<-->AC. This CAPWAP/UDP/IP 
> could be called the "transport tunnel" from the perspective of the 
> wireless client frames.
> 
> So tunnel and UDP application are not mutually exclusive (it is a 
> question of which layer's perspective one is talking about).
> 
> (b) I took Pat's comments to agree with my statements. Both he and I 
> seem to be talking about fragmenting at the CAPWAP level before 
> attaching a UDP/IP header. Maybe Pat can elaborate more on this.
> 
> Thanks.
> 
> -Puneet
> 
> To: Puneet Agarwal; Darren Loher; Pat Calhoun (pacalhou); sujay; 
> Vishwas Manral; Abhijit Choudhury; [email-masked]
> Thanks for your quick reply. One thing I am confused about is the 
> definition of a tunnel vs. a UDP application.
> Traditionally running an application on UDP/IP then over some kind of 
> layer 2 is not defined as a tunnel rather just a normal UDP 
> application. Otherwise, DNS, RTP, SIP or any application on top of UDP 
> will become a tunnel instead of an application. So is CAPWAP an 
> application of UDP or UDP/IP is tunnel to CAPWAP? As a application, it 
> is usually does not deal with fragmentation issue because it deems it 
> as IP layer issue. Otherwise, each application will have its own 
> built-in fragmentation algorithm and this will defeat the purpose of 
> having fragmentation functionality at IP layer. As a tunnel, a MTU may 
> be optionally defined to avoid tunneled packet fragmentation. But my 
> experience with IPsec tunnel tells me that sometimes the pre and post 
> encapsulation are both needed to be supported at the same time unless 
> the MTU of entire path of a tunnel is known.  The "transport tunnel" 
> is a definitely interesting definition. Not sure where this fits in.
> 
> The reason I talked about the tunnel vs application is that your 
> answer to the fragmentation requirement is different from Pat's. His 
> answer is about the middle box. Having worked on the firewall business 
> for several years, I have hardly come across any middle box (firewall) 
> to be configured to drop the fragmented IP packets. The customers or 
> end users will screen at the IT if they chose to do that :-) Who knows 
> how many layers of encap a packet will be subjected to after many 
> layers of tunneling? Just for an example, IP over GRE over IPsec.... 
> Whatever running on the inner IP may be encapsulated with its own 
> layers of tunnels.... As having been pointed out, the fragmentation is 
> not avoidable in today's networks, simply dropping it is usually not 
> an option at all for any serious and real deployment. This may be true 
> for some old stateless packet filtering firewalls. Not sure how many 
> really still be deployed there.
> 
> Changming
> 
> 
> To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay; 
> Vishwas Manral; Abhijit Choudhury; [email-masked]
> 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:
> 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).
> 
> To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); sujay; 
> Vishwas Manral; Abhijit Choudhury; [email-masked]
> 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
> 
> 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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 15 Jan 2006 20:02:01 -0800

The LWAPP protocol does allow for the packets to be fragmented at the application layer, and yes, we have found this to be more transparent to any middlebox (FW or not) system, that would otherwise have store any fragments and reassemble in order to determine whether they comply to a corporate policy. Yes, you are correct that the simple inclusion of a site-to-site IPSec tunnel would resolve this problem, but we are unfortunately not always in a position to require that customers change their network deployments (hence cost) in order to deploy WLANs.

Pat Calhoun

> Sent: Friday, January 13, 2006 1:58 PM
> To: Pat Calhoun (pacalhou); Puneet Agarwal; Changming Liu; 
> Darren Loher; sujay; Vishwas Manral; Abhijit Choudhury; 
> [email-masked]
> Using a firewall seems as a reasonable choice for a topology 
> where the AC and WTP are in separate geographical sites. The 
> immediate follow up question that came in mind would be: does 
> your solution employ a fragmentation scheme at the 
> application level or let the IP transport layer handle it?
> 
> Another point is the use of VPN gateway. I'd think that it's 
> rational to assume that the remote WTP is probably the only 
> topology in which firewall make sense, thus wouldn't the VPN 
> gateway at both ends moot the issue?
> 
> Regards,
> Emek
> 
> To: Sadot, Emek (Emek); Puneet Agarwal; Changming Liu; Darren 
> Loher; sujay; Vishwas Manral; Abhijit Choudhury; [email-masked]
> (just out of 
> he and I 
> > 2) Packet/fragment reordering is not really an issue for 
> CAPWAP (and I 
> > agree with you).
> > 
> > Thanks.
> > 
> > -Puneet
> > 
> does not) 
> and should