Subject: RE: [eap] network selection

From: "Lortz, Victor" <[email-masked]>
Date: Mon, 19 Jan 2004 14:42:57 -0800

Generally a user doesn't care how IP datagrams are routed because there
is no cost premium paid by the user for one path vs. another.  A
different analogy that might be helpful is as follows:  suppose we
consider the phone network.  It is possible to establish a default long
distance provider for a given phone line.  However, even if such a
default exists, it remains possible to dial a number such as 10 10 123
or an 800 number for alternative long distance service.  This imposes
more inconvenience on the user, but the savings may be significant.  

Best Regards,
Vic

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, January 19, 2004 12:17 PM
To: Lortz, Victor; [email-masked]
Subject: Re: [eap] network selection

Hello Victor,

> Alper, you are assuming that there is a direct roaming agreement
between
> the user's home ISP and the NAP (using PANA terminology).  3GPP is
also
> interested in scenarios in which there is no direct relationship.
> Instead, there is an intermediary "broker" network such as an
aggregator
> (or in 3GPP parlance, a VPLMN) that has roaming agreements with the
> other two.  In this context, especially if there is more than one
> candidate intermediary, the user may wish to discover and subsequently
> designate a preferred intermediary.

Actually I'm not denying the possibility of a multi-hop AAA routing
between
the NAP and ISP. All I'm saying is this topology and its associated
management is better handled by the servers running the AAA protocols
(RADIUS, Diameter). Not by the user's host. Doing otherwise would
complicate
the host, and I'm not sure if this is necessary.

The problem is similar to datagram routing. The host only knows its
default
gateway and the final destination for its data traffic. The intermediate
routing is handled by the routers.

Alper

> 
> Best Regards,
> Vic
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alper Yegin
> Sent: Friday, January 16, 2004 6:35 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [eap] network selection
> 
> Hello Jari,
> 
> Thank you for capturing this discussion.
> 
> I have some comments, please see below...
> 
>     First, there is the problem of "Access Network discovery".  This
>     is the problem of discovering access networks available in the
>     vicinity, and the points of presence (POPs) associated with those
>     networks. 
> 
> In PANA we borrowed two terms from the DSL networks, NAP (Network
Access
> Provider) and ISP. NAP is the owner/operator of the access
> infrastructure
> (such as the WLAN AP in the coffee shop). It provides L2 access to the
> clients and connect them to their ISP. ISP should have a business
> agreement
> with the NAP for this "roaming" service.
> 
> I think our "ISP" corresponds to your "Access network"? And what is
the
> "home network" then?
> 
> If we are talking about general "access network discovery", I think it
> would
> involve discovering both NAPs and their associated (serviced) ISPs in
my
> client's vicinity. I think we are more interested in the latter part
of
> the
> problem.
> 
> Referring to Figure 2:
> 
>  In this
>  figure, the user "[email-masked]" has to be authenticated through ISP
>  2, since the domain "corp3.com" is served by it.
> 
> I think another way to read this is "All the employees of corp3.com
has
> an
> account with ISP2 under their name. When they connect to ISP2, their
> traffic
> is VPN'ed to the corporate network". Right?
> 
> 
>  There has been requests to place credential and AAA route selection
>  under user control, as the user is affected by the pricing and other
>  differences.
> 
> I don't think this is necessary. I should only care about my ISP
> selection,
> and be able to trust my ISP to figure out the best AAA route for me
(in
> figure 3, isp1.com is aware of both paths). If the access network is
> trying
> to rip me off, my ISP should be able to catch that. And if my ISP is
> ripping
> me off, oh well.....
> 
> Regarding the attack on 2.4.1: I think this is a combined issue of
> network
> identity theft in the absence of unprotected or unverified discovery,
> and
> bandwidth reselling. These can be issues on their own even when
> separated. I
> don't think the combination has an effect here.
> 
>  Basically, if the "rogue" access point has a flat fee
>  account and a contract with a clearing house, it can offer access to
>  anyone with a per-byte account, NAT their packets, and send the
>  traffic forward on its own account, and generate income.
> 
> And this is just one way to provide a legitimate service, given that
the
> upstream service provider legally allows you to resell the bandwidth.
If
> you
> are using someone else's network name to lure clients in, this is a
> separate
> issue. 
> 
>  However, IPsec could be used to detect the
>  presence of such NATs, even if NAT traversal is in use.
> 
> There wouldn't be any needs for NAT when a /64 IPv6 prefixes are
> delegated
> to mobile clients. So, relying on NAT detection is not sufficient.
> 
>     Similarly, the IEEE 802.1af has discussed the
>     idea of supporting network discovery within a future revision to
>     IEEE 802.1X.
> 
> Supporting this functionality in the EAP lower layer seems logical to
> me.
> This is what we did with the PANA design.
> 
>     In the IETF, a potential alternative is use of the SEAMOBY CARD
>     protocol [13], which enables advertisement of network device
>     capabilities over IP.  Another alternative is the recently
>     proposed Device Discovery Protocol (DDP) [12], which provides
>     functionality equivalent to IEEE 802.1ab using ASN.1 encoded
>     advertisements sent to a link-local scope multicast address.
> 
> Using CARD lets you collect information about the networks in your
> client's
> vicinity. These are the potential points of attachments upon movement.
I
> think the use of DDP can be similar (if, access points are in the same
> subnet). Neither is about discovering and selecting an immediate
access
> network. I think it is worth mentioning PANA in here, where this
> selection
> takes place during the network access AAA (before client engages in
> authentication). 
> 
>  The representation of link layer parameters within EAP
>  should utilize a common framework, to make it easier to define new
>  link layers and keep the selection of EAP methods independent of the
>  link layer.
> 
>  ...
> 
>  The security requirements for network discovery depend on the type of
>  information being discovered.  Some of the parameters may have a
>  security impact, such as the claimed name of the network the user
>  tries to attach to.  Unfortunately, current EAP methods do not always
>  make the verification of such parameters possible.
> 
> I think hosting these functionalities in the EAP lower layer is a
better
> approach.
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
> 

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Jan 2004 11:01:02 +0200

> more inconvenience on the user, but the savings may be significant.

Requirements for user control have been expressed. Requirements
for automatic operation have also been expressed. And there
are clear tradeoffs in the user control case, ease of use vs.
freedom of selection. I don't think we can make the user control
requirement go away, but it may be helpful to think about the
analogy from the long distance dialing above. Are we *requiring*
the user to do something, or just *allowing* it? This is also
related to the use of the mediating network selection, do we
have it because of *missing* or just *ambiquous* routes?
Finally, there is the question of whether the user or his
device are doing this.

I think we can agree that the user should not be required
to do anything. This would imply either

   (a) There has to be a working default route, or
   (b) The user's device needs to take care of the
       selection

Given that existing user devices might not be able to do (b),
my preference is (a). Of course, its hard for any standards
to dictate that the service providers must keep the AAA routing
tables perfectly completely all the time, so it may be necessary
to allow (b) as well, as long as we understand its not going to
work for everyone.

--Jari