Subject: [eap] network selection

From: Jari Arkko <[email-masked]>
Date: Sat, 10 Jan 2004 14:19:59 +0200

Hi,

Bernard and I have put together a draft that defines the network selection
problem and summarizes the discussion we had in December. Before it appears
in the I-D directories, you can access it from my page at:

   http://www.arkko.com/publications/eap/draft-ietf-eap-netsel-problem-00.txt
   http://www.arkko.com/publications/eap/draft-ietf-eap-netsel-problem-00.html

One of the key conclusions is that the network selection problem involves
many parts, and going forward it is important that we decide which parts
need to be addressed. It is also important to ensure that IETF-IEEE-3GPP do
not create multiple competing solutions in this space.

Comments very much appreciated.

--Jari

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Jan 2004 18:34:43 -0800

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Jan 2004 10:07:50 +0200

Hi Alper,

> with the NAP for this "roaming" service.

Those are good terms.

> I think our "ISP" corresponds to your "Access network"? And what is the

Our "access network" is the physical access points and associated NAP, I
think. A practical example would be a specific AP broadcasting on a specific
channel and a specific SSID such as "Starbucks". Our "home network" is where
the client would have its subscription, i.e. the domain part of the user's NAI.
Does this make it clearer?

I'm not exactly sure what the mapping is to PANA ISP, however. PANA ISP appears
to be a lower layer concept which may or may not have something to do with the
the user's home domain. For instance, you might have two available ISPs in PANA
but the same NAI might apply to both.

> client's vicinity. I think we are more interested in the latter part of the

This leads me to think that your definition of ISP is closer to what we
have called a "mediating network". I.e. it might not be the "end" domain
in the AAA chain?

> account with ISP2 under their name. When they connect to ISP2, their traffic

This is right.

> is VPN'ed to the corporate network". Right?

There may or may not be a VPN service associated with this. If you
don't think about companies but ISPs with a roaming service instead,
you can probably see the non-VPN case: users would just get access
through the local ISP, but their packets would be routed directly to
the Internet.

> to rip me off, my ISP should be able to catch that. And if my ISP is ripping

I think I personally agree. But is your ISP the final home domain or
possibly a roaming partner of the user's home domain?

> don't think the combination has an effect here.

Ok.

> are using someone else's network name to lure clients in, this is a separate

I agree.

> to mobile clients. So, relying on NAT detection is not sufficient.

Right. Good point, thanks.

> This is what we did with the PANA design.

Great!

> takes place during the network access AAA (before client engages in

Ok.

> I think hosting these functionalities in the EAP lower layer is a better

I agree that security for discovery should be done at the layer discovery
itself is done, i.e., typically at the link layer.

However, there is an additional issue which the above paragraphs are
trying to address. The problem is that even if the lower layers are
secure by themselves, the information passed in them might be false,
if the access points are lying. Thus, it might be useful to be able
to cryptographically verify that information passed in the lower layer
corresponds to the information passed in the AAA chain. The way to
do this is to exchange at least some important parameters over EAP
as well, and then ensure that the three pieces of information match.

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Sat, 31 Jan 2004 11:59:04 -0800

Hi Jari,

> Does this make it clearer?

Can we look at this from routing perspective, and say access networks
provide L1-L2 service, home network provides L3 service? I get my IP address
from my home network's domain (like the ISP when I connect via a DSL line).

> but the same NAI might apply to both.

In DSL networks:
                                           +----- ISP1.com (AAA_server)
                                           |
PaC ------ NAS (PAA/router/AAA_client) ----+
                                           |
                                           +----- ISP2.com (AAA-server)

NAS is owned by a NAP.

My client (PaC) can have account with both ISP1.com and ISP2.com. It
connects to ISP1.com when I login with [email-masked].

> have called a "mediating network". I.e. it might not be the "end" domain

No, it is. Because this is where I have an account to connect to the
Internet.

> through the local ISP, but their packets would be routed directly to

But where do I get the IP address from? If it is from my "home ISP" but the
packets are forwarded to the Internet directly via "local ISP", then ingress
filtering is an issue. This is why I VPN'ed the packets.

> possibly a roaming partner of the user's home domain?

ISP is the final home (from "connecting to the Internet perspective). This
is where I get the L3 service from, my IP address and all.

(There is another home, like my corporate network, docomolabs-usa.com. If I
want to get there while I'm roaming, I use VPN. The ISP that I'm using to
connect to the Internet is not the same as the ISP my corporate network is
using.)

I agree. 

Alper