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.
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.)
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.
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 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 ;-)
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.)
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
Minor clarifications/editorial nits:
Section 3: CAPWAP base protocol requires that all Request messages are
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"?
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"?
Given there will be spec changes, created issue 171.
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue171
PatC
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf