First off, am I correct in assuming that you agree with the other issues you chose not to comment on and that you will be taking action to amend the assessment on these points specifically:
---snip--- Woj> There is nothing diverging in saying that the way PANA claims to meet this requirement comes at a significant cost of complexity (to both a BRAS, and to an operator), which is what is failed to be considered; PANA has no way of carrying circuit-id info defined today, and requires an assorted tightly coupled mechanism to be in place to meet the requirement. Woj> Try this exercise. The requirement states: Must fit into TR-101 operational model. Read TR-101, draw an operational model and see what components come up. I assure you that things like managing pre-PANA pools, handling pre-PANA authentication failures, configuring PANA, dealing with link local addressing, etc, will not be there, nor will you find any operator currently managing this items. It doesn't take a wealth of knowledge to see that PANA is a new operational item, and the assessment presented is not correct. Woj> One of the problems in the assessment is that it appears to respond to different requirements with different PANA deployment models (there are at least three - 1, 2a and 2b). Since an operator will only use one of these, the assessment should clarify which one is assumed in each case. ---snip--- and inline... > -----Original Message----- > From: Alper Yegin [mailto:[EMAIL PROTECTED] > Sent: 11 December 2007 12:54 > To: Wojciech Dec (wdec); [email protected] > Cc: Mark Townsley (townsley); 'Jari Arkko' > Subject: RE: [Pana] Re: DSLF Requirement analysis > > > BRAS learns the Option 82 via DHCP and Home AAA learns via RADIUS. > > What dedicated mechanism are you referring to? > > > > Woj> There needs to be a dedicated mechanism is the one whereby some > > software component on the BRAS needs to pick up info from the > > sw-component "caching" circuit-id info, when PANA is ready, > and shoot > > off the result to AAA. > > There is already such code extracting the Option 82 content > from DHCP message and "shooting off" to AAA with RADIUS, right? Woj> Right, all in an atomic operation. > > > All this coupling and coordination of components is bad news for > > session bring up time, troubleshooting, etc. > > You need to substantiate such claims with technical points. > Otherwise not sure what purpose such claims serve, especially > repeating them... Woj> I take it you're refusing to accept the fact that vendors experienced with building these products have concerns with what this technology involves. > > > > 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. > > > > Woj> This is indeed very novel. So in fact the first trip to the AAA > > server triggered by PANA delivers the circuit-id to the BRAS in the > > AAA response. Then DHCP triggers local Authorization at the > BRAS. This > > is even more tight coupling of mechanism in evidence, also > requiring > > an operator to make changes to Radius. The answer to another > > requirement actually claims that no Radius changes are needed! > > > "Must re-use existing SP Authentication infrastructure (use > Radius Database) ..." > > What we are talking about is carrying the already defined > RADIUS attribute (the one used for transporting Option 82 > payload) from AAA server to the client, as opposed to what's > already done now: from AAA client to the server. This does > not touch the RADIUS database at all. Woj> I see that you have not bounced this off any operator running large scale Radius set-ups today? Sending a circuit-id in an access-accept requires at least a change to an existing Radius set-up, and in some cases the server code; servers don't just do this automatically today, nor is this done (or required) for ppp access. I won't even mention things like Radius proxies. > > > > 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. > > > > Woj> A couple of non trivial issues: > > - Show me any SP using it for anything in broadband? (Link > local has > > been defined for small networks) > > You need to point out a specific problem. Saying that it is > not used so it shall never be used does not make any sense. Woj> The fact that it is not used impacts the operational model, so it is a valid point. > > > - Doesn't work in shared VLAN model where host-host L2 > forwarding is > > disabled (the conflict resolution mechanism doesn't work) > > Why not? So, you won't allow use of IPv6 link-locals either? > If there are real problems how do you expect IPv6 to work at all? Woj> You're throwing the IPv6 mantra back at me, while I'm telling you that IPv4 link locals won't work in today's L2 access and aggregation set-ups, or require extensive changes to the security mechanisms. > > > - Requires more changes on Access node to enable forwarding > > Again, just a claim without any technical explanation is not > useful for this discussion. Woj> Perhaps you could illuminate us on how you envisage that an access-node that is configured NOT to pass any IP traffic before seeing a DHCP assignment will be able to forward local link IP sourced addresses to the BRAS? > > > > 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. > > > > Woj> But the client is affected, eg DHCP stack... The assessment > > Woj> claims > > no such impact is there. > > You must have a different definition for "OS impacting." By > no definition of "OS impacting" one would think that sending > a different lifetime value in a variable field would impact > the "operating system", or "protocol stack". Woj> Your point is in theory reasonable, unfortunately in practice (as I've been taking pains to point out) sending such a different lifetime value can prove to require DHCP protocol stack changes, besides a PANA stack to be added. Some call that OS impacting... > > > > 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. > > > > Woj> I'll leave that to lawyers. My point was that one > shouldn't use > > Woj> the > > "open source is here" argument when answering the > requirement "Must be > > simple to implement ...", because you have no way of > knowing whether > > people will choose the open source software or not. > > It's their decision. We are just providing them information. > > > 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? > > > > Woj> You seem to have a personal obsession with DHCP-Auth that is > > clouding your judgment, and seemingly the assessment statement. > > Nowhere > > Please stay away from making such judgments and personal > comments on this mailing list. Woj> Somehow this has not what stopped you from making a judgment about me and DHCP-auth supporters... > > > do I mention DHCP-Auth in this thread and my comments are strictly > > about the PANA WG's assessment of the DSLF Requirements; > take them as > > a cue on what's missing in PANA. > > Regarding your question: Configuring an IP address on the client > > before authentication requires a significant change to the > L2 security > > mechanisms utilized today by operators today, as well as > BRAS changes, > > etc. Have a look at SAVI. I'm making a very specific IPv4 statement > > here and if you look at the vast majority of SPs, that's > what they're > > using today. The assessment of the PANA WG for this requirement > > assumes that it's ok to configure such IP addresses. I'm > saying that this is not ok. > > Where does the requirement say "it is not OK"? > We are going with the official DSLF requirements. I don't see > a requirement like what you are saying. Rather than > expressing your own requirements and your own > interpretations, please seek DSLF to amend and expand the > current requirements. That'd be more productive for all of us. Woj> We sure will. The whole > > Alper > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
