Re: The Emperor Has No Clothes: Is PANA actually useful?,
I have read both PANA protocol and PANA framework drafts. I understand the concept and it seems to me an useful protocol. In particular, EAP over IP is necessary, IMO, and my understanding is that PANA base protocol is all about EAP over IP. The framework document should be an informational one and those scenarios that are described in PANA framework document should be treated as examples only. In fact, we don't see similar documents in many other WGs and therefore it should not be a requirement for PANA protocol. I also believe that many folks in IETF like to see a protocol that support EAP over IP. Since PANA has been chartered to address this problem, folks should work within the PANA WG and resolve the issues, if there is any. AFAIK, several network security experts have reviewed the PANA documents but I have not seen any major security issue with the PANA protocol discussed either in the mailing list or at the WG level. We had some discussions with the operators and many of them think that a protocol like PANA should have been available yesterday. We know few proprietary solutions that can be replaced by an IETF work like PANA. regards, -Subir --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: The Emperor Has No Clothes: Is PANA actually useful?
Dave Crocker wrote: I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. The fact that the IETF is supposed to be based on Rough consensus and running code is completely being missed here. Currently there are multiple interoperable implementation of the protocol in addition to there existing an open-source implementation as well. The fact that several years of peoples work and effort has gone into this is being ignored by claims that I find quite have a vested interest. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? I would also expect to hear a response to this. I would also like to ask if the people who claim to be unable to understand the scenarios where PANA can be applied have attended a PANA WG meeting or have cared to ask these questions on the ML. d/ -Raj ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
* Bernard Aboba: My question is more why do they need EAP in situations where they are not running at the link layer than why do they want or not want PANA. The simple answer is that there are situations which IEEE 802.1X cannot handle on wired networks. As specified, IEEE 802.1X is network port control, which means that authorization is controllable only at the port level. If there is more than one host connected to a switch port, then that model no longer applies. Isn't this just a don't do that, then scenario? Plugging in a hub tends to undermine much of the accountability 802.1X is supposed to provide. Anyway, 802.1X is terminally broken because end users can rewire that port and bypass security policies (put a laptop with bridging software onto it, plug in a hub, and so on). It's very hard to solve this problem at a sub-IP layer because you need an ARP replacement which is tied to the port (physical layer) and IP rouuting (network layer) at the same time, and in a secure fashion. And without some cryptography on the payload, you still won't be able to tell two hosts on the same port apart. My personal conclusion from this mess is to give up trying to make the sub-IP layers secure, but start directly at the IP layer. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Isn't this just a don't do that, then scenario? Plugging in a hub tends to undermine much of the accountability 802.1X is supposed to provide. Sure, except that the cost of don't do that is rather high -- a switch port for every host. Anyway, 802.1X is terminally broken because end users can rewire that port and bypass security policies (put a laptop with bridging software onto it, plug in a hub, and so on). The issue here is not key exchange; it's the lack of data protection. IEEE 802.11i derives a unique key per STA MAC, using it to key link layer ciphersuites providing encryption/integrity/replay protection, which eliminates piggybacking. Yet it relies on 802.1X. My understanding is that 802.1ae/af will also solve the problem, by enabling virtual ports. It's very hard to solve this problem at a sub-IP layer I think the point is that there is a significant need (at least in the short term) for a transitional solution. Enterprise WPA/WPA2 is being deployed, albeit perhaps more slowly than we'd like. Moving the problem up a layer doesn't really address expense/deployment concerns that much, especially since IPsec acceleration chipsets ship in much lower volumes than say, chipsets supporting 802.11, 802.3 or other link layer technologies. At the end of the day, there is significant appeal in being able to roll out solutions that don't require forklift upgrades. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?,
I have been trying to post the following message last few days but failed. Another try.. Subir Das wrote: I have read both PANA protocol and PANA framework drafts. I understand the concept and it is an useful protocol to me. In particular, EAP over IP is necessary, IMO, and my understanding is that PANA base protocol is all about EAP over IP. The framework document should be an informational one and those scenarios that are described in PANA framework document should be treated as examples only. Also these are not only the scenarios that people will like to or deploy in their networks. There are several business aspects to it. I also believe that many folks in IETF would like to see a protocol that support EAP over IP. Since PANA has been chartered to address this problem, folks should work within the PANA WG and resolve the issues, if there is any. AFAIK, several network security experts have reviewed the PANA documents but I have not seen any major security issue with the PANA protocol discussed either in the mailing list or at the WG level so far. Saying that the protocol is too complex and there is a simpler solution will not help much, IMO, unless we really compare the technical merits and demerits. We had some discussions with the operators and many of them think that a protocol like PANA would be very useful in their networks, if standardized it quickly. It's already late!! regards, -Subir --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf at ietf.org
Re: The Emperor Has No Clothes: Is PANA actually useful?
Hi Joel, Reading the entire thread, I think we should seriously consider your detailed suggestions to improve the PANA framework draft for broader acceptance in the community. Thank you, Yoshihiro Ohba On Tue, May 30, 2006 at 09:42:25AM -0400, Joel M. Halpern wrote: I think the confusion and complexity that I perceive comes from the fact that the framework problem treats all the tasks (user authentication, network selection, and securing the network connection as being of the same significance or same relationship to the solution. I think that most of the discussion of IPSec and pre-post PANA addresses does not belong here at all. Let me suggest an approach that might simplify and shorten the document: [Unfortuantely, I can't promise that it will fix everyone's problems.] 2. Describe the primary goal of PANA, and approach thereto. This would state that the goal is to authenticate the user using an IP level protocol. This would probably state that the primary approach is to proivde a transport for EAP that meets the requirements for an EAP transport [cite RFC.] 3. Describe very briefly the interaction between the EP and the PAA. State that the protocol between them is out of scope. Note that the EP must allow PANA messages to the PAA before authentication is completed. (Yes, that's obvious, but it is actually worth stating.) 4. Describe that PANA protocol needs to provide for negotiation of information before authentication. List briefly some of the things to be negotiated (services available, algorithms available.) Also indicate that the PANA protocol can provide additional post-authentication information to the client (in the PANA response) and to the EP. Securing the data channel between the PCC and the EP should be out of scope. If you want to say anything about that, you might note that this may be done in a link specific fashion, in may be done with an unauthenticated IP exchange before PANA, or PANA may be used to carry additional credentials / keys to be used to establish an authenticated secure association. The reason I would not include this is that the question of why I need an authenticated exchange will complicate the document. The other reason for not describing it is that it does not change the framework at all, and should be documented as a usage of PANA capabilities, in its protocol RFC. I would then probably dramatically reduce section 10. Trying to describe all those cases does not actually help the reader get the mental model. And I think they are too deployment specific. The real key here is to focus on the primary goal. The resulting document ought to be clearer, and focused on the problem that needs to be solved. It can indicate that PANA can be used to help other things, but that those things are not the purpose / point of PANA. At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote: Hi Joel, Thank you for spending your time reading the framework document and sending your feedback. Please see my response below. On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote: In reading the PANA Framework document, what I read seemed to me to be more of a system or solution document than a clean IETF protocol framework. I think your reading is correct. The document describes how different types of access network deployments are enabled by PANA. I saw efforts to address three different problems: 1) Securing an otherwise unsecured link, when the access node is not known to the client in advance. 2) Selecting an authorization (charging, possibly packet handling) service Just to make sure, do you mean by 2) network selection that is described in Section 8 of pana-framework draft? 3) Authenticating the user EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. This is surely one problem PANA is trying to solve, and has been clarified from the beginning of the work and more in this dicussion, I believe. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering) from EAP-based network access authentication is another problem. When a lower-layer does not provide EAP service, it is clear that PANA is a standard way to solve the problem. Perhaps the main confusion is coming from the fact, as a side effect of solving this bootstrapping problem, that it is possible to use PANA to bootstrap lower-layer ciphering *even if the lower-layer supports EAP*. While I understand the confusion but let me explain several reasons for why I think this is still viable for lower-layers that support EAP. - Use of PANA
Re: The Emperor Has No Clothes: Is PANA actually useful?
I think the confusion and complexity that I perceive comes from the fact that the framework problem treats all the tasks (user authentication, network selection, and securing the network connection as being of the same significance or same relationship to the solution. I think that most of the discussion of IPSec and pre-post PANA addresses does not belong here at all. Let me suggest an approach that might simplify and shorten the document: [Unfortuantely, I can't promise that it will fix everyone's problems.] 2. Describe the primary goal of PANA, and approach thereto. This would state that the goal is to authenticate the user using an IP level protocol. This would probably state that the primary approach is to proivde a transport for EAP that meets the requirements for an EAP transport [cite RFC.] 3. Describe very briefly the interaction between the EP and the PAA. State that the protocol between them is out of scope. Note that the EP must allow PANA messages to the PAA before authentication is completed. (Yes, that's obvious, but it is actually worth stating.) 4. Describe that PANA protocol needs to provide for negotiation of information before authentication. List briefly some of the things to be negotiated (services available, algorithms available.) Also indicate that the PANA protocol can provide additional post-authentication information to the client (in the PANA response) and to the EP. Securing the data channel between the PCC and the EP should be out of scope. If you want to say anything about that, you might note that this may be done in a link specific fashion, in may be done with an unauthenticated IP exchange before PANA, or PANA may be used to carry additional credentials / keys to be used to establish an authenticated secure association. The reason I would not include this is that the question of why I need an authenticated exchange will complicate the document. The other reason for not describing it is that it does not change the framework at all, and should be documented as a usage of PANA capabilities, in its protocol RFC. I would then probably dramatically reduce section 10. Trying to describe all those cases does not actually help the reader get the mental model. And I think they are too deployment specific. The real key here is to focus on the primary goal. The resulting document ought to be clearer, and focused on the problem that needs to be solved. It can indicate that PANA can be used to help other things, but that those things are not the purpose / point of PANA. At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote: Hi Joel, Thank you for spending your time reading the framework document and sending your feedback. Please see my response below. On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote: In reading the PANA Framework document, what I read seemed to me to be more of a system or solution document than a clean IETF protocol framework. I think your reading is correct. The document describes how different types of access network deployments are enabled by PANA. I saw efforts to address three different problems: 1) Securing an otherwise unsecured link, when the access node is not known to the client in advance. 2) Selecting an authorization (charging, possibly packet handling) service Just to make sure, do you mean by 2) network selection that is described in Section 8 of pana-framework draft? 3) Authenticating the user EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. This is surely one problem PANA is trying to solve, and has been clarified from the beginning of the work and more in this dicussion, I believe. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering) from EAP-based network access authentication is another problem. When a lower-layer does not provide EAP service, it is clear that PANA is a standard way to solve the problem. Perhaps the main confusion is coming from the fact, as a side effect of solving this bootstrapping problem, that it is possible to use PANA to bootstrap lower-layer ciphering *even if the lower-layer supports EAP*. While I understand the confusion but let me explain several reasons for why I think this is still viable for lower-layers that support EAP. - Use of PANA for bootstrapping IKEv2. I explained several reasons for why doing this while IKEv2 can carry EAP, in my response to Vidya: http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html. - Use of PANA for bootstrapping IEEE 802.11i PSK mode. This makes APs and non-AP STAs that support 802.11i but do not support 802.11r can transit from one AP to another
RE: The Emperor Has No Clothes: Is PANA actually useful?
Lucy, Thanks! -- E -- -Original Message- -- From: Lucy E. Lynch [mailto:[EMAIL PROTECTED] -- Sent: Friday, May 26, 2006 2:31 PM -- To: Gray, Eric -- Cc: Narayanan, Vidya; Sam Hartman; Bernard Aboba; ietf@ietf.org -- Subject: RE: The Emperor Has No Clothes: Is PANA actually useful? -- -- On Fri, 26 May 2006, Gray, Eric wrote: -- -- For those of us that are just trying to follow this discussion, -- what does the word posture mean in this context? -- -- according to draft-thomson-nea-problem-statement-02.txt -- -- Posture: Posture refers to the hardware or software -- configuration of -- an endpoint as it pertains to an organization's security policy. -- Posture may include knowledge about the types of hardware and -- software installed and their configurations, e.g. OS name and -- version, application patch levels, and anti-virus signature file -- version. -- -- -- -- -- -- Eric -- -- -- -Original Message- -- -- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] -- -- Sent: Friday, May 26, 2006 2:05 PM -- -- To: Sam Hartman; Bernard Aboba -- -- Cc: ietf@ietf.org -- -- Subject: RE: The Emperor Has No Clothes: Is PANA -- actually useful? -- -- -- -- -- -- Bernard == Bernard Aboba -- [EMAIL PROTECTED] writes: -- -- -- -- My question is more why do they need EAP in -- -- situations where -- -- they are not running at the link layer than why do -- -- they want or -- -- not want PANA. -- -- -- -- Bernard The simple answer is that there are -- -- situations which IEEE -- -- Bernard 802.1X cannot handle on wired networks. As -- -- specified, -- -- Bernard IEEE 802.1X is network port control, which -- -- means that -- -- Bernard authorization is controllable only at the -- -- port level. If -- -- Bernard there is more than one host connected to a -- -- switch port, -- -- Bernard then that model no longer applies. -- -- -- -- Yeah. I guess I wonder whether you are actually getting -- -- network access authenticatino at that point or whether you -- -- are getting a service that allows you to check posture. It -- -- seems that a service that simply allows you to check posture -- -- should be not EAP. -- -- -- -- -- -- -- -- I fully agree. As far as I can tell, using EAP in -- this manner merely -- -- reduces it to a posture transport protocol. The level -- of security -- -- provided by EAPoUDP does not seem to be any greater than a -- -- kerberos-based authentication done today in most enterprise -- -- networks, -- -- considering the presence of switched ethernet. Hence, the -- -- only reason to -- -- move to EAPoUDP would be to check posture and I agree -- with Sam that -- -- making EAP the posture transport protocol is a bad idea. -- -- -- -- Vidya -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- Lucy E. Lynch Academic User Services -- Computing CenterUniversity of Oregon -- llynch @darkwing.uoregon.edu (541) 346-1774 -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Sam, Thanks! -- E -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Friday, May 26, 2006 5:20 PM -- To: Gray, Eric -- Cc: Narayanan, Vidya; Bernard Aboba; ietf@ietf.org -- Subject: Re: The Emperor Has No Clothes: Is PANA actually useful? -- -- Gray, == Gray, Eric [EMAIL PROTECTED] writes: -- -- Gray, For those of us that are just trying to follow this -- Gray, discussion, what does the word posture mean in this -- Gray, context? -- -- Assertions about your OS state--things like patch levels, -- configuration of security settings, etc. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Yoshihiro Ohba wrote: Hi Joel, Reading the entire thread, I think we should seriously consider your detailed suggestions to improve the PANA framework draft for broader acceptance in the community. Which is strong hint that this discussion now belongs on the PANA mailing list. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?)
Avi Lior wrote: The statement regaring GEE and PANA was not made by me but rather by your company! In order to sway support towards EAP over HRPD, Qualcom made statements that PANA was dead at the IETF and that GEE will be standardize at the IETF. perhaps the IETF should have been consulted through the 3GPP2-IETF liaison? actually I have seen some not-so-correct claims being made about IETF protocols in other SDOs too (for e.g. NETLMM in 3GPP). the SDOs should be making more use of the liaisons instead of believing individual claims. Vijay ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?)
I think it is our collective responsiblity not to make false claims when moving our agenda forward. This is true with any group. Liaison should not be used for fact checking. This will create extra-ordinary work for them. They have better things to do. -Original Message- From: Vijay Devarapalli [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 2:53 PM To: Avi Lior Cc: ietf@ietf.org Subject: IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?) Avi Lior wrote: The statement regaring GEE and PANA was not made by me but rather by your company! In order to sway support towards EAP over HRPD, Qualcom made statements that PANA was dead at the IETF and that GEE will be standardize at the IETF. perhaps the IETF should have been consulted through the 3GPP2-IETF liaison? actually I have seen some not-so-correct claims being made about IETF protocols in other SDOs too (for e.g. NETLMM in 3GPP). the SDOs should be making more use of the liaisons instead of believing individual claims. Vijay ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?)
I think it is our collective responsiblity not to make false claims when moving our agenda forward. This is true with any group. Very much in agreement. Liaison should not be used for fact checking. Speaking as a liaison, this sort of fact checking (what is the real status of WG X or Document Y) is most certainly one of the things I think is appropriate for a liaison to do. And I would hope that my answer never differs from the one others are making... This will create extra-ordinary work for them. On the other hand, not consulting them, and having misinformation propagated can also end up creating (much) more work for the liaison. Indeed, one of the important reasons for having liaisons is to facilitate information flow and prevent misinformation and miscommunication. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
AW: The Emperor Has No Clothes: Is PANA actually useful?
Hi Jari, Anyway, I agree with Dave Crocker that the bar should be higher for using there's another solution argument in last call discussion of chartered work than in, say, a BOF discussion. Perhaps we should focus more on whether the function itself is something that we agree on, and what we can do to fix/scope/help PANA. That's very true given that some solutions that were mentioned in the discussion appeared recently while the PANA protocol was in AD Evaluation for a long time already. One example: draft-barany-eap-gee-00.txt Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
and algorithm agility 5. The security considerations section says, If the EP does not verify whether the PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. This is at best not clear, or perhaps a serious security hole. It appears that either address authorization (CGA?) is needed or a particular configuration of IP addresses is needed for IPsec to be effective. Since these are not really about complexity, and in fact mostly not even the base spec, we'll deal with them in a separate thread. So, in summary, I have really put a lot of time reviewing and reading PANA documents before making my statements. As many have said, if it is one or two persons who have some doubts it's one thing. It looks like I am in good company in expressing my opinions. How is it useful if people make subjective claims like PANA is too complex (and carry it to the extent to justify deprecating this effort based on that claim), without really substantiating it? Again, thanks for your time and effort for the PANA-IPsec review! Alper I am really not going to spend any more *substantial* time on this thread. regards, Lakshminath Alper -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 3:58 PM To: Alper Yegin Cc: ietf@ietf.org Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?) At 03:20 PM 5/26/2006, Alper Yegin wrote: So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. Alper, It's clear now that PANA documents as written are found to be complex and with gaps by folks who have spent the time to review them during the IETF LC process. So, whereas there is consensus at WG level as determined by Raj and you to forward the documents to the IESG, at the IETF LC level, I see that there is no broad consensus as I understand the word rough consensus. We are not feeding on complexity, we are not married to it either. If you can tell us what parts we can simplify, the whole community would be grateful to you. I did a review of PANA-IPsec and had several questions and comments, but then of course the discussion moved to what does PANA buy more than say EAP over IKEv2 and I didn't have a reasonable answer. Further, my recollection is that several emails in this thread have already listed things PANA might do away with to reduce the complexity (e.g., one of Jari's emails). regards, Lakshminath Please describe where you see unnecessary complexity, and suggest remedies. Thanks. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Lakshminath, Please see inline... -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 2:32 PM To: Avi Lior; Pekka Savola; Sam Hartman Cc: ietf@ietf.org Subject: RE: The Emperor Has No Clothes: Is PANA actually useful? Avi, EAPoHRPD was designed after a thorough technical evaluation of PANA proved that the PANA suite of protocols are unnecessarily complex, and those technical reasons, some of which you state below, were put forth in front of 3GPP2. I am very knowledgeable about what happened in 3GPP2 wrt to PANA and EAP over HRPD. (Sadly) I would not characterize what happened in 3GPP2 as a thorugh technical evaluation. Nor would I characterize that it was proven that PANA was over complex. The decision taken by 3GPP2 was political. It was based on horse-trading. As I said before the only techincal comparison between PANA and EAP over HRPD showed the two protocols using the same number of messages. So the only difference between them was that the PANA messages had the overhead to be expected from UDP. debate of course was between PANA and EAPoHRPD, and GEE is but a small optional enhancement to address the case of parallel EAP authentications. GEE is not an EAP lower layer and thus it is invalid to compare it to PANA. The statement regaring GEE and PANA was not made by me but rather by your company! In order to sway support towards EAP over HRPD, Qualcom made statements that PANA was dead at the IETF and that GEE will be standardize at the IETF. I would further say that discounting the technical evaluation done elsewhere is fine, but an evaluation based on the same technical drivers (the complexity of PANA vs. EAP over link-layers) will need to be done in the IETF. So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. In 3GPP2 deploying EAP over HRPD is not enough. Another proocol was needed to carry the EAP message to the Authenticator in the PDSN. With PANA, the EAP message was carried from the Mobile directly to the PDSN. EAP over HRPD therefore required two portocols. Seems to me that that is far more complex to deploy then PANA. By the way, the same is true in WiMAX. PKMV2 only brings the EAP message to the Base Station, WiMAX had to create another protocol to carry the EAP message to the ASN-GW. Again, don't count 3GPP2 as part of the broader community. That would be a missleading. You don't want to misslead people do you? Hopefully this too will be my last email. But if anyone attemtps to mischaracterize what happened in 3GPP2 I will be sure to chime in again. Avi This is my last email on this line of arguments. best regards, Lakshminath At 11:19 PM 5/25/2006, Avi Lior wrote: If I characterize the 3GPP2 decision not to use PANA I would have to say that it was purely based on Politics and not on technical merits. The politics included misinformation such as telling operators That PANA was dead at the IETF and that GEE will become a Standard Track RFC soon. Other information cited for not using PANA were: 1- EAP typically runs directly over a link layer. See the following text from RFC 3748: EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. 2- HRPD Link Layer satisfies all lower layer requirements as specified in section 3.1 of RFC 3748; for example, the requirements for lower layer error detection, minimum MTU, ordering guarantees, etc. 3- PANA is not currently used in any commercial networks (wired or wireless) such as DSL, PacketCable, WLAN, WiMAX, 3GPP UMTS, etc. 4- PANA is very complex with excessive protocol overhead that makes it less attractive for use in mobile cellular environments. 5- It's unclear if PANA can reach RFC status within the 3GPP2 designated time frame due to fundamental issues that are out of control of 3GPP2. See the companion contribution X31-20060327-030 for a detailed explanation of various PANA issues. In particular issue 4, probably the only technical comment was shown by your own company to be an exageration. The analysis showed that over the air the number of message exchanges were the same as those needed by a link layer approach. The only difference was the overhead of the packet headers, which I would not characterize as excessive protocol overhead given the context. The other issues cited have been shown to been inaccurate or baseless in fact. But I would say that the political campaign against PANA was executed flawlessly in 3GPP2. I hope that the IETF makes its decisions based on technical merits rather then on the success or failure of political campaigns. Lets therefore not use PANAs failure in 3GPP2 as an example. -Original Message- From: Lakshminath Dondeti [mailto
Re: The Emperor Has No Clothes: Is PANA actually useful?
Avi, I'd appreciate it if you could refrain from mentioning how representatives from specific companies spoke in another SDO. In the IETF, we trust each other to leave our company affiliations at the door. The fact that statements about the IETF were made elsewhere may be relevant, but who employs the people making them isn't our concern. Everybody, This discussion seems to have gone about as far as is useful. It's not uncommon in the IETF for the value of ongoing work to be controversial. I think the WG Chairs and AD concerned have some interesting input to evaluate at this point. Brian Avi Lior wrote: Lakshminath, Please see inline... -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 2:32 PM To: Avi Lior; Pekka Savola; Sam Hartman Cc: ietf@ietf.org Subject: RE: The Emperor Has No Clothes: Is PANA actually useful? Avi, EAPoHRPD was designed after a thorough technical evaluation of PANA proved that the PANA suite of protocols are unnecessarily complex, and those technical reasons, some of which you state below, were put forth in front of 3GPP2. I am very knowledgeable about what happened in 3GPP2 wrt to PANA and EAP over HRPD. (Sadly) I would not characterize what happened in 3GPP2 as a thorugh technical evaluation. Nor would I characterize that it was proven that PANA was over complex. The decision taken by 3GPP2 was political. It was based on horse-trading. As I said before the only techincal comparison between PANA and EAP over HRPD showed the two protocols using the same number of messages. So the only difference between them was that the PANA messages had the overhead to be expected from UDP. debate of course was between PANA and EAPoHRPD, and GEE is but a small optional enhancement to address the case of parallel EAP authentications. GEE is not an EAP lower layer and thus it is invalid to compare it to PANA. The statement regaring GEE and PANA was not made by me but rather by XX! In order to sway support towards EAP over HRPD, X made statements that PANA was dead at the IETF and that GEE will be standardize at the IETF. I would further say that discounting the technical evaluation done elsewhere is fine, but an evaluation based on the same technical drivers (the complexity of PANA vs. EAP over link-layers) will need to be done in the IETF. So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. In 3GPP2 deploying EAP over HRPD is not enough. Another proocol was needed to carry the EAP message to the Authenticator in the PDSN. With PANA, the EAP message was carried from the Mobile directly to the PDSN. EAP over HRPD therefore required two portocols. Seems to me that that is far more complex to deploy then PANA. By the way, the same is true in WiMAX. PKMV2 only brings the EAP message to the Base Station, WiMAX had to create another protocol to carry the EAP message to the ASN-GW. Again, don't count 3GPP2 as part of the broader community. That would be a missleading. You don't want to misslead people do you? Hopefully this too will be my last email. But if anyone attemtps to mischaracterize what happened in 3GPP2 I will be sure to chime in again. Avi This is my last email on this line of arguments. best regards, Lakshminath At 11:19 PM 5/25/2006, Avi Lior wrote: If I characterize the 3GPP2 decision not to use PANA I would have to say that it was purely based on Politics and not on technical merits. The politics included misinformation such as telling operators That PANA was dead at the IETF and that GEE will become a Standard Track RFC soon. Other information cited for not using PANA were: 1- EAP typically runs directly over a link layer. See the following text from RFC 3748: EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. 2- HRPD Link Layer satisfies all lower layer requirements as specified in section 3.1 of RFC 3748; for example, the requirements for lower layer error detection, minimum MTU, ordering guarantees, etc. 3- PANA is not currently used in any commercial networks (wired or wireless) such as DSL, PacketCable, WLAN, WiMAX, 3GPP UMTS, etc. 4- PANA is very complex with excessive protocol overhead that makes it less attractive for use in mobile cellular environments. 5- It's unclear if PANA can reach RFC status within the 3GPP2 designated time frame due to fundamental issues that are out of control of 3GPP2. See the companion contribution X31-20060327-030 for a detailed explanation of various PANA issues. In particular issue 4, probably the only technical comment was shown by your own company to be an exageration. The analysis showed that over the air the number of message exchanges were the same as those needed by a link layer approach. The only difference
Re: The Emperor Has No Clothes: Is PANA actually useful?
Hi Joel, Thank you for spending your time reading the framework document and sending your feedback. Please see my response below. On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote: In reading the PANA Framework document, what I read seemed to me to be more of a system or solution document than a clean IETF protocol framework. I think your reading is correct. The document describes how different types of access network deployments are enabled by PANA. I saw efforts to address three different problems: 1) Securing an otherwise unsecured link, when the access node is not known to the client in advance. 2) Selecting an authorization (charging, possibly packet handling) service Just to make sure, do you mean by 2) network selection that is described in Section 8 of pana-framework draft? 3) Authenticating the user EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. This is surely one problem PANA is trying to solve, and has been clarified from the beginning of the work and more in this dicussion, I believe. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering) from EAP-based network access authentication is another problem. When a lower-layer does not provide EAP service, it is clear that PANA is a standard way to solve the problem. Perhaps the main confusion is coming from the fact, as a side effect of solving this bootstrapping problem, that it is possible to use PANA to bootstrap lower-layer ciphering *even if the lower-layer supports EAP*. While I understand the confusion but let me explain several reasons for why I think this is still viable for lower-layers that support EAP. - Use of PANA for bootstrapping IKEv2. I explained several reasons for why doing this while IKEv2 can carry EAP, in my response to Vidya: http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html. - Use of PANA for bootstrapping IEEE 802.11i PSK mode. This makes APs and non-AP STAs that support 802.11i but do not support 802.11r can transit from one AP to another without necessarily perform EAP for every AP transition as long as the APs are acting as EPs of the same PAA. One may argue that this usage becomes useless when all APs and non-AP STAs are migrated to 802.11r, but it is still possible to use PANA for inter-ESS transition which is not covered by 802.11r. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. One of the reasons for this may be that the problem statement and requirements are described in a separate RFC (i.e., RFC 4058) not in the pana-framework draft. Of course another reason may be that I, the editor of the draft, am not a native English speaker. BTW, there is no appendix in pana-dramework draft. So you may refer to Section 10.1 about DSL. Is this correct? I hope this sheds some light on the discussion. Yoshihiro Ohba Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Hello Sam, Please find my inline specific replies. Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Hmm, not involved in the PANA working group... At least I am not actively contributing to the PANA group's I-Ds even if I had several chances to join the working group discussion in the form of offline or on-line, However, I can still say that I am not actively involved in the PANA WG. Therefore, I think I can share my view and thought on this thread. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. I also understand the concern about PANA because in these days most link layers provide their own link specific authentication facilities. On that situation, the IP connectivity is not allowed before the link specific authentication procedure is completed. So, I suppose that the arguments and criticisms about PANA are coming from on this point . However, I'd say that this fact can not throw out the advantage of PANA which delivers the EAP over UDP, thus link independent authentication procedure can happen. Moreover, it can supplement the underlying network which is lack of the authentication facility. If one would like to try to stress about the other alternative, oh,,,please do not go that way. PANA WG/IETF already have spent more than one year. I think it is more productive to enhance our existing efforts rather than throwing out this and taking the other direction from the bottom line. I hope I am misunderstanding the current situation and the implication from my mind is incorrect. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. At least, I am understanding what is PANA and what it aims for and what it complements. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. Same with my previous response. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. How about joining the PANA WG's discussion and having a chance to share the concern? Though I am not a freak in the PANA WG, I think there are many folks who can relieve the concern. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. IMHO, noted technical flaws from framework and protocol are different with some peoples' observation that it is not fully understandable and it is not a good idea. It would be great if we can proceed the **technical discussions** based on the texts from PANA framework and protocol because it seems that we all have reviewed those drafts. Best Regards, -Junghoon We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but
Re: The Emperor Has No Clothes: Is PANA actually useful?
Lakshminath Dondeti wrote: I tried this in my secdir review, for instance suggesting that perhaps PANA-IPsec should be limited to IKEv2 and 4301 and people had different opinions ranging from 'not sure about forcing IKEv2 on PANA' to 'there wouldn't be any differentiator to PANA' (they are not quotes; I am paraphrasing), and so really didn't find a consensus to make any recommendations. That discussion has still been going on (but I forget if it was in secdir list, with the ADs, or on the PANA list). FWIW, I fully agree that limiting to IKEv2 would be the right choice. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
Lakshminath, Are you aware that you are not answering my question? Please describe where you see unnecessary complexity, and suggest remedies. Noone came near answering these, so throwing the ball to someone else wont help. I am not, really. I am saying that the question has been answered by others. For instance, Jari says the following: Jari's message is the only real attempt. I'm not aware of any other. Can you give some pointers? One advice that I would like to give is to take another look at the ambition level and scale it down. (Management 101: if you can't fix it, rip it out.) A solution that does not mix IP and link layer solutions would be preferrable, IMHO, and then we would get out of the 802.11 interaction problems. Perhaps lose the EP separation. Core PANA as a way to run EAP and confirm possession of the resulting key would be very useful, IMHO. Tunneling IPsec for data packets could be optional. --Jari We need to discuss these in more details. Before we jump to pruning features, we need to first identify the source of complexity in the design, then discuss if it can be simplified (is that feature really needed, are there alternatives solutions). Only after then we can decide what to do. There is necessary complexity, and there is unnecessary complexity. In addition to those I never quite understood the need for NAP and ISP authentications and including all that discussion in the main protocol, to state one additional concern. The need is specified in the requirements document (RFC 4058, Section 4.1.1). Having presented EAP-GEE which was driven by a need for dual-EAP-authentication, you should not be that unclear about this feature. And if you are familiar with IEEE 802.16e security, dual-EAP is there as well. In fact, 16e design was influenced by the PANA's dual-EAP design. Anything else in the PANA protocol design? That's it? This is awfully short of a list for someone who claims PANA is too complex to be used anywhere. In my secdir review of PANA-IPsec I had the following high-level comments (a detailed review is posted on secdir; I am not sure about whether you've seen it. Let me know otherwise): Very recently we got it. Thank you for the review. 1. The document should restrict itself to IKEv2 and IPsec as in 4301 and 4303. There is also a reference to MOBIKE in PANA protocol, but this document doesn't talk about that. Perhaps that gap needs to be filled. 2. I have suggestions for revision of PSK derivation from the PaC-EP- Master-Key 3. EAP Re-authentication, PSK switch over, new IKEv2 and IPsec establishment needs more detailed specification. 4. I have some comments about default crypto algorithms and algorithm agility 5. The security considerations section says, If the EP does not verify whether the PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. This is at best not clear, or perhaps a serious security hole. It appears that either address authorization (CGA?) is needed or a particular configuration of IP addresses is needed for IPsec to be effective. Since these are not really about complexity, and in fact mostly not even the base spec, we'll deal with them in a separate thread. So, in summary, I have really put a lot of time reviewing and reading PANA documents before making my statements. As many have said, if it is one or two persons who have some doubts it's one thing. It looks like I am in good company in expressing my opinions. How is it useful if people make subjective claims like PANA is too complex (and carry it to the extent to justify deprecating this effort based on that claim), without really substantiating it? Again, thanks for your time and effort for the PANA-IPsec review! Alper I am really not going to spend any more *substantial* time on this thread. regards, Lakshminath Alper -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 3:58 PM To: Alper Yegin Cc: ietf@ietf.org Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?) At 03:20 PM 5/26/2006, Alper Yegin wrote: So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. Alper, It's clear now that PANA documents as written are found to be complex and with gaps by folks who have spent the time to review them during the IETF LC process. So, whereas there is consensus at WG level as determined by Raj and you to forward the documents to the IESG, at the IETF LC level, I see that there is no broad consensus as I understand
Re: The Emperor Has No Clothes: Is PANA actually useful?
Vidya, Administratively scoped multicast is not the only way for PAA discovery. DHCP based PAA discovery is also available: draft-ietf-dhc-paa-option-02.txt Regards, Yoshihiro Ohba On Fri, May 26, 2006 at 04:34:22PM -0700, Narayanan, Vidya wrote: Hi Jari, Hi Vidya, Re 1: I do believe an IP layer solution in this space is potentially useful. Not as something that replaces existing link layer solutions and takes over the market, but there are situations where it would be useful, for instance over link layers that have no such support, as a solution for networks where you just want to add a node in the middle of the access network without updating all access points (kind of like a replacement for weblogin but without the need for user intervention), etc. I am trying to figure out the use case for an IP layer solution in this space as an access authentication protocol and I am not convinced that we need something like PANA. If you are in fact, adding a node in the middle of the access network that is going to perform access control, is it just performing authentication or also attempting to derive keys and secure the data traffic? With a solution like PANA, a link layer secure association protocol or IPsec needs to be run to secure data traffic. If the former, the authenticator (or at least the EP) needs to be located at the edge. This needs support at the link layer anyway, and all such link layers already support EAP. If the latter, the most natural solution to use is IKEv2 with EAP, since even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't see what benefit PANA provides here. My comment above relates to the overall interest in an IP layer solution without considering what protocol is used. I also wrote in my e-mail something about the different alternative solutions. It is true that IKEv2 with EAP is potentially a good fit for this task. IKEv2 is my favorite EAP encapsulation protocol :-) However, its not clear that it currently has all the parts (though I could have missed some extension somewhere). For instance, some mechanism appears to be needed to discover that you are in a network that requires this type of operation, and to find the address of the control device that you need to talk to. I haven't done the research on how easy it would be to add this (probably quite easy) or if there are other things that we would need. Thoughts? Let me separate out two issues here. In order to discover that you are in a network that requires this type of operation, you need to know via some kind of advertisements (SSID, for instance) that you are not in the home network. For instance, VPN connections today are mostly user initiated. Another issue that you mention here is the discovery of the address of the control device - this is typically done via DNS today. Thinking further about the PAA discovery mechanisms outlined in the PANA protocol, it seems to bring some deployment concerns. Administratively scoped multicast is one of the advocated methods of performing PAA discovery. Administrative scoping of multicast is a huge administrative burden and is not a good deployment option. Protocols like DVMRP allow TTL scoping which are somewhat better. But, the thought of opening up port control to allow multicast packets into the network prior to authentication is not appealing to me. Another option that PANA provides for PAA discovery is traffic-driven discovery. This is somewhat similar to what EAP relies on - i.e., the network figures out that it needs to send an EAP Request Identity (in the absence of an EAPoL-Start like message). In short, discovery hardly seems to be a reason to use PANA to me - I'm trying to at least taste the kool-aid, even if I can't drink it all, but somehow, am yet finding a convincing reason why I should :) Vidya Anyway, I agree with Dave Crocker that the bar should be higher for using there's another solution argument in last call discussion of chartered work than in, say, a BOF discussion. Perhaps we should focus more on whether the function itself is something that we agree on, and what we can do to fix/scope/help PANA. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
establishment needs more detailed specification. 4. I have some comments about default crypto algorithms and algorithm agility 5. The security considerations section says, If the EP does not verify whether the PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. This is at best not clear, or perhaps a serious security hole. It appears that either address authorization (CGA?) is needed or a particular configuration of IP addresses is needed for IPsec to be effective. Since these are not really about complexity, and in fact mostly not even the base spec, we'll deal with them in a separate thread. So, in summary, I have really put a lot of time reviewing and reading PANA documents before making my statements. As many have said, if it is one or two persons who have some doubts it's one thing. It looks like I am in good company in expressing my opinions. How is it useful if people make subjective claims like PANA is too complex (and carry it to the extent to justify deprecating this effort based on that claim), without really substantiating it? Again, thanks for your time and effort for the PANA-IPsec review! Alper I am really not going to spend any more *substantial* time on this thread. regards, Lakshminath Alper -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 3:58 PM To: Alper Yegin Cc: ietf@ietf.org Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?) At 03:20 PM 5/26/2006, Alper Yegin wrote: So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. Alper, It's clear now that PANA documents as written are found to be complex and with gaps by folks who have spent the time to review them during the IETF LC process. So, whereas there is consensus at WG level as determined by Raj and you to forward the documents to the IESG, at the IETF LC level, I see that there is no broad consensus as I understand the word rough consensus. We are not feeding on complexity, we are not married to it either. If you can tell us what parts we can simplify, the whole community would be grateful to you. I did a review of PANA-IPsec and had several questions and comments, but then of course the discussion moved to what does PANA buy more than say EAP over IKEv2 and I didn't have a reasonable answer. Further, my recollection is that several emails in this thread have already listed things PANA might do away with to reduce the complexity (e.g., one of Jari's emails). regards, Lakshminath Please describe where you see unnecessary complexity, and suggest remedies. Thanks. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Vidya, Overall, network access authentication and establishing IPsec SA are two related but different things. EAP over IKEv2 is an integrated approach while PANA framework is a split approach. In general, both approaches have pros and cons. Speaking of the split approach, there are number of reasons for why splitting is useful: - If you implement PANA, gateway discovery comes free. However, the integrated approach could also define its own gateway discovery mechanism. - Since EAP over IKEv2 does not cache EAP keying material or parameters, when IKE_SA is deleted for many reasons, the client needs to run EAP over IKEv2 again when a new IKE_SA needs to be established sometime later. In PANA case, EAP keying material is cached by PAA as long as the PANA session remains, and the keying material is reusable for establishing new IKE_SAs without running another EAP. - Since EAP over IKEv2 does not cache EAP keying material, when the client needs to create multiple IKE_SAs for a particular gateway for many reasons, the client needs to run EAP for each IKE_SA. In PANA case, one EAP run is sufficient for establishing multiple IKE_SAs for the same gateway. - As Alper already mentioned, since PANA allows PAA and EP to be separated, one EAP run is sufficient for establishing multiple IKE_SAs for different gateways (EPs) controlled by the same PAA instead of running multiple EAP runs for multiple IKE_SAs. - In an environment where network access authentication is needed but not IPsec SA (e.g., DSL), EAP over IKEv2 is too much. Hope this helps, Yoshihiro Ohba On Fri, May 26, 2006 at 12:00:31PM -0700, Narayanan, Vidya wrote: Hi Jari, Hi Lakshminath, I guess there are differences in our understanding of 3G-WLAN interworking (and I could be wrong), but the point is that they (plan to) use EAP over IKEv2. We can try and debate the details offline, as that is not central to the discussion here. There's no question of whether IKEv2/EAP is being used. 3G-WLAN interworking is one example, Unlicensed Mobile Access is another one, what IKEv2/EAP was originally designed for is corporate VPN access, etc. But in most of these cases the usage is really VPN like, i.e., you already have Internet connectivity but to get to a closed network or service you contact a gateway via IKEv2. That gateway is often known beforehand and it could be in the other side of the world. Access control to get your Internet connectivity is another matter. 3G-WLAN, for instance, assumes local mechanisms for that in addition to whatever VPN to the home network. The specs don't really say much about what the local mechanisms are except that they need to be EAP-based if authentication via the 3G network is desired. But the assumption is that on a 802.11 network, 802.11i would get used. I am not sure that the VPN case and the access control in the 3G-WLAN case are that different. The VPN access you are describing really provides remote access control. The point of that is that the edge equipment is out of control (and potentially untrusted) of the entity providing access and hence there is a need for remote access control. It is essentially the same scenario for parts of 3G-WLAN interworking. The access points may be provided by a vendor that is different from the operator and hence, an operator's box is performing remote access control using IPsec - the method to set up the IPsec SA was chosen to be an IKEv2/EAP combination. Of course, in the cases where the WLAN equipment can be trusted and is part of the operator's network, 802.11i would potentially be used as you say. The only difference in the enterprise WLAN vs 3G-WLAN scenario is that the former is providing intranet access, while the latter is for general internet access even. However, this is really about semantics. If an entity actually receives a valid IP address to use in the local network, it only needs to perform IPsec/IKEv2 with the operator's box in the 3G-WLAN case for access to home domain services (no different really from the corporate VPN case). Vidya This leaves still the question of whether IKEv2/EAP or PANA could be used to provide access control for the Internet connectivity. More on that in my other e-mail. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
Alper Yegin wrote: We need to discuss these in more details. Before we jump to pruning features, we need to first identify the source of complexity in the design, then discuss if it can be simplified (is that feature really needed, are there alternatives solutions). Only after then we can decide what to do. There is necessary complexity, and there is unnecessary complexity. Right. Let me clarify my original statement: It was expressed in the context of getting reviews and last call comments with a number of issues. Of course, if you can address those issues easily you should do that. But if you hit a problem and do not make progress in resolving an issue, you (= the WG) should consider whether some functionality associated with it is needed. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
automatic discovery [Re: The Emperor Has No Clothes: Is PANA actually useful?]
On Sat, 27 May 2006, Yoshihiro Ohba wrote: Vidya, Administratively scoped multicast is not the only way for PAA discovery. DHCP based PAA discovery is also available: draft-ietf-dhc-paa-option-02.txt I suspect adminsitratively scoped multicast discovery wouldn't be acceptable for much the similar reasons as Service Location Protocol (SLP) wouldn't be -- it requires multicast deployment. We made an analysis of end-point discovery mechanisms for v6 tunnels a while ago. It might be worth a read: http://draft-palet-v6ops-tun-auto-disc.potaroo.net -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). As I understand it, EAP over UDP is one of the items proposed for standardization in the NEA WG. You misunderstood it, despite the clear text in their charter: ... Requirements need to be defined for an EAP over L3 transport for L3 access scenarios. ... * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. That leads me to wonder whether the IETF will be chartering multiple WGs to standardize EAP encapsulation over IP. Although my understanding of both PANA and NEA is no doubt incomplete/wrong/confusled, having multiple EAP encapsulation standards seems duplicative to me. It is not suggested anyways. As for 3GPP2, I can get into really gory details of what has been happening there, but it's not technical at all (if you are familiar with 3GPP2 and the relevant players in this discussion, you can guess). The issue is that integration of PANA with link layer technologies requires the support of the organizations that own those link layers. Not necessarily. Why do you think so? 802.11 is a counter example. DSL is a counter example. Without that link layer integration (for whatever reason) the scenarios can't be realized, at least in a mainstream way. It seems to me that one of the motivations for PANA is to *avoid* link layer dependencies in situations where link layer technology is inadequate/can't be deployed, and a forklift upgrade isn't in the budget. In those circumstances, integration with link layers or IPsec VPN technology is not under consideration -- because that would require a forklift upgrade. For example, the wireless hotspot case where something more sophisticated than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN deployment isn't a realistic alternative. Or the shared wired media case where network port authentication doesn't really work, and wholesale switch port replacements aren't affordable. In both of those cases, EAP over IP might provide a light weight, easily deployed solution. Are you referring to NACP as EAP over IP? You acknowledged it is designed for wired networks. It is not even useful for wireless. Won't work. Yet, rather than focusing on the specific scenarios in which PANA might be compelling, the PANA framework document tries to cover a wide range of potential uses, trying to position PANA for use in scenarios where the case is less obvious. I think that would have been unnecessarily limiting, given that we designed a protocol that can naturally work in variety of scenarios. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
If I characterize the 3GPP2 decision not to use PANA I would have to say that it was purely based on Politics and not on technical merits. The politics included misinformation such as telling operators That PANA was dead at the IETF and that GEE will become a Standard Track RFC soon. Other information cited for not using PANA were: 1- EAP typically runs directly over a link layer. See the following text from RFC 3748: EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. 2- HRPD Link Layer satisfies all lower layer requirements as specified in section 3.1 of RFC 3748; for example, the requirements for lower layer error detection, minimum MTU, ordering guarantees, etc. 3- PANA is not currently used in any commercial networks (wired or wireless) such as DSL, PacketCable, WLAN, WiMAX, 3GPP UMTS, etc. 4- PANA is very complex with excessive protocol overhead that makes it less attractive for use in mobile cellular environments. 5- It's unclear if PANA can reach RFC status within the 3GPP2 designated time frame due to fundamental issues that are out of control of 3GPP2. See the companion contribution X31-20060327-030 for a detailed explanation of various PANA issues. In particular issue 4, probably the only technical comment was shown by your own company to be an exageration. The analysis showed that over the air the number of message exchanges were the same as those needed by a link layer approach. The only difference was the overhead of the packet headers, which I would not characterize as excessive protocol overhead given the context. The other issues cited have been shown to been inaccurate or baseless in fact. But I would say that the political campaign against PANA was executed flawlessly in 3GPP2. I hope that the IETF makes its decisions based on technical merits rather then on the success or failure of political campaigns. Lets therefore not use PANAs failure in 3GPP2 as an example. -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 3:44 PM To: Pekka Savola; Sam Hartman Cc: ietf@ietf.org Subject: Re: The Emperor Has No Clothes: Is PANA actually useful? The IETF does publish protocols that may or may not be viable in the real world. I think PANA, after a significant clean up, might belong in that category. I, for instance, have the following high-level issues: ** No real use cases out there, and no real hope either. 3GPP2 HRPD recently joined the growing list of L2 technologies that ruled out PANA. ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. ** PANA's notions of EP placement seem vague the EPs' location can range from the first-hop router to other routers within the access network (I don't want to paste it all here, but it's Section 7.1 in the framework document). Its crucial for a protocol that sets out to authenticate clients to enforce access control, to get the EP placement right. ** PANA has a notion of binding PANA authentication to an existing secure channel. It is not clear whether it makes sense and the framework document does not have any convincing text. That notion introduces more problems than solving any, I think. Here are some excerpts: Networks where a secure channel is already available prior to running PANA. The presence of a secure channel before PANA exchange eliminates the need for executing a secure association protocol after PANA. I guess the notion is that the existing secure channel is authenticated but for a different reason and PANA authenticates the client again for network access and binds the result using filters to that secure channel. Pretty ad hoc operation, I must say and I think breaks the EAP model. I can provide a more detailed review, but that's not the purpose of this thread. My conclusion is -- stealing Bernard's words -- EAP/IKEv2 will do for what PANA is supposed to support. PANA is not needed really. But if after clarifications, the WG insists that the docs be published, I guess the IESG might publish them as experimental or even move them to historic (not sure how the latter would work). regards, Lakshminath At 11:27 AM 5/24/2006, Pekka Savola wrote: On Wed, 24 May 2006, Sam Hartman wrote: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. ... FWIW, I do not believe the current framework document as written is sufficiently clear in order to be able to evaluate
Re: The Emperor Has No Clothes: Is PANA actually useful?
Sam, I think your note is asking in fact a number of questions: 1. Is the concept of EAP-authentication over IP for network access useful, as opposed to link layer mechanisms? 2. Is the PANA realization of this idea good, and are the documents satisfactory? 3. Is there a specific real-world case where PANA is being applied or will be applied? 4. What other alternatives exist for the same function and how do they compare to PANA? Re 1: I do believe an IP layer solution in this space is potentially useful. Not as something that replaces existing link layer solutions and takes over the market, but there are situations where it would be useful, for instance over link layers that have no such support, as a solution for networks where you just want to add a node in the middle of the access network without updating all access points (kind of like a replacement for weblogin but without the need for user intervention), etc. Re: 2: Here there are some issues, clearly. Defining a mechanism that works well in the IP layer does take some considerable care for discovery, local IP address, binding of the EAP to what is being done, etc. reasons. Even if you didn't have these complications, the task of getting all details right takes a long time, just witness how long 802.11i took. The task becomes even harder if you try cover situations that involve distributed implementation, allowances for different pluggable components, different environments, etc. This may be the root cause why we are in this discussion. Without the target WGs want to shoot for maximum flexibility, but if they overdo it they may get too many issues to worry about. And a lot of baggage to carry around in the protocol. And it for sure makes it hard to read the specs. Having said the above, I'm not sure there are any fundamental, unfixable problems in the protocol. The base protocol itself looks solid. Re: 3: This has been a long standing issue for the WG's results. I don't have much to add what was already said by others; in general, many of the specific technologies like 3GPP cellular or 802.11 employ their own link-layer solutions and the vendors tend to go with these. But I also know that PANA had been under serious consideration at least for 3GPP2 networks. Re: 4: There are indeed choices. The default assumption is going to be link layer protection, but as I said above, there seems to be some scenarios for other solutions as well. The question is what those solutions are and how they compare. One alternative is IKEv2 with its EAP support. It comes close to a full solution, but appears to lack at least discovery functionality since nomadic clients can't be expected to know the addresses of gateways in the networks they visit. But there may be some extension that I'm unaware of. (Historically, it is interesting to note that the first IKEv2 drafts started to appear around the time that PANA got chartered, though it seems that EAP support was added to IKEv2 only later.) Another alternative is described in draft-thomson-nacp-02.txt; this is a bare bones, very simple EAP-over-UDP solution. I like it, but if it were adopted as an IETF proposed standard it would probably need to support discovery, key confirmation and possibly some other things. PPPoE is an alternative. Propably folks who are doing this are going to continue using it. Some other partial solutions exist too. For instance, PANA has the capability to support authenticating both to a local network and to a home network; draft-barany-eap-gee is a solution for that (but met with some number of questions in the last EAP meeting). Is there a winner among the alternatives? Perhaps too early to tell. I have some unease with all of the options, in fact. So what's the conclusion? My conclusion is that there is need for a non-link layer solution, too. I feel the pain from PANA searching real world deployment, but I'm not sure we should set the PS bar so high that if you do not have commercial deployment you cannot publish your documents. We should, however, require that the specifications pass last call review, and work remains there. I'm not sure I have easy answers on how to get there. One advice that I would like to give is to take another look at the ambition level and scale it down. (Management 101: if you can't fix it, rip it out.) A solution that does not mix IP and link layer solutions would be preferrable, IMHO, and then we would get out of the 802.11 interaction problems. Perhaps lose the EP separation. Core PANA as a way to run EAP and confirm possession of the resulting key would be very useful, IMHO. Tunneling IPsec for data packets could be optional. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
What is the current state of the nea WG? I don't see it listed at http://ietf.org/html.charters/wg-dir.html - Ralph ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
In reading the PANA Framework document, what I read seemed to me to be more of a system or solution document than a clean IETF protocol framework. I saw efforts to address three different problems: 1) Securing an otherwise unsecured link, when the access node is not known to the client in advance. 2) Selecting an authorization (charging, possibly packet handling) service 3) Authenticating the user EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Hi Lakshminath, I guess there are differences in our understanding of 3G-WLAN interworking (and I could be wrong), but the point is that they (plan to) use EAP over IKEv2. We can try and debate the details offline, as that is not central to the discussion here. There's no question of whether IKEv2/EAP is being used. 3G-WLAN interworking is one example, Unlicensed Mobile Access is another one, what IKEv2/EAP was originally designed for is corporate VPN access, etc. But in most of these cases the usage is really VPN like, i.e., you already have Internet connectivity but to get to a closed network or service you contact a gateway via IKEv2. That gateway is often known beforehand and it could be in the other side of the world. Access control to get your Internet connectivity is another matter. 3G-WLAN, for instance, assumes local mechanisms for that in addition to whatever VPN to the home network. The specs don't really say much about what the local mechanisms are except that they need to be EAP-based if authentication via the 3G network is desired. But the assumption is that on a 802.11 network, 802.11i would get used. This leaves still the question of whether IKEv2/EAP or PANA could be used to provide access control for the Internet connectivity. More on that in my other e-mail. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Ralph Droms wrote: What is the current state of the nea WG? I don't see it listed at http://ietf.org/html.charters/wg-dir.html NEA held a BOF in Dallas, and I believe they are planning to hold a 2nd BOF in Montreal. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Alper == Alper Yegin [EMAIL PROTECTED] writes: Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). As I understand it, EAP over UDP is one of the items proposed for standardization in the NEA WG. Alper You misunderstood it, despite the clear text in their Alper charter: Alper ... Alper Requirements need to be defined for an EAP over L3 Alper transport for L3 access scenarios. I don't think he misunderstood. IT may not be in their charter, but they definitely did want to standardize EAP over UDP in at least some versions of NEA. My question is more why do they need EAP in situations where they are not running at the link layer than why do they want or not want PANA. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Ralph == Ralph Droms [EMAIL PROTECTED] writes: Ralph What is the current state of the nea WG? I don't see it Ralph listed at http://ietf.org/html.charters/wg-dir.html It had a BOF at the last IETF. It seems highly likely it will either have a proposed WG or BOF again. (Russ and I have received both a charter and a BOF proposal) Russ is shepherding the effort. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Sam - I see where the nea BOF was more-or-less associated with the Internet Area at IETF 65. Do you expect that nea would (if eventually chartered) land in Internet or Security? - Ralph On 5/26/06 10:58 AM, Sam Hartman [EMAIL PROTECTED] wrote: Ralph == Ralph Droms [EMAIL PROTECTED] writes: Ralph What is the current state of the nea WG? I don't see it Ralph listed at http://ietf.org/html.charters/wg-dir.html It had a BOF at the last IETF. It seems highly likely it will either have a proposed WG or BOF again. (Russ and I have received both a charter and a BOF proposal) Russ is shepherding the effort. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Dave - one quick follow on to your observation about will not work that falls somewhere between will not work and don't like it. There is another possibility: works, but there's a much simpler way to meet the same requirements... - Ralph On 5/26/06 11:34 AM, Dave Crocker [EMAIL PROTECTED] wrote: Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
I have to disagree. Firstly, if many of us reading the document can not figure out what problem it is solving, then the framework is not doing its job. Secondly, if there are existing, viable, deployed solutions to the problem that the WG is attempting to solve then the WG needs to explain somewhere (the framework document would seem the obvious place) why there is a need for a new solution. I am not claiming that the PANA protocol can't work. As was said many years ago with sufficient thrust, pigs will fly. But that does not make flying pigs a good thing. Yours, Joel M. Halpern At 11:34 AM 5/26/2006, Dave Crocker wrote: Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Dave Crocker escribió: Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. I totally agree with your statement, I was just thinking about sending a message in this line. I am (at least I thought I am) a scientific and as such I prefer to work with statement and lemas that allow me to reason with them. Although in some of the messages I have read there are more perceptions or opinions but too little technical criticism. In that sense I will like to see clear indication of what is not adequate and wrong in a more technical fashion, hence it will allow people to debate on it an a least explain the reason in objectives and not subjective ways My 2 cents on this If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Antonio F. Gómez Skarmeta Dept. IngenierÃa de la Información y las Comunicaciones Facultad de Informática Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Ralph Droms escribió: Dave - one quick follow on to your observation about will not work that falls somewhere between will not work and don't like it. There is another possibility: works, but there's a much simpler way to meet the same requirements... Which one? and why it is better? Antonio - Ralph On 5/26/06 11:34 AM, Dave Crocker [EMAIL PROTECTED] wrote: Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Antonio F. Gómez Skarmeta Dept. IngenierÃa de la Información y las Comunicaciones Facultad de Informática Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
At 5:21 PM +0300 5/26/06, Jari Arkko wrote: Ralph Droms wrote: What is the current state of the nea WG? I don't see it listed at http://ietf.org/html.charters/wg-dir.html NEA held a BOF in Dallas, and I believe they are planning to hold a 2nd BOF in Montreal. Mailing list info: https://www1.ietf.org/mailman/listinfo/nea. The post-Dallas discussions have been quite fruitful, and the discussion this week particularly so. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
My question is more why do they need EAP in situations where they are not running at the link layer than why do they want or not want PANA. The simple answer is that there are situations which IEEE 802.1X cannot handle on wired networks. As specified, IEEE 802.1X is network port control, which means that authorization is controllable only at the port level. If there is more than one host connected to a switch port, then that model no longer applies. For example, consider a user with two machines attached to a hub on a single port - a laptop and a desktop machine. The desktop authenticates via machine credentials, and for some reason the certificate has expired without being renewed. The laptop has up to date credentials. However, because they are both connected to the same port, they will each attempt to authenticate; since the desktop machine no longer has up to date credentials, its authentication will fail, causing port access to be denied, throwing the laptop off the network. The two machines will continue to cycle through authentication attempts, causing the port to alternatively be open and closed. Some of the solutions that have been discussed include: a. For the switch to keep MAC state on each port, which requires a additional CAM, and therefore a forklift upgrade, OR b. For the switch to support protected Ethernet (802.1ae) and associated key management (802.1af) so that traffic from each host can be cryptographically separated, also requiring an (even more expensive) forklift upgrade; OR c. For the host and routers to support EAP over UDP. Typically this works by having the router recognize a new host (e.g. new entry in the ARP table), then challenging it via EAP over UDP. If the host successfully authenticates, packets from that IP address are allowed to pass through the router filter; otherwise not. Of these approaches, b) is the most secure since it enables cryptographic separation between traffic from different MAC addresses, preventing MAC address piggyback attacks as well as enabling reliable shared media operation. However, it is also the most expensive approach, since each port now needs to support encryption; at lines rates of 1+ Gbps this can be pricey. Approach a) is less expensive (and less ecure) than b), but also requires a forklift upgrade. Approach c) is probably the least secure, but it is also the least expensive approach, since no switch ports need to be upgraded. One might argue that approach c) is likely to represent a short-term fix until switches supporting a) or b) are commonly available, and therefore that EAP over UDP has no long-term future. I would tend to agree with this, but would also observe that switches tend to have long replacement cycles. For example, it is common to see customers with Cat 5K switches that have been in place for a nearly decade with no immediate prospects for replacement. Those kind of customers are likely to find EAP over UDP appealing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Antonio - I'm not well-informed enough about the specifics of the PANA problem space and framework to make definitive recommendations. I was mostly making an observation, based on my experience, of another reaction someone might have to a particular technology/design/protocol. - Ralph On 5/26/06 11:50 AM, Antonio F. Gómez Skarmeta [EMAIL PROTECTED] wrote: Ralph Droms escribió: Dave - one quick follow on to your observation about will not work that falls somewhere between will not work and don't like it. There is another possibility: works, but there's a much simpler way to meet the same requirements... Which one? and why it is better? Antonio - Ralph On 5/26/06 11:34 AM, Dave Crocker [EMAIL PROTECTED] wrote: Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Bernard == Bernard Aboba [EMAIL PROTECTED] writes: My question is more why do they need EAP in situations where they are not running at the link layer than why do they want or not want PANA. Bernard The simple answer is that there are situations which IEEE Bernard 802.1X cannot handle on wired networks. As specified, Bernard IEEE 802.1X is network port control, which means that Bernard authorization is controllable only at the port level. If Bernard there is more than one host connected to a switch port, Bernard then that model no longer applies. Yeah. I guess I wonder whether you are actually getting network access authenticatino at that point or whether you are getting a service that allows you to check posture. It seems that a service that simply allows you to check posture should be not EAP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Ralph Droms wrote: Dave - one quick follow on to your observation about will not work that falls somewhere between will not work and don't like it. There is another possibility: works, but there's a much simpler way to meet the same requirements... ahh, good. this nicely permits making the underlying distinction a bit more strongly: There is a much simpler way to meet the requirements states an engineering preference. Further, it often involves comparing a concrete specification against an unspecified idea. The issue therefore is not whether the criticism is valid -- it often is -- but that it falls primarily into the I don't like it category. If there is a better way to solve a problem, those supporting the alternative ought to go and specify it and gain community adoption. Otherwise, we suffer the danger of preventing deployment of *any* capability, since we will always be waiting for work to get done on that simpler way of meeting the same requirements. The folks who actually did the work ought get to test that work in the market place... unless there is a clear basis for claiming that it won't work and reasonable consensus that the basis is valid. d/ ps. The process model that informs this line of thinking says that we should be strict in demanding strong indication of community support, when an effort starts -- and I will claim while the working group proceeds -- but that it should not factor that into the final standardization decision. In this latter stage, this concern looks too much like sour grapes. (Not that it necessarily is, but that it simply is not fair to use it as a basis for rejection at that stage.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Joel M. Halpern wrote: I have to disagree. Firstly, if many of us reading the document can not figure out what problem it is solving, then the framework is not doing its job. Secondly, if there are existing, viable, deployed solutions to the problem that the WG is attempting to solve then the WG needs to explain somewhere (the framework document would seem the obvious place) why there is a need for a new solution. I am not claiming that the PANA protocol can't work. As was said many years ago with sufficient thrust, pigs will fly. But that does not make flying pigs a good thing. Flying pigs would add RFC 2549 a totally new meaning, incrementing put through dramatically :) Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Here in germany DTAG.de, the infrastructure supplier for most aDSL providers does use PPPoE exclusively, authorization by PAP. It would be nice to connect an aDSL modem directly to a WLAN and let everybody use his own personal account via the AP. Alas - eavesdropping ... If PANA could come in here? I dont know PANA at all right now. That is why I dont know what harm it does. Can anybody tell me what to look for? At 11:34 AM 5/26/2006, Dave Crocker wrote: Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. There are more complicated protocols that have been implemented, like netbios over tcp, without thought of their impact on security. I have burnt my fingers running netbios (samba) on a system (linux) I deemed imune against hackers. I dont want to run that risk again. I dont see the pit I might fall in - but I cannot see very far right now, because of thouse high walls around me :) Still that is not a reason against documenting it. Just giving more insight would be welcome. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? Kind regards Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Joel M. Halpern wrote: I have to disagree. Firstly, if many of us reading the document can not figure out what problem it is solving, then the framework is not doing its job. As I tried to indicate, any sort of broad-based confusion about the purpose or use of a spec is a very basic indication that the spec cannot work. How can it work if the potential adopter community does not know what it is for or how to use it? So I suspect we do NOT disagree on this point. Secondly, if there are existing, viable, deployed solutions to the problem that the WG is attempting to solve then the WG needs to explain somewhere (the framework document would seem the obvious place) why there is a need for a new solution. I enjoy debating preferences and superiority as much as the next IETF attendee, but it is not a good basis for rejecting the diligent effort by a chartered working group. Basavaraj Patil wrote: The fact that the IETF is supposed to be based on Rough consensus and running code is completely being missed here. That is clearly not correct. The nature of Sam's public query is specifically (and explicitly) looking for certain kinds of rough consensus. Currently there are multiple interoperable implementation of the protocol in addition to there existing an open-source implementation as well. The fact that several years of peoples work and effort has gone into this is being ignored by claims that I find quite have a vested interest. That some people have a common view of the work and that they have used that common view to produce interoperable implementations is extremely important. However the difference between a few folks can make this work and the broad-based Internet technical community can make this work entails a non-trivial aspect of protocol scaling. Scaling in development and adoption is just as important as scaling in use. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Bernard == Bernard Aboba [EMAIL PROTECTED] writes: My question is more why do they need EAP in situations where they are not running at the link layer than why do they want or not want PANA. Bernard The simple answer is that there are situations which IEEE Bernard 802.1X cannot handle on wired networks. As specified, Bernard IEEE 802.1X is network port control, which means that Bernard authorization is controllable only at the port level. If Bernard there is more than one host connected to a switch port, Bernard then that model no longer applies. Yeah. I guess I wonder whether you are actually getting network access authenticatino at that point or whether you are getting a service that allows you to check posture. It seems that a service that simply allows you to check posture should be not EAP. I fully agree. As far as I can tell, using EAP in this manner merely reduces it to a posture transport protocol. The level of security provided by EAPoUDP does not seem to be any greater than a kerberos-based authentication done today in most enterprise networks, considering the presence of switched ethernet. Hence, the only reason to move to EAPoUDP would be to check posture and I agree with Sam that making EAP the posture transport protocol is a bad idea. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
On Fri, 26 May 2006, Gray, Eric wrote: For those of us that are just trying to follow this discussion, what does the word posture mean in this context? according to draft-thomson-nea-problem-statement-02.txt Posture: Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. -- Eric -- -Original Message- -- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] -- Sent: Friday, May 26, 2006 2:05 PM -- To: Sam Hartman; Bernard Aboba -- Cc: ietf@ietf.org -- Subject: RE: The Emperor Has No Clothes: Is PANA actually useful? -- -- -- Bernard == Bernard Aboba [EMAIL PROTECTED] writes: -- -- My question is more why do they need EAP in -- situations where -- they are not running at the link layer than why do -- they want or -- not want PANA. -- -- Bernard The simple answer is that there are -- situations which IEEE -- Bernard 802.1X cannot handle on wired networks. As -- specified, -- Bernard IEEE 802.1X is network port control, which -- means that -- Bernard authorization is controllable only at the -- port level. If -- Bernard there is more than one host connected to a -- switch port, -- Bernard then that model no longer applies. -- -- Yeah. I guess I wonder whether you are actually getting -- network access authenticatino at that point or whether you -- are getting a service that allows you to check posture. It -- seems that a service that simply allows you to check posture -- should be not EAP. -- -- -- -- I fully agree. As far as I can tell, using EAP in this manner merely -- reduces it to a posture transport protocol. The level of security -- provided by EAPoUDP does not seem to be any greater than a -- kerberos-based authentication done today in most enterprise -- networks, -- considering the presence of switched ethernet. Hence, the -- only reason to -- move to EAPoUDP would be to check posture and I agree with Sam that -- making EAP the posture transport protocol is a bad idea. -- -- Vidya -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Jari, Sam, I think your note is asking in fact a number of questions: 1. Is the concept of EAP-authentication over IP for network access useful, as opposed to link layer mechanisms? 2. Is the PANA realization of this idea good, and are the documents satisfactory? 3. Is there a specific real-world case where PANA is being applied or will be applied? 4. What other alternatives exist for the same function and how do they compare to PANA? Re 1: I do believe an IP layer solution in this space is potentially useful. Not as something that replaces existing link layer solutions and takes over the market, but there are situations where it would be useful, for instance over link layers that have no such support, as a solution for networks where you just want to add a node in the middle of the access network without updating all access points (kind of like a replacement for weblogin but without the need for user intervention), etc. I am trying to figure out the use case for an IP layer solution in this space as an access authentication protocol and I am not convinced that we need something like PANA. If you are in fact, adding a node in the middle of the access network that is going to perform access control, is it just performing authentication or also attempting to derive keys and secure the data traffic? With a solution like PANA, a link layer secure association protocol or IPsec needs to be run to secure data traffic. If the former, the authenticator (or at least the EP) needs to be located at the edge. This needs support at the link layer anyway, and all such link layers already support EAP. If the latter, the most natural solution to use is IKEv2 with EAP, since even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't see what benefit PANA provides here. Perhaps I am missing something here? Regards, Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Hi Jari, Hi Lakshminath, I guess there are differences in our understanding of 3G-WLAN interworking (and I could be wrong), but the point is that they (plan to) use EAP over IKEv2. We can try and debate the details offline, as that is not central to the discussion here. There's no question of whether IKEv2/EAP is being used. 3G-WLAN interworking is one example, Unlicensed Mobile Access is another one, what IKEv2/EAP was originally designed for is corporate VPN access, etc. But in most of these cases the usage is really VPN like, i.e., you already have Internet connectivity but to get to a closed network or service you contact a gateway via IKEv2. That gateway is often known beforehand and it could be in the other side of the world. Access control to get your Internet connectivity is another matter. 3G-WLAN, for instance, assumes local mechanisms for that in addition to whatever VPN to the home network. The specs don't really say much about what the local mechanisms are except that they need to be EAP-based if authentication via the 3G network is desired. But the assumption is that on a 802.11 network, 802.11i would get used. I am not sure that the VPN case and the access control in the 3G-WLAN case are that different. The VPN access you are describing really provides remote access control. The point of that is that the edge equipment is out of control (and potentially untrusted) of the entity providing access and hence there is a need for remote access control. It is essentially the same scenario for parts of 3G-WLAN interworking. The access points may be provided by a vendor that is different from the operator and hence, an operator's box is performing remote access control using IPsec - the method to set up the IPsec SA was chosen to be an IKEv2/EAP combination. Of course, in the cases where the WLAN equipment can be trusted and is part of the operator's network, 802.11i would potentially be used as you say. The only difference in the enterprise WLAN vs 3G-WLAN scenario is that the former is providing intranet access, while the latter is for general internet access even. However, this is really about semantics. If an entity actually receives a valid IP address to use in the local network, it only needs to perform IPsec/IKEv2 with the operator's box in the 3G-WLAN case for access to home domain services (no different really from the corporate VPN case). Vidya This leaves still the question of whether IKEv2/EAP or PANA could be used to provide access control for the Internet connectivity. More on that in my other e-mail. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Gray, == Gray, Eric [EMAIL PROTECTED] writes: Gray, For those of us that are just trying to follow this Gray, discussion, what does the word posture mean in this Gray, context? Assertions about your OS state--things like patch levels, configuration of security settings, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
AW: The Emperor Has No Clothes: Is PANA actually useful?
Hi Dave,
thanks for your feedback.
I guess your mail (and Jari's mail) try to be a little bit less biased
in this discussion.
~snip~
By contrast observations such as there are better solutions
or 'different solutions'
moves into the
fuzzier and more subjective realm of trying to predict market
preferences. The
IETF is not very good at making these predictions.
That's very nicely phrased. I guess we could have a long discussion
about this subject and why other organizations do not use some IETF
protocols. We all know that there is the 'not invented here' problem,
sometimes a company marketing story ('company X has developed it's own
proprietary protocol') and in some other cases it is an IPR issue.
If we now raise the bar for IETF protocols to a level where we consider
work as 'successful' or 'good' when other organizations make use of
these protocols then we should change our workstyle a little bit. We
could just rubber stamp protocols these SDOs developed on their own ...
~snip~
A small comment when it comes to understand documents:
I have realized that it is popular in standardization organizations to
be temporarly and selectively confused about some things.
I suspect that you can copy-and-paste Sam's mail, replace PANA with
another protocol and working group name, post it to the IETF mailing
list and you might get a similar response.
I would find it particularly helpful to have a concise
statement from someone
who says that PANA will not work. Cannot be implemented
(properly) by virtue of
technical errors or documentation too confusing to
understand. Or cannot be
deployed and used, by virtue of administrative complexity or, again,
documentation too confusing to understand.
Absent this, I will ask why it is productive to note that the
emperor is
pursuing an idiosynchratic sartorial style?
Sam accidently posted his mail shortly after the heated discussion of
PANA usage at the 3GPP2.
From the comments on this mailing list it is obvious which company was
not favor for PANA (for whatever reason).
Ciao
Hannes
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Hi Vidya, Re 1: I do believe an IP layer solution in this space is potentially useful. Not as something that replaces existing link layer solutions and takes over the market, but there are situations where it would be useful, for instance over link layers that have no such support, as a solution for networks where you just want to add a node in the middle of the access network without updating all access points (kind of like a replacement for weblogin but without the need for user intervention), etc. I am trying to figure out the use case for an IP layer solution in this space as an access authentication protocol and I am not convinced that we need something like PANA. If you are in fact, adding a node in the middle of the access network that is going to perform access control, is it just performing authentication or also attempting to derive keys and secure the data traffic? With a solution like PANA, a link layer secure association protocol or IPsec needs to be run to secure data traffic. If the former, the authenticator (or at least the EP) needs to be located at the edge. This needs support at the link layer anyway, and all such link layers already support EAP. If the latter, the most natural solution to use is IKEv2 with EAP, since even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't see what benefit PANA provides here. My comment above relates to the overall interest in an IP layer solution without considering what protocol is used. I also wrote in my e-mail something about the different alternative solutions. It is true that IKEv2 with EAP is potentially a good fit for this task. IKEv2 is my favorite EAP encapsulation protocol :-) However, its not clear that it currently has all the parts (though I could have missed some extension somewhere). For instance, some mechanism appears to be needed to discover that you are in a network that requires this type of operation, and to find the address of the control device that you need to talk to. I haven't done the research on how easy it would be to add this (probably quite easy) or if there are other things that we would need. Thoughts? Anyway, I agree with Dave Crocker that the bar should be higher for using there's another solution argument in last call discussion of chartered work than in, say, a BOF discussion. Perhaps we should focus more on whether the function itself is something that we agree on, and what we can do to fix/scope/help PANA. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
NEA scope (RE: The Emperor Has No Clothes: Is PANA actually useful?)
I, as a PANA WG chair, have many issues with this thread. It's objective, execution, place in IETF process, roles and responsibilities, etc. I'm not going to get into that now (yet). But I want to say I don't see how it's going to achieve what Sam thinks he wants to achieve -- neither the need for doing that as I explained earlier. We'll try to weed out the technical and useful stuff out of this jungle. Let me create separate threads for those and see if we can prevent further confusion before people confuse each other, and identify what additional work needs to be done on our documents. With that in mind, here is the first thread. -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 8:05 AM To: Alper Yegin Cc: 'Bernard Aboba'; ietf@ietf.org Subject: Re: The Emperor Has No Clothes: Is PANA actually useful? Alper == Alper Yegin [EMAIL PROTECTED] writes: Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). As I understand it, EAP over UDP is one of the items proposed for standardization in the NEA WG. Alper You misunderstood it, despite the clear text in their Alper charter: Alper ... Alper Requirements need to be defined for an EAP over L3 Alper transport for L3 access scenarios. I don't think he misunderstood. IT may not be in their charter, but they definitely did want to standardize EAP over UDP in at least some versions of NEA. This is not how the NEA charter read (see my above quotes). Where did you get this idea from? My question is more why do they need EAP in situations where they are not running at the link layer than why do they want or not want PANA. This is something that needs to be asked to the NEA community. PANA community did not invent using PANA for NEA. When NEA people said they needed IP over UDP, we said PANA does that. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Framework document scope (RE: The Emperor Has No Clothes: Is PANA actually useful?)
I have to disagree. Firstly, if many of us reading the document can not figure out what problem it is solving, then the framework is not doing its job. Framework document discusses deployments. Problem statement and requirements is what you are looking for (RFC 4058). Secondly, if there are existing, viable, deployed solutions to the problem that the WG is attempting to solve then the WG needs to explain somewhere (the framework document would seem the obvious place) why there is a need for a new solution. Again, this is in the scope of the problem statement and requirements. Alper I am not claiming that the PANA protocol can't work. As was said many years ago with sufficient thrust, pigs will fly. But that does not make flying pigs a good thing. Yours, Joel M. Halpern At 11:34 AM 5/26/2006, Dave Crocker wrote: Joel M. Halpern wrote: EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem. And spell out in clear English what use case needs that problem solved. I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard. Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either It will not work versus I don't like it. The former indicates a basic technical flaw, and the latter a matter of preference. If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use? By contrast observations such as there are better solutions moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue from publishing a specification, fear that no one will adopt it or that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.) In any event, I would claim that concerns over who will use PANA fall into the I don't like it category, since it basically seeks to make statements about market preferences, which is a small step from personal preferences. Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use. I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
GEE is but a small optional enhancement to address the case of parallel EAP authentications. GEE is not an EAP lower layer and thus it is invalid to compare it to PANA. What is GEE than? Please explain it to us in terms of RFC 3748. So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. We are not feeding on complexity, we are not married to it either. If you can tell us what parts we can simplify, the whole community would be grateful to you. Please describe where you see unnecessary complexity, and suggest remedies. Thanks. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
EAP/IKEv2 as an alternative to PANA (RE: The Emperor Has No Clothes: Is PANA actually useful?)
If the latter, the most natural solution to use is IKEv2 with EAP, since even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't see what benefit PANA provides here. My comment above relates to the overall interest in an IP layer solution without considering what protocol is used. I also wrote in my e-mail something about the different alternative solutions. It is true that IKEv2 with EAP is potentially a good fit for this task. IKEv2 is my favorite EAP encapsulation protocol :-) However, its not clear that it currently has all the parts (though I could have missed some extension somewhere). For instance, some mechanism appears to be needed to discover that you are in a network that requires this type of operation, and to find the address of the control device that you need to talk to. More fundamentally, when there are multiple gateways (for any redundancy/failover/etc reason), pure IKEv2 solution requires multiple EAP runs to get authorized for accessing one network. This does not work well with the AAA backend deployments (which defaults to one authentication per network access). And it did not make any sense to augment IKEv2 (let alone not being able to use IKEv1) to meet the PANA requirements, and then force everyone to use it even though they are not interested in IPsec SAs. This was discussed in the PANA WG long time ago. But for people who are not following the work and trying a last minute how about this now? this might appear like an original idea. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
At 03:20 PM 5/26/2006, Alper Yegin wrote: So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. Alper, It's clear now that PANA documents as written are found to be complex and with gaps by folks who have spent the time to review them during the IETF LC process. So, whereas there is consensus at WG level as determined by Raj and you to forward the documents to the IESG, at the IETF LC level, I see that there is no broad consensus as I understand the word rough consensus. We are not feeding on complexity, we are not married to it either. If you can tell us what parts we can simplify, the whole community would be grateful to you. I did a review of PANA-IPsec and had several questions and comments, but then of course the discussion moved to what does PANA buy more than say EAP over IKEv2 and I didn't have a reasonable answer. Further, my recollection is that several emails in this thread have already listed things PANA might do away with to reduce the complexity (e.g., one of Jari's emails). regards, Lakshminath Please describe where you see unnecessary complexity, and suggest remedies. Thanks. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
Lakshminath, Are you aware that you are not answering my question? Please describe where you see unnecessary complexity, and suggest remedies. Noone came near answering these, so throwing the ball to someone else wont help. Alper -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 3:58 PM To: Alper Yegin Cc: ietf@ietf.org Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?) At 03:20 PM 5/26/2006, Alper Yegin wrote: So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. Alper, It's clear now that PANA documents as written are found to be complex and with gaps by folks who have spent the time to review them during the IETF LC process. So, whereas there is consensus at WG level as determined by Raj and you to forward the documents to the IESG, at the IETF LC level, I see that there is no broad consensus as I understand the word rough consensus. We are not feeding on complexity, we are not married to it either. If you can tell us what parts we can simplify, the whole community would be grateful to you. I did a review of PANA-IPsec and had several questions and comments, but then of course the discussion moved to what does PANA buy more than say EAP over IKEv2 and I didn't have a reasonable answer. Further, my recollection is that several emails in this thread have already listed things PANA might do away with to reduce the complexity (e.g., one of Jari's emails). regards, Lakshminath Please describe where you see unnecessary complexity, and suggest remedies. Thanks. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
Lakshminath Dondeti wrote: At 05:07 PM 5/24/2006, Vijay Devarapallli wrote: On 5/24/06, Lakshminath Dondeti [EMAIL PROTECTED] wrote: ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. the 3G-WLAN interworking scenario is similar to an enterprise user gaining access to the enterprise via an IPsec gateway. a user who is subscribed to a mobile operator's services uses IKEv2 with a VPN-like gateway to access the operator's services. the mode is different. therefore I don't think this is an alternative to PANA and shouldn't be confused with PANA. we could discuss this more, but on a separate thread. Vijay /x-flowed Hi, I guess there are differences in our understanding of 3G-WLAN interworking (and I could be wrong), but the point is that they (plan to) use EAP over IKEv2. EAP over IKEv2 is used but in the remote gateway mode. exactly like access to an Enterprise through a VPN gateway. please dont confuse this with PANA for network access. Vijay We can try and debate the details offline, as that is not central to the discussion here. regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
At 04:03 PM 5/26/2006, Alper Yegin wrote: Lakshminath, Are you aware that you are not answering my question? Please describe where you see unnecessary complexity, and suggest remedies. Noone came near answering these, so throwing the ball to someone else wont help. I am not, really. I am saying that the question has been answered by others. For instance, Jari says the following: One advice that I would like to give is to take another look at the ambition level and scale it down. (Management 101: if you can't fix it, rip it out.) A solution that does not mix IP and link layer solutions would be preferrable, IMHO, and then we would get out of the 802.11 interaction problems. Perhaps lose the EP separation. Core PANA as a way to run EAP and confirm possession of the resulting key would be very useful, IMHO. Tunneling IPsec for data packets could be optional. --Jari In addition to those I never quite understood the need for NAP and ISP authentications and including all that discussion in the main protocol, to state one additional concern. In my secdir review of PANA-IPsec I had the following high-level comments (a detailed review is posted on secdir; I am not sure about whether you've seen it. Let me know otherwise): 1. The document should restrict itself to IKEv2 and IPsec as in 4301 and 4303. There is also a reference to MOBIKE in PANA protocol, but this document doesn't talk about that. Perhaps that gap needs to be filled. 2. I have suggestions for revision of PSK derivation from the PaC-EP-Master-Key 3. EAP Re-authentication, PSK switch over, new IKEv2 and IPsec establishment needs more detailed specification. 4. I have some comments about default crypto algorithms and algorithm agility 5. The security considerations section says, If the EP does not verify whether the PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. This is at best not clear, or perhaps a serious security hole. It appears that either address authorization (CGA?) is needed or a particular configuration of IP addresses is needed for IPsec to be effective. So, in summary, I have really put a lot of time reviewing and reading PANA documents before making my statements. As many have said, if it is one or two persons who have some doubts it's one thing. It looks like I am in good company in expressing my opinions. I am really not going to spend any more *substantial* time on this thread. regards, Lakshminath Alper -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 3:58 PM To: Alper Yegin Cc: ietf@ietf.org Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?) At 03:20 PM 5/26/2006, Alper Yegin wrote: So far evaluations done by the broader community seem to be concluding that PANA is in fact complex and not easily deployable. Who would that community be? I have heard the complexity issue from you and few others multiple times, but there has never been a justification to this claim. Alper, It's clear now that PANA documents as written are found to be complex and with gaps by folks who have spent the time to review them during the IETF LC process. So, whereas there is consensus at WG level as determined by Raj and you to forward the documents to the IESG, at the IETF LC level, I see that there is no broad consensus as I understand the word rough consensus. We are not feeding on complexity, we are not married to it either. If you can tell us what parts we can simplify, the whole community would be grateful to you. I did a review of PANA-IPsec and had several questions and comments, but then of course the discussion moved to what does PANA buy more than say EAP over IKEv2 and I didn't have a reasonable answer. Further, my recollection is that several emails in this thread have already listed things PANA might do away with to reduce the complexity (e.g., one of Jari's emails). regards, Lakshminath Please describe where you see unnecessary complexity, and suggest remedies. Thanks. Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Ever since PANA was first proposed, I did not understand why the IETF accepted it as a work item, because it seemed to me that it was duplicating existing capabilities (e.g., RADIUS, Diameter, etc.) and thereby needlessly increasing complexity system-wide. By this discussion, I surmise that you have greater insights than I. Hence this question to you: What 'bad thing' would happen should PANA not go forward? I suspect that this question has been answered many times. But could you please answer it using simple concepts for the benefit of those of us who aren't thinking deeply on a sleepy Friday evening? I am particularly interested in whether you believe end users require PANA and, if so, why? Thanks! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Hi Jari, Hi Vidya, Re 1: I do believe an IP layer solution in this space is potentially useful. Not as something that replaces existing link layer solutions and takes over the market, but there are situations where it would be useful, for instance over link layers that have no such support, as a solution for networks where you just want to add a node in the middle of the access network without updating all access points (kind of like a replacement for weblogin but without the need for user intervention), etc. I am trying to figure out the use case for an IP layer solution in this space as an access authentication protocol and I am not convinced that we need something like PANA. If you are in fact, adding a node in the middle of the access network that is going to perform access control, is it just performing authentication or also attempting to derive keys and secure the data traffic? With a solution like PANA, a link layer secure association protocol or IPsec needs to be run to secure data traffic. If the former, the authenticator (or at least the EP) needs to be located at the edge. This needs support at the link layer anyway, and all such link layers already support EAP. If the latter, the most natural solution to use is IKEv2 with EAP, since even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't see what benefit PANA provides here. My comment above relates to the overall interest in an IP layer solution without considering what protocol is used. I also wrote in my e-mail something about the different alternative solutions. It is true that IKEv2 with EAP is potentially a good fit for this task. IKEv2 is my favorite EAP encapsulation protocol :-) However, its not clear that it currently has all the parts (though I could have missed some extension somewhere). For instance, some mechanism appears to be needed to discover that you are in a network that requires this type of operation, and to find the address of the control device that you need to talk to. I haven't done the research on how easy it would be to add this (probably quite easy) or if there are other things that we would need. Thoughts? Let me separate out two issues here. In order to discover that you are in a network that requires this type of operation, you need to know via some kind of advertisements (SSID, for instance) that you are not in the home network. For instance, VPN connections today are mostly user initiated. Another issue that you mention here is the discovery of the address of the control device - this is typically done via DNS today. Thinking further about the PAA discovery mechanisms outlined in the PANA protocol, it seems to bring some deployment concerns. Administratively scoped multicast is one of the advocated methods of performing PAA discovery. Administrative scoping of multicast is a huge administrative burden and is not a good deployment option. Protocols like DVMRP allow TTL scoping which are somewhat better. But, the thought of opening up port control to allow multicast packets into the network prior to authentication is not appealing to me. Another option that PANA provides for PAA discovery is traffic-driven discovery. This is somewhat similar to what EAP relies on - i.e., the network figures out that it needs to send an EAP Request Identity (in the absence of an EAPoL-Start like message). In short, discovery hardly seems to be a reason to use PANA to me - I'm trying to at least taste the kool-aid, even if I can't drink it all, but somehow, am yet finding a convincing reason why I should :) Vidya Anyway, I agree with Dave Crocker that the bar should be higher for using there's another solution argument in last call discussion of chartered work than in, say, a BOF discussion. Perhaps we should focus more on whether the function itself is something that we agree on, and what we can do to fix/scope/help PANA. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
I tried this in my secdir review, for instance suggesting that perhaps PANA-IPsec should be limited to IKEv2 and 4301 and people had different opinions ranging from 'not sure about forcing IKEv2 on PANA' to 'there wouldn't be any differentiator to PANA' (they are not quotes; I am paraphrasing), and so really didn't find a consensus to make any recommendations. In the end though, I think perhaps publishing PANA documents after the necessary clean-up as experimental and informational RFCs is the right way to go about it. There is a long of line of WGs where this has happened and some of those documents have eventually come back into standards track. best regards, Lakshminath At 02:30 PM 5/26/2006, Jari Arkko wrote: Anyway, I agree with Dave Crocker that the bar should be higher for using there's another solution argument in last call discussion of chartered work than in, say, a BOF discussion. Perhaps we should focus more on whether the function itself is something that we agree on, and what we can do to fix/scope/help PANA. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AW: The Emperor Has No Clothes: Is PANA actually useful?
A small comment when it comes to understand documents: I have realized that it is popular in standardization organizations to be temporarly and selectively confused about some things. I suspect that you can copy-and-paste Sam's mail, replace PANA with another protocol and working group name, post it to the IETF mailing list and you might get a similar response. Agreed. Perhaps, we should do this all working groups in the IETF. I have no doubt in my mind that this list will be flooded with countless *opinions*. Perhaps, PANA is the first one on the list and others to follow soon.. -mohan I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? Sam accidently posted his mail shortly after the heated discussion of PANA usage at the 3GPP2. From the comments on this mailing list it is obvious which company was not favor for PANA (for whatever reason). Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
PANA vs. RADIUS/Diameter (RE: The Emperor Has No Clothes: Is PANA actually useful?)
Ever since PANA was first proposed, I did not understand why the IETF accepted it as a work item, because it seemed to me that it was duplicating existing capabilities (e.g., RADIUS, Diameter, etc.) and thereby needlessly increasing complexity system-wide. Sigh This is why some people think it creates complexity? PANA has nothing to do with duplicating RADIUS and Diameter. The relation between PANA and RADIUS/Diameter is clearly documented across multiple documents of this WG. For example, the framework document said: The PAA consults an authentication server in order to verify the credentials and rights of a PaC. If the authentication server resides on the same node as the PAA, an API is sufficient for this interaction. When they are separated (a much more common case in public access networks), a protocol needs to run between the two. AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are commonly used for this purpose. We even illustrated this in the same document: RADIUS/ Diameter/ +-+ PANA+-+ LDAP/ API+-+ | PaC |-| PAA || AS | +-+ +-+ +-+ ^ ^ | | | +-+ | IKE/ +| EP |+ SNMP/ API 4-way handshake +-+ And we even put this in an FAQ! http://www.panasec.org/docs/PANA-FAQ.txt for those that don't want to read the documents. What else should we do? Record a reading of the documents and mail it to everyone? These are impossible to miss when someone reads the documents. As in this, and several other examples in the latest threads, the answers are there -- when people are looking for answers. Alper By this discussion, I surmise that you have greater insights than I. Hence this question to you: What 'bad thing' would happen should PANA not go forward? I suspect that this question has been answered many times. But could you please answer it using simple concepts for the benefit of those of us who aren't thinking deeply on a sleepy Friday evening? I am particularly interested in whether you believe end users require PANA and, if so, why? Thanks! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)
Alper Yegin wrote: Are you aware that you are not answering my question? Please describe where you see unnecessary complexity, and suggest remedies. Noone came near answering these, so throwing the ball to someone else wont help. from what I can tell, it does not matter very much that some folks see pana as having too much complexity, except to the extent that it affects what does matter. and what *does* matter quite a bit is that it looks like quite a few folk are unclear about the problem papa solves or the way(s) to use it, to achieve that solution. as always, the burden for fixing such problems lies with those promoting the specifications. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Hi Sam, I wish you had approached the PANA WG first to get clarification on your concerns and questions. And I wish the responsible AD had said go to PANA WG rather than don't go there when you consulted him. Even after the PANA WG was chartered, we went through your suggested exercise twice with our AD (Thomas Narten), and got the problem statement approved in RFC 4058. No conditions have changed since than, so I am not sure why we need to go through this exercise again at this stage (the protocol documents passed AD review and getting readied for IESG review). I am sure if you ask a broad question like who is confused about a given protocol, you'd always have many positive answers -- for various reasons. Not sure if this is helpful. Having basic knowledge about network access authentication and EAP is a prerequisite for anyone to understand what PANA really does. And for the question of where it would be used... One answer is already in the IETF NEA BoF. It calls for EAPoverL3 transport. And the other answer is in the DSL networks. If you have access to DSL Forum documents, I recommend you look at dsl2006.174.02. The document lists requirements for network access authentication protocol. PANA is a documented candidate and in fact it is the only one that satisfies all of the requirements. I hope these answer your concerns. Alper -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 8:12 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: The Emperor Has No Clothes: Is PANA actually useful? Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community
Re: The Emperor Has No Clothes: Is PANA actually useful?
At 05:07 PM 5/24/2006, Vijay Devarapallli wrote: On 5/24/06, Lakshminath Dondeti [EMAIL PROTECTED] wrote: ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. the 3G-WLAN interworking scenario is similar to an enterprise user gaining access to the enterprise via an IPsec gateway. a user who is subscribed to a mobile operator's services uses IKEv2 with a VPN-like gateway to access the operator's services. the mode is different. therefore I don't think this is an alternative to PANA and shouldn't be confused with PANA. we could discuss this more, but on a separate thread. Vijay /x-flowed Hi, I guess there are differences in our understanding of 3G-WLAN interworking (and I could be wrong), but the point is that they (plan to) use EAP over IKEv2. We can try and debate the details offline, as that is not central to the discussion here. regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
I have reviewed the PANA framework document, the PANA protocol spec, and the PANA/IPsec document. After reading all these documents, I still do not understand why PANA is useful. The PANA framework document claims that it can be used along with IEEE 802.11i. However, IEEE 802.11 reviewed the document, and came to a different conclusion: http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-IETF-PANA.doc The other potential scenario outlined by the framework document is use along with IPsec. However, IKEv2 already supports EAP authentication, so I don't understand why PANA would be used for that scenario instead of IKEv2. I do understand the potential need for EAP to be encapsulated over IP. However, in practice PANA is more complex than EAP over UDP (see draft-thomson-nacp-02.txt), which looks like it is on the road to becoming the defacto standard for EAP encapsulation over IP. So from what I can tell, in each potential usage scenario PANA is either not feasible, is more complex than an established alternative, or has been rejected by the SDOs that have examined it. --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Hi Bernard, -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 4:46 PM To: ietf@ietf.org Subject: Re: The Emperor Has No Clothes: Is PANA actually useful? I have reviewed the PANA framework document, the PANA protocol spec, and the PANA/IPsec document. After reading all these documents, I still do not understand why PANA is useful. Just below you are acknowledging the need for EAP over IP. I don't understand how you can still claim you don't understand why PANA is useful... The PANA framework document claims that it can be used along with IEEE 802.11i. However, IEEE 802.11 reviewed the document, and came to a different conclusion: http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response- IETF-PANA.doc This is an inaccurate reading of the IEEE response (and you are the liaison). You are aware that virtual open-access AP mode is OK. One of the two alternatives we proposed had an issue, and the other one still holds. The other potential scenario outlined by the framework document is use along with IPsec. However, IKEv2 already supports EAP authentication, so I don't understand why PANA would be used for that scenario instead of IKEv2. You had commented on that earlier and I had explained it. http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html. If not clear, please follow up from there (we don't need to go back to your original question). I do understand the potential need for EAP to be encapsulated over IP. Thank you. However, in practice PANA is more complex than EAP over UDP (see draft-thomson-nacp-02.txt), which looks like it is on the road to becoming the defacto standard for EAP encapsulation over IP. De-facto? Could you please elaborate how it is becoming a de-facto standard? Besides. Of course PANA is more complex than EAPoUDP. The latter (an individual I-D) has very limited applicability. If it were to handle mobility and wireless, it'll also grow in complexity. Just to get some sense of it, compare 802.1X and 802.11r. So from what I can tell, in each potential usage scenario PANA is either not feasible, is more complex than an established alternative, or has been rejected by the SDOs that have examined it. Which SDOs? Please give us more detail. Thank you. Alper --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried
RE: The Emperor Has No Clothes: Is PANA actually useful?
Just below you are acknowledging the need for EAP over IP. I don't understand how you can still claim you don't understand why PANA is useful... The framework doesn't seem to talk much about simple EAP over IP scenarios, so I have assumed this is not the major focus. You are aware that virtual open-access AP mode is OK. One of the two alternatives we proposed had an issue, and the other one still holds. Right. I was referring only to the WPA/WPA2 scenarios. De-facto? Could you please elaborate how it is becoming a de-facto standard? EAP over UDP is one of the foundation technologies for Network Endpoint Assessment (NEA). As I understand it, EAPoUDP is being made available on most operating systems, and is in the process of being deployed by many enterprise customers. Besides. Of course PANA is more complex than EAPoUDP. The latter (an individual I-D) has very limited applicability. As I understand it, EAP over UDP is mostly being deployed for wired access scenarios where IEEE 802.1X might not work well (e.g. multiple hosts sharing a port). Which SDOs? Please give us more detail. As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has evaluated the PANA framework document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Just below you are acknowledging the need for EAP over IP. I don't understand how you can still claim you don't understand why PANA is useful... The framework doesn't seem to talk much about simple EAP over IP scenarios, so I have assumed this is not the major focus. I am sure you read RFC 4058 (like anyone who claims they don't understand PANA should have done). RFC 4058 said: PANA will carry EAP above IP in order to enable any authentication method on any link-layer. You are aware that virtual open-access AP mode is OK. One of the two alternatives we proposed had an issue, and the other one still holds. Right. I was referring only to the WPA/WPA2 scenarios. Your earlier statement did give another impression, like PANA does not work with 802.11i at all. Thanks for clarifying it now! De-facto? Could you please elaborate how it is becoming a de-facto standard? EAP over UDP is one of the foundation technologies for Network Endpoint Assessment (NEA). As I understand it, EAPoUDP is being made available on most operating systems, and is in the process of being deployed by many enterprise customers. Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). Client-side software may be made available by them for various platforms (note PANA is already made available as an open source --both client and software side). If Cisco develops a proprietary protocol on its own for a subset of our work, should we now stop what we do at IETF? Is that where this whole fuss is coming from now? Besides. Of course PANA is more complex than EAPoUDP. The latter (an individual I-D) has very limited applicability. As I understand it, EAP over UDP is mostly being deployed for wired access scenarios where IEEE 802.1X might not work well (e.g. multiple hosts sharing a port). Which SDOs? Please give us more detail. As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has evaluated the PANA framework document. How does this explain your rejected by the SDOs claim? IEEE 802.11 provided a review feedback and they fixed few important problems and acknowledged the applicability of our other alternative solutions. How is that a rejection?!? As for 3GPP2, I can get into really gory details of what has been happening there, but it's not technical at all (if you are familiar with 3GPP2 and the relevant players in this discussion, you can guess). Alper ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Thu, May 25, 2006 at 04:45:39PM -0700, Bernard Aboba wrote: I do understand the potential need for EAP to be encapsulated over IP. However, in practice PANA is more complex than EAP over UDP (see draft-thomson-nacp-02.txt), which looks like it is on the road to becoming the defacto standard for EAP encapsulation over IP. I don't think draft-thomson-nacp-02.txt is something to become an IETF standard EAP over UDP protocol because of its lack of security. In fact the draft admits: If breach of confidentiality and deliberate attacks on the integrity of the NACP protocol itself are a significant risk in certain deployment environments, NACP should be protected by a protocol that offers confidentiality and/or packet authentication, integrity and protection against replay e.g. IPSEC [RFC2401]. Why IPsec is needed to carry EAP? What is authentication protocol for bootstrapping IPsec to protect NACP, perhaps EAP over IKEv2?? I have other security-related issues on NACP. My view is that secure enhancement of NACP will be equivalent to the EAP over UDP protocol the IETF is standardizing, PANA. Yoshihiro Ohba So from what I can tell, in each potential usage scenario PANA is either not feasible, is more complex than an established alternative, or has been rejected by the SDOs that have examined it. --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Yes, that individual I-D is productized as a proprietary protocol by one company (Cisco). As I understand it, EAP over UDP is one of the items proposed for standardization in the NEA WG. That leads me to wonder whether the IETF will be chartering multiple WGs to standardize EAP encapsulation over IP. Although my understanding of both PANA and NEA is no doubt incomplete/wrong/confusled, having multiple EAP encapsulation standards seems duplicative to me. As for 3GPP2, I can get into really gory details of what has been happening there, but it's not technical at all (if you are familiar with 3GPP2 and the relevant players in this discussion, you can guess). The issue is that integration of PANA with link layer technologies requires the support of the organizations that own those link layers. Without that link layer integration (for whatever reason) the scenarios can't be realized, at least in a mainstream way. It seems to me that one of the motivations for PANA is to *avoid* link layer dependencies in situations where link layer technology is inadequate/can't be deployed, and a forklift upgrade isn't in the budget. In those circumstances, integration with link layers or IPsec VPN technology is not under consideration -- because that would require a forklift upgrade. For example, the wireless hotspot case where something more sophisticated than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN deployment isn't a realistic alternative. Or the shared wired media case where network port authentication doesn't really work, and wholesale switch port replacements aren't affordable. In both of those cases, EAP over IP might provide a light weight, easily deployed solution. Yet, rather than focusing on the specific scenarios in which PANA might be compelling, the PANA framework document tries to cover a wide range of potential uses, trying to position PANA for use in scenarios where the case is less obvious. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
I have other security-related issues on NACP. My view is that secure enhancement of NACP will be equivalent to the EAP over UDP protocol the IETF is standardizing, PANA. Can you describe why the security of PANA is better than EAP over UDP (NACP)? I had thought that they were more or less equivalent, since neither approach mandates protection. But maybe I am missing something? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Thu, May 25, 2006 at 09:24:03PM -0700, Bernard Aboba wrote: I have other security-related issues on NACP. My view is that secure enhancement of NACP will be equivalent to the EAP over UDP protocol the IETF is standardizing, PANA. Can you describe why the security of PANA is better than EAP over UDP (NACP)? I had thought that they were more or less equivalent, since neither approach mandates protection. NACP does not have its own integrity protection mechanism while PANA has. It is true that PANA AUTH AVP is optional, but the use of protection is mandatory when an EAP method that is capable of deriving keys is used. This is described in the PANA specification draft. We can discuss security aspects more, but what I would really like to say in this thread is that discussing usefulness of PANA or any other EAP transport without deep security analysis does not appear to be the right thing. Yoshihiro Ohba ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The Emperor Has No Clothes: Is PANA actually useful?
Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Wed, 24 May 2006, Sam Hartman wrote: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. ... FWIW, I do not believe the current framework document as written is sufficiently clear in order to be able to evaluate where and under which conditions and assumptions the solution could be deployed. Therefore it is not feasible to evaluate the usefulness or applicability of the PANA protocol itself either. My review is here: http://www1.ietf.org/mail-archive/web/ietf/current/msg41231.html There has been some follow-up work to clarify and address these. Based on the discussion, I fear revision would take significant cycles, so the result remains to be seen. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
The IETF does publish protocols that may or may not be viable in the real world. I think PANA, after a significant clean up, might belong in that category. I, for instance, have the following high-level issues: ** No real use cases out there, and no real hope either. 3GPP2 HRPD recently joined the growing list of L2 technologies that ruled out PANA. ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. ** PANA's notions of EP placement seem vague the EPs' location can range from the first-hop router to other routers within the access network (I don't want to paste it all here, but it's Section 7.1 in the framework document). Its crucial for a protocol that sets out to authenticate clients to enforce access control, to get the EP placement right. ** PANA has a notion of binding PANA authentication to an existing secure channel. It is not clear whether it makes sense and the framework document does not have any convincing text. That notion introduces more problems than solving any, I think. Here are some excerpts: Networks where a secure channel is already available prior to running PANA. The presence of a secure channel before PANA exchange eliminates the need for executing a secure association protocol after PANA. I guess the notion is that the existing secure channel is authenticated but for a different reason and PANA authenticates the client again for network access and binds the result using filters to that secure channel. Pretty ad hoc operation, I must say and I think breaks the EAP model. I can provide a more detailed review, but that's not the purpose of this thread. My conclusion is -- stealing Bernard's words -- EAP/IKEv2 will do for what PANA is supposed to support. PANA is not needed really. But if after clarifications, the WG insists that the docs be published, I guess the IESG might publish them as experimental or even move them to historic (not sure how the latter would work). regards, Lakshminath At 11:27 AM 5/24/2006, Pekka Savola wrote: On Wed, 24 May 2006, Sam Hartman wrote: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. ... FWIW, I do not believe the current framework document as written is sufficiently clear in order to be able to evaluate where and under which conditions and assumptions the solution could be deployed. Therefore it is not feasible to evaluate the usefulness or applicability of the PANA protocol itself either. My review is here: http://www1.ietf.org/mail-archive/web/ietf/current/msg41231.html There has been some follow-up work to clarify and address these. Based on the discussion, I fear revision would take significant cycles, so the result remains to be seen. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Disclaimer - I do work in the INT area, but have not been involved in the PANA WG. When this work was chartered, I failed to understand its need and the deployment use cases. Subsequently, about 3 years ago, I recommended against the use of PANA for the needs of my ex-employer. More recently, I have been advocating against the use of PANA in 3gpp2. With that background, some high level confusions that I have about the use of PANA: 1. Reading the framework document, it is simply not clear to me as to why PANA would be useful for any type of network. Actually, even after reading some other PANA documents, this is not clear to me. It seems to have become this complex suite of protocols that aren't specifically buying anything. Why would I want to go through IP address acquisition, for one, if I had a link layer that carried EAP, particularly for link layer security? 2. Link layer agnostic approach has often been cited as a reason to use PANA. I must say that I don't understand how it is link layer agnostic, when it depends on 802.11i 4-way handshake or the like for the secure association protocol. In fact, I am not sure how this even works with the currently defined secure association protocols in lower layers. None of the documents have provided any clarity to me on this. The use of IPsec/IKE for this is even more confusing to me - in this case, why would PANA be used instead of EAP-in-IKEv2? 3. Statements like ...whereas it allows only limited type of traffic (e.g., PANA, DHCP, router discovery, etc.) for the authorized PaCs do not exactly provide a clear picture of port control - yet another reason IMO to leave the EAP lower layer where it belongs (at the link layer). There are many other such confusions in my mind arising from the PANA documents that I won't get into here. 4. The choices that are left to deployment while using PANA constitute a long list for one protocol! Security before/after the PANA run, global vs local PRPA, DHCP vs 3927 vs 2131 for IPv4 PRPA, dual-stack handling behavior, secure association protocol choice and what it takes to make it work with PANA, need for POPA and unconfiguring PRPA, PAA/EP location and choice of protocol between those entities, IKEv1 vs IKEv2 etc. - I am sure I've missed more choices here; but, complex enough, to say the least! Given all of this, publishing these documents in the current stage as proposed standard RFCs concerns me. Vidya -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 8:12 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: The Emperor Has No Clothes: Is PANA actually useful? Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture
Re: The Emperor Has No Clothes: Is PANA actually useful?
On Wed, 24 May 2006, Sam Hartman wrote: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. Sam - I don't know if PANA will be useful, but I do know why some folks are interested... Have you taken a look at the I2 NetAuth work: http://security.internet2.edu/netauth/ These academic networks are interested in both PANA and NEA as part of their ubiquitous sign-on to RE networks agenda. I'm equally confused, but from another direction. - lel My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On 24 May 2006, at 20:52, Lucy E. Lynch wrote: I don't know if PANA will be useful, but I do know why some folks are interested... Have you taken a look at the I2 NetAuth work: http://security.internet2.edu/netauth/ These academic networks are interested in both PANA and NEA as part of their ubiquitous sign-on to RE networks agenda. While I can't comment on NetAuth, I've been engaged in the Europe's equivalent project for HEFE, Eduroam, for the last couple of years and to my knowledge we've never discussed PANA (even though at least a few of us have been aware of its gestation). FWIW I've personally never understood what niche(s) PANA was expecting to fill, but I assumed it was me being dim. josh. Josh Howlett, Networking Specialist, University of Bristol. email: [EMAIL PROTECTED] | phone: +44 (0)7867 907076 | interal: 7850 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?
On 5/24/06, Lakshminath Dondeti [EMAIL PROTECTED] wrote: ** EAP over IKEv2 seems like a more viable alternative: apparently being proposed in 3G-WLAN interworking scenario as the access auth protocol. the 3G-WLAN interworking scenario is similar to an enterprise user gaining access to the enterprise via an IPsec gateway. a user who is subscribed to a mobile operator's services uses IKEv2 with a VPN-like gateway to access the operator's services. the mode is different. therefore I don't think this is an alternative to PANA and shouldn't be confused with PANA. we could discuss this more, but on a separate thread. Vijay ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
