Subject: Re: New [issue25] Service Profile names

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 09 Oct 2003 10:48:16 -0700

In the initial text I recently provided, one NAP-Information AVP and
zero or more ISP-Information AVPs can optionally be carried in
PANA-Start-Request, where each AVP includes a unique (IANA-assigned)
provider identifier and a provider name.

When there are multiple PAAs, this kind of information could 
be used by PaC to choose a PAA.  So this issue might result in 
re-consideration of the current PAA selection procedure:

  "There can be multiple PAAs on the link. The result does not depend
  on which PAA PaC chooses. By default PaC chooses the PAA that sent
  the first response."

Note that section 4 of draft-yacine-pana-paa2ep-prot-eval-00.txt also
addresses a similer issue.

Yoshihiro Ohba

On Thu, Sep 25, 2003 at 10:50:16AM -0700, Alper Yegin wrote:
> 
> This piece of data sounds informative and potentially useful. I presume if
> we wanted to have this support, we'd define a new AVP that carries some sort
> of an "identifier" and optionally carried in PANA-Start-Request. Do we have
> to define the format of the data this AVP embeds? What type of information
> would the data be carrying?
> 
> 
> Alper
> 
> 
> > I think more about this issue and now I tend to agree that the
> > proposed functionality might be useful even if there is one PAA on an
> > IP link.  First, there may be multiple IP links available at a
> > physical location (e.g., a hotspot).  In such a case, if
> > PANA-Start-Request messages sent by PAAs contain some profile
> > information, a PaC can use the information to choose an appropriate IP
> > link to start authentication.  Second, even if there is only one IP
> > link in a physical location and one PAA on the link, a PaC can use the
> > information to determine whether it starts authentication on the IP
> > link or not.
> > 
> > Yoshihiro Ohba
> > 
> > 
> > 
> > On Wed, Sep 10, 2003 at 02:22:14PM +0300, [email-masked] wrote:
> >> New submission from Dan Forsberg <[email-masked]>:
> >> 
> >>> From Reinaldo Penno:
> >> <klip>
> >>> 3) In section 4.2, paragraph 3 it is mentioned that
> >>> "The result does not depend on which PAA PaC chooses.
> >>> By default PaC chooses the PAA that sent the first
> >>> reponse"
> >>> 
> >>> This is the DHCP approach. Where all servers are
> >>> equally good. 
> >>> 
> >>> I would propose that we think about incorporating
> >>> something of the PPPoE protocol that is widespread,
> >>> since PANA is more related to the PPPoE model.
> >>> 
> >>> In the response of the Discovery message each PPPoE
> >>> server include all the Service Profile (names) it
> >>> supports (the definition is loose on purpose).
> >>> Nowadays it is usually a list of ISPs or bandwidth
> >>> packages a user can choose.
> >>> 
> >>> I would argue that in the case of PANA (and specially
> >>> in the case of NAP vs ISP authentication), PAA servers
> >>> might support a very different set of attributes and a
> >>> PaC might prefer one over the other if it new of each
> >>> choices.
> >>> 
> >>> We could have a AVP in PANA for that purpose in the
> >>> answer to the Discovery message. it seems very simple,
> >>> could be optional and will provide a crucial
> >>> functionality for people that use PPPoE to migrate to
> >>> PANA.
> >> 
> >> Yoshihiro Ohba:
> >> 
> >> When we dicussed NAP and ISP separate authentication, I think the
> >> assumption is that there is a single PAA the PaC sees, and the NAI is
> >> used to choose a particular ISP.  Why do you need multiple PAAs to
> >> support NAP and ISP separate authentication?
> >> 
> >> 
> >> ----------
> >> category: Technical
> >> document: draft-ietf-pana-pana-xx.txt
> >> messages: 80
> >> nosy: dforsber
> >> priority: May Fix
> >> status: Pending
> >> title: Service Profile names
> >> ________________________________________________
> >> PANA Issues <[email-masked]>
> >> http://danforsberg.info:8080/pana-issues/issue25
> >> ________________________________________________
> >> 
> > 
> > 
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 13 Oct 2003 23:10:11 -0700

I agree with the earlier text proposed for handling service profile
advertisements.

