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

From: <[email-masked]>
Date: Fri, 8 Aug 2008 01:05:23 +0300

Pat Calhoun wrote:

> > 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).

> > 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...)

> > 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.

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?

> 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).

> > 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.

> > 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.

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: "Clint Chaplin" <[email-masked]>
Date: Thu, 7 Aug 2008 15:36:50 -0700

>  for most practical purposes when you're running TCP/IP).

Just because you are running TCP/IP as your main protocol doesn't
guarantee that it's the only protocol.  DNS, DHCP, UDP/IP and others
may be necessary to support running TCP/IP.

Now, do all those other support protocols not care about out-of-order
delivery?  I don't know the answer to that question.
-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 12:18:08 -0700

> > > (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.)
> 
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 

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>

> > > different.  When doing split MAC with 802.3 frames, the 802.3
frame 
> > > contains only two of the addresses; the "Radio MAC Address"

> > alternative way to deploy 802.11 infrastructure means that do not
need 
> > to support ad hoc mode ;-)
> 

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.)
> 
> > 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.
> 
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.

> 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.

> > > EAPOL-Key messages -- so probably shouldn't be sent to PTK), or
only 
> > > the TK used for encrypting traffic?
> >
> 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>

> 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>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: <[email-masked]>
Date: Mon, 18 Aug 2008 22:29:52 +0300

Pat Calhoun wrote:

> > 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.

Large bridges are indeed different, but small "wireless bridges" are
marketed for e.g. connecting a printer with wired Ethernet jack
to office WLAN.

Does this mean if the office WLAN switches to CAPWAP-based access
points, and uses split MAC with 802.3 frames, those would stop
working? 

(I don't think there's a need to expand the scope of the WG --
accurately documenting what parts of 802.11 don't 100% work
with CAPWAP is IMHO quite sufficient.)

<snip>

> > > > 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 
> > 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
> [...]
> 

Yes, but the spec isn't very clear on how the RSN IE exactly is
processed by the WTP (the IE has number of different fields).

> > 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.

Ok, that clarifies this part...

> 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.
> 

Again, except for the RSN IE, whose processing is mentioned,
but not described in detail.

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 07:52:49 -0700

> > > "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...)
> > 
use 

> > 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 
protocol, 
> > but would require lots more work.
> 
marketed for e.g. connecting a printer with wired Ethernet jack to
office WLAN.
> Does this mean if the office WLAN switches to CAPWAP-based access
points, and uses split MAC with 802.3 frames, those would stop working? 
> (I don't think there's a need to expand the scope of the WG --
accurately documenting what parts of 802.11 don't 100% work with CAPWAP
is IMHO quite sufficient.)

The size of the bridge is actually irrelevant. The use of the four
address frame format is the question. I would point you to the IEEE
802.11-2007 specification, section 7.1.3.1.3, which specifically states:

<standards quote>
To DS = 1, From DS = 1
   A data frame using the four-address format. This standard does not
define procedures for
   using this combination of field values.
</standards quote>

So to that end, I am proposing a modification to the last paragraph of
the introduction section:

<modified text>
1.  Introduction
[...]
   Note that this binding only supports the IEEE 802.11-2007
   specification.  Of note, this binding does not support the ad-hoc
   network mode defined in the IEEE 802.11-2007 standard.  This
   specification also does not cover the use of data frames with the
   four-address format, commonly referred to as Wireless Bridges, whose
   use is not specified in the IEEE 802.11-2007 standard.  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.
</modified text>

> > > 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
> > [...]
> > 

The WTP does not need to perform any processing of the RSN IE. The IE is
included in the Beacon and Probe Responses as-is by the WTP. Any
cryptographic policies are sent by the AC either through the Add Station
or the Session Key message elements. So in order to provide more
clarity, I propose adding the first sentence in the last paragraph of
the following text:

<modified text>
6.1.  IEEE 802.11 Add WLAN
[...]
  Power Constraint information element

   EDCA Parameter Set information element

   QoS Capability information element

   WPA information element  [WPA]

   RSN information element

   WMM information element  [WMM]

   These IEEE 802.11 information elements are stored by the WTP and
   included in any Probe Responses and Beacons generated, as specified
   in the IEEE 802.11 standard [IEEE.802-11.2007].  If present, the RSN
   information element is sent with the IEEE 802.11 Add WLAN message
   element to instruct the WTP on the usage of the Key field.
</modified text>

> > 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.
> > 
> Again, except for the RSN IE, whose processing is mentioned, but not
described in detail.

I believe this is now covered above.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 23:40:32 +0300

Pat Calhoun wrote:

> > > described in
> > >       message element, including the RSNIE, which 
> > >       indicates support of 802.1X and AES-CCMP.
> > > </current text>
> > 
> The WTP does not need to perform any processing of the RSN IE. The
> IE is included in the Beacon and Probe Responses as-is by the
> WTP. Any cryptographic policies are sent by the AC either through
> the Add Station or the Session Key message elements. 

By "processing", I meant the WTP has to parse the contents of the RSN
IE, find some field(s) inside it, and use those value(s) for something.
Both Sections 6.1 and 6.15 say the WTP does this; I'd like to see
more details for "some field(s)" and "something".

