On 4-okt-2007, at 22:22, Jari Arkko wrote:
How do we feel about this? Is this a good idea, considering the DSL architecture? How will it affect DHCP the protocol? How would you go about making DHCP extensions so that they work best for all possible environments and not just DSL? Is anyone already working on the combined draft promised above? Are there any other choices that we should recommend instead?
Let's start with the last question first: there is no discussion of IEEE 802.1x and why that would be insufficient here. Both drafts seem to be written to make things as easy as possible on the DSL service providers and their vendors without much consideration for the migration issues this would impose on end-users. DHCP clients are generally not a user serviceable part in the most popular operating systems and home gateways. This makes using something that is available today, such as 802.1x, highly preferable.
The other thing that is missing in action is IPv6. I think it's irresponsible to deploy any new technology that's IPv4-only at this point in time. For this reason, too, it's highly preferable to use a non-IP based authentication protocol.
There is some discussion in one of the drafts about what the client would be, but the discussion is not very illuminating. In my experience, there are two ways of connecting to DSL networks: with a simple modem, that doesn't do much except some protocol translation, and with a home gateway/router with the modem function built in. In the former case, the modem generally passes authentication protocols through more or less transparently, so any device connected to the modem, such as a PC or a home gateway/router without the modem function built in, will have to engage in authentication directly. In the case of the integrated home gateway, the authentication credentials would be configured on the gateway and client PCs wouldn't have to run the authentication protcol.
If PCs are expected to run the authentication protocol, I have two issues (in addition to the ones already mentioned, of course). The first is that, assuming the same options are defined for IPv6, I would oppose a de-facto requirement that all IPv6 hosts run DHCPv6. (Or DHCP for IPv4, for that matter.) For IPv4 hosts, the requirement to run DHCP doesn't seem excessive, considering current practice. The other issue is how the authentication is started. If client is expected to initiate authentication in the first message, this means it's not possible to have a client that can seamlessly connect to multiple networks that require authentication because the client wouldn't know which credentials to use at any given time. Also, being easily prompted to send credentials would be a security isssue: an attacker could initiate frequent DHCP exchanges to harvast hashed credentials. (Experience with WEP shows that this can be detrimental under certain circumstances.) So a mechanism where the server authenticates itself to the client would be a lot better.
Also, one of the drafts mentions MD5, which is pretty much dead in the water with a huge hole in the hull right now, it's only a matter of time until it officially sinks.
Further, I'd like to see a more general mechanism. Another situation where users need to provide credentials that can benefit from better standards are wifi hotspots. This situation is largely similar to the DSL situation with the exception that there is often no direct relationship with the operator of the hotspot and the user, so the user must either select a roaming partner and provide credentials appropriate for that roaming partner, or use some other interactive method to gain temporary access (scratch cards, credit card transactions).
This suggests that a mechanism where unauthenticated users are given temporary access to a walled garden and then full access at some later point would be more appropriate than a simple success/fail authentication method.
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
