Subject: [Capwap] Proposed resolution to Issue 217 - Frame format when wtp encrypts/decrypts

From: "Michael Montemurro" <[email-masked]>
Date: Fri, 22 Sep 2006 17:18:48 -0400

According to CAPWAP-02, section 11.7 states that the WTP must format the
frame according to the IEEE 802.11 specification as described in the IEEE
802.11 (1999) standard.

If that is the case, the WTP would transmit the frame to the AC in the same
IEEE 802.11 frame format. An AC would use the frame format described in the
IEEE 802.11 specification to transmit a frame to the WTP. The WTP would then
encrypt the frame and transmit it over the wireless network to the
destination.

I propose that we do not change CAPWAP to resolve this issue.

Cheers,

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

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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 25 Sep 2006 12:01:34 -0700

Hi Michael,
 
I disagree with the disposition.
 
This issue was created because it is unclear what the 802.11 frame from
WTP to AC looks like when the WTP is performing 802.11 decryption and
802.11 reassembly. At this point, the original over the air 802.11
frame(s) may have no bearing on  the pseudo-802.11 frames (frames that
are slightly different from the actual over the air frames) sent by the
WTP to the AC.
 
For Frames from WTP to AC (this is a generic list):
-------------------------------------------
a) Would these WTP to AC pseudo-802.11 frames have the .11 encryption
headers
b) Are 802.11 Sequence # fields valid and (how are the sequence control
bits set by WTP after reassembly)
c) Is Duration ID valid (if so how is it set by WTP)
d) What are the other  fields(s) that must be ignored by the AC?

All one wants to know is what fields must be set correctly by WTP and
what fields must be ignored by the AC as they may no longer be valid.
 
Similarly, on the AC-->WTP side, what fields must be set by AC and what
fields must be ignored by WTP for these pseudo-802.11 frames.
 
One hopes that CAPWAP can define this to ensure interoperable
implementations.
 
Thanks.
 
-Puneet

________________________________

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 2:19 PM
To: capwap
Subject: [Capwap] Proposed resolution to Issue 217 - Frame format when
wtp encrypts/decrypts

According to CAPWAP-02, section 11.7 states that the WTP must format the
frame according to the IEEE 802.11 specification as described in the
IEEE 802.11 (1999) standard. 
 
If that is the case, the WTP would transmit the frame to the AC in the
same IEEE 802.11 frame format. An AC would use the frame format
described in the IEEE 802.11 specification to transmit a frame to the
WTP. The WTP would then encrypt the frame and transmit it over the
wireless network to the destination. 

Cheers,
 
Mike

---

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 25 Sep 2006 19:56:10 -0400

Puneet,

I'm perfectly happy to add clarifying text. What do you want me to add? How
do you think it should work?

Cheers,

Mike

On 9/25/06, Puneet Agarwal <[email-masked]> wrote:
> 802.11 reassembly. At this point, the original over the air 802.11frame(s) may have no bearing on  the
> pseudo-802.11 frames (frames that are slightly different from the actual
> over the air frames) sent by the WTP to the AC.
>
> All one wants to know is what fields must be set correctly by WTP and what
> fields must be ignored by the AC as they may no longer be valid.
>
>  ------------------------------
> *From:* Michael Montemurro [mailto:[email-masked]]
> *Sent:* Friday, September 22, 2006 2:19 PM
> *To:* capwap
> *Subject:* [Capwap] Proposed resolution to Issue 217 - Frame format when
> wtp encrypts/decrypts
>
>
> same IEEE 802.11 frame format. An AC would use the frame format described
> in the IEEE 802.11 specification to transmit a frame to the WTP. The WTP
> would then encrypt the frame and transmit it over the wireless network to
> the destination.
>

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 25 Sep 2006 19:21:26 -0700

Sure. Here is my take on the solution (the exact wording can be worked
out once we agree on the general contents). I am sure the working group
will help clarify this further.
 
I assume that there are 2 models supported in CAPWAP Split-MAC for
802.11 DATA frames (note that we will have to fill this up for 802.11
Management frames also at a later time):
 
A) 802.11 encryption and 802.11 fragmentation done at the AC (as well as
802.11 decryption and 802.11 re-assembly at AC). 
This is the simple case.
B) 802.11 encryption and 802.11 fragmentation done at the WTP (as well
as 802.11 decryption and 802.11 re-assembly done at WTP).
    
****** CASE A ******
 
