RE: questions on draft-mariblanca-aaa-eap-lla-00.txt

Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com> Mon, 12 July 2004 20:08 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 12 Jul 2004 20:08:26 +0000
Message-ID: <EBF631554F9CD7118D0B00065BF34DCB09EA1232@il27exm03.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'jari.arkko@piuha.net'" <jari.arkko@piuha.net>, Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" <david.mariblanca@ericsson.com>
Subject: RE: questions on draft-mariblanca-aaa-eap-lla-00.txt
Date: Mon, 12 Jul 2004 15:08:15 -0500
MIME-Version: 1.0
Content-Type: text/plain

Hi Jari,

Thank you for your quick response. I guessed that the EAP-IKEv2 had some drafts behind it. Thank you for the links, I will look at those drafts.

As far as the attribute format on the EAP-message attribute, I understand the legacy deployment issues. I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work.

BR,

Madjid
 
-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Monday, July 12, 2004 2:01 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: radiusext@ops.ietf.org; David Mariblanca (EE/EEM)
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt


Nakhjiri Madjid-MNAKHJI1 wrote:

> I can understand that one may want to signal the info on the
> kind of L2 that is carrying the EAP messages over the link
> from end device to Access node, so PPP and 802.1x make sense.

Yes.

> But what is the purpose of IKEv2 and PANA? Are we saying we
> expanded the L2 concept to L3 and EAP is carried over IKEv2
> for protection over the single hop?

The EAP concept has already been expanded from L2 to L3 with the
introduction of things like IKEv2 or PANA. But this is really
not related to David's draft -- the expansion comes from
documents such as draft-ietf-ipsec-ikev2-nn.txt or draft-ietf-
pana-pana-mm.txt.

By the way, such usage of EAP in IKEv2 is not necessarily
limited to a single hop.

> If yes, then why nothing on IKEv1? Would you care to explain?

Because there is no current specification which would extend
IKEv1 so that it could use EAP authentication. (PIC did something
like that but my understanding is that PIC work is no longer
alive; please feel free to correct me if I have been mistaken.)

> I also have a general question: RFC 3579 defines an EAP-message
> attribute for RADIUS with an IANA type of 79. So far I have not
> understood how grouping of attributes works for RADIUS, but it
> feels like the EAP-message attribute and L2 info attribute 
> should be grouped together somehow, especially if the attribute
> space is tight. Anybody cares to explain?

The problem is that EAP-Message has already been implemented
and deployed, so its hard to add anything into that attribute
without breaking everyone's devices.

--Jari

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>