Jari Arkko wrote:
James,
I will venture a guess here: they don't want to deploy a new protocol.
It would be good to get the exact details from Ric or Mark or whoever
knows them. But my understanding is that their desires relate to
the following:
Good summary, Jari, I only have a bit more to add.
[In the interest of disclosure, I am fairly active in the DSL Forum, and
have been working in an advisory role with Ric and others on DHCP auth.
Suffice to say, I'm already fairly convinced that something like this is
necessary, or at least inevitable, given what I know about current DSL
deployments and trends. So, with individual contributor hat firmly in
hand....]
- Moving away from a user/password authentication that the
PPPoE users had would require changes in the business
processes, e.g., relying on line ID only.
Another part of the process is that the authentication stage needs to
happen before an IP address is assigned, and ACLs installed throughout
the network (by snooping the DHCP packets in transit) to allow packets
to/from that IP address to be sent and received.
And it would be a good thing to be able to move around with
your subscription. Assuming of course that the lower layers
in the DSL system are capable of allowing that without
some configuration.
In addition, is the requirement to support more than one device
(typically a Set-Top-Box) over a single subscriber line in "bridged"
mode between the STB and the BRAS. In the latter case, both line-id
credentials inserted by the DSLAM and credentials from the DHCP client
are used.
There is also the case where, due to the nature of the way the network
is operated and other circumstances, relying on the line id in the DSLAM
is not possible.
(And of course, its also a Good Thing to move away from
PPPoE... we should support that.)
- Moving away from AAA-based authentication would imply
changes in how subscriber data is managed and served.
- DSLAMs are already looking at DHCP packets and filtering
them appropriately. A new protocol would require changes
in DSLAMs.
- 802.1x runs between a port and a switch, I think this means
that in the DSL world this would translate into a requirement
for the DSLAM rather than the BRAS performing the
authentication.
The above two points center around the need for the authentication
protocol to operate over networks which may be ATM, Ethernet, a
combination of the two, have one or more DSLAMs and agg switches, etc.
DSL networks around the world have a variety of different architectures
at L2 and below.
- Practical implementations on the BRAS side currently do
the option 82 processing in the DHCP code, so new processing
steps for related purposes are convenient to have in the
same part of the code.
Use-cases require information which is currently presented to the BRAS
in the DHCP Discover, indicating a need for tight coupling with DHCP,
regardless of the packaging.
- Mark
The different reasons have a different nature. The first two
items do not imply that a DHCP-based solution is needed, just
that some AAA-based approach is. Last item is more about
convenience than anything else. Not sure what would be
involved in the third and fourth items.
Jari
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
