RE: alternatives for carrying eap lower layer information

["David Mariblanca (ML/EEM)" <david.mariblanca@ericsson.com>]

Hi Bernard,
you are proposing here to use Tunnel-Type and Tunnel-Medium-Type. The problem I see is that the values we wanted to allocate for EAP-lower-layer are:
          PPP                      1
          802.1X                   2
          IKEv2                    3
          PANA                     4

But in the attributes Tunnel-Type, Tunnel-Medium-Type and NAS-port-type you cannot find all these. And if you want some of them you have to use sometimes one attribute and sometimes other. For example, Tunnel-Type is for tunneled protocols and hence it does not include 802.1X.
On the other hand, Tunnel-Type and Tunnel-Medium-Type are for tunneling protocols. We want to use it for a IKEv2 exchange, which is not a tunneling protocol itself. Is this valid ?

BR,
David.

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: viernes, 24 de septiembre de 2004 0:57
To: 'radiusext@ops.ietf.org'; jari.arkko@piuha.net
Cc: David Mariblanca (ML/EEM)
Subject: Re: alternatives for carrying eap lower layer information


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.  

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. 

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