[Int-area] RE: dhcp-auth IPR (was RE: [Int-a] Why IETF should not standardize dhcp-auth)

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

Thanks Alper I concur derivative works are not incumbent and it is actually nice that derivative works are identified and that should not be required by the IETF.  None of the IETFs  business if not in the spec.

/jim

> -----Original Message-----
> From: Alper Yegin [mailto:[e-mail]]
> Sent: Tuesday, December 04, 2007 10:07 AM
> To: 'Eric Voit (evoit)'; Bound, Jim
> Cc: [e-mail]
> Subject: dhcp-auth IPR (was RE: [Int-area] Why IETF should
> not standardize dhcp-auth)
>
> Eric,
>
> Can you find any IPR on the PANA specification
> draft-ietf-pana-pana or any other essential specification
> that is a dependency for DSLF or any other SDO,etc. to implement PANA?
>
> That's the question.
>
> What you found below, and Toshiba's IPR are not on such
> specifications.
> Those are just derivative works, none of which needs to be
> implemented by DSLF. And no IETF work is impacted by them.
>
> So, DSLF can implement the PANA solution without being
> encumbered by IPR.
> That's the bottom line.
>
> The same cannot be said about draft-pruss-dhcp-auth-dsl-02
> because the IPR is right on that I-D.
>
>
>
>
> Alper
>
> > -----Original Message-----
> > From: Eric Voit (evoit) [mailto:[e-mail]]
> > Sent: Tuesday, December 04, 2007 4:23 PM
> > 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