As a member of the DSL Forum, I second this analysis. I think it is fine to present a proposal in a liaison, but I agree that the requirements below are not met as presented in the Analysis.
Regards, Curtis Sherbo -----Original Message----- From: Wojciech Dec (wdec) [mailto:[EMAIL PROTECTED] Sent: Thursday, December 06, 2007 9:11 AM To: Alper Yegin; [email protected] Cc: Mark Townsley (townsley); Jari Arkko Subject: [Pana] Re: DSLF Requirement analysis Hi Alper, Pana WG, on looking through the assessment of PANA against the DSLF requirements, which I have participated in laying down at the DSLF, I have to express a good number of issues wrt to the conclusions/justifications presented. I really cannot agree with statements put forward in the conclusion statement. The main issues specifically are: IPAuth-4 Must allow for authorization purposes the use of any additional identifiers that may be available, eg MAC address, Option82 circuit-id. PRESENTED ANSWER: Yes. MAC address is already available on the IP messages that carry PANA. PANA does not prevent use of Option 82 with DHCP. ISSUE: There is a fundamental problem in this assessment in that it assumes that DHCP Option 82 authentication will happen *separately* from PANA authentication or that somehow a mechanism will be implemented that allows PANA authentication to retrieve some cached DHCP option info (more on this later). This is either effectively double authentication with double the Radius messaging load, or a significant complication for BRASes. It is contrary to the spirit of the requirement which says that at (single) authentication additional parameters like client MAC address and/or Option 82 must be available. IPAuth-6 Must fit into TR-101 operational model PRESENTED ANSWER: Although we do not see any issues there, IETF does not have the expertise to fully evaluate this requirement. ISSUE: The TR-101 operational model, as any DSL operator's model, revolves around a familiar access protocol toolset composed primarily of; PPP, PPPoE, DHCP, Radius. Introducing a totally new protocol, coupled with additional device configuration, etc, to this mix has a fair bit of operational impact on an operator. This is a very pragmatic issue, but very relevant. PANA clearly suffers from this issue, and it doesn't require specific expertise to see this. IPAuth-9 Should be simple to implement on client (PC or CPE) PRESENTED ANSWER: Yes Implementation does not require changes to the operating system. Open source implementation available. ISSUE: I believe there are overlooked OS impacts here. PANA requires that a short, but not too short, temporary DHCP ip address lease for authentication be granted before the second post-PANA DHCP lease is granted. The OS must be able to handle this IP address and config change without disrupting applications above. If the temporary IP address lease is presented to the OS for use by applications other than PANA, and then shortly thereafter revoked, visible disruptions to applications may occur as sockets are reset, applications which received (or did not receive) proper config information in the first DHCP lease may not receive or be able to handle this config change without some timeouts, etc. (think about what happens to some OSes when you try to move from one subnet to another and receive a new DHCP lease). Bottom line, the IP address to IP address and lease to lease transition has a lot of potential for race conditions that could affect applications on the OS. One way to mitigate this would be to not present the first DHCP lease information to any application other than EAP, but of course this likely requires OS changes. IPAuth-14 Must allow for authentication and download of subscriber service profile before service IP address is assigned PRESENTED ANSWER: Yes PANA requires an IP address be configured prior to authentication (a IPv4/IPv6 link-local, or a short-lease DHCP address), but allows the "service IP address" be assigned after authentication. ISSUE: As discussed on the int-area thread, assigning IP addresses (temporary ones) for authentication purposes and then changing them does not fit the operational model of DSL, breaks the security mechanisms used in the access network, and requires that the BRAS and client OS be resilient to on-the-fly IP address changes. Also possibly the DSLAM and L2 aggregation switches. Regards, Woj. > -------- Original Message -------- > Subject: DSLF Requirement analysis > Date: Thu, 6 Dec 2007 03:38:50 +0200 > From: Alper Yegin <[EMAIL PROTECTED]> > To: <[email protected]> > CC: 'W. Mark Townsley' <[EMAIL PROTECTED]>, 'Jari Arkko' > <[EMAIL PROTECTED]> > > > > In the spirit of analyzing the DSLF's Subscriber Authentication > Requirements as presented through a liaison letter on May 25, 2007, we > discussed the following material during IETF 70 PANA WG meeting. > > http://www3.ietf.org/proceedings/07dec/slides/pana-3.ppt > > We have reached consensus among the PANA WG members present in the > room. In order to make this an official WG consensus, we are running > this by the WG via mailing list. > > If you have any feedback, please send an e-mail on the mailing list by > December 11, 2007 Tuesday 6pm PT. > > If there is no objection, IETF PANA WG will send a liaison letter to > DSLF based on this consensus. > > - IETF PANA WG Chairs > > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
