Subject: [Capwap] Re: Capwap Digest, Vol 3, Issue 10

From: "Steel, Dirk" <[email-masked]>
Date: Mon, 16 Jan 2006 13:54:00 +0100

--------------------------
Sent to you using BlackBerry email on my Siemens SK65

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Mon Jan 16 12:17:36 2006
Subject: Capwap Digest, Vol 3, Issue 10

Send Capwap mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.frascone.com/mailman/listinfo/capwap
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Capwap digest..."

Today's Topics:

   1. RE: Question on LWAPP-03 draft (Pat Calhoun (pacalhou))

----------------------------------------------------------------------

Message: 1
Date: Sun, 15 Jan 2006 20:02:01 -0800
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: RE: [Capwap] Question on LWAPP-03 draft
To: "Sadot, Emek (Emek)" <[email-masked]>,	"Puneet Agarwal"
	<[email-masked]>,	"Changming Liu" <[email-masked]>,	"Darren
	Loher" <[email-masked]>,	"sujay" <[email-masked]>,
	"Vishwas Manral" <[email-masked]>,	"Abhijit Choudhury"
	<[email-masked]>, <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="iso-8859-1"

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
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Sadot, Emek (Emek) [mailto:[email-masked]] 
> 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]
> Subject: RE: [Capwap] Question on LWAPP-03 draft
> 
> 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
> 
> I'm aware of several of my customers using FWs to remote 
> sites with WTPs.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [Capwap] Question on LWAPP-03 draft
> > 
> > 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,
> > 
> > (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,
> > 
> > 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,
> > 
> > 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
> > 
> 

------------------------------

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

End of Capwap Digest, Vol 3, Issue 10
*************************************
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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