Subject: [Pana] PANA specification and framework snaps

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 10 Jul 2004 00:59:24 -0400

The latest snapshots of PANA specification (05c) and PANA framework
(01c) are available at
http://www.toshiba.com/tari/pana/pana-spec.html.

1. PANA specication (draft-ietf-pana-pana-05c.txt)

Updates: Incoporated proposed text for Issues 98, 99, 100 as well as
editorial work by Hannes and AAA-Key revised definition by Alper.

Remaining issues : 94 and 95 (both on Section 9, waiting for revised
text from Alper and Hannes).

2. PANA framework (draft-ietf-pana-framework-01c.txt)

Updates: Reflected Randy Turner's comments.

Remaining issues : NONE (is it OK to submit?).

Best regards,

Yoshihiro Ohba

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 10 Jul 2004 13:24:12 +0200

hi yoshi, 

i have read the framework document and included some comments. most of them
are editorial. 
my feedback: this is a good and useful document. 

please find my comments at:
http://www.tschofenig.com/TEMP/draft-ietf-pana-framework-00-hannes.txt

ciao
hannes

ps: i haven't finished the entire document. hopefully i get the rest done
during the next week.

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Samstag, 10. Juli 2004 06:59
> To: [email-masked]
> Subject: [Pana] PANA specification and framework snaps
> 
> Updates: Incoporated proposed text for Issues 98, 99, 100 as 
> well as editorial work by Hannes and AAA-Key revised 
> definition by Alper.
> 
> Remaining issues : 94 and 95 (both on Section 9, waiting for 
> revised text from Alper and Hannes).
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Jul 2004 10:55:10 -0400

Hi Hannes,

Thanks for your comments.  Your comments are reflected to a new
snapshot 00d at http://www.toshiba.com/tari/pana/pana-spec.html.  
I have some comments below (tagged with [ohba]).

-------------------------------------------------------------
In section 5,

(snip)

      If the PaC is a dual-stack host, it can configure both IPv4 and
      IPv6 type POPAs.

      PRPA and the IP address of PAA are assumed to be on the same IP
      subnet, hence the PaC and PAA can perform on-link communication as
      required by PANA.

[hannes] there is no such assumption in pana. 

[ohba] The entire paragraph is revised as:

"
      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, as 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.
"

Does this work for you?

In Section 6,

   Network-layer ciphering, i.e., IPsec, can be used when data traffic
   protection is required but link-layer ciphering capability is not
   available.

[hannes] change to 
"
   Network-layer protection, i.e., IPsec, can be used when data traffic
   protection is required but link-layer protection is not
   available. Providing security at the network-layer allows to terminate security protection 
   deeper in the network.
"

[ohba] The last sentence in your suggested text seems to contradict
with "it is important to place the EP as close to the edge of the
network as possible."  So I would prefer not including the last sentence.

(snip)

  The details of such a mechanism is outside the
   scope of PANA protocol and is specified in [I-D.ietf-pana-ipsec].
   PANA provides bootstrapping functionality for such a mechanism by
   carrying EAP methods that can generate initial keying material.

   Using network-layer ciphers should be regarded as a substitute for
   link-layer ciphers when the latter is not available. Network-layer
   ciphering can also be used in addition to link-layer ciphering if the
   added benefits outweigh its cost to the user and the network.
  In
   this case, PANA bootstraps only the network-layer ciphering and
   link-layer is protected using any of the existing link-layer specific
   methods.

[hannes] the last paragraph is a repetition. 

[ohba]  Repetition of which text?  

In Section 7,

7. PAA-EP Protocol

   The PANA protocol provides client authentication and authorization
   functionality for securing network access.  The other component of a
   complete solution is the access control which ensures that only
   authenticated and authorized clients can gain access to the network.
   PANA enables access control by identifying legitimate clients and
   generating filtering information for access control mechanisms.

[hannes] "identifying legitimate clients" - what does that mean? 

[ohba] changed to "distinguishing authenticated and authorized clients
from others"

(snip)

7.1.1 Single PAA, Single EP, Co-located

   This model corresponds to the legacy NAS model.  Since the PAA and
   the EP are co-located, the PAA-EP communication can be implemented
   locally by using, e.g., IPC (Inter-Process Communication).  The only
   difference from the legacy NAS model is the case where there are
   multiple co-located PAA/EP devices on the same IP link and the PAA/EP
   devices are L2 switches or access points.

[hannes] the paa/ep cannot be a l2 switch in this model - only an access point. 

[ohba]  Why?

  In this case, for a PaC
   that attaches to a given PAA/EP device, other PAA/EP devices should
   not be visible to the PaC even if those devices are on the same IP
   link.

[hannes] what does it mean 'not be visible'?

[ohba] changed to "In this case, for a PaC that attaches to a given
PAA/EP device, other PAA/EP devices should not be discovered by the
PaC even if those devices are on the same IP link."

  Otherwise, the PaC may result in finding a PAA that is not the
   closest one to it during the PANA discovery and initial handshake
   phase and performing PANA with the wrong PAA.

[hannes] this issue might deserve a more detailed description.

[ohba] Changed to:

"
   Otherwise, the PaC may result in finding a PAA that is not the
   closest one to it during the PANA discovery and initial handshake
   phase and performing PANA with the PAA, which does not correspond
   to the legacy NAS model.
"

  To prevent this, each
   PAA/EP device on an L2 switch or access point should not forward
   multicast PANA discovery message sent by PaCs attached to it to other
   devices.

[hannes] is this really the solution? 

[ohba] I believe so, based on the legacy NAS model in which only one
authentication agent is discovered by a client.  If the client
discoveres a PAA a PAA that is not the closest one to it, then such a
case belongs to "Multiple PAAs" model instead of "Single PAA, Single
EP, Co-located".

7.1.2 Separate PAA and EP

   When PAA is separated from EP, two cases are possible with regard to
   whether PAA and EP are located in parallel or serial when viewed from
   PaC, for each of models described in this section.

   In the first case, PAA is located behind EP.  The EP should be
   configured to always pass through PANA messages and address
   configuration protocol messages used for configuring an IP address
   used for initial PANA messaging. This case can typically happen when
   the EP is an L2 switch or an access point (the EP also has an IP
   stack to communicate with PAA via a PAA-EP protocol).

[hannes] if the ep is an access point and the paa is "behind" the ep then it has to be an router. 
since pana has this one-hop away principle. 

[ohba] I think there is some misunderstanding here.  The access point
EP does not have to be a router under the one-hop away principle.
Specifically, there is an explicit text in the PANA requirement draft:

"
   The PAA and PaC MUST be exactly one IP hop away from each other.
   That is, there must be no IP routers between the two.  Note that this
   does not mean they are on the same physical link.  Bridging
   techniques can place two nodes just exactly one IP hop away from each
   other although they might be connected to separate physical links.  
"

             +---+        +---+        +---+
             |PaC|--------|EP |--------|PAA|
             +---+        +---+\       +---+
                                \
                                 +---- Internet

                     Figure 3: PAA and EP in Serial

(snip)

7.3 Filter Rule Installation

   Filtering rules to be installed on EP generally include a device
   identifier of PaC, and also cryptographic keying material (such as
   keys, key pairs, and initialization values) when needed.

[hannes] what is the difference between keys and key pairs? btw, ivs are most likely not installed since they are negotiated - at least in ike 

  The keying
   material is needed when attackers can eavesdrop and spoof on the
   device identifiers easily.  Each keying material is uniquely
   identified with a keying material name

[hannes] what is the 'keying material name'?  we had a long discussion on this issue in the pana wg. 

 and has a lifetime for key
   management purpose.

[hannes] not only for management purposes - it is for accounting, charging, access control & security reasons in general. 
the lifetime is an important issue here. 

  The keying material is used with link-layer or
   network-layer ciphering to provide additional protection. For issues
   regarding data-origin authentication see Section 6. 

[hannes] these issues should go into section 6 and not repeated here. 

[ohba] According to your comments on the first paragraph of section 7.1,
the paragraph is revised to:

" 

   Filtering rules to be installed on EP generally include a device
   identifier of PaC, and also cryptographic keying material (e.g., IKE
   pre-shared key [RFC2409]) when cryptographic data traffic protection
   is needed (See Section 6).  Each keying material is uniquely
   identified with a keying material name (e.g., ID_KEY_ID in IKE
   [RFC2409]) and has a lifetime for key management, accounting, access
   control and security reasons in general.  In addition to the device
   identifier and keying material, other filter rules, such as the IP
   filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
   EAP application [I-D.ietf-aaa-eap] may be installed on EP.

"

Yoshihiro Ohba