Issue #138

CAPWAP WG Meeting

IETF 68, Prague

Issue 138#138: Support and Negotiation of WTP data encryption in the

CAPWAP protocol

• Proposed solution to require WTP encryption at both AC & WTP.– Issue evolved to require WTP to support 802.11 encryption and

allow the AC to choose centralized encryption. (MAY vs MUST)

• Discusssion/Presentation at Interim Meeting, show of hands did not set consensus– Once we have meeting consensus, then WG list check is

needed.– Consensus Call on 2/23/07. Ended on March 1st w/o consensus– Consensus check on WG list did not have enough participation,

less than 2 weeks in order to meet IETF draft deadlines

Issue #138

• Originally included several sub-issues• Only remaining issue is interoperability for two

802.11 encryption modes in Split MAC mode– Encryption/decryption performed on the WTP– Encryption/decryption performed on the AC

• For interoperability, we have two choices:– State that at least one mode is mandatory to

implement on both ends (all ACs and WTPs must support that mode)

– State that both modes are mandatory to implement on one end (both modes may be optional on the other)

Issue #138 History

• Our document has historically stated that both modes are optional– Not sufficient to ensure interoperability– Do we need to state a mandatory mode, given that

Split MAC operation is already optional?

• At the interim meeting, we narrowed the choices to two options, but there was no consenus on which to choose– Support for encryption/decryption at the WTP is

mandatory at both ends, enc/dec at the AC is optional– Support for both modes is required in all WTPs, both

are optional in the ACs

Issue #138 Discussion Points

• In favor of requiring WTP to support both modes– Both modes will be widely available, each with benefits in

different situations– Centralized encryption mode has desirable security properties

(centralized control of keys, etc.)

• In favor of making WTP encrypt/decrypt mandatory and AC decrypt/encrypt optional– Simplifies minimal implementation (only one mandatory mode on

each end)– We know that this mode is supported by all WTP and AC

hardware solutions (and 802.11 chipsets)– This mode is compatible with current and future 802.11 features

(in 802.11e and 802.11n)

Reviewing the options

WTP AC

Encryption at AC MUST MAY

Encryption at WTP

MUST MAY

WTP AC

Encryption at AC MAY MAY

Encryption at WTP

MUST MUST

Option 1 Option 2

Option 1: ACs MAY support encryption either in AC or WTP. WTPs MUST support both encryption in WTP or AC.

Option 2: All ACs and WTPs MUST support encryption at WTP, and MAY support encyption at AC

Issue 138 Consensus CallConsensus Call on 2/23/07. Ended on March 1st w/o consensus.

1)  To provide system component interoperability, the WTP MUST support 802.11 encryption/decryption at the WTP, and the WTP MUST support 802.11 encryption/decryption at the AC.   The AC MUST support either 802.11 encryption/decryption at the WTP or 802.11 encryption/decryption at the AC.

The AC MAY support both 802.11 encryption/decryption at the WTP and 802.11 encryption/decryption at the AC.

 -OR- 2)  To provide system component interoperability, the WTP and AC MUST support

802.11 encryption/decryption at the WTP.  The WTP and AC MAY support 802.11 encryption/decryption at the AC. 

 Note the 2 proposals differ with support of 802.11 encryption/decryption at the AC. As there has been no objections to the optional use of DTLS in the Data Plane, this

portion of issue 138 is closed. 

Issue #138 Decision

• WG needs to reach a decision on this issue for the document to advance– Very few people have voiced an opinion– What do the rest of you think?