RE: alternatives for carrying eap lower layer information

["Blair T. Bullock" <bbullock@ipass.com>]

Sorry if this comment is not very salient to this thread....

I like that level of clarification of virtual transport since it seems
to be a trend to make everything a VIRTUAL N-P-T simply because it is
not of a single distinct interface type and may also encompass
non-physical transport which is not explicitly defined.

Such as an Access Gateway that feeds both ENET and 802.11 Access Points,
but uses L2TP for transport.... What N-P-T is it?!  Aw, heck let's just
call it Virtual.   =^(   

What I don't get is why include Auth Methods such as PANA and PEAP? The
Nas-Port-Type should describe the consumed (inbound) service as stated
in this thread.  Today it is commonly used to differentiate and bill
consumed services at different rates based on Media used by the STA, but
unfortunately we have cases where dial, Wi-Fi and Ethernet NAS set all
N-P-T to Virtual; regardless.   PEAP can be used over Ethernet and
Wi-Fi, so to claim a N-P-T of PEAP is just as ambiguous as to the
consumed service is it not?  Could these virtual transport and multi-use
protocol extensions allow this to break-down into an ambiguous mess?

Thanks for your time, 

Blair

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Jari Arkko
Sent: Monday, November 08, 2004 5:06 AM
To: Bernard Aboba
Cc: 'radiusext@ops.ietf.org'; David Mariblanca (EE/EEM)
Subject: Re: alternatives for carrying eap lower layer information

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



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