80 likes | 215 Views
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.
E N D
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 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 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?