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 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 1 st 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 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 chipsets) –This mode is compatible with current and future features (in e and n)

Reviewing the options WTPAC Encryption at ACMUSTMAY Encryption at WTP MUSTMAY WTPAC Encryption at ACMAY Encryption at WTP 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 Call Consensus Call on 2/23/07. Ended on March 1 st w/o consensus. 1) To provide system component interoperability, the WTP MUST support encryption/decryption at the WTP, and the WTP MUST support encryption/decryption at the AC. The AC MUST support either encryption/decryption at the WTP or encryption/decryption at the AC. The AC MAY support both encryption/decryption at the WTP and encryption/decryption at the AC. -OR- 2) To provide system component interoperability, the WTP and AC MUST support encryption/decryption at the WTP. The WTP and AC MAY support encryption/decryption at the AC. Note the 2 proposals differ with support of 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?