Subject: [Pana] [pana-fwk] proposed text for issue 160

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Apr 2005 18:50:54 -0400

Note: Text for [8] is based on the assumption that when the PAA is
off-link, the PaC uses an IPv6 non-link-local address as the IPsec-TOA
as well as the PRPA.  This is under discussion in pana-ipsec issue
161.

[1] In section 3, change:

"
      The PAA resides on a node that is typically called a NAS (network
      access server) in the local area network.  The PAA can be hosted
      on any IP-enabled node on the same IP subnet as the PaC.  For
      example on a BAS (Broadband Access Server) in DSL networks, or
      PDSN (Packet Data Serving Node) in 3GPP2 networks.
"

to:

"
      The PAA resides on a node that is typically called a NAS
      (network access server) in the access network.  For example on a
      BAS (Broadband Access Server) in DSL networks, or PDSN (Packet
      Data Serving Node) in 3GPP2 networks.  In addition, the PAA can
      also be hosted on any IP-enabled node in the access network or
      even beyond the access network.
"

[2] In section 3, change:

"
   An initially unauthorized PaC starts the PANA authentication by
   discovering the PAA on the access network, followed by the EAP
   exchange over PANA.  The PAA interacts with the AS during this
   process.  Upon receiving the authentication and authorization result
   from the AS, the PAA informs the PaC about the result of its network
   access request.
"

to:

"
   An initially unauthorized PaC starts the PANA authentication by
   discovering the PAA, followed by the EAP exchange
   over PANA.  The PAA interacts with the AS during this process.
   Upon receiving the authentication and authorization result from the
   AS, the PAA informs the PaC about the result of its network access
   request.
"
  
[3] In section 5, change:

"
   3.  In IPv6, clients configure a link-local address [RFC2462] when
      they initialize an interface.  This address SHOULD be used as a
      PRPA.
"

to:

"
   3.  In IPv6, clients configure a link-local address [RFC2462] when
       they initialize an interface.  This address SHOULD be used as a
       PRPA when the clients have prior knowledge that a PAA is on
       the same IP link as the clients.  Otherwise, a non-link-local
       address should be used the a PRPA when such an address is available 
       prior to running PANA.
"

[4] In section 5, change:

"
      The PaC with a PRPA and the PAA with IP address X can perform
      on-link communication as required by PANA.  In IPv4, the PRPA and
      IP address X have the same on-link prefix.  In IPv6, the two
      addresses are link-local addresses.  When the PaC replaces its
      IPv4 PRPA with an IPv4 POPA, the PaC and PAA SHOULD create host
      routes to each other, when they do not share the same on-link
      prefix any more.  This is needed for the PaC with the IPv4 POPA
      and the PAA with IP address X to continue on-link communication.
      In this case, the PaC SHOULD create a host route to IP address X,
      and the PAA SHOULD create a host route to the IPv4 POPA.  PANA
      defines a mechanism for the PaC to report the POPA to the PAA.
"

to:

"
      When the PAA is one IP hop away from the PaC, the PaC with a
      PRPA and the PAA with IP address X can perform on-link
      communication.  In IPv4, the PRPA and IP address X have the same
      on-link prefix.  In IPv6, the two addresses are link-local
      addresses.  When the PaC replaces its IPv4 PRPA with an IPv4
      POPA, the PaC and PAA SHOULD create host routes to each other,
      when they do not share the same on-link prefix any more.  This
      is needed for the PaC with the IPv4 POPA and the PAA with IP
      address X to continue on-link communication without sharing the
      same on-link prefix.  In this case, the PaC SHOULD create a host
      route to IP address X, and the PAA SHOULD create a host route to
      the IPv4 POPA.  PANA defines a mechanism for the PaC to report
      the POPA to the PAA.  

      When the PAA and PaC are more than one IP hop away from each
      other, the PRPA MUST be a non-link-local address.  In this case,
      they can communicate with each other based on the standard IP
      packet routing without having a host route.
"

[5] In section 7, change:

"
   EPs' location in the network topology should be appropriate for
   performing access control functionality.  The closest IP-capable
   access device to the client devices is the logical choice.  PAA and
   EPs on an access network should be aware of each other as this is
   necessary for access control.  Generally this can be achieved by
   manual configuration.  Dynamic discovery is another possibility, but
   this is left to implementations and outside the scope of this
   document.
"

to:

"
   EPs' location in the network topology should be appropriate for
   performing access control functionality.  When the access control
   is performed at link-layer, or at IP layer with the use of IPsec,
   the closest IP-capable access device to the client devices is the
   logical choice.  PAA and EPs should be aware of each other as this
   is necessary for access control.  Generally this can be achieved by
   manual configuration.  Dynamic discovery is another possibility,
   but this is left to implementations and outside the scope of this
   document.
