Subject: RE: [Fwd: [L2tpext] Tunneling for Wireless LAN Authentication]

From: "Mike Moreton" <[email-masked]>
Date: Wed, 11 Dec 2002 09:16:42 -0000

Glen, Mark,

To give a little more background.

The situation is where you already have an authenticated L2 (and L3)
connection to the network via an existing Access Point.  At some point
you detect the presence of a new access point on a different channel
that you might want to roam to at some point.  Most equipment can only
scan alternative channels for very short intervals of time (without
disrupting the main channel), so pre-authenticating with the new Access
Point over the air is difficult.

So the aim is to send the authentication frames to the new access point
via the connection you already have with the existing access point and
the network that connects the access points.  The payloads of these
frames are cryptographically unprotected so that at the MAC level there
doesn't need to be any additional protection.  (The payloads are
designed to be sent in unauthenticated, unencrypted MAC frames over the
air, and it's difficult to see how any tunnelling protocol could be less
secure than that...)

I've talked to Russ Housley (who was one of the authors of RFC3378) and
he has convinced me that my concerns about routers possibly
unencapsulating frames were not valid.  A router (even if it implemented
RFC3378) would only do this if the IP packet encapsulating the frame was
addressed to it directly.  As long as we used the IP address of the
"new" access point there should be no problem.  So it looks like RFC3378
might be a solution.

As to what the "some other mechanism" might be for determining the IP
address of the new access point, I've heard rumours that some
manufacturers include a proprietary information element in the beacon
frames broadcast by their Access Points.  Totally against the standard
of course...

Mike Moreton, Synad Technologies.

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]] 
Sent: 11 December 2002 08:49
To: [email-masked]
Cc: Mike Moreton; [email-masked]
Subject: Re: [Fwd: [L2tpext] Tunneling for Wireless LAN Authentication]

Glen Zorn wrote:
> "Mike Moreton" <[email-masked]> writes:
> 
> 
>>All,
>>
>>
>>
>>I don?t know if anyone can help me here?
>>
>>
>>
>>The IEEE is working on enhancements to the security features of its
>>802.11 wireless LAN technology.  One of the features of this is an
>>authentication mechanism based on 802.1X EAPOL frames.  In certain
>>circumstances these can transit a bridged network to Access Points
>>different to the one with which the wireless client is currently
>>associated.
>>
>>
>>
>>However, as the IEEE only works on level 2 standards, there are no
>>mechanisms for reaching a remote AP not on the subnet, even should its
>>IP address be known by ?some other mechanism?.  It would be nice to
make
>>a suggestion about the technique to be used, even if the IEEE couldn?t
>>lay down a formal standard.
>>
>>
>>
>>One obvious solution would be to tunnel the EAPOL frames to the remote
>>AP inside some sort of IP based protocol (in the case of an IP
>>network).  It appears that PPP can do that, but PPP is probably much
to
>>complex in order just to get a few (unprotected) frames across.
RFC3378
>>describes a very simple encapsulation, but it sounds as if ?helpful?
>>routers along the way might de-encapsulate the frames, which is
>>definitely not what is required.  What is needed is an end-to-end
>>encapsulation.

I think that the crux of this issue is the chicken-and-egg problem of
802.1X 
EAPOL providing ethernet (e.g. L2) authorization, while IP clearly
requires L2 
connectivity for it to operate (at L3). Thus, even if your IP addresses
are 
known by "some other mechanism" (not speculating what that mechanism is)
then 
you clearly need to have L2 enabled between them to communicate, at
least for 
the packets carrying your EAP-in-IP packets (or EAPOL-in-something-in-IP

packets). The intermingling of layers here seems to suggest the
possibility of 
at least some hit to the IEEE protocols, as well as associated security 
implications, for passing "these few" EAP-in-IP frames before actually 
authorizing the link fully via EAPOL.

>>
>>
>>
>>Can anyone help?
> 
> 
> Ignoring much of the nonsense therein, EAP over UDP
> (draft-engelstad-pana-eap-over-udp-00.txt) might work.  How about
Ethernet
> (or 802.11, if you prefer) over L2TPv3?

L2TPv3 would certainly work for transportation of 802.1X frames, but
this also 
could be considered an undue amount of functionality for just a few auth
frames.

Assuming you knew the IP addresses of the boxes you wanted to transport
802.1X 
frames between, just sending them as you suggest seems the simplest
solution 
(over UDP as well as anything else).
draft-engelstad-pana-eap-over-udp-00.txt is 
the right idea in name, though the draft does seem to have a lot more
text 
within than I would, at first stroke, think necessary here (It's also
expired).

- Mark

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "Mike Moreton" <[email-masked]>
Date: Wed, 11 Dec 2002 09:16:42 -0000

Glen, Mark,

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]] 
Sent: 11 December 2002 08:49
To: [email-masked]
Cc: Mike Moreton; [email-masked]
Subject: Re: [Fwd: [L2tpext] Tunneling for Wireless LAN Authentication]

make
to
RFC3378

Ethernet

- Mark