Capwap Mailing List: RE: Per packet authentication ICV

[Michael Vakulenko (michaelv]

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