Subject: RE: [eap] network selection

From: "Lortz, Victor" <[email-masked]>
Date: Sun, 18 Jan 2004 18:28:59 -0800

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.  

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 Jan 2004 12:16:37 -0800

Hello Victor,

> 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