Subject: [Capwap] AD review of draft-ietf-capwap-threat-analysis-01

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jun 2008 14:15:52 +0200

Please find below the AD Review of draft-ietf-capwap-threat-analysis-01.
I believe that the document is mature and stable. I found a small number
of issues which are grouped in Technical and Editorial. As none of them
has a dramatic impact or would require very consistent editing I suggest
to consider these comments as Last Call comments, and proceed directly
to IETF Last Call with this document. 

T1. Did the editors and the Working Group consider capitalizing
RECOMMENDED and NOT RECOMMENDED as per RFC2119 when dealing with the
recommended or not recommended practices described in Sections 4.2 and
4.3? If they did I would be interested to hear why they chose not to use
capitalization. 

T2. Section 8 - I am missing from the list of vulnerabilities introduced
by CAPWAP the vulnerabilities introduced by the CAPWAP MIB (or other)
management interface. By exposing management objects related to the
CAPWAP protocol the management interface exposes information otherwise
not accessible to managers of 'fat' APs that a CAPWAP deployment
replaces. 

E1. [80211I], [80211SEC] and [8021X] are fundamental for the
understanding of this document. I suggest that they are moved to
Normative References. 

E2. It would be appropriate to include a note drawing the attention to
the fact that this document is based on the 2004 edition of the IEEE
802.1X standard, and that a new version of the protocol is under
development in IEEE 802.1X at the time of the development of this
document. 

E3. Please be explicit in the Abstract section about the fact that the
scope of the document is CAPWAP deployments that will use the IEEE
802.11 binding

Regards,

Dan

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Sun, 29 Jun 2008 12:35:36 -0600

The following is the response from myself (as well as portions from
Scott Kelly); neither of the editors are reachable - except Scott
briefly.

Being the WG's document, others in the list also should also be able to
respond to this.

The editors will, as they get to see this, respond soon. (Scott may this
coming week).

Regards,
-mani
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 5:16 AM
To: [email-masked]
Subject: [Capwap] AD review of draft-ietf-capwap-threat-analysis-01

[Mani, Mahalingam (Mani)] we did not consider capitalizing then. The
expectation on this draft was this to be a descriptive analysis of what
would have become too large a Security Considerations section for the
(base and binding) protocols. The prescriptive notations, it is
expected, in the summarized (Security Considerations) sections of the
protocol drafts (and, I believe, they are).

[Mani, Mahalingam (Mani)] Scott's comments: " With respect to snmp, as
you note, this is new work. We did not address capwap device (i.e. AC)
management interfaces, because these are outside the scope of capwap --
that is, capwap manages APs, but it is not used to manage ACs. It seems
reasonable to assume that this is out of scope for a capwap threat
analysis SNMP does change this a bit, but only if we allow AP
management/monitoring, in which case it becomes a parallel (albeit less
capable) management channel."

[Mani, Mahalingam (Mani)]  this should not be an issue. Can this be done
in AUTH48 or RFC-Ed stage?

E2. It would be appropriate to include a note drawing the attention to
the fact that this document is based on the 2004 edition of the IEEE
802.1X standard, and that a new version of the protocol is under
development in IEEE 802.1X at the time of the development of this
document. 
[Mani, Mahalingam (Mani)] 
[Mani, Mahalingam (Mani)] the reference clearly notes 2004 version. By
the time the revised 802.1X in progress emerges, it will carry 2008 or
2009 (more likely). Hopefully, this RFC will carry 2008 timestamp -
enough to make the distinction.
Is this light informational change introducible in AUTH48 or without
another spin of the draft?

[Mani, Mahalingam (Mani)] agreed - though the base protocol related
analysis is commonly applicable.

Regards,

Dan