Capwap Mailing List: Re: NAT-T

[Darren (dplore]

Another way to explain this NAT issue is an AC cannot not know what
source IP or source UDP port a WTP's data channel may show up on if
the data port is separate from the control channel port.  It doesn't
matter if the AC told the WTP which port to use or if the WTP used a
well known port.  A NAT between AC and WTP can and will change this.

It is an issue of using a separate port for the data channel.  The
data channel is not protected in any way by DTLS.  If one wants to
protect the data channel, that can be handled outside of capwap.

Two possible fixes both sound "okay" to me.  It would be good to hear
from implementors on what they would prefer:

1. Pat points out that we can identify which WTP is sending traffic to
the AC by the BSSID carried in the (unprotected, unencrypted) data
packet.   The AC could also verify the STA MAC address is on the
authorized list as well.

2. A mux field could be added as Scott specifies.  This would be
similar to the layer 2 mux header from lwapp.


This did make me think of a different question though....  Can a
spoofed BSSID/STA data packets can make it through the AC?  Is this
something to be worried about?  Conceivably such packets would not
traverse a properly functioning WTP, but could be sent from other
hosts who would have to guess WTP BSSID's and possibly STA MAC if the
AC checked both.


-Darren


On 3/22/06, Scott G. Kelly <s.kelly [at] ix.netcom.com> wrote:
> Hi Abhijit,
>
> Comments inline below...
>
> -----Original Message-----
> >From: Abhijit Choudhury <Abhijit [at] sinett.com>
> >Sent: Mar 22, 2006 12:07 PM
> >To: "Scott G. Kelly" <scott [at] hyperthought.com>, capwap <capwap [at] 
> >frascone.com>
> >Subject: RE: [Capwap] NAT-T
> >
> >Scott,
> >
> >I am not sure I understand the issue you are raising.
> >How much of this has to do with the "optional" DTLS
> >protection of the data channel ? I think we need to
> >decide as a group whether DTLS protection of the data
> >channel is even needed before we go ahead and complicate
> >the state machine further.
>
> The issues exist no matter what. Data channel protection is not a factor in 
> this discussion. And I think this will simplify, not complicate, the state 
> machine implementation.
>
> >That said, a lot of applications use separate TCP or UDP ports
> >for control and data and they have no issue traversing
> >NAT. The control channel conveys the data port that
> >needs to be opened up, and this may require ALG intervention
> >to set up the data connection in the NAT box.
>
> I think this is a misconception. Sure, there are protocols with multiple 
> channels that eventually gained middlebox support, but it was not simple, and 
> it took a long time.  What you seem to be suggesting is that we rely on 
> middlebox vendors to implement CAPWAP ALGs. I think this is a very risky 
> strategy.
>
> Take a look at what IPsec went through for NAT-T.  The IPsec group explored 
> and rejected this approach. Let's not repeat their trials and tribulations. 
> They solved this problem by pushing both datagram channels over one UDP 
> session. It works, it's simpler than two ports, and we can do it today, 
> without requiring lobbying and  cooperation from middlebox vendors.
>
> >In CAPWAP, I'm not sure why the first
> >packet from the client has to initiate the data channel
> >setup. Clearly, a data channel will be needed, and the
> >UDP port can be identified during the control channel
> >setup process. So, when the first data packet shows up,
> >everything including the NAT session is already in place.
> >Applications like FTP do this on a command by command basis.
> >In the case of CAPWAP it's much much simpler; there is
> >one session that needs to be opened up in advance and
> >is long-lived.
>
> Applications like FTP run over TCP, and are so ubiquitous that firewall 
> vendors eventually came around to supporting them as part of the cost of 
> market admission. TCP sessions are stateful, and that makes deciding when to 
> tear down bindings straightforward for the middlebox. Not so for CAPWAP, on 
> either count - it's UDP, and while we might hope it will someday become 
> ubiquitous, it's not today. If we want to finish the spec in this decade, I 
> think we should focus on defining a solution that stands on its own, without 
> dependencies on yet to be formed working groups and vendor alliances.
>
> I don't understand the resistance. The mux header will make implementations 
> much simpler.
>
> Scott
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>