[secdir] Secdir review of draft-ietf-opsawg-capwap-alt-tunnel-08

[Catherine Meadows <[e-mail]>]

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: [phone]
fax: [phone]
email: [e-mail] <mailto:[e-mail]>