Re: alternatives for carrying eap lower layer information

[Jari Arkko <jari.arkko@piuha.net>]

Bernard Aboba wrote:
> There are multiple problems being discussed here: 
>
> a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2, etc.) from non-tunneled EAP methods. 
>
> b. Ability to differentiate EAP lower layers from one another (EAP-IKEv2).
>
> In terms of problem a), the EAP peer and server know what EAP method is being negotiated (and whether it is tunneled), but the NAS is presumed to be a pass-through.  Therefore, I am not clear how the NAS would obtain information on the EAP method to put into an attribute, unless it gets this from the RADIUS server.  

Yes, it seems you are right. The endpoints of the two methods should
always be the same, so there is no need to tell the distinction to
anyone.

> In terms of problem b), it seems that the problem arises in part from the allocation of a single NAS-Port-Type (Virtual) to all tunnels.  In contrast, in RFC 2868 the combination of Tunnel-Type and Tunnel-Medium-Type attributes enables description of virtually any tunnel type over any medium.  I'd suggest that this approach is more sound than trying to allocate a NAS-Port-Type value for every conceivable combination. 

I think you are right on this one also. But are you suggesting that
these attributes be used, or just that the same idea of separating
this into two steps makes sense?

I think you must mean the latter, because it seems that
RFC 2868 is targeted towards mandatory tunneling, i.e.,
something that happens after the traffic leaves the NAS.
What we are talking about here is a service provided
as a tunnel, something that happens before the traffic
enters the NAS. This might lead to a confusion if the
same attributes were used, or am I missing something?
Presumably you could have both a virtual service coming
in and a mandatory tunnel going out...

If I am right we should do the following:

1. Use the NAS-Port-Type as the primary differentiator
   between different kinds of incoming connections to NAS.
   If its 802.11, use value 19. If its IKEv2 or any
   other sort of non-physical interface, use 5 (Virtual).
   Allocate a new value for PANA.

2. Then, if 5 (Virtual) was used above, define a new attribute
   that indicates the type of the virtual device.

   NAS-Virtual-Port-Type
     1 (IKEv2)
     2 ...

3. Optionally, define another attribute that also defines the
   type of protocol that this virtual service run on top of
   (e.g., IPv4 or IPv6).

This would work for me, I think.

The crucial question is whether the RFC 2868 attributes can
be used for this purpose or if new ones are needed because
the mandatory tunneling vs. incoming usage collides. Opinions?

--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/>