Re: [Int-area] Why IETF should not standardize dhcp-auth

[Yoshihiro Ohba <[e-mail]>]

With regard to IPR on PANA and DHCP, my company has submitted an IPR
statement related to the ongoing discussion on DSL authentication on
October 23, 2007 (the statement does not seem to have been uploaded to
the IETF IPR disclosure page yet, so let me attach a copy of the IPR
statement).  On the other hand, I am not sure whether the patent
application indicated in the IPR statement is essential to the DSL use
case being discussed.

Regards,
Yoshihiro Ohba



On Tue, Dec 04, 2007 at 08:44:49AM +0200, Alper Yegin wrote:
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area
> 

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area