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

["Eric Voit (evoit)" <[e-mail]>]

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