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