Last Call Review of draft-ietf-opsawg-capwap-hybridmac-06
review-ietf-opsawg-capwap-hybridmac-06-secdir-lc-meadows-2014-12-04-00

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.

I believe that this document is ready, with minor issues in the Security
Considerations Section.

This ID concerns the correction of an ambiguity in the CAPWAP protocol.  That
protocol supports two Medium Access Control (MAC) modes with respect to

two entities: a Wireless Transmission Point (WTP) and an Access Controller
(AC).  In one of the modes, split mode, encryption functionality can be located
at either

the WTP or the AC, but no clear way is given of having the AC inform the WTP of
where the encryption functionality should be located.  This ID presents a means
by which

the WTP informs the AC of the various MAC profiles it supports, and then the AC
determines the appropriate profile and configures the WTP with the profile
while configuring

the WLAN.

The Security Considerations Section says that this document does not introduce
any new security risks compared to RFC5416, and that the security considerations

described in RFC5416 apply here as well.  I believe that a document that
addresses the placement of encryption functionality should say something more,
in particular

*why* it introduces no new security risks.  In the case of negotiation, the
main security risk is that an attacker could interfere with the negotiation so
that a less secure

alternative is chosen even when a more secure one is available.  In the
security considerations section of RFC5416 it is noted that there is a
possibility of a

replay attack if encryption resides at the WTP.  The risk is slight, and the
only way of closing the security gap is expensive, so the authors of RFC5416
decide to let

the risk stand.  However, this presents a conceivable attack in which an
attacker could cause an AC to believe that a WTP only supports   encryption
functionality at the WTP,

and the AC would choose the less secure mode.  Although the risk this
introduces is also slight, I believe that this should be mentioned. Also, would
I be correct in assuming

that a WTP that supports encryption at the WTP but not at the AC is unlikely?
If that is so, it might be possible to close the security gap by having the ATP
reject advertisements (request

a retransmit?) that only support encryption at the WTP, and if so you should
mention that too.

Nits:

The word “clearly” is repeated in line 7 of the abstract.

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