(Presumably, other IEs are just stored and copied to Beacons and Probe
Responses -- the WTP doesn't need to parse them. Is this correct?). 

> So in order to provide more clarity, I propose adding the first
> sentence in the last paragraph of the following text:
> 
> <modified text>

As I wrote above, I don't think "instruct" is enough here, or in
Section 6.15. Which fields are used, and how?

(As an example of ambiguity, the RSN IE can list multiple pairwise
cipher suites. If both TKIP and CCMP are listed in the RSN IE, what
does the WTP do? The IEEE 802.11 Station Session Key message
element could -- and perhaps should -- contain a "Cipher Suite" 
field, but currently, it doesn't.)

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 18:50:28 -0700

> > The WTP does not need to perform any processing of the RSN IE. The
IE 
> > is included in the Beacon and Probe Responses as-is by the WTP. Any 
> > cryptographic policies are sent by the AC either through the Add 
> > Station or the Session Key message elements.
> 
> Both Sections 6.1 and 6.15 say the WTP does this; I'd like to see more
details for "some field(s)" and "something".

I think you are asking two separate questions. In terms of what
processing needs to happen when the WLAN is created, which requires that
many IEs are sent, including RSN, the answer is none. The WTP only
includes them in the Beacons and Probe Responses.

> (As an example of ambiguity, the RSN IE can list multiple pairwise
cipher suites. If both TKIP and CCMP are listed in the RSN IE, what does
the WTP do? The IEEE 802.11 Station Session Key message element could --
and perhaps should -- contain a "Cipher Suite" 
> field, but currently, it doesn't.)

OK, now in terms of Section 6.15, there is some processing required.
Sorry, I thought you were talking about the beacons/probes, not this
section. In the IEEE standard, the AP can advertise multiple cipher
suites in the Beacon and Probe Responses, but it confirms the cipher to
use in message three of the 4-Way Key Handshake. So I have modified the
text in section 6.15 to be specific about the cipher and AKM fields. So
the new text reads:

<new text>
6.15.  IEEE 802.11 Station Session Key
[...]

   The RSN information element MUST sent along with the IEEE 802.11
   Station Session Key in order to instruct the WTP on the usage of the
   Key field.  The WTP MUST observe the AKM field of the RSN information
   element in order to identify the authentication protocol to be
   enforced with the station.

   If cryptographic services are provided at the WTP, the WTP MUST
   observe the algorithm dictated in the Pairwise Cipher Suite field of
   the RSN information element sent by the AC.  The RSN Information
   Element included here is the one sent by the AC in the third message
   of the 4-Way Key Handshake, which specifies which cipher is to be
   applied to provide encryption and decryption services with the
   station.  The RSN Information Element is used to communicate any
   supported algorithm, including WEP, TKIP and AES-CCMP.  In the case
   of static WEP keys, the RSN Information Element is still used to
   indicate the cryptographic algorithm even though no key exchange
   occurred.

</new text>

Does this address your comment?

PatC

---

From: <[email-masked]>
Date: Thu, 21 Aug 2008 11:06:46 +0300

Pat Calhoun wrote:

> > By "processing", I meant the WTP has to parse the contents of the
> > RSN IE, find some field(s) inside it, and use those value(s) for
> > something.  Both Sections 6.1 and 6.15 say the WTP does this; I'd
> > like to see more details for "some field(s)" and "something".
> > 
> > (Presumably, other IEs are just stored and copied to Beacons and
> > Probe Responses -- the WTP doesn't need to parse them. Is this
> > correct?).
> 
> processing needs to happen when the WLAN is created, which requires
> that many IEs are sent, including RSN, the answer is none. The WTP
> only includes them in the Beacons and Probe Responses.

It seems the WTP has to parse the RSN IE to find out at least
the Group Cipher suite, no?

<snip>

> > cipher suites. If both TKIP and CCMP are listed in the RSN IE,
> > what does the WTP do? The IEEE 802.11 Station Session Key message
> suites in the Beacon and Probe Responses, but it confirms the cipher
> to use in message three of the 4-Way Key Handshake. So I have
> modified the text in section 6.15 to be specific about the cipher
> and AKM fields. So the new text reads:
> 
> <new text>
>    Station Session Key in order to instruct the WTP on the usage of
>    the Key field.  The WTP MUST observe the AKM field of the RSN
>    information element in order to identify the authentication
>    protocol to be enforced with the station.
> 
>    observe the algorithm dictated in the Pairwise Cipher Suite field
>    of the RSN information element sent by the AC.  The RSN
>    Information Element included here is the one sent by the AC in
>    the third message of the 4-Way Key Handshake, which specifies
>    which cipher is to be applied to provide encryption and
>    decryption services with the station.  The RSN Information
>    Element is used to communicate any supported algorithm, including
>    WEP, TKIP and AES-CCMP.  In the case of static WEP keys, the RSN
>    Information Element is still used to indicate the cryptographic
>    algorithm even though no key exchange occurred.
> 
> </new text>
> 

Yes, this looks clear enough.

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 21 Aug 2008 11:39:13 -0700

> It seems the WTP has to parse the RSN IE to find out at least the
Group Cipher suite, no?

Got it. Here is the new text:

<new text>

   If cryptographic services are provided at the WTP, the WTP MUST
   observe the algorithm dictated in the Group Cipher Suite field of the
   RSN information element sent by the AC.  The RSN Information Element
   is used to communicate any supported algorithm, including WEP, TKIP
   and AES-CCMP.  In the case of static WEP keys, the RSN Information
   Element is still used to indicate the cryptographic algorithm even
   though no key exchange occurred.
</modified text>

The same text was added to section 6.21 (IEEE 802.11 Update WLAN).

PatC