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

[Yoshihiro Ohba <[e-mail]>]

Eric,

On Tue, Dec 04, 2007 at 11:27:50AM -0500, Eric Voit (evoit) wrote:
> I can certainly find a claim which would be needed by the DSLF.  I need
> go no farther than Claim 1 of binding of DHCP and PANA... 
> http://tinyurl.com/yvjx9l 
> 
> "1. A method for binding dynamic host configuration and network access
> authentication, comprising: providing a network access authenticator to
> authenticate at least one client device; providing a dynamic host
> configuration server to dynamically distribute IP addresses for client
> devices; maintaining synchronization of an authentication session
> between the at least one client device and the network access
> authenticator and a dynamic host configuration session between the
> dynamic host configuration server and said at least one client device
> when either an authentication session or a dynamic host configuration
> session is lost."
> 
> So while neither DHCP nor PANA are encumbered by this specific claim,
> making any usable deployment incorporating the two is.  

I think a deployment is possible without necessarily maintaining
synchronization between an authentication session or a dynamic host
configuration session when either session is lost, unless the
authentication session generates a key to secure the dynamic host
configuration session.

Yoshihiro Ohba

> This puts it in
> the exact same position as DHCP-Auth & 802.1af in terms of IPR
> implications for deployment.
> 
> Eric
> 
> 
> > -----Original Message-----
> > From: Bound, Jim, December 04, 2007 10:25 AM
> > 
> > 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
> 
> 


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