A-MSDU deaggregation support

A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Hey,

I just looked at the deaggregation code for unrelated reasons and
thought about it a bit more; shouldn't there be some sort of checks that
the 802.11 rules about identical addresses are adhered to to avoid
having rogue packets pretending to come from somewhere else enter the
networking stack? This can usually be avoided by using RSNA, but this
code allows one to easily circumvent this which makes us look pretty
bad.

Makes you wonder why they included full 802.3 framing in the
subframes...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: A-MSDU deaggregation support

[Tomas Winkler]

On 9/9/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> Hey,
>
> I just looked at the deaggregation code for unrelated reasons and
> thought about it a bit more; shouldn't there be some sort of checks that
> the 802.11 rules about identical addresses are adhered to to avoid
> having rogue packets pretending to come from somewhere else enter the
> networking stack? This can usually be avoided by using RSNA, but this
> code allows one to easily circumvent this which makes us look pretty
> bad.
>
> Makes you wonder why they included full 802.3 framing in the
> subframes...
>
There is difference between receiving and destination address. AP is
receiving address but not the destination. If station sends packets to
multiple stations it still go through one AP (receiving address). The
only restriction is that all the packets in A-MSDU belongs to one TID
stream.

There is actually different problem with the A-MSDU deaggregation and
this is EPOL filtering. One of the packets might belong to EAPOL
handshake

Tomas

> johannes
>
>

Re: A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Mon, 2007-09-10 at 14:41 +0300, Tomas Winkler wrote:

> There is difference between receiving and destination address. AP is
> receiving address but not the destination. If station sends packets to
> multiple stations it still go through one AP (receiving address). The
> only restriction is that all the packets in A-MSDU belongs to one TID
> stream.

Good point. However, shouldn't we be checking the SA/TA?

> There is actually different problem with the A-MSDU deaggregation and
> this is EPOL filtering. One of the packets might belong to EAPOL
> handshake

Good point as well. Also, there's still the headroom reservation thing I
haven't really walked through.

But I would like to ask you to not work on this at this time, I'm going
to make some larger changes in this area that may end up doing
deaggregation in a loop and pushing the remaining packets through some
more rx handling.

Michael had the idea to introduce a type of interface that would see all
frames not destined for other interfaces including those eapol packets
etc. to run the userspace mlme (wpa_supplicant or hostapd) on such an
interface to avoid copying all data packets. This will most likely
require framing the packet to 802.3 before it is cloned for each
interface (currently we copy for each interface!), and hence the
deaggregation would be done along with reframing regular packets,
eapol/802.1X filtering would move behind that.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Mon, 2007-09-10 at 14:41 +0300, Tomas Winkler wrote:

> There is actually different problem with the A-MSDU deaggregation and
> this is EPOL filtering. One of the packets might belong to EAPOL
> handshake

Why do we filter those anyway? What's wrong with having them show up on
the regular 802.3 framed interface all the time? Isn't that how 802.1X
was basically designed?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: A-MSDU deaggregation support

[Tomas Winkler]

On 9/25/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2007-09-10 at 14:41 +0300, Tomas Winkler wrote:
>
> > There is actually different problem with the A-MSDU deaggregation and
> > this is EPOL filtering. One of the packets might belong to EAPOL
> > handshake
>
> Why do we filter those anyway? What's wrong with having them show up on
> the regular 802.3 framed interface all the time? Isn't that how 802.1X
> was basically designed?
>
EAPOL frames should not be filtered out. Everything else should be filtered out
except EAPOL frames till the port is open.

The problem is the order of the handlers.  First you need to
deaggregated the frame then filtered out non EAPLOL frames if the port
is not open.

Tomas

> johannes
>
>

Re: A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

On Wed, 2007-09-26 at 01:24 +0200, Tomas Winkler wrote:

> EAPOL frames should not be filtered out. Everything else should be filtered out
> except EAPOL frames till the port is open.

Right now though, when we're an AP, we're sending EAPOL frames to the
mgmt interface instead of the regular 802.3 interface. This quite sucks
wrt. deagg. But it's also very weird, look at ieee80211_rx_h_802_1x_pae.
It sends
 * eapol frames for non-STA interfaces that are for us -> mgmt iface
 * non-eapol frames from unauthorized STAs -> bitbucket
 * everything else -> the regular 802.3 interface

Right afterwards, unencrypted non-EAPOL frames are dropped.

So any STA can actually send EAPOL frames with an arbitrary destination
MAC address except our own into our 802.3 interface. Hence, it looks
like the first case above is only for having eapol on mgmt iface.

The only problem I see with not doing this is that hostapd will have to
listen for EAPOL frames on all VLAN interfaces but I suppose that is
doable.

> The problem is the order of the handlers.  First you need to
> deaggregated the frame then filtered out non EAPLOL frames if the port
> is not open.

Yeah, I know, I had a plan a while back, will see if I can implement it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: A-MSDU deaggregation support

[Tomas Winkler]

On 9/26/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2007-09-26 at 01:24 +0200, Tomas Winkler wrote:
>
> > EAPOL frames should not be filtered out. Everything else should be filtered out
> > except EAPOL frames till the port is open.
>
> Right now though, when we're an AP, we're sending EAPOL frames to the
> mgmt interface instead of the regular 802.3 interface. This quite sucks
> wrt. deagg. But it's also very weird, look at ieee80211_rx_h_802_1x_pae.
> It sends
>  * eapol frames for non-STA interfaces that are for us -> mgmt iface
>  * non-eapol frames from unauthorized STAs -> bitbucket
>  * everything else -> the regular 802.3 interface
>
> Right afterwards, unencrypted non-EAPOL frames are dropped.
>
> So any STA can actually send EAPOL frames with an arbitrary destination
> MAC address except our own into our 802.3 interface. Hence, it looks
> like the first case above is only for having eapol on mgmt iface.
>
> The only problem I see with not doing this is that hostapd will have to
> listen for EAPOL frames on all VLAN interfaces but I suppose that is
> doable.
>
I wonder of port control is done for ethernet. 1X is not WLAN invention.
I'll try to dig it.

