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

["Haines Wolfe" <[e-mail]>]

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 <[e-mail]>
>To: [e-mail]
>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: [e-mail] [mailto:[e-mail]]
>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:
>	[e-mail].
>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
>[e-mail]
>http://www1.ietf.org/mailman/listinfo/dhcwg


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


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