One question: does it make sense to allow PaC to optionally include an ISP
or NAP identifier in the PANA-start-answer to identify the binding between
the subsequent authentication and the service provider? This can be an
optional feature. When not stated, the realm as suggested by the EAP
identifier provides this information.

> on which PAA PaC chooses. By default PaC chooses the PAA that sent

I'm still not convinced that an access network would have PAAs from
different NAPs on the same link. Are we talking about multiple PAAs run by
the same NAP but possibly handling AAA traffic for different ISPs? Maybe
this happens.... Nevertheless, I agree we can re-consider the above text. It
is kind of limiting without justification...

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 10:08:34 -0700

> identifier provides this information.

I was also thinking the same thing and I think it makes sense in terms
of providing more flexibile way of ISP selection so that a client that
uses can choose an ISP among multiple choices with using a single NAI.

I'll provide additional text on this.

> the same NAP but possibly handling AAA traffic for different ISPs? 

I was assuming that multiple PAAs run by the same NAP but possibly
handling AAA traffic for different ISPs, but I think it is also
possible to have different NAPs on the same link, as NAP and ISP are
basically logical separation and what is applicable to ISP is also
logically applicable NAP.  But I think PANA design should not have to
care about details on how the service profiles are used.

> Maybe

My opinion is that flexible choice of PAA (and EP) is possible as long
as the choice is consistent with data packet routing.  

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 11:59:13 -0700

Here is the new text which reflects Alper's comments.

Yoshihiro Ohba

---
In Section 4.2, change

From:

"  When a PaC receives the PANA-Start-Request message in response to
   the PANA-PAA-Discover message, it responds with a PANA-Start-Answer
   message. The PANA-Start-Answer message contains the initial sequence
   numbers in the tseq and rseq fields of the PANA header, a copy of
   the received Cookie as the PANA payload."

To:

"  A PANA-Start-Request can also contain zero or one NAP-Information
   AVP and zero or more ISP-Information AVPs to advertise the
   information on the NAP and/or ISPs.

   When a PaC receives the PANA-Start-Request message in response to
   the PANA-PAA-Discover message, it responds with a PANA-Start-Answer
   message if it wishes to enter the authentication phase.  The
   PANA-Start-Answer message contains the initial sequence numbers in
   the tseq and rseq fields of the PANA header, a copy of the received
   Cookie (if any) as the PANA payload.  If the received
   PANA-Start-Request message contains a NAP-Information AVP and zero
   or more ISP-Information AVP, the PaC MAY additinally contain the
   received NAP-Information AVP and, if any, one of the received
   ISP-Information AVP(s) in the PANA-Start-Answer message to identify
   the binding between the subsequent authentication and the NAP/ISP.
   If the PaC does not contain a NAP-Information AVP or an
   ISP-Information AVP, the EAP peer identity or some default
   information MAY be used to identify the binding."

In Section 9.3.3, change

from:

"
      PANA-Start-Request ::= < PANA-Header: 2, REQ >
                    [ Cookie ]
                  * [ AVP ]
"

to:

"
      PANA-Start-Request ::= < PANA-Header: 2, REQ >
                    [ Cookie ]
		    [ NAP-Information ]
                  * [ ISP-Information ]
                  * [ AVP ]
"

In Section 9.3.4, change

from:

"     PANA-Start-Answer ::= < PANA-Header: 3 >
                    [ Cookie ]
                  * [ AVP ]"

to:

"     PANA-Start-Answer ::= < PANA-Header: 3 >
                    [ Cookie ]
		    [ NAP-Information ]
                    [ ISP-Information ]
                  * [ AVP ]"

Add the following sections:

"9.4.9 NAP-Information AVP

The NAP-Information AVP (AVP Code: 1029) is of type Grouped, and
contains one globally unique identifier of the NAP in a
Provider-Identifier AVP and one enterprise name of the NAP in a
Provider-Name AVP.  Its Data field has the following ABNF grammar:

      NAP-Information ::= < AVP Header: 1029 >
                           { Provider-Identifier }
                           { Provider-Name }
                         * [ AVP ]

9.4.10 ISP-Information AVP

The ISP-Information AVP (AVP Code: 1030) is of type Grouped, and
contains one globally unique identifier of the ISP in a
Provider-Identifier AVP and one enterprise name of the ISP in a
Provider-Name AVP.  Its Data field has the following ABNF grammar:

      ISP-Information ::= < AVP Header: 1030 >
                           { Provider-Identifier }
                           { Provider-Name }
                         * [ AVP ]

9.4.11 Provider-Identifier AVP 

The Provider-Identifier AVP (AVP Code: 1031) is of type Unsigned32,
and contains an IANA assigned "SMI Network Management Private
Enterprise Codes" [IANAWEB] value, encoded in network byte order.

9.4.12 Provider-Name AVP 

The Provider-Name AVP (AVP Code: 1032) is of type UTF8String, and
contains the UTF8-encoded name of the provider."

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Oct 2003 12:51:27 -0700

> logically applicable NAP.

I didn't think so. NAP is the owner of the access network (cables, routers,
switches, antennas, etc.) and there can only be one according to the current
models.

> But I think PANA design should not have to

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Oct 2003 13:27:28 -0700

I was thinking something in terms of this:

- If only a NAP-info is included in the PANA-start-answer, that means the
following authentication should be directed to particular NAP's AAA.
- If only a ISP-info is included in the PANA-start-answer, that means the
following authentication should be directed to particular ISP's AAA.
** in these cases, the NAP and ISP info overwrites whatever the EAP client
identifier may suggest. One *-info is included at a time when separate
authentication will take place.

- If both NAP-info and ISP-info are included, that means only one
authentication will take place. The *-info indicates the chosen service
combination. The authentication request is forwarded to ISP's AAA.

- If no *-info is included, that means the implicit selection depends on the
EAP client identifier.

We might also modify the f-flag logic. Maybe we can fold that logic to
PANA-start-request/answer exchange. PANA-start-request can signal the
capability to provide separate auth along with the list of ISPs/NAP.
PANA-start-answer can signal whether the PaC will do separate auths or not.
A flag in the message header can deliver this capability/choice.

Comments?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 14:38:38 -0700

> authentication will take place.

OK.

> combination. The authentication request is forwarded to ISP's AAA.

It seems natural for this case that separate authentication will take
place with using particular NAP's AAA and ISP's AAA.

> - If no *-info is included, that means the implicit selection depends on the

It seems natural for this case that only one authentication will
take place with the authentication request being forwarded to ISP's
AAA.

> A flag in the message header can deliver this capability/choice.

Or can we use *-info contained in PANA-start-{request,answer} for that
purpose instead of definig a new flag?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 14:43:44 -0700

> switches, antennas, etc.) and there can only be one according to the current

Yes, you are right according to the current models.  (I just thought
that the access network could be shared among multiple NAPs...)

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2003 17:04:56 -0700

[I'm resending this messsage. Apparently we were using the old mailing list
and it started bouncing....]

On 10/16/03 4:51 PM, "Alper Yegin" <[email-masked]> wrote:

> 
> Here is another attempt...
> 
> Assuming:
> - PAA may optionally include *-info in the PANA-start-request to "advertise"
> the availability of service providers to the user.
> - PaC may optionally include its choice of service providers in
> PANA-start-answer, which effects the AAA routing. In the absence of *-info,
> service selection and AAA routing is based on the client identifier used
> within EAP conversation.
> - PAA may optionally enable NAP-ISP authentication separation.
> - PaC may optionally perform separate NAP and ISP authentication.
> 
> 
> How about this:
> - PAA advertises auth separation capability by using S-flag in
> PANA-start-request. PaC communicates its desire to separate them using the
> same flag in the PANA-start-answer.
> 
> - If S-flag is not set in the request, there will be only one round of
> authentication. PaC can indicate its choice of NAP and ISP by including
> their *-info in the  PANA-start-answer. AAA routing will be based on the
> ISP choice. 
> 
> - If S-flag is set, there may be two rounds of authentication, depending on
> the PaC's preference.
> - If PaC wants to enable separate authentication, it should turn on the
>   S-flag in PANA-start-answer. In that case, at most one *-info may be
>   included at once, and it dictates the service provider selection.
> - If PaC does not care about separate authentication, it unsets the S-flag
>   in PANA-start-answer, and this is same as if PAA never set the S-flag.
> 
> Does this make sense?
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2003 17:04:56 -0700

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 08:08:05 -0700

I forward my reply to the new list.

Yoshihiro Ohba

