Capwap Mailing List: RE: Per packet authentication ICV

[Bob O'Hara (bob]

Michael,

As you point out, it is up to the AP to implement efficient scheduling.
As the AP is also an 802.11e station, by definition, it may also
fragment MSDUs in order to achieve that goal of efficient scheduling.
Given particular TSPECs and station TXOPs, the only way that efficiency
may be achieved in some cases is to fragment MSDUs to fill the air time
that would otherwise be wasted.  This does require real-time scheduling
decisions to be made in the AP, potentially on a frame by frame basis.

 -Bob
  
-----Original Message-----
From: Michael Vakulenko [mailto:michaelv [at] legra.com] 
Sent: Thursday, July 17, 2003 1:47 PM
To: Clint Chaplin
Cc: lwapp [at] frascone.com
Subject: RE: [Lwapp] Per packet authentication ICV


802.11e says that station may fragment MSDUs in order to increase the
probability of successful transfer across the WM and/or in order to use
available TXOP duration limits efficiently in cases where the remaining
TXOP duration is shorter than the
time required to transmit the entire pending MSDU. 

In the specific case you've noted, AP also acts as a coordinator that is
responsible for scheduling in the QBSS, thus controlling TXOPs. So, it's
up to AP to implement efficient scheduling that takes into account sizes
of queued MPDUs to better utilize WM. 

If it's the mobile station that fragments the MSDU, then the AP performs
reassembly, in which case the AP do not have to take any real-time
decisions.

Thanks,

-- Michael Vakulenko.

At 01:59 PM 7/16/2003, Clint Chaplin wrote:

I must point out a potential problem here, one that might force at least
some 802.11 processing into the APs:
The solution for QoS that is being proposed by IEEE 802.11 TGe will
force any decisions as to what to send and when into the AP itself; the
AP simply will not have enough time to poll the AR for
information/guidance.  In addition, the decision as to where to split a
MSDU into MPDUs in order to fit into the given time slot must be made
>now< and at the AP, and that includes encrypting the MPDUs.  Therefor,
it will be impossible for the AR to do the TKIP encryption; it will have
to be handled by the AP.

Which means that the packets data packets between the AR and the AP
will have to be protected in some other way.

Clint (JOATMON) Chaplin

>>> "Inderpreet Singh" <isingh [at] chantrynetworks.com> 7/16/03 04:51:13
>>>
Things were sounding fine until I saw "mandate 802.11 processing in
the
AR".  
 
I beg to differ.  Mandating any kind of 802.11 processing on the AR is
enforcing an architectural solution to a performance and cost of
hardware problem.  There is no technical merit to doing this from a
protocol perspective.  Furthermore, correct me if I am wrong, but
shouldn't we shy away from mandating the physical or logical location
of
where IEEE protocols (L2 packets) are processed.  This doesn't seem to
me to be theIETF approach.
 
So, the security threats and vulnerabilities of unencrypted
encapsulated
data packets are obvious (or maybe not). But note that there is no
guarantee that the packets are going to be protected with 802.11i (or
WPA in the interim) in the first place.so mandating 802.11 processing
in
the AR doesn't solve the inherent security threat.  
 
To make it flexible and to meet the security requirements why not
approach it as such:
 
Data packet encapsulation - 2 negotiable options within the protocol
spec
 
1)       802.3 encapsulation - wireless client's 802.11 data is first
bridged by AP into 802.3 and then use lwapp to encapsulate and send to
AR
2)       802.11 encapsulation - wireless client's 802.11 data is
directly encapsulated with lwapp and sent to AR
 
If option 1 is the negotiated then the implementation SHOULD enforce
higher layer security policies for the data traffic.  For example,
data
traffic is secured via IPsec or SSL, etc.  In addition, an
implementation MAY secure (per-packet auth) the transport of the
encapsulated data packets (between AP and AR)
 
If option 2 is negotiated then the implementation MAY enforce that
802.11 security mechanisms like WPA and eventually 802.11i have been
used to secure the user's data. (of course it may further enforce
higher
layer security protection as well.).  In addition, an implementation
MAY
secure (per-packet auth) the transport of the encapsulated data packets

 
This is a high level proposal.we could discuss further online and also
at the BOF.
 
Comments?
 
Inderpreet
--
-----Original Message-----
From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com] On
Behalf Of Rama krishna prasad
Sent: Tuesday, July 15, 2003 11:43 PM
To: Pat R. Calhoun
Cc: lwapp [at] frascone.com 
Subject: Re: [Lwapp] Per packet authentication ICV
 
Hi,
 
        Processing performance is very relative term and anyway, I
also
feel that  it should be kept in mind.
       But, more importantly, I feel LWAPP is really useful in solving
the problem of
           management. It is achieved by making AP implementation
simple
and
           devoid of any context information specific to station, such
as 802.1x context,
           Firewall/NAT context,SSL context, QoS Context etc.. This
will
eliminate
           problem of mobility at the AP level.
 
     OK, then let us make it simple. If we need to avoid per packet
authentication, then
     we should go for doing TKIP at the AR level. That is all packet
integrity and security
     should be cheeked at the AR level whether it is MAC level
security,
IPSEC network
     level security or SSL application level security.  If we mandate
this, then I feel there
     is no need for 'per packet authentication' between APs and AR.
Also, the AP can
     send 802.11 packets to the AR and AR can extract AP events such
as
     Associate/De-Associate/Re-Associate/Open authentication from the
802.11 packets.
     Since TKIP is going to be done at the AR, I assume that AR also
should generate
     802.11 packets, which inturn will be forwarded to stations by the
APs. If we agree to this,
     we need to add text to this effect in the specifications.
 
 Regards
 Rama Krishna Prasad 


________________________________________________________________________
This email has been scanned for computer viruses.
_______________________________________________
Lwapp mailing list
Lwapp [at] frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp