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:[EMAIL PROTECTED] > Sent: Tuesday, December 04, 2007 9:23 AM > To: Bound, Jim; Alper Yegin > Cc: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > > Sent: Tuesday, December 04, 2007 1:45 AM > > > To: [EMAIL PROTECTED] > > > 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 > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
