Subject: [Capwap] Issue #4: Potential Middlebox Issues

From: Margaret Wasserman <[email-masked]>
Date: Wed, 18 Jul 2007 10:39:43 -0400

Magnus Westerlund raised the following questions regarding
CAPWAP and Middleboxes:

A question to the group is if anyone really thinks that there will be  
any
middleboxes (NATs or firewalls) in the path between the STA, WTP or  
AC. To me it
appears that it is more likely that these are located outside of this  
system but
I may be wrong.

Also this should not be an issue as long as the node on the inside  
initiate all
bi-directonal message sequences and the peer responds back to the  
source of the
messages. The real issue with middleboxes are usually when an  
external peer
opens a new packet flow towards the inside of an middlebox. If you  
don't have
these then there should be minimal concern.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Jul 2007 08:15:59 -0700

Yes, CAPWAP will have to operate in presence of middleboxes (e.g.,
NATs). It is for this purpose that both the control and the data UDP
session have a keepalive mechanism (Echo Request/Response and Data
Channel Keep Alive, respectively). Since the data channel is not a
reliable channel, there is no concept of a request/response. The
protocol specifies that the WTP initiates the keepalive, and when
received by the AC, it sends its own.

Note that the default timers specified in the document are to send the
keepalive packets every 30 seconds:

<text>
4.7.2.  DataChannelKeepAlive

   The DataChannelKeepAlive timer is used by the WTP to determine the
   next opportunity when it must transmit the Data Channel KeepAlive.

   Default: 30

4.7.6.  EchoInterval

   The minimum time, in seconds, between sending Echo Request messages
   to the AC with which the WTP has joined.

   Default: 30
</text>

You will note that both of these are scheduled to be sent every 30
seconds. The Echo Request is different because it is only sent if 30
seconds have expired on the control channel and no other messages were
exchanged. So in a busy control channel, the Echo Request would never be
sent. The data plane, however, differs because in most AC
implementations there is a decoupling between the actual forwarding,
generally done in hardware, and control plane. Therefore, it is simpler
for an implementation to simply send the keepalive when the timer
expires, as opposed to constantly looking at the forwarding plane to
determine when 30 seconds have expired.

I recognize that the 30 second default value is different from the 2
minute value that seems to have made its way into the UDP transport
guidelines I-D. I will note that the I-D also states that some
middleboxes do not observe the two minute recommendation, and I am
worried about interoperability issues with such middleboxes. My
implementation has used 30 seconds and so far we have not seen any
issues in the field, so I am personally reluctant to change this timer.

PatC

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 7:40 AM
To: capwap
Subject: [Capwap] Issue #4: Potential Middlebox Issues

Magnus Westerlund raised the following questions regarding CAPWAP and
Middleboxes:

A question to the group is if anyone really thinks that there will be
any middleboxes (NATs or firewalls) in the path between the STA, WTP or
AC. To me it appears that it is more likely that these are located
outside of this system but I may be wrong.

Also this should not be an issue as long as the node on the inside
initiate all bi-directonal message sequences and the peer responds back
to the source of the messages. The real issue with middleboxes are
usually when an external peer opens a new packet flow towards the inside
of an middlebox. If you don't have these then there should be minimal
concern.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap