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

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

Eric thanks for sending this and that says a lot and good you said it.  I believe ERic no IPR should be permitted in the IETF at all.  I know I will never win that battle and don't want to start it again.  I think with all the IPR here eventually the IETF will loose yet another founding principle that is not written down but open systems standardization environment.

Alper I think you need to respond to this now in the community ????????????

/jim

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[e-mail]]
> Sent: Tuesday, December 04, 2007 9:23 AM
> To: Bound, Jim; Alper Yegin
> Cc: [e-mail]
> Subject: RE: [Int-area] Why IETF should not standardize dhcp-auth
>
> IPR free is better, yes.
>
> But Alper himself is the sole inventor of US Pre-grant 20070028092:
> "Method and system for enabling chap authentication over PANA
> without using EAP"
> http://tinyurl.com/38k62e
> If he has disclosed this on the IETF IPR site, I cannot find
> it.  This is even after I directly emailed him about the
> problem in October (see below).
>
> It sickens me to see Alper claiming PANA as "IPR free".
>
> BTW: Alper's is not the only PANA patent submission you will see at:
> http://appft1.uspto.gov/netahtml/PTO/search-bool.html
>
> Eric
>
> -----Original Message-----
> From: Eric Voit (evoit)
> Sent: Friday, October 19, 2007 12:00 PM
> To: Pekka Savola; Alper Yegin
> Cc: 'Internet Area'
> Subject: RE: [Int-area] DCHP-based authentication for DSL?
>
>
> > From: Pekka Savola, October 19, 2007 5:10 AM
> > To: Alper Yegin
> > Cc: 'Internet Area'
> >
> > On Fri, 19 Oct 2007, Alper Yegin wrote:
> > > There does not appear to be a strong justification to
> hack DHCP the
> > > way you are proposing. Many people spoke against that already.
> >
> > FWIW, Cisco has claimed IPR on the DHCP solution:
> >
> > http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-pruss-dhcp-auth-
> > dsl-00.txt
> >
> > I wonder if other solutions are similarly affected.
> >
> > Just something to chew on when looking at potentially applicable
> > solutions...
> >
>
> Well, since you brought it up...
>
> Binding of DHCP and PANA...
> http://tinyurl.com/yvjx9l
>
> Triggering DHCP actions from IEEE 802.1x state changes...
> http://tinyurl.com/2avgk2
>
> If you spend ten minutes on the USPTO website, you will
> quickly see that all of this technology has claims on it, far
> more than on the IETF IPR website.
>
> http://www.uspto.gov/patft/
>
> "Results of Search in US Patent Collection db for:
> (DSL AND Authentication): 953 patents."
>
> "Results of Search in US Patent Collection db for:
> ((EAP AND Network) AND Access): 146 patents."
>
> At least Cisco disclosed its IPR to the IETF.
>
> Eric
>
>
>
> > From: Bound, Jim, December 04, 2007 8:42 AM
> >
> > 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
> >
>
>
> _______________________________________________
> 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