Curtis Sherbo wrote:
> ... The BRAS will not install a
> forwarding entry for a subscriber that it has not learned through the DHCP
> process. Forwarding entries are then built based on the assigned IP address
> and the requesting MAC.
Ah. That wasn't clear from the draft.
> 3) Service providers typically do not want to allow configuration of a
> client until they are authenticated. Often because they will provide
> alternate configuration depending on their identification.
That's fine. Can they use EAP?
> 4) The goal of draft-pruss-dhcp-auth-dsl is to provide an option for service
> providers to maintain their investment in their current AAA infrastructures
> with little or no changes to them. I don't believe it is intended to alter
> DHCP server implementations, but rather proxy/relays/servers that are
> implemented in BRAS platforms. I suppose this is really the area for
> debate.
The draft could be implemented by having the relay filter & edit DHCP
requests. That's awkward, though, and possible only because the DHCP
packets are unsigned....
> 5) Client side implementations that would require modification are typically
> in the control of the service provider. They may be a managed residential
> gateway, or a dsl modem. User owned equipment is typically not allowed to
> authenticate the PPPoE session today, I would see this as being no
> different.
An alternate solution that would achieve the same goal, but wouldn't
require piggy-backing authentication onto DHCP would be to use EAP.
EAP-MD5 is already supported by all supplicants, and is just CHAP.
Using EAP also permits the authentication methods to be updated without
modifying DHCP.
The only problem is that wired authentication does not have the
equivalent of wireless systems broadcasting SSID's. That problem can be
addressed via the following method.
1) Client sends a DHCP DISCOVER or DHCP request
2) relay (BRAS) responds with "DHCP AUTH required"
This would be a new DHCP message, containing a list of
authentication domains (read: SSIDs).
3) Client does EAP to BRAS
4) on EAP success, client performs DHCP again.
The downside to this approach is that it requires more code on the
client and on the BRAS than just putting CHAP into DHCP. The upside is
that I think it may get wider acceptance than CHAP inside of DHCP. It
leaves authentication to EAP, and network configuration to DHCP.
i.e. one of the widely acknowledged problems in performing EAP
authentication for wired networks is the inability to know that EAP is
a requirement. A related problem is that even if the client knows EAP
is required, it doesn't know which network it is connected to, and
therefore which credentials it should present.
With this approach, it's clear that the BRAS is blocking all DHCP
traffic, and not rewriting packets. It's also clear that DHCP servers
do not have to change. DHCP clients have to change, but hopefully
minimally, and only to kick-start an EAP session when a DHCP "Auth
required" packet is received. The existing client DHCP timers for
retransmits, etc. could even be left alone, as the EAP session *should*
finish before the next DHCP request is sent.
If this appears to be a viable approach, I can write up a draft this
coming week.
Alan DeKok.
_______________________________________________
Int-area mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/int-area
