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
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana