On Tue, Dec 11, 2007 at 12:56:29PM +0100, Wojciech Dec (wdec) wrote: (snip) > > > 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!
I agree that some mechanism to carry circuit-id in PANA message would be needed when DHCP is not used for obtaining a pre-PANA address, in order to avoid any change to existing RADIUS implementations. We (PANA WG) can certainly work on a mechanism to carry a circuite-id in PANA-Client-Initiation (PCI) message if needed. That's not a big deal than adding a mechanism to carry EAP over DHCP in terms of IETF specification work. On the other hand, there are also other PANA use cases in which DHCP is used for obtaining a pre-PANA address. In such cases, I don't think any change to existing RADIUS implementations is needed. So overall, I think the current assessment is still valid. (snip) > > > 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 available addresses. Setting the lease time shorter in both > these > cases will increase the availability of addresses." > > Woj> The above link simply points out something that DHCP practitioners > and several operators have known for some time; short leases don't quite > work in reality. The answer to this requirement claims that besides PANA > there is no other impact on the client, well I differ especially > whenever mention of DHCP short leases is made (and it is made quite > often) More information is available on the short lease with Windoes DHCP server: http://support.microsoft.com/kb/261964 "After a Dynamic Host Configuration Protocol (DHCP) client lease expires, it is not immediately scavenged from the database." This means Windows DHCP server is slow to update the database (and hence short lease is not recommended). On the other hand, I could not interprete the text to indicate all DHCP servers on any OS have the same issue and/or Windows DHCP clients do not work with short lease. (snip) > > > > 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? > > Woj> You seem to have a personal obsession with DHCP-Auth that is > clouding your judgment, and seemingly the assessment statement. Nowhere > 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. I don't really understand why configuraing IPv6 link-local address before authentication will satisfy DSLF requirements while configuraing IPv4 address before authentication won't. Can you please explain? Yoshihiro Ohba _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