On Fri, Oct 17, 2003 at 08:02:21AM -0700,  wrote:
> On Thu, Oct 16, 2003 at 04:51:11PM -0700, Alper Yegin wrote:
> > 
> What does the above sentense mean?
> 
> - Either one ISP-info or one NAP-info may be included.
> 
> - One NAP-info and/or one ISP-info may be included.
> 
> (I guess you mean the latter.)
> 
> In addition, I'm currently assuming that one PAA is associated with a
> single NAP. In this case, including NAP-info in the answer may be
> redundant.
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 08:08:05 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 10:28:25 -0700

>> (I guess you mean the latter.)

I mean, there can be at most one info AVP (this AVP may be either ISP-info,
or AVP-info). Since there is a separate authentication round going on, each
round should be associated with a single service provider.

>> single NAP. In this case, including NAP-info in the answer may be

Including a NAP-info in the answer (when separate authentication is going
on) means that the supplied authentication info should be used with the NAP.
(NAP's AAA).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 10:28:25 -0700

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 11:04:28 -0700

> round should be associated with a single service provider.

I think each authentication round can be associated with a different
AAA, i.e., NAP authentication can use NAP's AAA and ISP authentication
can use ISP's AAA (possibly with using a different identity in each
authentication round).  Do you mean such a scenario should not be
supported?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 11:04:28 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 11:19:37 -0700

> authentication round).  Do you mean such a scenario should not be

There is some misunderstanding. This is exactly what I'm trying to support
in the protocol design.

If PAA offers and PaC accepts to authenticte to NAP and ISP separately,
there will be two rounds of EAP authentication. Each round should be
associated with one service provider, whose identity is carried in a *-info
AVP. For example, in the first round, PaC can send NAP-info, in the second
round it can send ISP-info. My point was, NAP-info and ISP-info should not
be carried at the same time (round) in this case. (if you do, how will the
PAA know which AAA to contact? Would it be ISP's AAA, or NAP's AAA? Having a
single *-info makes it clear).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 11:19:37 -0700

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 12:33:00 -0700

> There is some misunderstanding. This is exactly what I'm trying to support

OK. But...

> single *-info makes it clear).

in the current design there is only one PANA-Start-Request/Answer exchange 
even when two EAP authentication rounds are performed in a PANA authentication 
phase.  How can we specify the two *-info AVPs in separate answer messages?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 12:33:00 -0700

OK. But...

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 13:18:21 -0700

> phase.  How can we specify the two *-info AVPs in separate answer messages?

You are right, I forgot that... How about including the other *-info in
PANA-Bind-answer at the end of first EAP authentication (or, in the first
PANA-auth-answer message following the PANA-binding)?

Alper

>>>>>>>>> - If no *-info is included, that means the implicit selection depends
>>>>>>>>> on
>>>>>>>>> the
>>>>>>>>> EAP client identifier.
>>>>>>>>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 13:18:21 -0700

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 14:08:21 -0700

> PANA-auth-answer message following the PANA-binding)?

It can. On the other hand, there would be several other alternatives, too.

What I'm currently thinking is:

- When PaC sends a PANA-Start-Answer message with S-bit set, it can
contain one NAP-info and one ISP-info.

- PAA determines the order of NAP/ISP authentications.  It includes
either one ISP-info or one NAP-info in PANA-Auth-Request of each round
of EAP authentication in the determined order.

- PaC that receives the PANA-Auth-Request understands which
authentication is occuring and use an appopriate identity in each
round of EAP.

- In each round, once PAA receives the first PANA-Auth-Answer, it can
stop including the *-info.

The difference is that, in your scheme PaC determines the order and in 
the above scheme PAA determines the order.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Oct 2003 14:08:21 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 18:12:08 -0700

Letting the PAA control the order may be preferred, I guess.

Alper

>>>>>>>>>>> - If only a NAP-info is included in the PANA-start-answer, that
>>>>>>>>>>> means
>>>>>>>>>>> the
>>>>>>>>>>> - If only a ISP-info is included in the PANA-start-answer, that
>>>>>>>>>>> means
>>>>>>>>>>> the
>>>>>>>>>>> PANA-start-answer can signal whether the PaC will do separate auths
>>>>>>>>>>> or
>>>>>>>>>>> not.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2003 18:12:08 -0700

Alper