RE: L2tpext Digest, Vol 15, Issue 4

Ignacio,

Thank you for the review. 

Please see my comments inline [mvk]

Thanks
Mahesh


------------------------------

Date: Tue, 26 Jul 2005 17:55:57 -0700
From: Ignacio Goyret <[email protected]>
Subject: Re: [L2tpext] Extending the Proxy Authen AVPs for Extensible
	Authentication Protocol (EAP)
To: Mahesh Kelkar <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"

Mahesh,
Great work for a first cut! Thanks for putting the effort in writing
this draft.

A few comments:
1) You should only describe the values for EAP. Let the other protocols
   be defined by RFC2661. Duplicating the information on that RFC will
   only lead to confusion.
   ie, instead of copying the section for "Proxy Authen Type (ICCN)"
   and showing all possible values, simply state that a new value is
   used for EAP. Same for the other AVPs.

[mvk] Proxy Authen AVPs' details were duplicated to provide the
collective description. The contents of Proxy Authen AVPs were not
altered except for the new EAP additions. However, if its not a common
practice I will fix it as per your recommendation.

2) I believe that your appendix A should be most of the gut of this
draft.
   Consider moving it into its own section.

[mvk] ok.

3) It seems your Scenarios are a little too restrictive and not very
   realistic. For example, Scenario III assumes that the LAC will not
   perform any PPP authentication, which necessarily requires a new LCP
   negotiation cycle (due to different authentication requirements).

[mvk] Each scenario identifies a unique case and describes the EAP
behavior for each one of them. To define all these unique cases I have
added all these restrictions.

[mvk] Scenario III discusses a case where LAC negotiates EAP in LCP; but
uses the physical identifier as a username and hence does not require an
EAP Identity exchange. LAC manufactures the EAP identity response using
the available username and sends it to the backend authentication server
on the LAC. 

[mvk] Use of physical id as a username is identified as a possibility in
the EAP RFC 3748, Section 2 - [1]. Realistically, it may not apply for
tunneled EAP case. 

4) In Scenario I, the LAC does not seem to do any authentication,
   just send an EAP message and that's it? How would it know that
   the user is a valid user if the authentication is not allowed
   to conclude?

[mvk] Due to the limitations discussed in the Scenario IV, we cannot
have LAC negotiate the EAP authentication. 
1. LAC should trust the packets received on the PPP link and use the
username received in the EAP Identity response.
2. LAC should be configured to tunnel the user just by looking at the
username (ex. domain name)


5) In Scenario IV, the LAC should NOT send an EAP Success. If it did so,
   it would be allowing the client to proceed to the Network phase of
PPP.
   The whole point of proxy authentication is to give the LNS a chance
   to avoid an LCP renegotiation.

[mvk] On the receipt of EAP success the peer will start the Network
Phase in PPP. And on the receipt of next EAP request packet from the
LNS, the peer will start the re-authentication. The re-authentication
will work, only if  EAP authentication method supports it. If the EAP
authentication method does not support it then it can result into the
PPP interface termination or LCP re-negotiation. This is one of the
reasons that we do not support and recommend scenario IV.


This is a good start, but it needs more work.

Cheers,
-Ignacio

At 10:51 7/25/2005 -0700, Mahesh Kelkar wrote:
>
>This draft defines a new Proxy Authen Type for EAP and
>defines the contents of Proxy Authenticate Data for EAP.
>
>Please see the appendix for the "possible
>configurations/setups". It discusses different scenarios
>for the EAP hand-off.
>
>Your thoughts and comments would be greatly appreciated.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-kelkar-l2tpext-eap-proxy-auth
en-ext-00.txt
>
>Thanks
>Mahesh