> -----Original Message----- > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Sent: 11 December 2007 19:05 > To: Wojciech Dec (wdec) > Cc: Alper Yegin; [email protected]; Mark Townsley (townsley); Jari Arkko > Subject: Re: [Pana] Re: DSLF Requirement analysis > > 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.
The issue is that an operator will deploy one mode of PANA or the other, not both. The assement should indicate which one is assumed for the answers. The other issue, as in my previous mails, is that if this extra coupling of DHCP-PANA-AAA state is assumed then it complicates BRAS implementations and more significantly operations. > > (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 > > Woj> 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. Woj> Let's say that this is a grey area. My previous feedback from operators has highlighted that this is an issue. That said unless the PANA WG can claim with 100% accuracy that it's not an issue, the assement is not accurate. > > (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? Woj> I'm specifically not addressing IPv6, because how IPv6 should actually be deployed in broadband is a grey area for me. I can count on one hand the # of operators I know who have done so, and amongst these there are differences. > > Yoshihiro Ohba > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
