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
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
Total of 120 messages in the last 7 days.
script run at: Fri May 26 00:03:01 EDT 2006
Messages | Bytes| Who
+--++--+
11.67% | 14 | 11.45% |87948 | [EMAIL PROTECTED]
6.67% |8 | 5.90% |45306 | [EMAIL
Jeff,
Disclaimer - I wasn't even aware of this document before reading this
thread. However, I have now read it, so feel prepared to comment.
As it only just came out, you haven't missed much of a debate.
(1) The IANA is a group of adults, but it is no longer a group of
protocol subject
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
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
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
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
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
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,
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
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:
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
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]
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
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
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?
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:
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,
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
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
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
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
On 5/25/06 at 4:30 PM -0400, Sam Hartman wrote:
Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.
Sam, I'm sorry, but this is completely unadulterated NONSENSE. Who is
this we to whom you are referring that is paying for
Bernard Aboba wrote:
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
Pete == Pete Resnick [EMAIL PROTECTED] writes:
Pete On 5/25/06 at 4:30 PM -0400, Sam Hartman wrote:
Ultimately, the rfc-editor function needs to be accountable to
the IETF community because we're the ones paying for it.
Pete Sam, I'm sorry, but this is completely unadulterated
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
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
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
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
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.
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, I fully agree. As far as I can tell, using EAP in this
Narayanan, manner merely reduces it to a posture transport
Narayanan, protocol. The level of security provided by EAPoUDP
Narayanan, does not seem to be any
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.
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
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
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, I fully agree. As far as I can tell, using EAP in this
Narayanan, manner merely reduces it to a posture transport
Narayanan, protocol. The level of security provided by EAPoUDP
Narayanan, does not seem to
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
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
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
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
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
On 5/26/06, Geoff Huston [EMAIL PROTECTED] wrote:
Delving down a bit here, I suspect that, as always, the longstanding issue
here is the actual level of 'independence of the RFC Editor, and the
potential for a player to perform an end run around the IETF Internet
Standards Process
The problem
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 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
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,
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
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
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
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
On Friday, May 26, 2006 05:23:24 PM -0400 Sam Hartman
[EMAIL PROTECTED] wrote:
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, I fully agree. As far as I can tell, using EAP in this
Narayanan, manner merely reduces it to a posture transport
Narayanan,
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
Jeff,
Please see some questions/comments inline below.
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, I fully agree. As far as I can tell, using
EAP in this
Narayanan, manner merely reduces it to a posture transport
Narayanan, protocol. The level of
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
The IESG has received a request from the RADIUS EXTensions WG to consider the
following document:
- 'RADIUS Attributes for Virtual LAN and Priority Support '
draft-ietf-radext-vlan-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the RADIUS EXTensions WG to consider the
following document:
- 'RADIUS Delegated-IPv6-Prefix Attribute '
draft-ietf-radext-delegated-prefix-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
The IESG has received a request from an individual submitter to consider the
following document:
- 'Considerations on the IPv6 Host density Metric '
draft-huston-hd-metric-02.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has approved the following document:
- 'Location Types Registry '
draft-ietf-geopriv-location-types-registry-06.txt as a Proposed Standard
This document is the product of the Geographic Location/Privacy Working Group.
The IESG contact persons are Ted Hardie and Jon Peterson.
A URL
The IESG has received a request from the Audio/Video Transport WG to consider
the following document:
- 'RTP Payload Format for H.263 using RFC2190 to Historic status '
draft-ietf-avt-rfc2190-to-historic-06.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from the IP Telephony WG to consider the
following document:
- 'The ENUM Dip Indicator parameter for the tel URI '
draft-ietf-iptel-tel-enumdi-04.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
A new Request for Comments is now available in online RFC libraries.
RFC 4467
Title: Internet Message Access Protocol (IMAP)
- URLAUTH Extension
Author: M. Crispin
Status: Standards Track
Date: May 2006
A new Request for Comments is now available in online RFC libraries.
RFC 4508
Title: Conveying Feature Tags with the
Session Initiation Protocol (SIP) REFER Method
Author: O. Levin, A. Johnston
Status: Standards Track
61 matches
Mail list logo
