Alper, your reply does not contain any new items that change my disagreement wrt to the PANA assessment. The issue appears to be in the effort to ignore, or severely short change, the additional operational costs that PANA is bound to introduce, along with the impact to existing devices due to the extra complexity.
> -----Original Message----- > From: Alper Yegin [mailto:[EMAIL PROTECTED] > Sent: 06 December 2007 13:49 > To: Wojciech Dec (wdec); [email protected] > Cc: Mark Townsley (townsley); 'Jari Arkko' > Subject: RE: DSLF Requirement analysis > > Wojciech, > > > 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. > > There does not have to be two RADIUS calls. > > If the pre-PANA address is configured via DHCP (as opposed to > being a link-local address), then the Option 82 is made > available to the authenticator but that does not trigger > RADIUS call. Instead, RADIUS call is triggered when the PANA > starts. So, the RADIUS call triggered by PANA can convey both > the circuit ID and also carry out the EAP authentication. So this avoidance of double authentication relies on what I refer to above as a dedicated mechanism that retrieves cached circuit-id info. It seems that this mechanism is likely to be more complex, and more operationally impacting then I originally thought due to the coupling between DHCP and PANA. The extra complexity stems from the need to keep (on the BRAS) track of at least; pre-PANA hosts that have not authenticated; pre-PANA hosts that have authenticated; post-PANA hosts that have authenticated; pre-PANA addressing assignments; post-PANA addressing assignment. This swapping of each host from one state to the other is enough to radically impact the session bring-up rate of any BRAS. This is a comment that has been expressed by all BRAS vendors, and somehow keeps getting ignored. Furthermore the need for an operator to be able to understand, configure, maintain and troubleshoot this mechanism, besides the added overhead of having to use the extra pre-PANA pools, is what impacts operations adversely. Based on my work with operational departments I can say that this mix is enough to dissuade many. I do not agree that PANA currently satisfies this requirement and my ISSUE with the assessment still stands. > > If the pre-PANA address is a link-local address, then again > PANA triggers the RADIUS call. And this time AAA can deliver > the expected Option 82 value to the network. RADIUS is not > triggered during the DHCP that follows PANA. > The expected value is checked against the incoming DHCP > message's Option 82 and verified. Not sure what you mean by "AAA delivers the expected Option-82 to the network"? AAA expects to hear that value from the network device, not the other way round. In any case, the local link address option is a non starter for IPv4. PANA does not satisfy this requirement. > > > > 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. > > You are saying a new protocol is a no-no. I don't see that > requirement anywhere. Perhaps if the equipment vendors were to pay operators to deploy, maintain and troubleshoot (i.e. effectively out source operations) then adding new protocols becomes a non issue. Any other arrangement is operationally impacting, which comes down to increased costs for the operator. The desire to remove PPP (an extra protocol) is a reverse example of this. I see no way that adding new protocol (like PANA) can claim not to increase it. Again, PANA does not match this requirement. > > > > 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. > > As we said, this is not a MUST. There are other options. But > to give you the full list: > > 1. PaC configures a link-local address, or 2. PaC configures > a short-lease DHCP address > 2.a. That address is same as what the PaC will use > after successful > authentication, or > 2.b. PaC will be configured a new IP address after successful > authentication. As stated earlier; local link addressing is a non starter (it doesn't even convey circuit-id, besides being something of a esoteric substance for IPv4). Then, 2a does not meet the criteria of assigning a useful IP address after authentication. And all of 2, as mentioned earlier, due to the short DHCP leases are OS impacting. Finally, this link actually reveals the truth about the unsuitability of DHCP-short leases on at least one popular OS platform (other implementations deriving from RFC 1541 are likely to have similar issues): http://support.microsoft.com/kb/158016 > > > 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. > > 1 and 2a have no problem. That's an assertion to which you're entitled, but based on the previously presented arguments I disagree. OSes are impacted, 1 is a no-go, and 2 introduces unnecessary complexity on the BRAS. > > 2b requires the OS to hide the interface from applications. I > worked on Solaris TCP/IP development. I know Solaris has a > way to mark an interface hidden -- so that it does not appear > to the applications that does not know it exists. I can see > if other OSes have similar features. OSes which has this > capability can also use 2b without impacting applications. Not everyone runs Solaris... Your statement contradicts the answer the PANA WG gave to this requirement, yet you don't admit so. Allow me to quote "Yes Implementation does not require changes to the operating system. Open source implementation available.". The open source topic is a red herring, as it all depends on what conditions are attached to it, and the policy of the implementers for using open source... > > > > > > 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, > > Can you point to the text that we are breaking? Please check the IETF70 SAVI BOF material. In the pre-PANA DHCP short-lease case IP traffic will flow between the client and the BRAS before authentication. This is enough to have broken a common L2 security mechanism, or require changes on the DSLAMs/Access-Nodes. Again, this requirement is not fulfilled by PANA without resorting to mechanisms that are un-realistic (and most likely broken) -Woj. > > And also explain how DHCPv6 that runs with link-local IPv6 > address is not a problem (by now I asked this question at > least 3 times here and there -- no > answer....) > > > and requires that the BRAS and client OS be resilient to > on-the-fly IP > > address changes. > > Already explained above. > > > Also possibly the DSLAM and > > L2 aggregation switches. > > Thanks. > > Alper > > > > > > > > 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
