Subject: [Capwap] Distingushing Protected and Unprotected Control messages

From: "David T. Perkins" <[email-masked]>
Date: Sun, 23 Jul 2006 19:11:33 -0700 (PDT)

HI,

At the CAPWAP WG session during the IETF meeting there were
short presentations by Pat and Scott concerning the "MUX
Header". I also quickly presented 2 slides. Below is the contents
of the slides with a small bit of elaboration. 

>From my perspective, I view the "MUX header issue" as simply
how to distingush between protected and unprotected CAPWAP
control messages in UDP packets. Note, if I have totally overlooked
a solution (which could be based on some reasonable constraint),
please let me know. 

Determining if a CAPWAP Control Message is Protected or Unprotected
-------------------------------------------------------------------

Background
----------
1) Both CAPWAP protected and unprotected messages are sent over UDP
2) Protected messages are sent encapsulated within a DTLS message
   that is the content of a single UDP packet
3) A DTLS message has a DTLS header, followed by the original
   message (which may be encrypted, and possibly compressed),
   and followed by DTLS trailer
4) A DTLS session must be established before DTLS can be
   used to encapsulate CAPWAP control messages
5) Presently, there are 4 message types that are unprotected
   (with are discovery request/response & primary discovery
   request/response)
6) There may be additional unprotected message types when 
   CAPWAP is expanded  to cover AC-AC communication in follow-on work
7) It may not be possible to always determine if a received message
   is an unprotected or protected message by looking at
   the first few octets of a UDP packet's content

Problem
-------
How to determine if a CAPWAP control message is protected or
unprotected?

Possible Solutions
------------------
1) Prefix CAPWAP messages with a header that indicates if the
   rest of the message is protected or unprotected (this is
   what has been called the MUX header)
2) Use different UDP ports (that is, use one well known UDP port
   to receive unprotected messages and another for protected
   messages)
3) Do a TLS (and thus, DTLS) hack to send unprotected content
   that is not in a session. That is, both protected and unprotected
   CAPWAP messages would be wrapped by the DTLS header and
   trailer, but "unprotected" messages would use a "fake"
   DTLS session identifier and would have no integrity
   check or encryption
4) When receiving a UDP packet, check if there is already
   a DTLS session established based on source IP:UPDport, and if
   so, then assume DTLS encapsulation (that is, a protected message).
   Otherwise assume the there is no DTLS encapsulation
   (that is, an unprotected message). However, this does
   not work because the message to start a DTLS session
   has a DTLS header! Also, when a session is established
   and a WTP resets and sends out unprotected Discovery
   messages, the AC must timeout the existing DTLS session
   (and terminate it) before it can respond to the Discovery
   message. Note, it must also timeout any existing session
   before starting a new DTLS session if it examines only
   the source IP:UDPport from WTP UDP packets.
5) When receiving a UDP packet from a WTP, the AC uses the source
   UDP port to determine if the CAPWAP message is protected or
   unprotected. However, this does not work due to NAT
   boxes that change the source UDP port!

Suggested Solution
------------------
Both a using a "MUX header" and 2 well known UDP ports on
the AC are technically workable and easy to implement.
To me, they both appear to have the same cost to write
code and have the same execution CPU and memory costs.
However, due to the emotional response attached to the
MUX header approach, my first choice is to use 2 well
known UDP ports on an AC.

Regards,
/david t. perkins

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

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