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(_at_)qualcomm(_dot_)com]
Sent: Friday, May 26, 2006 3:58 PM
To: Alper Yegin
Cc: ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf