> -----Original Message----- > From: Alper Yegin [mailto:[EMAIL PROTECTED] > Sent: 11 December 2007 22:06 > To: Wojciech Dec (wdec); [email protected] > Cc: Mark Townsley (townsley); 'Jari Arkko' > Subject: RE: [Pana] Re: DSLF Requirement analysis > > > First off, am I correct in assuming that you agree with the other > > issues you chose not to comment on > > No I don't. And I had already responded to those issues. >
You haven't > > 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 > > Woj> 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. > > The point of enumeration was to show there exists solutions > to the problem you claimed. Both 1 and 2b being practical and > applicable to all requirements as explained, I don't see a > need to do anything else. Practical in your mind, and during the course of this discussion it's become increasingly evident that there's been very poor guidance in how DSL operators deploy their networks, and the practical problems in them, and the mechanisms already in place on the network elements. You've also chosen to ignore BRAS vendor concerns. > > > > > -----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 > > > > Woj> 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. > > We certainly followed up on their input on the int-area list > and I had already said that we did that and I had even given > this link: > http://www1.ietf.org/mail-archive/web/int-area/current/msg01129.html If you're referring to the statement "And yes your observation is correct, the DHCP auth solution with EAP has the same issues" you're missing the point, I'm talking about a PANA solution specifically and the statement is that it will be difficult to acheive the same scale and performormance. It also affects the widely deployed access-nodes (have you ever tried configuring a dynamic PANA filter on an access-node??) > > > > > > 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 > > > > Woj> 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 > > Woj> 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. > > You seem to be talking about "not even a single line of code > change." So once again, you seem to have more requirements in > your mind than what the requirements read. If you convince > DSLF that the requirements shall be amended in such a way, > then you should do that. Once we get such requirements from > DSLF, we make an attempt at responding to them. > > > > > > 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. > > Telling us? You should be explaining the "why" part..... We > cannot be going with your assessment without seeing the > technical explanation. IPv4 is still around, that's what I'm telling you. That's technical fact #1. Fact #2, look at SAVI which describes the source guard mechanism used today - your assement makes no mention of the assumption that such a mechanism needs to be either revised, or dual addressing pools (and short leases) be used. > > > > > - 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? > > Once again...... as explained earlier on the int-area > list...... this appears to be reconfiguration of filters to > allow PANA in addition to DHCP. And as explained earlier, your assessment makes no mention of this assumption and which PANA mode it applies to. > > > > > > 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, > > I find it impossible to believe that you need a different > DHCP stack because now your DHCP client is getting a short lease. Where is your proof? Practice has shown something different. And again, your assessment makes absolutely no mention of this assumption. > > > besides a PANA > > stack to be added. Some call that OS impacting... > > As iterated many times on the int-area list, PANA can be > added as 3rd party software. It does not have to impact the OS. > > > > > > 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 > > Woj> 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
