Subject: RE: [Pana] and network selection

From: Avi Lior <[email-masked]>
Date: Tue, 9 Nov 2004 11:40:19 -0500

Hi Alper,

I personally agree that PANA should do network selection and that the EAP
based network selection is only a stop gap.  That is why I really started
this discussion.

But if PANA is the way we ought to do network selection I think it is
missing somethings.

-Its not enough to select the next hop;

  PaC---PAA/NAS---VAAA----B1AAA-----B2AAA----HAAA
                            |                  |
                            +-------B3AAA------+

As the diagram shows, the user my prefer to go through B3AAA and not B2AAA.

-It should present possible options by knowing the PaC.  Perhaps the PaC
should send the identity in the Start-Request.  Then the PAA can respond
with the appropriate ISP Information.

In other words, why not duplicate the EAP network selection capability?

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Tuesday, November 09, 2004 11:06 AM
> To: [email-masked]
> Cc: 'Avi Lior'; 'Yoshihiro Ohba'; [email-masked]
> Subject: RE: [Pana] and network selection
> 
> 
> Jari,
> 
> > Yes. Two things remain, however:
> > 
> > (1) Does someone have an answer as to how all this can be
> >      accomplished in the current AAA protocols while
> >      still allowing the local access provider to have
> >      a proxy AND roaming? I'm not quite sure how the
> >      destination realm value is set in the case of
> >      Diameter EAP, for instance.
> 
> I think Yoshi has responded to that issue.
> 
> > 
> > (2) We need to consider this in light of Avi's question,
> >      which was what additional value the PANA ISP selection
> >      provides over things that already exist in EAP. I
> >      personally do not believe you absolutely need to
> >      have additional value, but of course it would be
> >      useful if you could demonstrate, for instance, that
> >      your "L2" network selection scheme is better than
> >      what exists in 802.1X.
> 
> I think ND&S belongs to layers below EAP (EAP lower-layer, or 
> even below that). Doing that in EAP can only be workaround in 
> case lower-layers don't already handle that. Maybe not all 
> EAP lower-layers can handle that, but since we are designing 
> PANA from scratch, we could. So, imho we are doing the "right 
> thing" ;-)
> 
> So, imo, the right question is not why we need this 
> functionality in PANA when we can do it with EAP, but the 
> other way around. I hope someone can answer that too.
> 
> Meanwhile, let me discuss what happens when you do ND&S in 
> EAP. I presume you are referring to 
> "draft-adrangi-eap-network-discovery-05".
> My comments are based on that.
> 
> EAP is for "authentication". I think the authentication 
> end-points should be chosen before the authentication is 
> engaged. If not, then we end up having to require changes to 
> EAP behavior, as the I-D suggests. On the peer, 
> authenticator, and the authentication server. 
> 
> The ISP ND&S issue can be solved within client-NAS. There 
> shouldn't be a need to involve the AS, but the I-D suggests 
> that. And I didn't understand which AS fails the client ID 
> when the NAI is not supported...
> 
> Performance is another issue. ND&S is best done before EAP is 
> engaged. The proposed scheme in the worst case involves an 
> extra round trip to a AS to do ND&S. 
> 
> The scheme suggests adding information after the NUL in id 
> request. "workaround" is the nicest word that comes to my 
> mind to characterize such a solution. And, of course it may 
> conflicts with other people's "workarounds" ;-)
> 
> And the MTU limitation...
> 
> Overall, I can see this scheme being needed when the 
> lower-layers don't help at all. When using PANA, ISP 
> selection can be handled by PANA-specific mechanism.
> 
> 
> Going back to 802.1X... Is there a ND&S facility in 1X? Or, 
> are you referring to the EAP-scheme I discussed above? 
> 
> > 
> >      Speaking of multicast packets, how does a PANA client
> >      know that it needs to initiate a PANA exchange?
> 
> It either knows the PAA in advance, or dynamically discovers 
> (solicited and unsolicited PANA-Start) it.
> 
> >      What
> >      if you added a new PANA multicast message that told
> >      the client about this and carries the ISP/ASP info
> >      within it?
> 
> Hmm... We don't have that. But the cost of ISP/ASP discovery 
> is one mcast sent by the PaC in the worst case. So, I'm not 
> sure if the benefit overweighs the cost of adding one more 
> message/mechanism to the spec... Comments?
> 
> Alper
> 
> 
> 
> 
> > 
> > --Jari
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 9 Nov 2004 10:23:20 -0800 (PST)

> In other words, why not duplicate the EAP network
It may be nice to have that feature. But is that
sufficient ? Someone may want more than what EAP
network selection capability can provide. My
understanding is that EAP network selection only
allows to select the first hop that the visited
network has business agreement with. what if there are
multiple hops between the visited network and the home
network ? Does it make sense to select the whole path
instead of just the first hop ? I understand it is
more complex. I don't even know whether it makes sense
or not. 

But, my point is that we should get more experience
with how EAP network selection will be used in
practice and then we can perhaps optimize PANA to
include it if it really proves useful.

2 cents
mohan

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Nov 2004 16:52:41 -0800

Hi Avi,

> In other words, why not duplicate the EAP network selection
capability?

I think in fact there are two separable problems:

1- First hop ISP selection.
2- Intermediary AAA selection (they are between 1st hop ISP and home
ISP).

PANA has 1, but not 2.

I see 2 as "dynamic AAA routing using loose source routing". 

1 is a clear problem. But as Mohan was saying, 2 may not be ready for
prime time. I personally have questions/concerns on that. For example,
the EAP-based solution assumes there is only one intermediary. It could
be more in fact. Also, and more importantly, I'd think this AAA routing
is better handled by the infrastructure. I don't fully understand the
need to burden end host with that. Even if we handle it within PANA, we
should be able to translate it into RADIUS. Does RADIUS have a mechanism
to encode such routing? 

Alper