Subject: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07

From: <[email-masked]>
Date: Tue, 29 Jul 2008 12:48:06 +0300

I read capwap-protocol-binding-ieee80211-07 on my way to Dublin;
here are some comments/observations. 

Substantial topics first:

I was under the impression that 802 (or at least 802.11) required (or
assumed) strict in-order delivery -- but perhaps I remember this wrong?
(Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order
delivery, and it seems the data channel doesn't have mechanisms to
reorder or drop out-of-order packets.)

802.11 header has 4 different addresses, all of which can be
different.  When doing split MAC with 802.3 frames, the 802.3 frame
contains only two of the addresses; the "Radio MAC Address" field in
CAPWAP header contains the third -- but what about the fourth one?

The document should have some more text about how the WTP processes
IEEE 802.11 IEs it receives from the AC. Section 6.6 talks about
copying them to Beacon/Probe Response messages, but it seems that in
some cases, the WTP also does some local processing. (I was sort of
expecting a list of all IEs, and description of expected WTP
processing (possibly none) for them.)

Section 6.15: Is this really the PTK (which also includes KCK and KEK,
which aren't needed by the WTP since the AC is handling the EAPOL-Key
messages -- so probably shouldn't be sent to PTK), or only the TK used
for encrypting traffic?

Is the binding specified here sufficient for 802.11r as well, or would
something more be needed? (I don't know the answer -- but probably the
document should tell what it is)

Section 6.14 says that packets exceeding this priority are either
dropped or "down-tagged" -- but it seems which of these is done
depends on WTP (and the AC can't even know what the WTP does).  
Isn't this problematic for interoperability?

Question: Section 4 says the "Destination WLANs" field is used only
for multicast/broadcast; how is the destination WLAN determined for
unicast? (Is this by mapping destination MAC address to earlier IEEE
802.11 Station messages -- which means a single MAC address can't be
in more than one WLAN?) (Perhaps the document should have couple
of sentences about this)

Question: The WLAN ID is always shown as 8 bits, but it seems some
other parts limit the spec to 16 WLANs per WTP Radio. Could a WTP
supporting more than 16 WLANs use multiple Radio IDs, or is 16 a hard
limit? (Perhaps the document should have couple of sentences about
this -- at least saying that WLAN ID is between 0 and 15)

Minor clarifications/editorial nits:

Section 3: CAPWAP base protocol requires that all Request messages are
odd numbers, and Responses even; these aren't.

Section 3.1, "sent after the CAPWAP Configuration Update Request
message (..) has been received by the WTP" probably means "sent after
the CAPWAP Configuration Update Response message has been received by
the AC"?

Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station
QoS Profile"

Section 6.1 and 6.21: are some of these 802.11 information elements
optional, or are all of them always included?

Section 6.1 and 6.21: what do you put in "Key Status" if you're
not using encryption at all?

Section 6.21: to avoid repetition of text, I'd suggest simply
pointing to existing text in Section 6.1 for field descriptions.

Section 6.1 and 6.21: "32 byte Session Key" -- length depends
on "Key Length" field, right?

Section 6.2/10.6: is the "Combiner" a bit field or enumerated field?
(And in the former case, an explicit bit diagram would be very useful
to avoid confusion about bit numbering)

Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably
be shown as 3 bits in the diagram, to make it unambiguous about
which bits are not used.

Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would
benefit for some clarification -- does 802.11 really drop all
unencrypted EAPOL-Key frames if you have an encryption key? (it seems
that would cause difficulties when e.g. client reboots -- but I'm not
sure what 802.11 does here)

Section 6.15: "MUST NOT be sent if the WTP had not specifically
advertised support for the requested encryption scheme": would be
easier to understand if it said how the WTP advertises this
(presumably, the Encryption Capabilities field in the WTP Descriptor
Message Element?)

Sections 6.20 and 6.22: the DSCP Tag field should probably be shown 
as 6 bits in the diagram, to make it unambiguous how it's sent in
IPv4/IPv6 header (and which bits are unused).

Section 6.16, "maximum value of 65535" -- the fields are 32 bits,
so probably should be 4294967295?

Section 6.20 and 6.22: "if packets are to be DSCP tagged" would
benefit of clarifying what packets are meant (I guess it means
CAPWAP Data packets sent from the WTP to the AC?).

Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field?
(In the former case, an explicit bit diagram would be very useful
to avoid confusion about bit numbering.)

Section 6.23: "Country Code" field probably should be called "Country
String" (since it contains other things than the country code, and
it's called "country string" in 802.11), and it should be 3 octets
instead of 4.

Section 6.23: The description of third octet of Country field doesn't
quite match IEEE 802.11 (e.g. 'X' character is missing, and the '255'
entry is confusing).

Section 6.23: reference [ISO.3166.1984] should be to the latest
edition, not 1984 version:

   [ISO.3166-1] International Organization for Standardization, "Codes
                for the representation of names of countries and their
                subdivisions - Part 1: Country codes", ISO Standard
                3166-1:1997

Section 6.25: an explicit bit diagram would be useful for the "Radio
Type" field, since it's not clear whether e.g. "2" really means bit
number 2, or perhaps bit number 6 (rest of the text suggests it's the
latter).

Section 8.1: an explicit bit diagram would be useful (since bit
numbering has been somewhat inconsistent in various parts of the
spec).

Section 8.1: WEP is missing from the list?

Section 8.1: there probably should be IANA considerations text 
about how the remaining bits are allocated.

Section 10.2, "defines 27 new Message Types" -> "defines 25 new
Message Element Types"?

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 30 Jul 2008 16:06:24 -0700

Hi Pasi, 

Finally over your comments on the base protocol, and just getting around
to the binding spec. I will only create issues where needed, and
therefore indicated below. Otherwise I will simply address them in this
e-mail.
 
> (Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order
delivery, and it seems the data channel doesn't 
> have mechanisms to reorder or drop out-of-order packets.)
> 
different.  When doing split MAC with 802.3 frames, the 
> 802.3 frame contains only two of the addresses; the "Radio MAC
Address" field in CAPWAP header contains the third -- 
> but what about the fourth one?

> The document should have some more text about how the WTP processes
IEEE 802.11 IEs it receives from the AC. Section 
> 6.6 talks about copying them to Beacon/Probe Response messages, but it
seems that in some cases, the WTP also does some local processing. (I
was sort of expecting a list of all IEs, and description of expected WTP
processing (possibly none) for them.)

Section 6.14 says that packets exceeding this priority are either
dropped or "down-tagged" -- but it seems which of these is done depends
on WTP (and the AC can't even know what the WTP does).  
Isn't this problematic for interoperability?

Question: Section 4 says the "Destination WLANs" field is used only for
multicast/broadcast; how is the destination WLAN determined for unicast?
(Is this by mapping destination MAC address to earlier IEEE
802.11 Station messages -- which means a single MAC address can't be in
more than one WLAN?) (Perhaps the document should have couple of
sentences about this)

Question: The WLAN ID is always shown as 8 bits, but it seems some other
parts limit the spec to 16 WLANs per WTP Radio. Could a WTP supporting
more than 16 WLANs use multiple Radio IDs, or is 16 a hard limit?
(Perhaps the document should have couple of sentences about this -- at
least saying that WLAN ID is between 0 and 15)

Section 3.1, "sent after the CAPWAP Configuration Update Request message
(..) has been received by the WTP" probably means "sent after the CAPWAP
Configuration Update Response message has been received by the AC"?

Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS
Profile"

Section 6.1 and 6.21: what do you put in "Key Status" if you're not
using encryption at all?

Section 6.21: to avoid repetition of text, I'd suggest simply pointing
to existing text in Section 6.1 for field descriptions.

Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key
Length" field, right?

Section 6.2/10.6: is the "Combiner" a bit field or enumerated field?
(And in the former case, an explicit bit diagram would be very useful to
avoid confusion about bit numbering)

Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be
shown as 3 bits in the diagram, to make it unambiguous about which bits
are not used.

Section 6.15: "MUST NOT be sent if the WTP had not specifically
advertised support for the requested encryption scheme": would be easier
to understand if it said how the WTP advertises this (presumably, the
Encryption Capabilities field in the WTP Descriptor Message Element?)

Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as 6
bits in the diagram, to make it unambiguous how it's sent in
IPv4/IPv6 header (and which bits are unused).

Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so
probably should be 4294967295?

Section 6.20 and 6.22: "if packets are to be DSCP tagged" would benefit
of clarifying what packets are meant (I guess it means CAPWAP Data
packets sent from the WTP to the AC?).

Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field?
(In the former case, an explicit bit diagram would be very useful to
avoid confusion about bit numbering.)

Section 6.23: "Country Code" field probably should be called "Country
String" (since it contains other things than the country code, and it's
called "country string" in 802.11), and it should be 3 octets instead of
4.

Section 6.23: reference [ISO.3166.1984] should be to the latest edition,
not 1984 version:

Section 8.1: an explicit bit diagram would be useful (since bit
numbering has been somewhat inconsistent in various parts of the spec).

Section 8.1: there probably should be IANA considerations text about how
the remaining bits are allocated.

Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message
Element Types"?

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 30 Jul 2008 16:31:26 -0700

Hi Pasi, 

> reorder or drop out-of-order packets.)
The MAC layer will provide guaranteed delivery at the AP, but remember
that the air isn't exactly a reliable medium. The AP is then responsible
for tunneling the packets. For open or when crypto is provided at the
WTP, there are no issues with re-ordering. When crypto is provided at
the AC, both TKIP and AES have no ordering requirements, so that is also
not an issue.

> Address" field in CAPWAP header contains the third -- but what about
the fourth one?
The CAPWAP WG only supports 802.11-2007, and does not support ad-hoc
mode (client-client). The very fact that we are providing an alternative
way to deploy 802.11 infrastructure means that do not need to support ad
hoc mode ;-)

