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

[Jari Arkko <[e-mail]>]

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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>