At 12:15 AM 5/27/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:
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.
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. And that actually
alludes to the point of feature creep. 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.
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.
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.
You really have two options:
1. You can continue these threads and respond line by line and pretty
soon we'll all give up. 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, 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