> > The problem is the order of the handlers.  First you need to
> > deaggregated the frame then filtered out non EAPLOL frames if the port
> > is not open.
>
> Yeah, I know, I had a plan a while back, will see if I can implement it.
>
Hope to get there as well in near future.

> johannes
>
>

Re: A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Wed, 2007-09-26 at 13:46 +0200, Tomas Winkler wrote:

> > The only problem I see with not doing this is that hostapd will have to
> > listen for EAPOL frames on all VLAN interfaces but I suppose that is
> > doable.
> >
> I wonder of port control is done for ethernet. 1X is not WLAN invention.
> I'll try to dig it.

I haven't ever seen it, but I'm not sure.

> > > The problem is the order of the handlers.  First you need to
> > > deaggregated the frame then filtered out non EAPLOL frames if the port
> > > is not open.
> >
> > Yeah, I know, I had a plan a while back, will see if I can implement it..
> >
> Hope to get there as well in near future.

Ok, let me know what you plan to do. John has pushed the deagg patch
into the "dungeon" branch so it's still there for reference.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: A-MSDU deaggregation support

[Tomas Winkler]

On 9/26/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2007-09-26 at 13:46 +0200, Tomas Winkler wrote:
>
> > > The only problem I see with not doing this is that hostapd will have to
> > > listen for EAPOL frames on all VLAN interfaces but I suppose that is
> > > doable.
> > >
> > I wonder of port control is done for ethernet. 1X is not WLAN invention.
> > I'll try to dig it.
>
> I haven't ever seen it, but I'm not sure.
I'm sure.
>
> > > > The problem is the order of the handlers.  First you need to
> > > > deaggregated the frame then filtered out non EAPLOL frames if the port
> > > > is not open.
> > >
> > > Yeah, I know, I had a plan a while back, will see if I can implement it.
> > >
> > Hope to get there as well in near future.
>
> Ok, let me know what you plan to do. John has pushed the deagg patch
> into the "dungeon" branch so it's still there for reference.

Oh... another victim.  Getting lost in current patch movement... Looks
like most of the decision are happening somewhere else...

> johannes
>
>

Re: A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Wed, 2007-09-26 at 14:32 +0200, Tomas Winkler wrote:

> > > I wonder of port control is done for ethernet. 1X is not WLAN invention.
> > > I'll try to dig it.
> >
> > I haven't ever seen it, but I'm not sure.

> I'm sure.

Oh, I know about 802.1X, sorry, meant that I haven't seen port control
done in Linux.

> > Ok, let me know what you plan to do. John has pushed the deagg patch
> > into the "dungeon" branch so it's still there for reference.
> 
> Oh... another victim.  Getting lost in current patch movement... Looks
> like most of the decision are happening somewhere else...

That particular patch definitely had problems like the missing
skb_reserve. Right now I'm thinking we should do PAE stuff after
converting to 802.3 and do deaggregation at the same time as converting
to 802.3 because that's basically what it is. But if you want to look at
it I'll go back to making hostapd work.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: A-MSDU deaggregation support

[Jouni Malinen]

On Wed, Sep 26, 2007 at 09:39:54AM +0200, Johannes Berg wrote:

> So any STA can actually send EAPOL frames with an arbitrary destination
> MAC address except our own into our 802.3 interface. Hence, it looks
> like the first case above is only for having eapol on mgmt iface.

EAPOL ethertype is not supposed to be bridged, so it would be perfectly
fine dropping these wherever it is most convenient to do.

> The only problem I see with not doing this is that hostapd will have to
> listen for EAPOL frames on all VLAN interfaces but I suppose that is
> doable.

That's fine. This should be doable with just one packet socket that is
not bound to any interface or alternatively with multiple sockets (one
per interface). I wouldn't be too concerned about the extra cost here as
long as the other EAPOL related silliness (e.g., the difference in
encryption of re-keying packets in 802.1X with dynamic WEP vs. WPA).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: A-MSDU deaggregation support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Thu, 2007-09-27 at 18:39 -0700, Jouni Malinen wrote:
> On Wed, Sep 26, 2007 at 09:39:54AM +0200, Johannes Berg wrote:
> 
> > So any STA can actually send EAPOL frames with an arbitrary destination
> > MAC address except our own into our 802.3 interface. Hence, it looks
> > like the first case above is only for having eapol on mgmt iface.
> 
> EAPOL ethertype is not supposed to be bridged, so it would be perfectly
> fine dropping these wherever it is most convenient to do.

Not sure I understand. If it's not supposed to be bridged then I hope
the bridging code knows about this. Otherwise, we can fix it. But I
don't understand the second part of your sentence, I was actually
proposing not doing anything special to EAPOL packets at all except
accepting them unencrypted.

> > The only problem I see with not doing this is that hostapd will have to
> > listen for EAPOL frames on all VLAN interfaces but I suppose that is
> > doable.
> 
> That's fine. This should be doable with just one packet socket that is
> not bound to any interface or alternatively with multiple sockets (one
> per interface).

Good point.

>  I wouldn't be too concerned about the extra cost here as
> long as the other EAPOL related silliness (e.g., the difference in
> encryption of re-keying packets in 802.1X with dynamic WEP vs. WPA).

That sentence seems unfinished?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]