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

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 8 Jan 2007 16:03:38 -0500

To resolve this issue, I propose to add the following text to the
description of split MAC (It will have to be modified further pending
on the resolution to the "encryption at AC" issue.

The location where the header elements will described is given below.
It would be the responsibility of the WTP to do any padding to the
frame for the purpose of encryption.

MAC header field   Location
FCS:
  Version                AC
  ToDS                   AC
  FromDS               AC
  Type                    AC
  SubType              AC
  MoreFrag             WTP
  Retry                   WTP
  Pwr Mgmt            WTP
  MoreData             WTP
  Protected             WTP
  Order                   AC
Duration:               WTP
Address 1:            AC
Address 2:             AC
Address 3:            AC
Sequence Ctrl:      WTP
Address 4:           AC
QoS Control:        AC
Frame Body:        AC
FCS:                   WTP

Cheers,

     Mike

On 9/25/06, Puneet Agarwal <[email-masked]> wrote:
>
>
> 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
>
>
> On 9/25/06, Puneet Agarwal <[email-masked]> wrote:
> >
> >
> > 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.
> >
> > 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: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 08:49:51 -0800

Michael,

One small change, but the first FCS (below) should have been called
'Frame Control', not FCS.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> Sent: Monday, January 08, 2007 1:04 PM
> To: Puneet Agarwal
> Cc: capwap
> Subject: Re: [Capwap] Proposed resolution to Issue 217 - 
> Frame format whenwtp encrypts/decrypts
> 
> To resolve this issue, I propose to add the following text to 
> the description of split MAC (It will have to be modified 
> further pending on the resolution to the "encryption at AC" issue.
> 
> It would be the responsibility of the WTP to do any padding 
> to the frame for the purpose of encryption.
> 
> > 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.Sequence Control.Sequence Number should be set to 
> the sequence 
> > number of the "over the air" .11 frame(s)
> >
> > 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:
> >
> > It is quite likely that I have missed more than a few 
> cases. It would be great if others can chime in.
> >
> > Thanks.
> >
> > -Puneet
> >
> >
> > 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
> >
> >
> > > 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.
> > >
> > > b) Are 802.11 Sequence # fields valid and (how are the sequence 
> > > control bits set by WTP after reassembly)
> > > 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.
> > >
> > > 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.
> > >

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 09:40:00 -0800

My apologies, but I also believe the following text needs to be added
immediately following the figure below:

   Note that the FCS field is not included in 802.11 frames exchanged
   between the WTP and the AC.  Upon sending data frames to the AC, the
   WTP is responsible for validating, and stripping the FCS field.  Upon
   receiving data frames from the AC, the WTP is responsible for adding
   the FCS field, and populating the field as described in [3].

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Wednesday, January 10, 2007 8:50 AM
> To: Michael Montemurro; Puneet Agarwal
> Cc: capwap
> Frame formatwhenwtp encrypts/decrypts
> 
> Michael,
> 
> One small change, but the first FCS (below) should have been 
> called 'Frame Control', not FCS.
> 
> Pat Calhoun
> > whenwtp encrypts/decrypts
> > 
> > can be worked out once we agree on the general contents). I am sure 
> > the working group will help clarify this further.
> > >
> fill this 
> > up for 802.11 Management frames also at a later time):
> > >
> > >
> > 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)?
> > >
> > number is maintained in the AC (though one can structure it so that 
> > either place can work - we need to define some requirements here).
> > >
> > >
> > 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.
> > > >
> > correctly by WTP and what fields must be ignored by the AC 
> as they may 
> > no longer be valid.
> > > >
> > > > Subject: [Capwap] Proposed resolution to Issue 217 - 
> Frame format 
> > must format the frame according to the IEEE 802.11 specification as 
> > described in the IEEE 802.11 (1999) standard.
> > > >
> > 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.
> > > >

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 10 Jan 2007 15:14:53 -0800

Hi Michael/Pat,

I assume this proposal is about part 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)).

The area that I find a little confusing is the statement:
"The location where the header elements will described is given below."

Does this mean where the field MUST be checked on receiving the CAPWAP
DATA packet. If a receiver is not indicated as the location, then the
receiver will ignore the field (or does it need to still check it)?

For example, if we look at the "Protected             WTP" field.
>From WTP--> AC
At AC, do we need to ignore the "Protected" field and assume it is 0 and
drop the pkt if it is 1?

>From AC-->WTP
At WTP, do we assume that "Protected" field is 0 or do we drop the pkt
if it is 1?

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 9:40 AM
To: Pat Calhoun (pacalhou); Michael Montemurro; Puneet Agarwal
Cc: capwap
Subject: RE: [Capwap] Proposed resolution to Issue 217 - Frame
formatwhenwtp encrypts/decrypts

Pat Calhoun

> Subject: Re: [Capwap] Proposed resolution to Issue 217 - Frame 
> formatwhenwtp encrypts/decrypts
> 
> Michael,
> 
> CTO, Wireless Networking Business Unit Cisco Systems
> 
>  
>