RE: [Pana] and network selection

[Alper Yegin <[e-mail]>]

Hi Avi,

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

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









> 
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[e-mail]]
> > Sent: Tuesday, November 09, 2004 11:06 AM
> > To: [e-mail]
> > Cc: 'Avi Lior'; 'Yoshihiro Ohba'; [e-mail]
> > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pana