Subject: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Apr 2004 13:55:56 -0700

This is a proposed resolution for issue 56.

Partial text is from section 4.2...

Change from:

   If the S-flag of the received PANA-Start-Request message is not set,
   PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent
   back to the PAA.  In this case, PaC can indicate its choice of ISP by
   including its ISP-Information AVP in the PANA-Start-Answer message.
   AAA routing will be based on the ISP choice if an ISP-Information AVP
   is specified in the PANA-Start-Answer message, otherwise it will be
   based on EAP identifier.

   If the S-flag of the received PANA-Start-Request message is set, PaC
   can indicate its desire to perform separate EAP authentication for
   NAP and ISP by setting the S-flag in the PANA-Start-Answer message.
   In this case, PaC can also indicate its choice of ISP by including
   its ISP-Information AVP in the PANA-Start-Answer message.  AAA
   routing for NAP authentication will be based on the NAP.  AAA routing
   for ISP authentication will be based on the ISP choice if an
   ISP-Information AVP is specified in the PANA-Start-Answer message,
   otherwise it will be based on EAP identifier.  If the S-flag of the
   received PANA-Start-Request message is set and the S-flag of the
   corresponding PANA-Start-Answer message is not set, only one EAP
   authentication occurs without distinction between NAP and ISP
   authentications.  In this case, PaC can still indicate its choice of
   ISP by including its ISP-Information AVP in the PANA-Start-Answer
   message.

To:

   If the S-flag of the received PANA-Start-Request message is not set,
   PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent
   back to the PAA.  In this case, PaC can indicate its choice of ISP by
   including an ISP-Information AVP in the PANA-Start-Answer message.
   When a AAA backend is used, the identity of the destination AAA
server 
   or realm MUST be determined based on the explicitly chosen ISP. When
the 
   ISP-Information AVP is not present, the access network MAY rely on
the
   client identifier carried in the EAP authentication method to make
this 
   determination.

   If the S-flag of the received PANA-Start-Request message is set, PaC
   can indicate its desire to perform separate EAP authentication for
   NAP and ISP by setting the S-flag in the PANA-Start-Answer message.
   In this case, PaC can also indicate its choice of ISP by including
   its ISP-Information AVP in the PANA-Start-Answer message. When a AAA
   backend is used, the access network determines the destination AAA
server 
   for NAP authentication. The identity of the destination AAA server or
   realm for ISP authentication is determined as described earlier. If
the
   S-flag of the received PANA-Start-Request message is set and the
S-flag 
   of the corresponding PANA-Start-Answer message is not set, only one
EAP
   authentication occurs without distinction between NAP and ISP
   authentications.  In this case, PaC can still indicate its choice of
   ISP by including its ISP-Information AVP in the PANA-Start-Answer
   message.

Comments welcome.

Alper

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Apr 2004 01:27:17 -0700

I agree on the proposed text.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Apr 2004 01:27:17 -0700

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Apr 2004 08:51:10 +0300

>    including an ISP-Information AVP in the PANA-Start-Answer message.

I believe you mean that the inclusion of the ISP-Information AVP
is optional, and up to the decision of the client. If so, perhaps
"MAY" instead of "can" is more appropriate?

>    ISP-Information AVP is not present, the access network MAY rely on

SHOULD? What else can it do?

>    ISP by including its ISP-Information AVP in the PANA-Start-Answer

Do you mean this:

   If the S-flag of the received PANA-Start-Request message is set, PaC
   can indicate its desire to perform separate EAP authentication for
   NAP and ISP by setting the S-flag in the PANA-Start-Answer message.
   If the S-flag in the PANA-Start-Answer message is not set, only one
   authentication is performed and the processing occurs as described
   earlier. If the S-flag in the PANA-Start-Answer message is set,
   the determination of the destination AAA server or realm for
   ISP authentication is performed as described earlier. In addition,
   where backend AAA servers are used, the destination AAA server
   for NAP authentication is determined entirely by the access network
   (without considering any AVPs or EAP client identifiers).

