Wojciech, I see some times your points are digressing from what the requirements are talking about. We shall discuss other things separately in order to keep the focus on the requirements. I'm not saying they are not important; I'm saying those discussions outside the scope of the requirements do not impact the response IETF PANA WG is preparing in response to requirements.
DSLF is free to expand the requirements and request PANA WG to work on it. In fact I'm hearing that members are taking additional requirements to next week's DSLF meeting. > > > 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. BRAS learns the Option 82 via DHCP and Home AAA learns via RADIUS. What dedicated mechanism are you referring to? > 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. We followed up on that thread in int-area list. Have you read it? Please indicate where you disagree on that threat. Meanwhile, your above points are diverging from the requirement. > 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. Let me be a bit more elaborate on that. AAA client on the BRAS learns the expected value (or values??) from AAA server during network access authentication. DHCP follows access authentication. During DHCP, BRAS learns the used value from network device (DSLAM, etc.) via DHCP. And BRAS does the comparison to see if they match. > In any case, the local link address option is a non > starter for IPv4. PANA does not satisfy this requirement. You should explain why IPv4 link-local is a non-starter. > > > > > > > > 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. Requirement has nothing to do with whether a new protocol can be added or not. Again, completely missing such a requirement. If you have issues with the requirements, you shall convince DSLF to modify it? > > > 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). Discussed above. > Then, 2a does not meet the criteria of assigning a useful IP > address after authentication. Yes, option 2a's applicability is limited to those deployments/scenarios that do not rely on AAA-delivered IP address. [There's a workaround to this issue if DSLF is willing to accept going to AAA twice: Once for during DHCP; second time during PANA] > And all of 2, as mentioned earlier, due to > the short DHCP leases are OS impacting. Nothing to do with the OS. It's a configuration on the DHCP server to set the lease time. > 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 It's talking specifically about "Microsoft Windows NT DHCP Service". Is complying with "Microsoft Windows NT DHCP Service" deployment guidelines part of DSLF requirements? Can you figure out the technical essence, necessity of what they are saying? They even say "Additionally, a DHCP Administrator may want to assign a shorter lease time to scopes with low ratios of availible addresses. Setting the lease time shorter in both these cases will increase the availiblity of addresses." > > > 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. I gave Solaris as an example that I'm familiar with. We need to check other OSes if they support the same. If the same feature is available, it is usable this way. If not, it's still OK -- see Yoshi's response. > 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... www.opendiameter.org Project includes PANA implementation. Do you see something in that implementation such that it shall not qualify as "open source"? If so, we can reconsider making such a statement. > > > 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) Can you, please, answer this question that I'm asking you for the 2nd time and other DHCP-auth supporters for the 4th time: Whatever problems you are seeing with the client being configured with an IP address before it is authenticated, how does it work with DHCPv6 given that the client is configured with IPv6 link-local address before it initiates DHCPv6? Alper > > -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
