Re: need clarification on UDP ports
From: NKA NKA (nka.capwapgmail.com)
Date: Tue, 17 Oct 2006 13:00:08 -0700 (PDT)
________________________________
From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com]
Sent: Tue 10/17/2006 10:37 PM
To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro
Cc: capwap [at] frascone.com
Subject: [Capwap] 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 ?

[NKA} As per my understanding, you don't need to have two seperate UDP ports for handling DTLS and Non-DTLS control packets. Following is the logic which I would use at AC:

 1. If AC receives a UDP packet on its control port, and if it CAN'T
find the session
 information corresponding to the sender WTP, then the arrived packet can
 be considered to be a discovery packet.

 In the above situation, for some reason, if WTP sent a DTLS packet, AC can
 continue to assume it to be a discovery packet. So it should feed the arrived
 DTLS packet to its discovery packet processing module. Ultimately the
 packet will get dropped by AC due to packet parsing error (chances of DTLS
 packet looking like a valid discovery packet is very very slim).
After a few trial,
 WTP will reboot and ultimately get in sync with AC's State machine.


2. If AC receives a UDP packet on its control port, and if it CAN find the session information corresponding to the sender, then the arrived packet can be considered as a DTLS packet. So AC should feed such packets to DTLS module directly.

 You may have a situation in which session information exists for a WTP at AC,
 but WTP is sending non-DTLS packet. Even in such situation, AC can feed such
 packets to DTLS module, which will ultimately reject the packet. AC can use
 this kind of notification to tear down the existing session, which
will bring AC's
 state machine in sync with that of WTP.

I have not given much thought about the data path issue. May be the
initial policy
(about dtls) exhcnage would help. Once both the party (AC as well as WTP) agree
whether DTLS will be used or not, the same information can be used for
programming the hardware. I know that issue # 221 is tracking data
path policy issue.

NKA


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

Results generated by Tiger Technologies using MHonArc.