> > > 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. > > Small clarification, as my statement above is incorrect (apologies > for the error). I meant to write: never quite understood the need > for including the discussion on NAP and ISP authentication in the > main protocol specification. I also don't understand the binding > aspects of the NAP and ISP authentication, but that's an issue I > already raised on the PANA mailing list. > > My point is that including the dual authentication specification in > the base spec is one that adds to the complexity. That is a good and constructive point. We'll re-consider that part of the design. Thank you. > And that actually > alludes to the point of feature creep. In the absence of any other technical feedback you are providing on the complexity matter, I don't see how you jump to such a conclusion... > You understand that several > folks have trouble seeing the motivation for PANA, and are also > looking for certain details that are not there; it's easy to see that > they find some of the features that are already in the spec to be of > no significance, at least to them. I don't know what exactly you are referring to. But at least sticking to the thread subject, at least provide us what are those features that you think have no significance? > >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. > > You probably already know that without GEE, we can still do dual > authentications! GEE allows multiple EAP authentications to happen > in parallel. I don't know how dual authentications work without GEE. If you care to explain, feel free to start a separate thread. > >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. > > Alper, I have typed up my review of the PANA-IPsec spec in detail and > haven't done the same with the others. But there are other reviews > on the protocol document and the framework document. I am not sure I > am going to find time to write up the issues I have on PANA-PANA and > PANA-Framework for the next 10 days. But, you must realize though > that the points have already been made, if you are willing to take > the time to go through the reviews, list them in an email and try and > make an attempt to address them instead of challenging them. Lakshminath, are you aware that we have responded to all such reviews? In fact, have you read them? Have you read them and found any issues? They were sent on the PANA WG and IESG lists. In the absence of a "yes" answer to all of these questions, I cannot make much sense out of your above statement. > You really have two options: > > 1. You can continue these threads and respond line by line and pretty > soon we'll all give up. As I had stated at the very beginning of the thread, since you made a comment about the complexity (to the extent that you recommend this protocol is not useful), I thought you'd help us identify the exact issues and fix them. You are not doing that, despite so much e-mailing. > I was going to stop with my previous > message, but I will with this one. (May clarify if people find > errors in my logic, but that's about it). The IESG goes on to make > the decision. > > 2. You can really make the effort to look at the reviews and comments > as the "outsiders' perspective" and try and see what's worth pruning > and what's worth clarifying further, It would help us a lot if you look at the review threads and tell us if we are missing anything. Alper > and then perhaps one or more > link layer SDOs would find the revised PANA to be attractive enough > to adopt. Please believe me when I say that honest attempts were > made to adopt PANA (I must say that with some architectural > simplifications in mind). > > best wishes, > Lakshminath > > > > > 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:ldondeti@xxxxxxxxxxxx] > > > > > Sent: Friday, May 26, 2006 3:58 PM > > > > > To: Alper Yegin > > > > > Cc: ietf@xxxxxxxx > > > > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf