1

DHCP Authentication DHCP Authentication DiscussionDiscussion

INTAREA meeting, 70th IETFINTAREA meeting, 70th IETFVancouver, CanadaVancouver, Canada

Jari Arkko and Ralph DromsJari Arkko and Ralph Droms

2

Outline

• Introduction and background

• DSL community needs & proposal (Ric)

• Summary of discussion and analysis

• Discussion

3

Introduction and Background

• Moving away from PPPoE in DSL

• But still keeping some of the business models and infrastructure

• DSL Forum liaison to IETF (Jul & Oct)

• A number of different potential approaches (802.1X, PANA, DHCP, ...)

• Considering DHC recharter

• Other SDOs and extensions

4

The Desired Outcome of Discussion

• Present the proposal on the table

• Discuss the architectural and protocol implications

• Sense of the room on the direction:– Yes/No for doing DHCP work on this– Maybe also guidance on alternatives (if no)

and details (if yes)• Decisions on list

5

Content

• Issues to think about

• Requirements from an IETF perspective

• Way Forward

6

Issues to Think About (1/2)

• Moving away from PPPoE is good• Freedom to carry your CPE device to a

location of your choosing is good• IETF specification of extensions in this

space is good, as opposed to vendor specific solutions

• Multi-SDO coordination can be fun

7

Issues to Think About (2/2)

• Potential solutions– Layer 2 solutions (IEEE liaison)– IP layer network access control solutions (PANA)– Subscriber authentication in DHCP with either CHAP or EAP

• DHCP drafts are in very early stages– Need significant work– Not here to discuss details – focus on architectural impact of

doing something in a particular way

• Solutions cannot be evaluated merely by their e2e behaviour– The architecture at the home site matters (CPE vs. hosts)– Ability of the network in between to deal with the required

signalling (1X, PANA, DHCP)– Future developments matter (IPv6, other updates, etc.)

8

Challenges in DHCP Solutions (1/2)

• Securing the DHCP transaction vs. using DHCP for access control– Preventing configuration does not prevent

access if manual configuration is possible– Access to link vs. beyond the link

• A DHCP-based solution does not work with hosts that employ stateless IPv6

• Server vs. relay responding to messages

9

Challenges in DHCP Solutions (2/2)

• Retransmission responsibility on the client vs. server side

• CHAP vs. EAP

• A number of other issues from the list:– MTU issues, OFFER vs. ACK, key binding, session ids, ...

10

Acceptable Solution Requirements

• MUST solve the detailed technical issues• MUST NOT place requirements on hosts:

– Requiring hosts to support DHCP AUTH– Requiring all IPv6 hosts to support DHCPv6

• MUST handle both IPv4 and IPv6• MUST be able to deal with backwards

compatibility issues & fit the state machine• MUST accurately describe the limitations

and applicability of the solution• MUST conform to existing DHCP RFCs

11

Way Forward

• Discussion now• Sense of the room on the direction:

– Yes/No for doing DHCP work on this– Maybe also guidance on alternatives (if no)

and details (if yes)• Consensus call on the list• If a DHCP-based approach is chosen,

revise draft and recharter DHC WG to include this effort

• If not, we will ask DSL Forum to think about other solutions (such as 802.1X)

12

Background Material Slides

13

Current status and analysis• DSLF liaison statements have been discussed on int-area

mailing list:www1.ietf.org/mail-archive/web/int-area/current/

– Initial question: msg00957.html– Followup: msg01171.html– Followup: msg01215.html

• Discussion has not demonstrated rough consensus either to accept or to reject the DSLF liaison statement request to develop extensions to DHCP

• Some detailed reviews of the specific proposal– Arkko: msg01245.html– Aboba: msg01257.html

14

Liaison Statement 2

"At this time, we would like to make the IETF aware that during our most recent DSL Forum quarterly meeting, the Architecture and Transport Working Group agreed to seriously consider adopting a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt or draft-zhao-dhc-user-authentication-02. We understand that the authors of these specifications intend to produce a combined document soon. The DSL Forum formally requests that the IETF adopt this as a work item, and would appreciate being advised of progress as soon as possible.”Combined draft: draft-pruss-dhcp-auth-dsl-02.txt

15

Questions We Asked When the Liaison Was Received

• How do we feel about this [request]?• 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?

• I would like to hold the discussion on this [request] in [the int-area] list until we've determined that the DHCP protocol is the right tool for the job.

16

Other

• Draft-iab-ip-config by Aboba and Thaler• Slides from Dave Thaler's DHC WG

presentation in IETF-68• There is an IPR declaration on draft-

pruss