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

From: "Haines Wolfe" <[email-masked]>
Date: Thu, 22 Nov 2001 14:05:54 +0000

I think it is a good idea to combine 802.1x and DHCP, which can give us a 
better subscribe management solution for public broadband access.

For broadband access, such as DSL, CableModem, or Wireless/Long Reach LAN, 
end-user interface is mainly the Ethernet. As for the middle-layer 
non-Ethernet network(HFC or ATM), they act mainly as the emulated LAN 
bridge. And with the trend of "Ethernet everywhere" or "Ethernet to the 
first/last mile", we need a corresponding subscriber management (AAA) 
solution which is cheap, simple, and efficient.

PPPoE was mainly used in ADSL access. With the backend network is mainly 
ATM, there exist point-to-point "virtual bridge" between CPE and NAS. So it 
can reuse the AAA infrastructure widely deployed in ISP's dial-up network. 
But despite all the merits inherited from PPP, it brings out complexity, 
inefficiency, overhead, and additional cost.  Lots of packets generated from 
server farm LAN segment, while size of which is 1500, will be fragmentd at 
NAS(BRAS), thus cause seriously performance decrease.

Requirement for "IP directly over Ethernet in data plane" is emerging. Some 
vendors have web-based service sign on solutions, but which can only cover a 
little. While some DHCP enhancement work has been taken, to demostrate a 
sound solution model, which can be referenced from 1)"Triggering AAA from 
DHCP Relay Agents", 2)"AAA/DHCP Proposal", and this issue:
1) http://www.ietf.org/proceedings/01mar/I-D/dhc-aaa-ra-00.txt
2) http://www.ietf.org/proceedings/01mar/slides/dhc-2/index.html

But some more details may need to be discussed about the AAA model of public 
broadband access.

i) roles of NAS(BRAS), DHCP relay, 802.1x PAE, and AAA Client
ii) security
iii) accounting

i) To replace PPP, we must have a networking gear like NAS/BRAS. In dial-up 
network, which terminate PPP link; while in broadband access, which act as a 
dhcp relay agent, and a radius AAA client, to
control user access, apply policy, provide and account for the service.

EAPoL is the ideal protocal between user terminal and NAS, which extended 
the flexibility of PPP authentication(such as smartcard support), without 
the overhead in data plane of the stack protocal, and enable the reusing of 
ISP's AAA infrastructure. Which is the case in the figure 2, slide 3, in 
(2).

But in case of wireless LAN or long reach Ethernet(VDSL) access, PAE is 
typically a Lay-2 device, which is very close to uesr 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, Then the 
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

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.

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.

For public access, we may need to prevent any two host from communicating, 
until frames sent from which reached the NAS, that is, it looks like a 
point-to-point virtual tunnel from host to NAS. Some vendor's LAN switch can 
wok in a "MUX forwarding" mode, such as Cisco PVLAN, 3Com and Extreme has 
similar implementation, which can do this.

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?

>From: Ralph Droms <[email-masked]>
>To: [email-masked]
>Subject: [dhcwg] Publication of draft-droms-agentopt-8021x-00.txt
>Date: Mon, 19 Nov 2001 21:03:35 -0500
>
>This announcement didn't make it onto the dhcwg mailing list...
>
>- Ralph
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, November 19, 2001 8:29 AM
>Subject: I-D ACTION:draft-droms-agentopt-8021x-00.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>	Title		: 802.1X Credentials Sub-option for the DHCP Relay Agent
>                           Information Option
>	Author(s)	: R. Droms, J. Schnizlein
>	Filename	: draft-droms-agentopt-8021x-00.txt
>	Pages		: 7
>	Date		: 16-Nov-01
>
>The IEEE 802.1X protocol provides authenticated layer 2 network
>access.  As part of the authentication for 802.1X, a device such as a
>switch or a wireless LAN access point can receive credentials from
>the authentication authority identifying the user of a device
>requesting access.  These credentials can then be used by a DHCP
>server in the selection of an IP address for assignment to the device
>through its DHCP client.  The 802.1X Credentials sub-option allows an
>access device that implements 802.1X and that can create DHCP Relay
>Agent options to pass along credentials for the user of a device
>received during 802.1X authentication to a DHCP server.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-droms-agentopt-8021x-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-droms-agentopt-8021x-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-droms-agentopt-8021x-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>-----
>To:
>Subject:
>Date: Mon, 19 Nov 2001 16:07:31 -0500
>X-Mailer: Internet Mail Service (5.5.2653.19)
>
>
>
>
>  ATT83737.txt
>
>
>  VIRUS1_DETECTED_AND_REMOVED_draft-droms-agentopt-8021x-00_VIRINFO.TXT
>
>
>_______________________________________________
>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 06:37:56 -0800 (PST)

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. 

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

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

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

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

> it, to determinate more easily when the user is offline, and release the 

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/