Capwap Mailing List: Re: Issue 171: Pasi nits on binding spec

[Pat Calhoun (pacalhou) (pcalhoun]

> > > Does this mean that e.g. all WTPs MUST support WMM? (since the AC 
> > > MUST always send the WMM information element) And MUST support WPA

> > > forever (in addition to RSN)?
> > 
> > Well... We are 2007, and I'm not sure how much we need to care about

> > hardware out there that is unable to support IEEE 802.11-2007. If 
> > there is ever a new IEEE standard for securing, then the list of IEs

> > would have to change, but that would be post IEEE 802.11-2007
anyhow. 
> > The CAPWAP specification could publish an updated set of rules of
what 
> > IEs need to be present.
> 
> I can't find any mention of "WMM Information Element" in IEEE
> 802.11-2007 -- I assumed it's some extension that not everyone
implements?

Yup - my bad. Now include a reference to the WMM web page on
www.wi-fi.org.

> 
> BTW, how are you planning to update these rules without breaking
backwards compatibility?

There are a couple of ways, but the most obvious one would be to have
the next binding use a new Wireless Binding Identifier (WBID).

> <snip>
> > Oh, I see. Well, that makes sense. Here is the new text:
> > 
> > <new text>
> > 6.20.  IEEE 802.11 Update Station QoS
> > [...]
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
> > 8 9 0 1 2
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |   Radio ID    |                  MAC Address
|
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |          MAC Address          |   DSCP Tag    |
Reserved|8021p|
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > [...]
> >    Reserved:   All implementations complying with this 
> > protocol MUST set
> >       to zero any bits that are reserved in the version of the 
> > protocol
> >       supported by that implementation.  Receivers MUST ignore all 
> > bits
> >       not defined for the version of the protocol they support.
> > 
> >    8021p:   The three bit 802.1p priority value to use if 
> > packets are to
> >       be IEEE 802.1p tagged.
> > </new text>
> 
> Here DSCP Tag should be 6 bits, not 8.

OK, here is the packet format:

<new text>
</new text>

> <snip>
> > > > > 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?).
> > > > 
> > > > New text:
> > > > <new text>
> > > > 6.20.  IEEE 802.11 Update Station QoS
> > > > 
> > > >    The IEEE 802.11 Update Station QoS message element is used 
> > > >    to change
> > > >    the Quality of Service policy on the WTP for a given station.
> > > >    The
> > > >    QoS tags included in this message element are to be applied
to
> > > >    packets received by the station.
> > > 
> > > By "packets received by the station", do you mean "packets sent by

> > > the WTP to the station"? (In this case, including DSCP here is 
> > > slightly unexpected -- those packets aren't necessarily even IP?)
> > 
> > Hmmm... Should have read: "applied to packets received at the WTP
from 
> > the station."
> 
> In this case, it seems both "Update Station QoS" and "WTP Quality of
Service" message elements apply to same packets -- how do they interact?

I have added addition verbage to make this clearer:

<new text>
6.20.  IEEE 802.11 Update Station QoS

   The IEEE 802.11 Update Station QoS message element is used to change
   the Quality of Service policy on the WTP for a given station.  The
   QoS tags included in this message element are to be applied to
   packets received at the WTP from the station indicated through the
   MAC Address field.  This message element overrides the default values
   provided through the IEEE 802.11 WTP Quality of Service message
   element (see Section 6.22.  Any tagging performed by the WTP MUST be
   directly applied to the packets receive from the station, as well as
   the CAPWAP tunnel, if the packets are tunneled to the AC.

[...]

6.22.  IEEE 802.11 WTP Quality of Service

   The IEEE 802.11 WTP Quality of Service message element value is sent
   by the AC to the WTP to communicate quality of service configuration
   information.  The QoS tag included in this message element are the
   default QoS values to be applied to packets received by the WTP from
   stations on a particular radio.  Any tagging performed by the WTP
   MUST be directly applied to the packets receive from the station, as
   well as the CAPWAP tunnel, if the packets are tunneled to the AC.
</new text>

> 
> How does the tagging work (or not work) if the 'C' bit in IEEE 802.11
Station Session Key message element is set?
Well.. If that's the case, the packets inside the tunnel cannot be
modified - that would be the responsibility of the AC. I can add:

<new text>
      C:   The one bit field is set by the AC to inform the WTP that
         encryption services will be provided by the AC.  When set, the
         WTP SHOULD police frames received from stations to ensure that
         are properly encrypted as specified in the RSN Information
         Element, but does not need to take specific cryptographic
         action on the frame.  Similarly, for transmitted frames, the
         WTP only needs to forward already encrypted frames.  Since
         packets received by the WTP will be encrypted, the WTP cannot
         modify the contents of the packets, including modifying the
         DSCP markings of the encapsulated packet.  In this case, this
         function would be the responsibility of the AC.
</new text>

> 
> I'm also slightly surprised to see the WTP modifying the contents of
IP packets here -- I thought it was acting as Layer 2 device for user
plane traffic (not making any assumptions about the Layer 3 protocol
carried in 802.3 frames). At the very least, the text should probably
say the DSCP Tag applies only to packets with certain values in the
> 802.3 Type field.

OK, I can modify the text to specifically read:
<new text>
   DSCP Tag:   The 6 bit DSCP label to use if packets are eligible to be
      DSCP tagged (see [RFC2474]).
</new text>

> > > > [...]
> > > > 6.22.  IEEE 802.11 WTP Quality of Service
> > > > 
> > > >    The IEEE 802.11 WTP Quality of Service message element value
is
> > > >    sent by the AC to the WTP to communicate quality of service
> > > >    configuration information.  The QoS tag included in
> > this message
> > > >    element are to be applied to packets received by the WTP from
> > > >    station on a particular radio.
> > > > </new text>
> > > 
> > > By "applied to packets received by the WTP from the station", do
you 
> > > mean the tagging is applied to the headers received by the WTP, or

> > > to the headers added by WTP for CAPWAP data tunneling?
> > > (If it's the former, the comment above about DSCP applies)
> > > 
> > I am proposing adding the following sentence to both sections 6.20
and
> > 6.22:
> > 
> > <new text>
> >    Any tagging performed
> >    by the WTP MUST be directly applied to the packets receive from
the
> >    station, as well as the CAPWAP tunnel, if the packets are 
> >    tunneled to the AC.
> > </new text>
> 
> The comment above about 'C' bit and DSCP Tag applies here as well...

I think this comment is now handled above.

> 
> <snip>
> > > Well, some new WTPs might decide *not* to support WEP anymore --
> > perhaps not yet, but five year from now..? (But if support of WEP is

> > required, the document should say so)
> > 
> > Understood, but IEEE 802.11-2007 still requires the AP support it.
> 
> If I'm reading IEEE 802.11-2007, Section A.4.4.1 correctly, it seems
supporting WEP is optional...?

Yes, I see PC2 as optional, but all of the sub-elements are being
mandatory. I suppose I should read this as those sub-elements are
required only if WEP was implemented. We could fix this problem by
allocated another bit in section 8.1, alongside TKIP and AES. Note that
this would reduce the total number of bits available for the whole
protocol, unless we do something to address issue 172.

PatC