Re: [dhcwg] Publication of draft-droms-agentopt-8021x-00.txt

[Bernard Aboba <[e-mail]>]

As I'll describe, I believe that your proposal is not really appropriate
for discussion in the DHC WG, since it makes very fundamental changes
to the IEEE 802.1X specification, It should therefore be brought to the
IEEE 802.1X revision PAR, lead by Tony Jeffree. 

> But in case of wireless LAN or long reach Ethernet(VDSL) access, PAE is 
> typically a Lay-2 device, which is very close to user 
> terminal. Obviously,  it seems impossible to move the NAS function down
> to this point, for that will bring much management burden. Thus, we
> need to pass the 802.1x/EAP message to the NAS/DHCP relay agent, from
> PAE or radius server. 

There is a very basic problem with this. IEEE 802.1X specificates
states very specifically that 802.1X frames MUST NOT be forwarded by layer
2 devices. That is why an IEEE non-forwardable multicast address has been
reserved for use with 802.1X.

The logic behind this is explained in the 802.1X appendix. The issue here
is the interaction between spanning tree, VLAN tagging and 802.1X that
would occur if 802.1X were to be terminated in a core switch. As a result,
802.1X was designed very explicitly for edge authentication. 

Note that this does not specifically prohibit encapsulation of EAP packets
over IP, as is achieved in RADIUS/EAP, described in RFC 2869. 

Note that because both 802.1X and RADIUS are light weight, layer 2 devices
are very capable of functioning as NASen, as defined by the NASREQ WG.
Often this can be handled as a firmware upgrade to existing switches
or access points. So in practice, the "assistance" you refer to is not
usually necessary. 

> above model need a little improvement. A good way to do this is to let the 
> NAS "stand in the middle of radius interaction", acting as a radius proxy. 
> All the PAEs send radius requests and receive replys throuth the NAS/DHCP 
> relay agent, then NAS relay the radius message to or from radius server.
> 
>      (AAA client)---------->(radius proxy/AAA client)
> host--->PAE--->..Lan Switch..--->NAS/DHCP relay------->Server

Implementing a RADIUS proxy/DHCP relay is fine, but the NAS function here
is really implemented on the switch, since a NAS is by definition the
device that terminates the layer 2 connection. Also, the PAE and the LAN
Switch exist within the same entity. 

> Advantage is obvious: consistent with the model above, existing PAE need not 
> any change(only set the radius server address to the NAS's), less burden via 
> central access management. We can even see the PAEs as the extension of the 
> NAS AAA client module

Within 802.1X the PAE MUST be implemented on the switch or access point.
Since 802.1X frames MUST NOT be forwarded, and not all 802.1X frames are
encapsulated within RADIUS, there isn't really an alternative. Of course,
operating a RADIUS proxy/DHCP relay does have management benefits, but
that's a separate discussion. 

> ii) If someone change his MAC address after authentication, it may cause DOS 
> attack via the address learning process of the middle LAN switch. So, the 
> port of PAE must be logical, each host under a physical port has its own 
> authentication session. After successful Auth, a dynamic filter is 
> installed, to discard frames which MAC address is not matched. In fact, 
> without 802.1x, solutions like PPPOE will cause such security problem also.

Interaction of 802.1X and learning is one of the reasons why this kind of
scenario is explicitly prohibited by the 802.1X specification. I'd also
note that 802.1X also explicitly prohibits use in shared media, except
where a separate "logical port" can be established for each connection
(e.g. 802.11 with WEP). 

> iii) 802.1x has not defined any standard ways like echo-request/reply in PPP 
> LCP. Link layer signal detection is not enough, and do we need to enhance 
> it, to determinate more easily when the user is offline, and release the 
> resource?

Addition of link layer echo is currently under discussion within the IEEE
802.1X revision PAR. Since the IEEE just recently met in Austin, TX the
minutes of the meeting should be posted shortly on the 802.1 web page at
http://grouper.ieee.org/groups/802/1/


_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg