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

From: "Haines Wolfe" <[email-masked]>
Date: Fri, 23 Nov 2001 03:25:05 +0000

>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.
>
>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.
>

Note that NAS has many functions, not only port switch on/off based on 
authentication result. I'm not suggesting that move AAA client function away 
from PAE, and put any fundamental change on the PAE model defined in 
existing 802.1x spec. But it's very clear that 802.1x PAE can not function 
as a "real" NAS itself, although we can integrate it into the public access 
model described in the two previous issues that I've referenced.

802.1 WG focus on PAE itself, and DHC WG focus on the broadband access 
model. What I'm discussing in mainly not on how to change 802.1x and PAE 
function, but on how to integrate it in the access model discussed above. 
This is why I discussed it in this WG.

>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.
>

Generally, NAS is a router or layer-3 switch, which must not be a layer-2 
device. PAE and NAS need not exist in the same intity. For NAS, when it 
connect to user hosts throuth P-to-P tunnel(such as ADSL), PAE lies in NAS; 
when there exist middle switchs, PAE lies in the closest switch to host, and 
communicate with radius server through proxy module in NAS.

>
>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.
>

EAPOL_Start is not needed by NAS, it only tell the PAE to send 
identity_request message. EAPOL_Logoff should cause the PAE to send radius 
request of accounting or other attribute, which will be obtained by NAS as a 
radius proxy. For public access, I think that is enough.

>
>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).
>

There is no interaction between 802.1x and learning. In fact, learning occur 
at middle switch after PAE. Even you have a point-to-point network between 
PAE and host, if you do not apply a filter based on the authentication 
session, MAC address spoofing can occur at any middle switch between PAE and 
the NAS(the network access control point). Logical port is for management 
convenience, for simplify the state machine of the PAE, when there exist 
more than one MAC(including a user change his NIC) under a physical port. 
Security is not a problem, for the hosts in the shared LAN belongs to the 
same entity, for example, a family.

>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/dhcwg

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Nov 2001 22:17:03 -0800 (PST)

> model. 

Last time I looked, defining mechanisms for broadband Internet access is
*not* within the scope of the DHC WG charter. On the other hand, the IEEE
currently has an Ethernet First Mile (EFM) study group, as well as the
IEEE 802.1X revision group. So I would suggest that you are more likely to
have a fruitful discussion of your proposals by taking them to the IEEE. 

> radius proxy. For public access, I think that is enough.

It sounds like you would like to propose changes to the IEEE 802.1X
state machine. Since the IEEE 802.1X revision PAR is now active, that is
the best place to take such proposals. Making such proposals to the DHC 
WG is not likely to generate much forward movement.