> was sort of expecting a list of all IEs, and description of expected 
> WTP processing (possibly none) for them.)
There are two mode of operation:
1. Split MAC. In this case, the WTP needs to make sure that the beacons
have the proper information. Other than that,the AC handles all of the
IEs in the manner described in the 802.11-2007 standard.
2. Local MAC. In this case, the 802.11 management packets are processed
in the WTP, as described 2.2.2. In this case, the WTP handles the IEs in
the manner described in the 802.11-2007 standard.

> Section 6.15: Is this really the PTK (which also includes KCK and KEK,
which aren't needed by the WTP since the AC is 
> handling the EAPOL-Key messages -- so probably shouldn't be sent to
PTK), or only the TK used for encrypting traffic?
We send the whole PTK. The WTP simply extracts what it needs and uses
it.

> Is the binding specified here sufficient for 802.11r as well, or would
something more be needed? (I don't know the 
> answer -- but probably the document should tell what it is)
Given we only support 802.11-2007, we do not worry about 802.11r at this
point (or 802.11n), so the answer is yes, more is needed.

> Section 6.14 says that packets exceeding this priority are either
dropped or "down-tagged" -- but it seems which of 
> these is done depends on WTP (and the AC can't even know what the WTP
does).  
> Isn't this problematic for interoperability?
Created issue 169.
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue169

> Question: Section 4 says the "Destination WLANs" field is used only
for multicast/broadcast; how is the destination 
> WLAN determined for unicast? (Is this by mapping destination MAC
address to earlier IEEE
> 802.11 Station messages -- which means a single MAC address can't be
in more than one WLAN?) (Perhaps the document 
> should have couple of sentences about this)
Well... Right. If the packet is destined for a specific host, then the
802.11 packet will include that info. The Destination WLAN is only for
multicast/broadcast traffic. Not sure what is missing.

> Question: The WLAN ID is always shown as 8 bits, but it seems some
other parts limit the spec to 16 WLANs per WTP 
> Radio. Could a WTP supporting more than 16 WLANs use multiple Radio
IDs, or is 16 a hard limit? (Perhaps the document 
> should have couple of sentences about this -- at least saying that
WLAN ID is between 0 and 15)
Created issue 170.
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue170
odd numbers, and Responses even; these aren't.
Yes, this was raised already and will be addressed in the next rev.

> Section 3.1, "sent after the CAPWAP Configuration Update Request
message (..) has been received by the WTP" probably 
> means "sent after the CAPWAP Configuration Update Response message has
been received by the AC"?
Profile"
using encryption at all?
> Section 6.21: to avoid repetition of text, I'd suggest simply pointing
to existing text in Section 6.1 for field 
> descriptions.
Length" field, right?
> Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be
shown as 3 bits in the diagram, to make it 
> unambiguous about which bits are not used.
> 
benefit for some clarification -- does 802.11 
> really drop all unencrypted EAPOL-Key frames if you have an encryption
key? (it seems that would cause difficulties 
> when e.g. client reboots -- but I'm not sure what 802.11 does here)
> 
advertised support for the requested encryption 
> scheme": would be easier to understand if it said how the WTP
advertises this (presumably, the Encryption Capabilities 
> field in the WTP Descriptor Message Element?)
> 
> Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as
6 bits in the diagram, to make it unambiguous 
> how it's sent in

> Section 6.20 and 6.22: "if packets are to be DSCP tagged" would
benefit of clarifying what packets are meant (I guess 
> it means CAPWAP Data packets sent from the WTP to the AC?).
> 
> Section 6.23: "Country Code" field probably should be called "Country
String" (since it contains other things than the 
> country code, and it's called "country string" in 802.11), and it
should be 3 octets instead of 4.
> Section 6.23: The description of third octet of Country field doesn't
quite match IEEE 802.11 (e.g. 'X' character is 
> missing, and the '255'
>                 subdivisions - Part 1: Country codes", ISO Standard
Type" field, since it's not clear whether e.g. 
> "2" really means bit number 2, or perhaps bit number 6 (rest of the
text suggests it's the latter).
> Section 8.1: an explicit bit diagram would be useful (since bit
numbering has been somewhat inconsistent in various 
> parts of the spec).
> Section 8.1: there probably should be IANA considerations text about
how the remaining bits are allocated.
> Section 10.2, "defines 27 new Message Types" -> "defines 25 new
Message Element Types"?
Given there will be spec changes, created issue 171.
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue171

PatC