I support strongly Alper below and anytime we can avoid an IPR solution vs. IPR free we should always select the IPR free solution given they both resolve the problem. I am also not convinced DHCP should be used for net access authentication.
Best, /jim > -----Original Message----- > From: Alper Yegin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 04, 2007 1:45 AM > To: [EMAIL PROTECTED] > Subject: [Int-area] Why IETF should not standardize dhcp-auth > > > There are several concerns against standardizing > draft-pruss-dhcp-auth-dsl-02. > > > 1. Architectural > > When it comes to solving "distinct" fundamental problems > (e.g., access > auth, mobility, configuration, QoS), IETF defines > "distinct" protocols > for each. Piggybacking one over other for the sake of some > optimization > (product/performance/etc) conflicts with the strategy we have been > following at IETF. > > IAB document draft-iab-ip-config-00.txt is clear on that: > > Network access authentication is a distinct problem > from Internet > host configuration. Network access authentication is > best handled > independently of the configuration mechanisms in use > for the Internet > and higher layers. > > > 2. IETF principle > > IETF has already defined a solution for the problem: PANA. As a > principle, IETF should first make an attempt to see if it > really does not > > solve the problem and consider refining its protocol if necessary. > Defining a new protocol each time someone has another > solution is not > compliant with IETF's principle goal of achieving interoperability. > > PANA already satisfies the requirements we received from DSLF. > > > 3. Breaking DHCP > > EAP and DHCP do not stack up well because none of the end > points, state > machines, call flows match. And the proposal ends up breaking DHCP. > Specifically: > > - DHCPOFFER does not deliver IP address, despite RFC2131 saying: > > The server MUST return to the client: > > o The client's network address, as determined by the rules given > earlier in this section, > > - DHCP relay is inserting DHCP options (CHAP, EAP) when relaying > messages to the DHCP client. Relay is not supposed to do that. > > - DHCP server receives the DHCPREQUEST but it does not respond to > it. Instead, DHCP relay generates the DHCPACK/DHCPNAK > (See Figure 3). > > - DHCP relay is generating DHCP messages (see Figure 5). Relays > are not supposed to do that. Although not documented yet, same > misbehavior is needed for EAP retransmissions, and > re-authentication. > This is turning DHCP into a 3-party protocol. > > - RFC3118 cannot be used when DHCP relay inserts options > towards DHCP > client, removes options towards DHCP server, consumes > some messages, > generates some messages. Basically, this is breaking the > end2end model. > > - DHCP server does not see the DHCPREQUEST, as it is consumed by > the relay (see Figure 5). > > > 4. Failing DSLF requirements > > Despite the clear statements in the DSLF requirements, > this proposal is > not supporting authentication of the devices behind the HGW (CPE). > Instead, authors are denying the requirements: > > IPAuth-8 Must handle L3 CPE device authentication and > end-device > (PC) > user based authentication (likely with L2 CPEs > in the latter > case) > > IPAuth-9 Should be simple to implement on client (PC or CPE) > > This is because it is not possible to modify deployed PC > stacks with > that solution as DHCP is an internal part of the operating > systems. On > the other hand, PANA can be supported at the application > layer and it > does not require change to the IP stack. > > > 5. IETF's IPR strategy > > IETF has already produced an IPR-free solution to this > problem: PANA. Why > > should IETF not recommend use of PANA but instead rubber stamp an > IPR-encumbered solution? > > > 6. Community pushback > > Several people (excluding all PANA-related people) already > spoke against > it. > > > Under the light of these issues, it is not clear why IETF is > even considering standardizing such a solution at this point. > > DSLF in its liaison letter said they were "seriously > considering" using this solution, not like "demanding it be > standardized." It's perfectly fine if IETF analyzes the > solution and concludes it has serious issues, and responds > with another alternative for DSLF's consideration. > > Regards, > > Alper > > > > > _______________________________________________ > 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
