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?
As a Service Provider I can say that architecture considerations done in DSLF
are mainly driven by the evolution of the already deployed solutions for IP
Sessions: infect in order to gradually migrate from PPP based to IP based
Sessions many SP's today already use a naïf form of
identification/authentication based on line ID carried on DHCP w/option 82.
Using DHCP w/option 82 as credential for authentication lacks in flexibility
because line ID is automatically inserted by the Access Node and restricts the
authentication to the DSL Line so it does not allow performing authentication
based on username and password, but it can be seen as good starting point to
develop a complete solution starting from an existing and already used
approach. Basically DHCP is the protocol already involved in the IP Session
creation because used for configuring the IP address, and it is the protocol
that is currently allowed to transit across Access Node before authentication
process completes; adding Authentication mechanism to the DHCP protocol could
be seen a way to fill the gap currently present for username/password
authentication capability keeping the same behavior provided by PPP: subscriber
authentication done before IP Address allocation. In addition considering the
impacts on other network elements, DHCP Auth impacts the Residential Gateways
(RGW), end user devices and BNG (Broadband Gateway/L3 edge) requiring an
extension of a protocol already present on these devices, but it does not
require any change to both AAA infrastructure allowing SP's to re-use currently
implemented RADIUS based architecture already in place for PPP, and it does not
require additional functionalities in the Access Node that can continues to
play the role of the DHCP snooping agent together with performing Layer 2
security functions (like preventing Layer 2 flooding, and DHCP spoofing
attempts.)
In summary I think IETF should take in account architecture aspects evaluated
by DSL Forum and work on DHCP Authentication proposal as a solution that can
fulfill these requirements.
Thanks and Best Regards,
Roberta
-------------------------------------------------------
Roberta Maglione - CCIE #18425
Telecom Italia
Broadband Network Services Innovation
-------------------------------------------------------
--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and
may contain confidential information. If you have received the message in
error, be informed that any use of the content hereof is prohibited. Please
return it immediately to the sender and delete the message. Should you have any
questions, please contact us by replying to [EMAIL PROTECTED]
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
