Capwap Mailing List: Re: Last call comments for capwap-protocol-binding-ieee80211-07

[Pat Calhoun (pacalhou) (pcalhoun]

> > > 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.
> 
> IEEE 802.11 spec talks about the possibility that the higher layer
protocol (run on top of 802?) would require in-order delivery (IP
doesn't, of course), and seems to be able to provide strict in-order
delivery.
> 
> It might be at least good to discuss this topic in the spec
(describing that CAPWAP might not be able to provide fully faithful
> 802.11 implementation in Split MAC mode, but that this doesn't matter
for most practical purposes when you're running TCP/IP).

Fair enough, I am proposing adding the following paragraph to section
2.2.1:

<new text>
   Note that when the WTP tunnels data packets to the AC (and vice
   versa), the CAPWAP protocol does not guarantee in-order delivery.
   When the protocol being transported over IEEE 802.11 is IP, out of
   order delivery is not an issue as IP has no such requirements.
   However, implementors need to be aware of this protocol
   characteristic before deciding to use CAPWAP.
</new text>


> > > 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 ;-)
> 
> I wasn't thinking about ad-hoc mode, but rather a STA sending a packet
to an AP where the 802.3 source address would be different from the
transmitting STA address.  Is this possible? (Perhaps a "wireless
Ethernet bridge", which connects to PC via wired Ethernet, but looks
like STA to the AP? Although I'm not quite sure how the address fields
really look in this situation...)

Yes, you are correct that bridges work this way, but this is not a use
case we are trying to address in this working group. An access point
uses the IEEE 802.11 primitives for populating its learning table (e.g.,
association request), while a bridge needs to use other means (e.g.,
spanning tree). Trying to add wireless bridges to this specification
would not only expand the scope of the WG and protocol, but would
require lots more work.

 
> > > 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.
> 
> This is contradicted by text in e.g. Section 6.15, which requires the
WTP to process (beyond copying to beacons) the IE received from AC even
in Split MAC mode.

OK, fair enough. That is one exception, but that one is described in the
spec. The spec even includes:

<current text>
2.2.1.  Split MAC
[...]

   o  The WTP generates the IEEE 802.11 Beacon frames, using information
      provided to it through the IEEE 802.11 Add WLAN (see Section 6.1)
      message element, including the RSNIE, which indicates support of
      802.1X and AES-CCMP.
</current text>

>
> Also, it seems that some of the IEs sent are not even included in
beacons; e.g. Section 6.1 says the AC MUST send the Power Capability IE
to the WTP -- but reading 802.11, I can't seem to find any place the AP
would actually send this IE (it's sent by the STA). So what does the WTP
do with it?

OK, that should have been Power Constraint, not Power Capability. Thanks
for finding that one.

> 
> > 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.
> 
> Right, 802.11-2007 specifies how the WTP processes IEs received from
the STA. But it doesn't specify how to process IEs received from AC
(obviously, since the concept of AC doesn't exist).

Actually, re-reading the spec, I don't see where it dictates that the
WTP needs to process IEs. It does mention that the WTP needs to look at
the Result-Code in the (re-)Association Response. It also does mention
that the AC MAY send a Disassocation Request to the station, through the
WTP, and that the WTP should take the Disassocation Request as an
indication that service for the station is to be terminated.

Otherwise, there are no IE processing requirements.


> > > 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.
> 
> In that case, the "key the WTP is to use when encrypting traffic
to/from the station" is a bit confusing -- that would only the TK.

Well, you are ignoring the next sentence here. However, I can add a
little clarification to the next sentence. The thing is, when WEP is
used, then the contents are the actual WEP key, so we can't get into PTK
discussions in that sentence. So I am proposing the following:

<new text>
   Key:   The key the WTP is to use when encrypting traffic to/from the
      station.  For dynamically created keys, such as those used with
      WPA and RSN, this is commonly known as a Pairwise Transient Key
      (PTK).  For static keys, such as those used in WEP, the Key field
      contains the actual encryption key.
</new text>

> > > 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.
> 
> The document certainly gives the impression of supporting 802.11n,
since it's e.g. listed in WTP Radio Information message element.
> If that's not the case, it'd be useful to say explicitly that more is
needed for 11r and 11n.

Fair point, so I will add the following paragraph to the end of the
introduction section:

<new text>

   Note that this binding only supports the IEEE 802.11-2007
   specification.  New protocol specifications published outside of this
   document (e.g., IEEE 802.11n, IEEE 802.11r) are therefore not
   supported through this binding, and must be addressed either through
   a separate CAPWAP binding, or an update to this binding.
</new text>