"

[6] Add the following paragraph in section 10:

"
   This section describes several deployment examples where PANA is
   used as network access authentication.  Although all of the
   examples have PAAs in the access network for simplicity, it is
   possible to place the PAAs behind the access network to reduce the
   number of PAAs in the administrative domain.
"

[7] In section 10.2.1.2, delete the following sentence:

"
   In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local
   address.  
"

[8] In Appendix A.2, 

Change:

"
   Case A: IPsec-TIA obtained by using DHCPv6

      This case is similar to Case A in IPv4, except that a link-local
      address is used as the PRPA and IPsec-TOA, and that the DHCPv6
      procedure can occur at any time after link-layer association and
      before IKE.
"

to:

"
   Case A: IPsec-TIA obtained by using DHCPv6

      This case is similar to Case A in IPv4, except that the DHCPv6
      procedure can occur at any time after link-layer association and
      before IKE.
"

Change:

"
   Case B: IPsec-TIA obtained by using IPv6 stateless address
   autoconfiguration

      In this case, the IPsec-TOA (link-local address) and IPsec-TIA
      (global address) are configured through IPv6 stateless address
      autoconfiguration before running IKE.  Other configuration
      information can be obtained by using several methods including
      authenticated DHCPv6, Configuration Payload exchange and DHCPv6
      over IPsec SA.
"

to:

"
   Case B: IPsec-TIA obtained by using IPv6 stateless address
   autoconfiguration

      In this case, the IPsec-TOA and IPsec-TIA are configured through
      IPv6 stateless address autoconfiguration before running IKE.
      Other configuration information can be obtained by using several
      methods including authenticated DHCPv6, Configuration Payload
      exchange and DHCPv6 over IPsec SA.
"

Change:

"
   Case C: IPsec-TIA obtained by using authenticated DHCPv6
      This case is similar to Case C of IPv4, except that a link-local
      address is used as the PRPA, and that there is no need for
      additional PANA-Update exchange to update the the IP address of
      the PaC.

to:

"
   Case C: IPsec-TIA obtained by using authenticated DHCPv6

      This case is similar to Case C of IPv4, except that there is no
      need for additional PANA-Update exchange to update the the IP
      address of the PaC.
"

Best regards,

Yoshihiro Ohba

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 26 Apr 2005 16:13:50 -0700

Hi Yoshi,

Thank you for the proposed text. Please see below for my feedback.

>       The PAA resides on a node that is typically called a NAS
(network
>       Data Serving Node) in 3GPP2 networks.  

>	  In addition, the PAA can

You are somehow associating "access network" with the "last hop." I
don't think this association is well-accepted. To me, a network hanging
off of Internet for allowing access of users is an "access network" even
though it may have a multi-hop topology within itself. For that, I'd
recommend we rewrite the last sentence as:

"The PAA may be one or more IP hops away from the PaCs."

>    AS, the PAA informs the PaC about the result of its network access

OK.

>        address should be used the a PRPA when such an address is
available

I think the discussion regarding link-local vs. global address relates
to both bullets 2 and 3. For that, I'd recommend:

3. In IPv6, clients automatically configure a link-local address
[RFC2462]
   when they initialize an interface. Additionally, they may also
configure
   global address(es) when DHCP or router advertisements with global 
   prefixes are made available to the them. 

Following that, we could say:

In case PAA is not on the same IP subnet as the PaCs are, the deployment
must ensure that a non-link-local PRPA is configurable by the clients.

>       packet routing without having a host route.

If I'm remembering this right, we had this mechanism to preserve
TTL==255 check despite PaC jumping to another subnet. Now that we don't
care about this check anymore, maybe we can yank out this whole
discussion??

>    manual configuration.  Dynamic discovery is another possibility,
but
>    but this is left to implementations and outside the scope of this

OK.

>    number of PAAs in the administrative domain.

Again, the notion "access network" is an issue here. Also, this section
talks about DSL and WiFi deployments. And in these deployments, the
chosen PAA locations are pretty fixed, imo. In this context, talking
about other alternatives may not help. I recommend we not include that
text.

>    In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local

OK.

>       procedure can occur at any time after link-layer association and

OK.

>       exchange and DHCPv6 over IPsec SA.

OK.

>       need for additional PANA-Update exchange to update the the IP

OK.

Thanks.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Apr 2005 08:06:49 -0400

Hi Alper,

Thank you for the comments.  I agree with all the comments.
Especially removing the host route stuff (your comment on [4]) 
is very good.

New changes on [4]:

Delete the following paragraph from section 5:

"

Delete the following sentense from section 8:

"
   If they don't share
   the same prefix, they SHOULD use host routes to reach each other.
"

Regards,
Yoshihiro Ohba