[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
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area