a1) The WTP forwards the unmodified 802.11 Data frame that it
successfully receives over the air to the AC.
      Question1: Received Sequence numbers are maintained at the AC I
assume -  is this correct. Is the CAPWAP conforming AC expected to do
any sanity checks on the sequence numbers (especially for un-encrypted
packets)?
 
a2) The AC sends a fully formed 802.11 DATA frame to the WTP. The WTP is
allowed to change the  following fields:
    11.FrameControl.MoreFrag
    11.FrameControl.Retry
    11.FrameControl.MoreData
    11.Duration
Question2: Transmitted Sequence numbers are maintained at the AC or at
the WTP? What is the requirement?
For .11 fragments one would assume that Transmit sequence number is
maintained in the AC (though one can structure it so that either place
can work - we need to define some requirements here).
 
****** CASE B (the more interesting case) ******
In this case the WTP creates a pseudo-802.11 header when sending frames
from WTP to AC.
 
b1) For DATA frames sent from the WTP to the AC, the fields MUST be
interpreted/processed as follows by the AC:
    11.FrameControl.MoreFrag must be set to 0 by WTP (and checked by the
AC)
    11.FrameControl.Retry must be ignored by the AC
    11.FrameControl.Protected Frame must be set to 0 by WTP (and checked
by the AC)
    11.Duration must be ignored by the AC
    11.Sequence Control.Sequence Number should be set to the sequence
number of the "over the air" .11 frame(s)
    11.Sequence Control.Fragment Number MUST be set to 0 by WTP
 
It is expected that all other .11 header fields are the same as in the
received "over the air" .11 frame.
 
Question3: I assume the sequence numbers MUST be maintained by the WTP
in this case. Is that correct?
 
b2) For .11 DATA frames sent from the AC to the WTP, the fields MUST be
interpreted/processed as follows by the WTP/AC:
 
        11.FrameControl.MoreFrag MUST be set to 0 by AC
        11.FrameControl.Retry SHOULD be set to 0 by AC
        11.FrameControl.Protected Frame MUST be set to 0 by AC
        11.Duration must be ignored by the WTP
        11.Sequence Control.Sequence Number should be set to 0 by the AC
        11.Sequence Control.Fragment Number MUST be set to 0 by WTP

It is quite likely that I have missed more than a few cases. It would be
great if others can chime in.
 
Thanks.
 
-Puneet

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 4:56 PM
To: Puneet Agarwal
Cc: capwap
Subject: Re: [Capwap] Proposed resolution to Issue 217 - Frame format
when wtp encrypts/decrypts

Puneet,
 
I'm perfectly happy to add clarifying text. What do you want me to add?
How do you think it should work?
 
Cheers,
 
Mike

	Hi Michael,

	This issue was created because it is unclear what the 802.11
frame from WTP to AC looks like when the WTP is performing 802.11
decryption and 802.11 reassembly. At this point, the original over the
air 802.11 frame(s) may have no bearing on  the pseudo-802.11 frames
(frames that are slightly different from the actual over the air frames)
sent by the WTP to the AC. 
	 
	For Frames from WTP to AC (this is a generic list):
	-------------------------------------------
	a) Would these WTP to AC pseudo-802.11 frames have the .11
encryption headers
	b) Are 802.11 Sequence # fields valid and (how are the sequence
control bits set by WTP after reassembly)
	c) Is Duration ID valid (if so how is it set by WTP)
	d) What are the other  fields(s) that must be ignored by the AC?

	All one wants to know is what fields must be set correctly by
WTP and what fields must be ignored by the AC as they may no longer be
valid. 
	 
	Similarly, on the AC-->WTP side, what fields must be set by AC
and what fields must be ignored by WTP for these pseudo-802.11 frames. 

	Thanks.
	 
	-Puneet

	From: Michael Montemurro [mailto:[email-masked]] 
	Sent: Friday, September 22, 2006 2:19 PM
	To: capwap
	Subject: [Capwap] Proposed resolution to Issue 217 - Frame
format when wtp encrypts/decrypts

	According to CAPWAP-02, section 11.7 states that the WTP must
format the frame according to the IEEE 802.11 specification as described
in the IEEE 802.11 (1999) standard. 
	 
	If that is the case, the WTP would transmit the frame to the AC
in the same IEEE 802.11 frame format. An AC would use the frame format
described in the IEEE 802.11 specification to transmit a frame to the
WTP. The WTP would then encrypt the frame and transmit it over the
wireless network to the destination. 

	Cheers,
	 
	Mike