Subject: [Pana] issue25 revised text

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Oct 2003 06:37:57 -0700

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:

"  PAA MAY enable NAP-ISP authentication separation by setting the
   S-flag of the message header of the PANA-Start-Request.  Also, the
   PANA-Start-Request MAY 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 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."

In Section 4.3 change

from:

"  A single PANA session can enable more than one EAP authentication.
   This is used to satisfy the separate NAP and ISP authentications
   scenario.  Each EAP authentication is delineated from the subsequent
   one.  The F-flag in the PANA header indicates if this was the final
   authentication from sender's perspective.  If the PAA enables two
   separate authentication, it should not set the F-flag in after the
   first EAP method.  This indicates PAA's willingness to offer another
   authentication method for NAP-ISP separation.  PaC can respond with
   the F-flag unset, indicating PaC's willingness to go through a
   second authentication method.  The PaC can optionally decline by
   setting the F-flag, and this concludes the PANA authentication.  If
   the PAA does not offer two levels of authentication, then it sets
   the F-flag even at the end of first EAP exchange.  In that case the
   PaC has no other option but to set the F-flag to mark the end of
   PANA authentication."

to:

"  A single PANA session can enable more than one EAP authentication.
   This is used to satisfy the separate NAP and ISP authentications
   scenario.  Each EAP authentication is delineated from the subsequent
   one.  The F-flag in the PANA header indicates if this was the final
   authentication from sender's perspective.  If the PAA enables two
   separate authentication, it should not set the F-flag in after the
   first EAP method.  This indicates PAA's willingness to offer another
   authentication method for NAP-ISP separation.  PaC can respond with
   the F-flag unset, indicating PaC's willingness to go through a
   second authentication method.  The PaC can optionally decline by
   setting the F-flag, and this concludes the PANA authentication.  If
   the PAA does not offer two levels of authentication, then it sets
   the F-flag even at the end of first EAP exchange.  In that case the
   PaC has no other option but to set the F-flag to mark the end of
   PANA authentication.

   PAA determines the execution order of NAP authentication and ISP
   authentication.  PAA can indicate which EAP authentication is
   currently occurring by including a NAP-Information or an
   ISP-Information AVP of the corresponding EAP authentication in
   PANA-Auth-Request messages. The PAA MAY stop including the AVP once
   it receives the first PANA-Auth-Answer message of the current EAP
   authentication."

In Section 9.1 change

from:

"  Flags
                                                                                
     The Flags field is eight bits.  The following bits are assigned:
                                                                                
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |R r r r F r r r|
    +-+-+-+-+-+-+-+-+"
                                                                                
To:
                                                                                
"  Flags
                                                                                
     The Flags field is eight bits.  The following bits are assigned:
                                                                                
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |R r r r F S r r|
    +-+-+-+-+-+-+-+-+"

In Section 9.1 

add:

"      S(eparate)
                   - When the S-flag is set in a PANA-Start-Request
                     message it indicates that PAA is willing to offer
                     separate EAP authentication for NAP and ISP.
                     When the S-flag is set in a PANA-Start-Answer
                     message it indicates that PaC accepts on
                     performing separate EAP authentication for NAP
                     and ISP."

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 ]
                    [ 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."

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

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 21 Oct 2003 06:53:32 -0700 (PDT)

Hi Yoshi,

I finally found comment to comment on this issue. In
PPPoE, the "Service-Profiles" tied to a specific ISP
are just names and descriptions. so, you can have even
*one* PPPoE server, offering several distinct services
such as "bandwidth 1024", "tunnelling", "video on
demand", etc, etc.

The same should apply to PANA.

The Service-Profiles in PPPoE are not just for
authentication. I mentioned in the first post that the
definition of the term was loose on purpose, and
that's where its power comes from. 

I'm not sure we can do this in this proposal. I'm not
sure after the IANA provider identifier we can convey
such information.

It seems we are trying to tie everything together for
the purposes of aithentication and in the process
distancing ourselves from the original meaning of the
field in PPPoE. If I'm wrong, please correct me.

The information contained in the packet should be (one
or more of) ISP + any services the ISP offers.
Something like

{ISP A}, {Gold, Silver, Bronze, Platinum}.
{ISP B}, {Video, Voice, VPN}

Can I do this with the current proposal?

thanks,

Reinaldo

--- Yoshihiro Ohba <[email-masked]> wrote:
>                      performing separate EAP
> authentication 
=== message truncated ===

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 21 Oct 2003 06:53:32 -0700 (PDT)

Hi Yoshi,

thanks,

Reinaldo

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Oct 2003 08:39:25 -0700

Hi Reinaldo,

I think it would be better to discuss the issue step-by-step.  That is
why I started from including provider identifier and name (and we have
reached a rough consensus on it).  I would suggest creating a new
issue to discuss whether more detailed service profile information
should be added or not.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Oct 2003 08:39:25 -0700

Hi Reinaldo,

Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 21 Oct 2003 09:20:41 -0700 (PDT)

okay,

I'm not the way it is today, this would be that
useful. Yes, it will take care of some cases that
carriers face, but will be one more barrier to PPPoE
migration.

In general, I would like to see PANA as an easy
migration from PPPoX, so people have a compelling
reason to change and see it's not a major hassle. I
know I've already suggested very basic and important
things like IP address allocation and people
disagreed, but it would make PANA's success much more
likely.

regards,

Reinaldo

--- Yoshihiro Ohba <[email-masked]> wrote:
> > >    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
> > > "  PAA MAY enable NAP-ISP authentication
> separation
> > > by setting the
> > >    zero or more ISP-Information AVPs to
> advertise
> > > the information on
> > >    the NAP and/or ISPs.
> > > 
> > >    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
> > >    If the S-flag of the received
> PANA-Start-Request
> > > message is not
> > >    ISP by including its ISP-Information AVP in
> the
> > > PANA-Start-Answer
> > >    If the S-flag of the received
> PANA-Start-Request
> > > message is set,
> > >    PaC can indicate its desire to perform
> separate
> > > EAP authentication
> > >    message. In this case, PaC can also indicate
> its
> > > choice of ISP by
> > >    AAA routing for NAP authentication will be
> based
> > > on the NAP.  AAA
> > >    routing for ISP authentication will be based
> on
> > > the ISP choice if
> > > "  A single PANA session can enable more than
> one
> > > EAP authentication.
> > >    This is used to satisfy the separate NAP and
> ISP
> > > authentications
> > >    scenario.  Each EAP authentication is
> delineated
> > > from the subsequent
> > >    one.  The F-flag in the PANA header indicates
> if
> > > this was the final
> > >    authentication from sender's perspective.  If
> the
> > > PAA enables two
> > >    separate authentication, it should not set
> the
> > > F-flag in after the
> > >    authentication method for NAP-ISP separation.
> 
> > > PaC can respond with
> > >    the F-flag unset, indicating PaC's
> willingness to
> > > go through a
> > >    setting the F-flag, and this concludes the
> PANA
> > > authentication.  If
> > >    the F-flag even at the end of first EAP
> exchange.
> > >  In that case the
> > >    PaC has no other option but to set the F-flag
> to
> > > mark the end of
>

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 21 Oct 2003 09:20:41 -0700 (PDT)

okay,

regards,

Reinaldo