Subject: RE: [Pana] and network selection

From: Alper Yegin <[email-masked]>
Date: Tue, 09 Nov 2004 08:06:17 -0800

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: Jari Arkko <[email-masked]>
Date: Tue, 09 Nov 2004 22:03:18 +0200

> I think Yoshi has responded to that issue.

Yes, and we seem to converge. Not sure if the no-proxy-at-the-
access-network limitation still needs some new text, but
otherwise this part is OK.

> we are doing the "right thing" ;-)

I agree. The more we have at the "lower" layer, the better.

> someone can answer that too.

Well, the EAP part of it is not just about discovery -- it is also
about identity selection, and providing the identity of the network
side.

> understand which AS fails the client ID when the NAI is not supported...

There's some complexity involved in this, depending on
which nodes do what, and how "full" the AAA routing
table is.

> such a solution. And, of course it may conflicts with other people's

Its a hack, no doubt about that :-) But probably necessary
in terms of being able to deploy this on a zillion access
points that do not yet support anything better.

> help at all.

Right.

> referring to the EAP-scheme I discussed above? 

There is no ND&S facility in 1X but the 802.11 WIEN group is
developing schemes for that.

> overweighs the cost of adding one more message/mechanism to the spec...

I'm not sure either. I guess the tradeoff is in the
client that either sees the information it wants in
public broadcast messages, or has to attach and send
its own packets to find out. The former is better if
it is likely that you need to go to another PANA link.
The latter is better if you are likely to be happy
with the information that you get. I think that PANA
has more capabilities to represent multiple ISPs on
a single link that 802.11 has. This would seem to imply
that staying on the same link is more likely in PANA
than in 802.11.

--Jari