Capwap Mailing List: Re: need clarification on UDP ports

[Pat Calhoun (pacalhou) (pcalhoun]

Abhijit, this issue was not addressed by the editors given that we were
waiting for the chairs to make a consensus determination, which occured
too close to the I-D deadline. That said, this would be a good time to
start the discussion.
 
My proposal would be as follows (this is conceptual, not actual draft
text). Note this proposal is optimized to utilize the fewest possible
ports, and assumes that IANA would not agree to a UDP port landgrab.
 
The AC maintains a DTLS SA table which consists of the WTP's IP address
and UDP port numbers. When the AC receives a Discovery Request on the
CAPWAP control port, it performs a lookup to determine whether the
IP/Port information matches the DTLS SA table. If the IP/Port does not
match an entry in the DTLS SA table, the AC responds with a Discovery
response and waits for a successful DTLS setup, which would create a new
DTLS SA. If there is a match, then the packet is a DTLS encrypted
payload, which is sent to the DTLS stack. The following is an example of
the packet exchange (note the ports used here are for illustration
purposes only):

WTP                                                       AC
(WTP Picks a pseudo-random source port)
----- CAPWAP Control/Discovery Request (662, 1233) ------> 
<---- CAPWAP Control/Discovery Response (1233, 662) ------

Using Scott's recommendation to look at the WBID, which when set to any
value other than 23 (which we will need to reserve), then we know this
packet is a discovery request, and process it accordingly. One
alternative to reserving a WBID would be to require that the Reserved
field in the CAPWAP header be set to '111', which would provide another
way to differentiate the packets.

--------- DTLS Session Setup/Control (662, 1233) -------->
<-------- DTLS Session Setup/Control (1233, 662) ---------

The WBID value of 23 will be an indication that the DTLS session is
being established (or the alternative proposed above)... at this point
all packets are from now on fed into the DTLS engine. Once the DTLS
session is established, all CAPWAP packets will be marked internally as
'Application Data', and once decrypted will be sent back into the CAPWAP
module for processing...

-------- CAPWAP Control/Join Request (662, 1233) ---------> (includes
support for DTLS/Data)
<------- CAPWAP Control/Join Response (1233, 662) --------- (Dictates
whether DTLS is to be used on data plane, and a random cookie)

When inactivity occurs over the control plane, the keepalive is sent to
keep the session alive (also useful for NAT traversal):

------- CAPWAP Control/Keepalive Request (662, 1233) ----->
<------ CAPWAP Control/Keepalive Response (1233, 662) -----

The following is optional, and occurs if DTLS needs to be used on the
data plane UDP port:

----------- DTLS Session Setup/Data (685, 1234) ---------->
<---------- DTLS Session Setup/Data (1234, 685) -----------

Again, the WBID of 23 is used to identify the DTLS packet. When used and
established, all CAPWAP data packets will be marked as 'Application
Data' within DTLS. So these packets would pop back out of the DTLS stack
for CAPWAP processing. Yes, this requires that the data plane remember
the configuration enforced by the AC, and therefore it does not mark
each packet as "with DTLS" or "without DTLS". We can do this, but
frankly it provides little value because ultimately, if DTLS was
required and a packet is sent in the clear, it will be dropped anyhow.
Furthermore, I trust an authenticated payload much more than a bit "in
the clear".

A specialized packet is then sent on the data plane to create the
correlation between the control and data plane sessions. A new bit in
the CAPWAP header, which I will call 'D' (for Data Management) is set so
this gets treated as a specialized packet on the data plane UDP port:

---------- CAPWAP Data/Announce Req (685, 1234) ----------> (Including
the cookie to bind to control channel)
<--------- CAPWAP Data/Announce resp (1234, 685) ----------

NOTE: Another alternative to this scheme is to include a session
identifier in the header, which provides the correlation between the
control and data channel. This would be much simpler to implement, and
not require special processing of the data plane. However, if folks
believe that keeping the NAT session fresh, then we need some mechanism
to keep the channel alive. If this is found to be desirable/required,
then a periodic exchange needs to occur to keep the NAT table entry
fresh (again, with the 'D' bit set):

------- CAPWAP Data/Keepalive Request (685, 1234) -------->
<------ CAPWAP Data/Keepalive Response (1234, 685) --------

Should the WTP fail, it would pick a new source UDP port for both the
control and data plane, and send a Discovery Request using the control
UDP port. It is important to note that the longevity of the uniqueness
characteristics of the UDP port is not very long (e.g., one day after
reboot). This is a new requirement on the WTP, but not unrealistic since
802.11 APs have to do this for the RADIUS protocol today (to maintain
unique session identifiers). The AC does not flush its current DTLS SA
until the DTLS exchange is complete (and successful).

WTP                                                       AC
(WTP picks a new pseudo-random source port)
----- CAPWAP Control/Discovery Request (772, 1233) ------> 
<---- CAPWAP Control/Discovery Response (1233, 772) ------

Using Scott's recommendation to look at the WBID, which when set to any
value other than 23 (which we will need to reserve), then we know this
packet is a discovery request, and process it accordingly.

--------- DTLS Session Setup/Control (772, 1233) -------->
<-------- DTLS Session Setup/Control (1233, 772) ---------

The WBID value of 23 will be an indication that the DTLS session is
being established... at this point all packets are from now on fed into
the DTLS engine.

If NAT is used, it is possible that the WTP's source IP address is used
for multiple WTPs. In this case, the AC can identify each WTP using the
DTLS credentials. The AC can then delete the old DTLS SAs (control and
optionally data), that are associated with the WTP's credentials.
Alternatively, the AC could simply wait for the sessions to expire.


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 


________________________________

        From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com] 
        Sent: Tuesday, October 17, 2006 10:08 AM
        To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro
        Cc: capwap [at] frascone.com
        Subject: need clarification on UDP ports
        
        
        Pat, Mike, Dorothy:
         
        I have a question based on v03 of the capwap spec.
        In section 3.1, the spec mentions well-known UDP
        ports for the CAPWAP control and data packets.
         
        There are four kinds of CAPWAP packets:
        1. DTLS protected control packets
        2. Unprotected control packets
        3. Unprotected data packets
        4. (Optional) DTLS protected data packets
         
        Will there be 4 well-known UDP port numbers ?
         
        1, 2 and 3 will be present simultaneously in any
        deployment. 3 and 4 may co-exist in a deployment
        if some data channels are encrypted and some not.
        There has to be a way to distinguish these four 
        kinds of packets.  The draft is not clear about how 
        this is done.
         
        Thanks,
           Abhijit