(Its still unclear to me, however, what happens if I see
a network that offers this double authentication for some
local NAP X. I don't have a subscription with X, though
I might have a subscription with ISP Y that has a roaming
relationship with X. What should I do? Can I set S=0
to get past this? But why would X offer authentication
if they don't require it? Or can I set S=1 and set my
NAI to jari@Y, and the AAA routing somehow works? Perhaps
the answer is in some of the many unread e-mails I have
on this list...)

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Apr 2004 08:51:10 +0300

Do you mean this:

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Apr 2004 15:52:47 -0700

> "MAY" instead of "can" is more appropriate?

Yes, let me fix that.

> SHOULD? What else can it do?

I don't want to lock anyone else to NAI-based ISP selection. Port,
circuit, or MAC address based selections (though not as dynamic!) may be
used.

>    (without considering any AVPs or EAP client identifiers).

Almost exactly! Thanks for the rewrite.
I think I'd remove the last parenthesized statement. I think it is
over-constraining especially considering the future AVPs, etc.

> to get past this? 

Yes. If the text is not clear on that, we should fix that.

> But why would X offer authentication
> if they don't require it? 

At least one application is differentiated services. By additionally
subscribing to NAPx, I get a better service than you do who only has an
account with ISPy. This is coming from DSL networks...

> Or can I set S=1 and set my
> NAI to jari@Y, and the AAA routing somehow works? 

If you only have account with ISPy, you don't select separate NAP-ISP
authentication by setting the S bit.

> Perhaps

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Apr 2004 15:52:47 -0700

Yes, let me fix that.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Apr 2004 05:56:57 +0300

> over-constraining especially considering the future AVPs, etc.

Ok. Re: over-constraining. My text was bad in the sense that
it said "don't do this" and it didn't really say "do this".
I agree that the former is over-constraining, but I also
feel that for interoperability, we should define one way
to do it. Future specifications or vendors can then add
new ways for "do this".

> Yes. If the text is not clear on that, we should fix that.

(snip)

> authentication by setting the S bit.

Ok. That's fine. Just wanted to check...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Apr 2004 05:56:57 +0300

(snip)

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Apr 2004 10:45:29 -0700

> to do it. Future specifications or vendors can then add

In the case of NAP authentication, the NAP is the ultimate AAA realm to
authenticate the client. There is no roaming, or inter-realm AAA
routing. If the NAS is running a AAA client, it needs to be
preconfigured with the AAA server's location. That's all I guess. 

I wasn't sure if you are suggesting we should add more text...?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Apr 2004 10:45:29 -0700

Alper

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Apr 2004 21:41:54 +0300

> I wasn't sure if you are suggesting we should add more text...?

Perhaps you should add something from your above explanation
to the draft?

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Apr 2004 11:43:34 -0700

>   (without considering any AVPs or EAP client identifiers).

I think the last sentence in Alper's text should be kept somewhere 
in this or previous paragraph:

"In this case, PaC can still indicate its choice of ISP by including
its ISP-Information AVP in the PANA-Start-Answer message." 

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Apr 2004 21:41:54 +0300

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Apr 2004 11:43:34 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 15:03:32 -0700

Another rev on the proposed text based on the earlier feedback.

Change from:

To:

   back to the PAA.  In this case, PaC MAY indicate its choice of ISP by

   If the S-flag of the received PANA-Start-Request message is set, PaC
   can indicate its desire to perform separate EAP authentication for
   NAP and ISP by setting the S-flag in the PANA-Start-Answer message.
   If the S-flag in the PANA-Start-Answer message is not set, only one
   authentication is performed and the processing occurs as described
   earlier. If the S-flag in the PANA-Start-Answer message is set,
   the determination of the destination AAA server or realm for
   ISP authentication is performed as described earlier. In addition,
   where backend AAA servers are used for NAP authentication, the NAP is
   considered the ultimate AAA realm, and the destination AAA server for
   this authentication is determined entirely by the local configuration

   on the access server hosting PAA (NAS).

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 15:03:32 -0700

Change from:

To: