Hi,

>   There are large benefits to doing this.  The client gets assigned an
> IP from a known and trusted source (the AAA server he's authenticating
> to).  The NAS gets an IP from a known and trusted source (the local AAA
> server).  Everyone is happy.

An interesting thought.

>   e.g.
>
>   supplicant      NAS      AAA server
>     --------------->                   Can I gain access?
>                    ---------->         Permit user on the net?
>              <----EAP--->              Lots of packets...
>                    <------------       AAA:  "IP 192.0.2.10"
>     <----------------------------      TLS tunnel: "IP 192.0.2.10"
>     <-------------->                   Surfs the net...
>
>   In a roaming environment, it's just as easy.  The local AAA server
> sends the home AAA server the IP it wants to allocate to the user, and
> the home AAA server puts that into the TLS tunnel:
>
>   supplicant      NAS      Local      home AAA
>     --------------->                         Can I gain access?
>                    ---------->               Permit user on the net?
>                              ----------->    Please assign IP 192.0.2.10
>                              <-----------    ACK's the IP 192.0.2.10
>                   <----EAP--->               Lots of packets...
>                    <---------                AAA "IP 192.0.2.10"
>     <-----------------------------------     TLS tunnel: "IP 192.0.2.10"
>     <-------------->                         Surfs the net...
> 
>   Comments?  Sticks and stones?

Poking it with a stick.

First, there is lots of precedence for assigning IPs from AAA of course. 
Framed-IP-Address and friends are used happily in PPP. It leads to a question 
though: with DHCP, more information than just the IP address is transmitted. 
Default GW, DNS, maybe WINS-servers, you name it. So a concept like the one 
you pictured requires duplicating all of DHCP within EAP methods if it is 
supposed to completely replace DHCP.
Also, backwards compatibility comes into play when local AAA tries to send its 
attributes of choice to home AAA and that one doesn't have the capabilities 
for EAP. Some fallback mechanism would be needed, and one that makes sure 
both mechanisms don't assign the same IP inadvertantly. Database-backed DHCP 
and sth like your own products "sqlippool" come to mind.

Policy-wise, are people happy with transmitting their, say, WINS servers from 
local to home AAA or do they consider that not-your-business details? I 
honestly don't know. They happily tell it their clients with DHCP after all.

Hm, actually, most of the things transmitted with DHCP exist in an attribute 
for RADIUS already, probably mostly because of its PPP usage. So the 
local-to-home way might not be so difficult after all.

Greetings,

Stefan

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [EMAIL PROTECTED]     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to