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

["Bound, Jim" <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, December 04, 2007 1:45 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area
>


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