Last Call Review of draft-ietf-opsawg-capwap-alt-tunnel-08
review-ietf-opsawg-capwap-alt-tunnel-08-secdir-lc-meadows-2016-10-20-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-opsawg-capwap-alt-tunnel-08-secdir-lc-meadows-2016-10-20

I have reviewed this document as part of the security directorate's 

ongoing effort to review all IETF documents being processed by the 

IESG.  These comments were written primarily for the benefit of the 

security area directors.  Document editors and WG chairs should treat 

these comments just like any other last call comments.

This draft describes an extension to the Control and Provisioning of Wireless Access Points (CAPWAP) protocol that encapsulates a station’s data frames between the Wireless Transition Point (ATP) and Access Controller (AC).  In some cases, it may be desirable to encapsulate data frames to an entity other than the AC (e.g. to an Access Router) or to use different

encapsulation models.  In particular, this would allow the WTP to tunnel non-management data frames to an endpoint different than the AC and to tunnel using different known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP.  A particular advantage of this approach that  encapsulating only the control plane to the AC, and thus separating management of the control plane from the management of the data plane, makes scaling easier and more efficient.

As far as I can tell, there do not seem to be any serious security issues with implementing this approach, especially since, as is noted in RFC [RFC5415], the data plane is already handled differently from the control plane, the control plane usually being protected by DTLS while the data plan is not. However, I think the Security Considerations Section needs to make a better case for this.

The text of the Security Considerations section is as follows:

This document introduces three new CAPWAP WTP message elements.

   These elements are transported within CAPWAP Control messages as the

   existing message elements.  Therefore, this document does not

   introduce any new security risks compared to [RFC5415] and [RFC5416].

   In CAPWAP, security for CAPWAP Data Channel is optional and security

   policy is determined by AC.  Similarly, the AC determines the

   security for the Alternate Tunnel between WTP and Alternate Tunnel

   Encapsulation Gateway.  The security considerations described in

   [RFC5415] and [RFC5416] apply here as well.

I find it hard to agree with the first three sentences. The document does more than simply introduce three new message elements.  It also

provides considerably more freedom in encapsulating data frames.  So it appears to me that what the Security Considerations section should concentrate on is the potential risk in providing this greater freedom. 

It’s also not clear to me what the purpose of the remaining part of the section, about the AC determining the policy.  Are you saying that, because the AC determines the policy in both CAPWAP and the CAPWAP extension, the security considerations for the first case also apply to the second case?  Some more discussion of why this is true, with references to the relevant risks discussed in [RFC5415] and [RFC5416], would be useful.  




Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil