Capwap Mailing List: Re: Proposed resolution to Issue 217 - Frame format whenwtp encrypts/decrypts

[Abhijit Choudhury (abhijit10425]

Hi Mike,

 

The text in the draft-ietf-capwap-protocol-binding-ieee80211-01.txt

is still not very clear on the frame format for split-MAC when the

WTP does encryption/decryption.

 

Here's some proposed text to help resolve the issue.  I propose we

replace the relevant text in the last paragraph on Page 7

with the text below.

 

 

---------------------- PROPOSED TEXT ----------------------------

 

   The WTP MUST include the IEEE 802.11 MAC header contents in all
   frames transmitted to the AC.  When 802.11 encryption/decryption is
   performed at the WTP, the WTP MUST decrypt the uplink frames,

   MUST set the Protected Frame field to 0, and MUST make the frame format

   consistent with that of an unprotected 802.11 frame prior to
   transmitting the frames to the AC.  The fields added to an 802.11

   protected frame, i.e., IV/EIV, MIC,and ICV ,  MUST be stripped

   off prior to transmission from the WTP to AC.

   For downlink frames, the Protected Frame field MUST be set to 0 by the

   AC as the frame being sent is unencrypted.  The WTP MUST apply

   the required protection policy for the WLAN, and set the Protected Frame

   field on transmission over the air.  The Protected Frame field always needs

   to accurately indicate the status of the 802.11 frame that is carrying it.

 

 

------------------------------------------------------------------

 

Cheers,

Abhijit

-----Original Message-----
From: Michael Montemurro [mailto:montemurro.michael [at] gmail.com]
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.

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 <pagarwal [at] broadcom.com> 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:montemurro.michael [at] gmail.com]
> 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 <pagarwal [at] broadcom.com> 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:montemurro.michael [at] gmail.com]
> > 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

---

Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.