[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>