[Pana] FW: AD review of: draft-ietf-pana-framework-05

----- Forwarded message from Mark Townsley <townsley@cisco.com> -----

X-VirusChecked: Checked
X-Env-Sender: townsley@cisco.com
X-Msg-Ref: server-13.tower-73.messagelabs.com!1128335117!49856035!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [64.102.122.149]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-IronPort-AV: i="3.97,167,1125892800"; 
   d="scan'208"; a="72679065:sNHT53308764"
From: Mark Townsley <townsley@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
To: prakash_jayaraman@net.com, rafa@dif.um.es, yohba@tari.toshiba.com,
	mohanp@sbcglobal.net, alper.yegin@samsung.com,
	Basavaraj Patil <basavaraj.patil@nokia.com>,
	Alper Yegin <alper.yegin@samsung.com>
CC: Margaret Wasserman <margaret@thingmagic.com>
Subject: AD review of: draft-ietf-pana-framework-05
X-OriginalArrivalTime: 03 Oct 2005 10:25:04.0615 (UTC)
FILETIME=[B839D770:01C5C804]
X-UIDL: fE%"!J@Z"!7%n!!gS`"!

Chairs and authors,

It is clear that a lot of thought, time and effort has gone into this 
document. Please don't take the multitude of comments and questions 
included in my review in any way a lack of respect for this.

Overall, I believe the document suffers from a tendency to be 
repetitive, loose, and is difficult to follow at times. I understand 
that you are trying to communicate a multitude of deployment options, 
which is part of the problem here. When trying to promote 
interoperability, remember that "less is more" - if there are some 
deployment scenerios that are unrealistic, simply remove them from the 
document (there is no need to keep them around for posterity). Focus on 
those which you really want to try and standardize and get working well,

describe them once, and you may end up with a shorter, but far better, 
document (and protocol) in the end.

Please find comments and questions within. I will begin the pana-pana 
document next, unless I hear otherwise.

Thanks,

- Mark

>PANA Working Group                                          P.
Jayaraman
>Internet-Draft
Net.Com
>Expires: January 12, 2006                                       R.
Lopez
>                                                        Univ. of Murcia
>                                                          Y. Ohba (Ed.)
>                                                                Toshiba
>                                                       M. Parthasarathy
>                                                                  Nokia
>                                                               A. Yegin
>                                                                Samsung
>                                                          July 11, 2005
>
>
>                            PANA Framework
>                     draft-ietf-pana-framework-05
>
>Status of this Memo
>
>  By submitting this Internet-Draft, each author represents that any
>  applicable patent or other IPR claims of which he or she is aware
>  have been or will be disclosed, and any of which he or she becomes
>  aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>  Internet-Drafts are working documents of the Internet Engineering
>  Task Force (IETF), its areas, and its working groups.  Note that
>  other groups may also distribute working documents as Internet-
>  Drafts.
>
>  Internet-Drafts are draft documents valid for a maximum of six months
>  and may be updated, replaced, or obsoleted by other documents at any
>  time.  It is inappropriate to use Internet-Drafts as reference
>  material or to cite them other than as "work in progress."
>
>  The list of current Internet-Drafts can be accessed at
>  http://www.ietf.org/ietf/1id-abstracts.txt.
>
>  The list of Internet-Draft Shadow Directories can be accessed at
>  http://www.ietf.org/shadow.html.
>
>  This Internet-Draft will expire on January 12, 2006.
>
>Copyright Notice
>
>  Copyright (C) The Internet Society (2005).
>
>Abstract
>
>  PANA (Protocol for carrying Authentication for Network Access) design
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
1]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  provides support for various types of deployments.  Access networks
>  can differ based on the availability of lower-layer security,
>  placement of PANA entities, choice of client IP configuration and
>  authentication methods, etc.  This document defines a general
>  framework for describing how these various deployment choices are
>  handled by PANA and the access network architectures.  Additionally,
>  two possible deployments are described in detail: using PANA over DSL
>  networks and wireless LANs.
>
>Table of Contents
>
>  1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
>    1.1  Specification of Requirements  . . . . . . . . . . . . . .   4
>  2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
>  3.   General PANA Framework . . . . . . . . . . . . . . . . . . .   6
>  4.   Environments . . . . . . . . . . . . . . . . . . . . . . . .  11
>  5.   IP Address Configuration . . . . . . . . . . . . . . . . . .  13
>  6.   Data Traffic Protection  . . . . . . . . . . . . . . . . . .  16
>  7.   PAA-EP Protocol  . . . . . . . . . . . . . . . . . . . . . .  17
>    7.1  PAA and EP Locations . . . . . . . . . . . . . . . . . . .  17
>      7.1.1  Single PAA, Single EP, Co-located  . . . . . . . . . .  18
>      7.1.2  Separate PAA and EP  . . . . . . . . . . . . . . . . .  18
>    7.2  Notification of PaC Presence . . . . . . . . . . . . . . .  20
>    7.3  Filter Rule Installation . . . . . . . . . . . . . . . . .  20
>  8.   Network Selection  . . . . . . . . . . . . . . . . . . . . .  21
>  9.   Authentication Method Choice . . . . . . . . . . . . . . . .  23
>  10.  Example Cases  . . . . . . . . . . . . . . . . . . . . . . .  24
>    10.1   DSL Access Network . . . . . . . . . . . . . . . . . . .  24
>      10.1.1   Bridging Mode  . . . . . . . . . . . . . . . . . . .  24
>      10.1.2   Router Mode  . . . . . . . . . . . . . . . . . . . .  25
>      10.1.3   PANA and Dynamic ISP Selection . . . . . . . . . . .  26
>    10.2   Wireless LAN Example . . . . . . . . . . . . . . . . . .  27
>      10.2.1   PANA with Bootstrapping IPsec  . . . . . . . . . . .  27
>      10.2.2   PANA with Bootstrapping WPA/IEEE 802.11i . . . . . .  32
>      10.2.3   Capability Discovery . . . . . . . . . . . . . . . .  34
>  11.  Security Considerations  . . . . . . . . . . . . . . . . . .  35
>  12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  36
>  13.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  37
>  14.  References . . . . . . . . . . . . . . . . . . . . . . . . .  38
>    14.1   Normative References . . . . . . . . . . . . . . . . . .  38
>    14.2   Informative References . . . . . . . . . . . . . . . . .  39
>       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40
>  A.   Other Possible Cases for PANA with Bootstrapping IPsec in
>       Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . .  42
>    A.1  IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . .  42
>    A.2  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . .  43
>       Intellectual Property and Copyright Statements . . . . . . .  48
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
2]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>1.  Introduction
>
>  PANA (Protocol for carrying Authentication for Network Access) is a
>  link-layer agnostic network access authentication protocol that runs
>  between a node that wants to gain access to the network and a server
>  on the network side.  PANA defines a new EAP [RFC3748] lower layer
>  that uses IP between the protocol end points.
>
>  The motivation to define such a protocol and the requirements are
>  described in [RFC4058].  Protocol details are documented in
>  [I-D.ietf-pana-pana].  [I-D.ietf-pana-ipsec] describes use of IPsec
>  for access control following PANA-based authentication.  IPsec can be
> 
>
>  used for per-packet access control, but nevertheless it is not the
> 
>
"per-packet access control" - don't you mean per-packet "security" or 
some other word that captures authentication, confidentiality, etc.

>  only way to achieve this functionality.  Alternatives include
>  reliance on physical security and link-layer ciphering.  
>
...Particularly given this comparison.

>Separation
>  of PANA server from the entity enforcing the access control is
> 
>
s/PANA/the PANA

>  envisaged as an optional deployment choice.  
>
You are talking about the PANA server before it is defined. After it is 
defined or by using some other wording for "PANA Server", this above 
sentence could read much easier as something like:

The PANA Server [remember to define what that is] may or may not be 
co-located with the entity enforcing the per-packet access control
function.

>SNMP [I-D.ietf-pana-
>  snmp] is chosen as the protocol to carry associated information
>  between the separate nodes.
> 
>
"By "separate nodes" I assume the PANA Server and "entity enforcing 
access control" ? How about something like: "When the PANA Server and 
Access Control functions are separate, SNMP is used to carry information

between the two nodes."

>  PANA design provides support for various types of deployments.
>  Access networks can differ based on the availability of lower-layer
>  security, placement of PANA entities, choice of client IP
>  configuration and authentication methods, etc.
>
>  PANA can be used in any access network regardless of the underlying
>  security.  For example, the network might be physically secured, or
>  secured by means of cryptographic mechanisms after the successful
>  client-network authentication.
> 
>
It "can" be, but "should" it be? This type of statement is a red flag 
for security ADs, just a warning.

>  The PANA client, PANA authentication agent, authentication server,
>  and enforcement point are the relevant functional entities in this
>  design.  PANA authentication agent and enforcement point(s) can be
>  placed on various elements in the access network (e.g., access point,
>  access router, dedicated host).
>
> 
>
What about the "PANA Server" ? Is that really a PANA Authentication 
Server? I think you need to reorder this intro a bit. Define the 
relevant functional entities before talking about how to place them.

>  IP address configuration mechanisms vary as well.  Static
>  configuration, DHCP, stateless address autoconfiguration are possible
>  mechanisms to choose from. 
>
Please include a reference for DHCP and stateless address
autoconfiguration

>If the client configures an IPsec tunnel
>  for enabling per-packet security, configuring IP addresses inside the
>  tunnel becomes relevant, for which there are additional choices such
>  as IKE.
> 
>
Reference for IKE.

>  This document defines a general framework for describing how these
>  various deployment choices are handled by PANA and the access network
>  architectures.  Additionally, two possible deployments are described
>  in detail: PANA over DSL (Digital Subscriber Line) networks and WLANs
>  (Wireless LANs).
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
3]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>1.1  Specification of Requirements
>
>  In this document, several words are used to signify the requirements
>  of the specification.  These words are often capitalized.  The key
>  words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
>  "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
>  are to be interpreted as described in [RFC2119].
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
4]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>2.  Terminology
>
>  Pre-PANA address (PRPA)
>
>     This is an IP address configured on a PANA client before starting
>     the PANA protocol exchange.
>
>  Post-PANA address (POPA)
>
>     This is an IP address (optionally) configured on a PANA client
>     after a successful authentication.
>
>  IPsec Tunnel Inner Address (IPsec-TIA)
>
>     This is an IP address configured on a PANA client as the inner
>     address of an IPsec tunnel mode SA.
> 
>
Spell out Security Association on its first use.

>  IPsec Tunnel Outer Address (IPsec-TOA)
>
>     This is the address configured on a PANA client as the outer
>     address of an IPsec tunnel mode SA.
>
>  Secure Association Protocol
>
>     A protocol that provides a cryptographic binding between the
>     initial entity authentication (and authorization) exchange to the
>     subsequent exchange of data packets.  Examples of secure
>     association protocols include the 4-way handshake in IEEE 802.11i
>     [802.11i], and IKE [RFC2409] in IP-based access control.
>
>
>
>
>
> 
>
I believe you could use a few more terms here, at least the functional 
entities, if not others.

>Jayaraman, et al.       Expires January 12, 2006                [Page
5]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>3.  General PANA Framework
>
>  PANA protocol is designed to facilitate authentication and
> 
>
"PANA protocol" in general, is redundant. The first "P" stands for 
"Protocol" already. All you need to say is "PANA is designed..."

>  authorization of clients in access networks.  PANA is an EAP
>  [RFC3748] lower-layer that carries EAP authentication methods
>  encapsulated inside EAP between a client node and an agent in the
>  access network.  While PANA enables the authentication process
>  between the two entities, it is only a part of an overall AAA
>  (Authentication Authorization and Accounting) and access control
>  framework.  A AAA and access control framework using PANA is
>  comprised of four functional entities.
> 
>
>  PANA Client (PaC):
>
>     The PaC is the client implementation of the PANA protocol.  This
> 
>
"client implementation of PANA." Again, no need for "PANA protocol" - 
I'll stop pointing these out now.

>     entity resides on the node that is requesting network access.
>     PaCs can be end hosts, such as laptops, PDAs, cell phones, desktop
>     PCs, or routers that are connected to a network via a wired or
>     wireless interface.  A PaC is responsible for requesting network
>     access and engaging in the authentication process using the PANA
>     protocol.
>
>  PANA Authentication Agent (PAA):
>
>     The PAA is the server implementation of the PANA protocol.  A PAA
>     is in charge of interfacing with the PaCs for authenticating and
>     authorizing them for the network access service.
> 
>
OK, so now I have seen this called the "PANA Server" the "PANA 
Authentication Server" and now the "PAA is the server implementation of 
PANA?" I think I can figure all this out, but there are more terms than 
needed here, I think.

>     The PAA consults an authentication server in order to verify the
>     credentials and rights of a PaC.  If the authentication server
>     resides on the same node as the PAA, an API is sufficient for this
>     interaction.  When they are separated (a much more common case in
>     public access networks), a protocol needs to run between the two.
>     AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
>     commonly used for this purpose.
>
>     The PAA is also responsible for updating the access control state
>     (i.e., filters) depending on the creation and deletion of the
>     authorization state.  The PAA communicates the updated state to
>     the enforcement points in the network.  If the PAA and EP are
> 
>
s/enforcement points/Enforement Points (EP)

>     residing on the same node, an API is sufficient for this
>     communication.  Otherwise, a protocol is required to carry the
>     authorized client attributes from the PAA to the EP.  While not
>     prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp]
>     is suggested for this task.
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
6]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>     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.  The PAA may be one or more IP
>     hops away from the PaCs.
> 
>
I thought "BRAS" (R for Remote) was more common than BAS. I could be 
wrong, the names of these things change all the time, and I am coming 
from a DSL-centric point of view (perhaps it is different from the 
wireless angle).

>  Authentication Server (AS):
>
>     The server implementation that is in charge of verifying the
> 
>
Is this another PANA Server?

>     credentials of a PaC that is requesting the network access
>     service.  The AS receives requests from the PAA on behalf of the
>     PaCs, and responds with the result of verification together with
>     the authorization parameters (e.g., allowed bandwidth, IP
>     configuration, etc).  The AS might be hosted on the same node as
>     the PAA, on a dedicated node on the access network, or on a
>     central server somewhere in the Internet.
>
>  Enforcement Point (EP):
>
>     The access control implementation that is in charge of allowing
>     access to authorized clients while preventing access by others.
>     An EP learns the attributes of the author
>
Do you mean access to authroized clients, or access of authorized 
payloads associated with clients? I gathered that this is a *traffic* 
EP, not necessarily a client EP per se.

>ized clients from the
>     PAA.
>
>     The EP uses non-cryptographic or cryptographic filters to
>     selectively allow and discard data packets.  These filters may be
>     applied at the link-layer or the IP-layer. 
>
Are the details of how one identifies a packet for a given client is 
detailed somewhere? This is very link-specific for the link-layer, but 
for IP you should be able to suggest something - is it source IP
address?

>When cryptographic
>     access control is used, between the PaC and EP.  
>
>Link or network layer protection (for
>     example TKIP, IPsec ESP) is used after the secure association
>     protocol established the necessary security association to enable
>     integrity protection, data origin authentication, replay
>     protection and optionally confidentiality protection.
> 
>
Nit, check above sentence for grammer and length.

>     An EP must be located strategically in a local area network to
>     minimize the access of unauthorized clients to the network.  For
>     example, the EP can be hosted on the switch that is directly
>     connected to the clients in a wired network.  That way the EP can
>     drop unauthorized packets before they reach any other client node
>     or beyond the local area network.
>
>  Figure 1 illustrates these functional entities and the interfaces
>  (protocols, APIs) among them.
> 
>
It might be a good idea to specify that PANA will not define API's per 
se (in the sense of POSIX or some such).

>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
7]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>                                             RADIUS/
>                                             Diameter/
>       +-----+       PANA        +-----+     LDAP/ API    +-----+
>       | PaC |<----------------->| PAA |<---------------->| AS  |
>       +-----+                   +-----+                  +-----+
>          ^                         ^
>          |                         |
>          |         +-----+         |
>     IKE/ +-------->| EP  |<--------+ SNMP/ API
>  4-way handshake   +-----+
>
>                     Figure 1: PANA Functional Model
>
> 
>
A minor suggestion: Personally, I like to see the figure *before* the 
descriptions. It helps sequential readers to have the picture in their 
mind first.

>  Some of the entities may be co-located depending on the deployment
>  scenario.  For example, the PAA and EP would be on the same node
>  (BAS) in DSL networks.  In that case a simple API is sufficient
>  between the PAA and EP.  In small enterprise deployments the PAA and
>  AS may be hosted on the same node (access router) that eliminates the
>  need for a protocol run between the two.  The decision to co-locate
>  these entities or otherwise, and their precise location in the
>  network topology are deployment decisions.
> 
>
As "deployment decisions" are they outside the scope of this document? 
If so, state this.

In general, there are cost, security, complexity, etc. tradeoffs here. 
It would be nice to see a detail of this... The way I think I would do 
it, is to start with a combined node and state that this is the 
simplest, most secure mode of operation, but that it is also the least 
flexible. Next, split out one component, say why this might be a good 
idea (pros), and then list the negatives (cons). Then split out another 
component and do the same. In the end, you see the two extremes, 
centralized and distributed, and have a clear understanding of the range

of issues as you move from one to the other.

>  Use of IKE or IEEE 802.11i 4-way handshake protocols for secure
>  association is only required in the absence of any lower-layer
>  security prior to running PANA.  Physically secured networks (e.g.,
>  DSL) or the networks that are already cryptographically secured on
>  the link-layer prior to PANA run (e.g., cdma2000) do not require
>  additional secure association and per-packet ciphering.  These
>  networks can bind the PANA authentication and authorization to the
>  lower-layer secure channel that is already available.
> 
>
Which begs that question as to, if you already have a cryptographically 
secure connection below, why you need another layer of authentication 
above. Perhaps the answer to this is that the keys for the lower-layer 
crypto may not be owned by the users running PANA. Thus, there is not a 
1:1 association, however, the suggestion that you may bind between 
layers diminishes this claim.

>  Figure 2 illustrates the signaling flow for authorizing a client for
>  network access.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
8]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>              PaC             EP               PAA              AS
>               |               |                |                |
>  IP address ->|               |                |                |
>  config.      |       PANA    |                |      AAA       |
>               |<------------------------------>|<-------------->|
>               |               |     SNMP       |                |
>  (Optional)   |               |<-------------->|                |
>  IP address ->|               |                |                |
>  reconfig.    |   Sec.Assoc.  |                |                |
>               |<------------->|                |                |
>               |               |                |                |
>               |  Data traffic |                |                |
>               |<----------------->             |                |
>               |               |                |                |
>
>                      Figure 2: PANA Signaling Flow
>
>  The EP on the access network allows general data traffic from any
>  authorized PaC, whereas it allows only limited type of traffic (e.g.,
>  PANA, DHCP, router discovery, etc.) for the unauthorized PaCs.  This
>  ensures that the newly attached clients have the minimum access
>  service to engage in PANA and get authorized for the unlimited
>  service.
> 
>

What level of review has this received from the SNMP community?

Also, is it possible to need a NAT between the EP and PAA?

>  The PaC MUST configure an IP address prior to running PANA. 
>
The PaC cannot use DHCP to get an IP address? When I see "configure" I 
immediately think "statically configure."

>After
>  the successful PANA authentication, depending on the deployment
>  scenario the PaC MAY need to re-configure its IP address or configure
>  additional IP address(es).  The additional address configuration MAY
>  be executed as part of the secure association protocol run (e.g., via
>  IKE).
> 
>
I think you need to warn the reader what this really means. Changing an 
IP address is not something that is always seamless for a host or set of

applications. This is really verging onto the territory of multi-homing 
in general, particularly when you suggest multiple IP addresses. This 
paragraph is really leaving open a lot of possibilities, is it possible 
to constrain this?

>  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.
>
>  If the PaC is authorized to gain the access to the network, the PAA
>  also sends the PaC-specific attributes (e.g., IP address,
>  cryptographic keys, etc.) to the EP by using SNMP.  The EP uses this
> 
>
So, SNMP is now a peer to peer key negotiation protocol ;-)

>  information to alter its filters for allowing data traffic from and
>  to the PaC to pass through.
>
>  In case cryptographic access control needs to be enabled after the
>  PANA authentication, a secure association protocol runs between the
>  PaC and the EP. 
>
If you have already exchanged keys, I wonder why you need to exchange 
them again.

>The PaC should already have the input parameters to
>  this process as a result of the successful PANA exchange.  Similarly,
>  the EP should have obtained them from the PAA via SNMP.  The secure
>
>
>
>Jayaraman, et al.       Expires January 12, 2006                [Page
9]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  association protocol exchange produces the required security
>  associations between the PaC and the EP to enable cryptographic data
>  traffic protection.  Per-packet cryptographic data traffic protection
>  introduces additional per-packet overhead but the overhead exists
>  only between the PaC and EP and will not affect communications beyond
>  the EP.
>
>  Finally data traffic can start flowing from and to the newly
>  authorized PaC.
> 
>
Hasn't traffic always been flowing to and from the PaC? It seems to me 
that, "finally," filters are installed at the EP which may allow data to

flow beyond the EP to a network, and from a network through the EP to 
the PaC.

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
10]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>4.  Environments
>
>  The PANA protocol can be used on any network environment whether
>  there is a lower-layer secure channel prior to PANA, or one has to be
>  enabled upon successful PANA authentication.
> 
>
>  With regard to network access authentication two types of networks
>  need to be considered:
>
>  a. Networks where a secure channel is already available prior to
>  running PANA
>
>     This type of network is characterized by the existence of
>     protection against spoofing and eavesdropping.  Nevertheless, user
>     authentication and authorization is required for network
>     connectivity.
>
>     One example is a DSL network where the lower-layer security is
>     provided by physical means (a.1).  Physical protection of the
>     network wiring ensures that practically there is only one client
>     that can send and receive IP packets on the link.  Another example
>     is a cdma2000 network where the lower-layer security is provided
>     by means of cryptographic protection (a.2).  By the time the
>     client requests access to the network-layer services, it is
>     already authenticated and authorized for accessing the radio
>     channel, and link-layer ciphering is enabled.
>
>     The presence of a secure channel before PANA exchange eliminates
>     the need for executing a secure association protocol after PANA.
>     The PANA session can be bound to the communication channel it was
>     carried over.  
>
What do you mean by "bound to the communication channel" - do you really

mean that the security requirements of PANA are different depending on 
the assumptions implied by underlying link layer? This is different than

"bound" to me (in general, "bindings" between layers are a red flag for 
bad design, so I'm not sure you want to suggest this).

>Also, the choice of EAP authentication method
>     depends on the presence of this security during PANA run.  Use of
>     some authentication methods outside a secure channel is not
>     recommended (e.g., EAP-MD5).
>
The above sentence seems as though it would be better suited for part 
(b). I think you are suggesting that if you fully trust the lower layer 
security, using a secure EAP protocol is not necessary (that is, you 
might as well just use a clear-text password). Thus any warnings of what

NOT to use, should be in the section where you discuss not having this 
lower layer security available.

>  b. Networks where a secure channel is created after running PANA
>
>     These are the networks where there is no lower-layer protection
>     prior to running PANA.  A successful PANA authentication enables
>     generation of cryptographic keys that are used with a secure
>     association protocol to enable per-packet cryptographic
>     protection.
> 
>
>     PANA authentication is run on an insecure channel that is
>     vulnerable to eavesdropping and spoofing.  The choice of EAP
>     method must be resilient to the possible attacks associated with
>     such an environment.  Furthermore, the EAP method must be able to
>     create cryptographic keys that will later be used by the secure
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
11]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>     association protocol.
> 
>
Here's where you might suggest EAP Methods to NOT use, and it would be 
nice to even venture to suggest ones that SHOULD be used. Even better if

you can name one that MUST be implemented, so that there is at least one

method that is available on all PANA implementations.

>     Whether to use a link-layer per-packet security (b.1) or a network
>     layer security (b.2) is a deployment decision. 
>
"a deployment decision" == "outside the scope of this document" ?

>This decision also
>     dictates the choice of the secure association protocol.  If link-
>     layer protection is used, the protocol would be link-layer
>     specific.  If IP-layer protection is used, the secure association
>     protocol would be IKE and the per-packet security would be
>     provided by IPsec AH/ESP regardless of the underlying link-layer
>     technology.
> 
>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
12]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>5.  IP Address Configuration
>
>  The PaC configures an IP address before the PANA protocol exchange
> 
>
Again, does "configures" include DHCP?

>  begins.  This address is called a pre-PANA address (PRPA).  After a
>  successful authentication, the client may have to configure a post-
>  PANA address (POPA) for communication with other nodes, if the PRPA
>  is a local-use (e.g., a link-local or private address) or a
>  temporarily allocated IP address.  An operator might choose
>  allocating a POPA only after successful PANA authorization either to
>  prevent waste of premium (e.g., globally routable) IP resources until
>  the client is authorized, or to enable client identity based address
>  assignment.
>
>  In case the PaC is a IPv4/IPv6 dual-stacked node, it may configure
>  more than one PRPA.  After a successful PANA authentication the PaC
>  may configure multiple POPAs.
>
> 
>
Aha, so the reference to "multiple IP addresses" before is only in the 
case of IPv4 and IPv6 (one each)?

>  There are different methods by which a PRPA can be configured.
>
>  1. In some deployments (e.g., DSL networks) the PaC may be statically
>     configured with an IP address.  This address SHOULD be used as a
>     PRPA.
>
>  2. In IPv4, most clients attempt to configure an address dynamically
>     using DHCP [RFC2131]. 
>
Most? There are a lot configuring addresses dynamically with PPP IPCP (I

still think PPPoE is more common in the EU and Asia than DHCP since 
cable dominance is more prevalent in N.A.).

>If they are unable to configure an address
>     using DHCP, they can configure a link-local address using
>     [I-D.ietf-zeroconf-ipv4-linklocal].
>
>     When the network access provider is able to run a DHCP server on
>     the access link, the client would configure the PRPA using DHCP.
>     This address may be from a private address pool [RFC1918].  Also,
>     the lease time on the address may vary.  For example, a PRPA
>     configured solely for running PANA can have a short lease time.
>     The PRPA may be used for local-use only (i.e., only for on-link
>     communication, such as for PANA and IPsec tunneling with EP), or
>     also for ultimate end-to-end data communication.
>
>     In case there is no running DHCP server on the link, the client
>     would fall back to configuring a PRPA via zeroconfiguration
>     technique [I-D.ietf-zeroconf-ipv4-linklocal].  This yields a long-
>     term address that can only be used for on-link communication.
>
>  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.
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
13]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  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.
>
>  When a PRPA is configured, the client starts the PANA protocol
>  exchange.  By that time, a dual-stacked client might have configured
>  both an IPv4 address, and one or more IPv6 addresses as PRPAs.
> 
>
Why would one have more than one IPv6 address as a PRPA?

>  Regardless of whether the PaC has both IPv4 and IPv6 PRPAs or only
>  one of those, only one PANA run is required.  A dual-stack device
>  that implements PaC or PAA MUST be able to run PANA over both IPv4
>  and IPv6.  When a dual-stack PaC or PAA initiates PANA
>  authentication, it chooses either IPv4 or IPv6 where the choice is
>  made depending on the deployment.  A dual-stack PaC or PAA that is
>  initiated PANA authentication by its peer MUST use the same IP
>  version that the peer is using.
> 
>
Is it concievable that the PANA options for IPv6 need to be different 
than IPv4? I'm wondering if you might would rather have these run 
separately rather than one PANA session for both.

>  When the client successfully authenticates to the network, it may be
>  required to configure POPAs for its subsequent data communication
>  with the other nodes.
> 
>
And how is this done? Renegotiating IPCP (possible, but often 
impractical), a DHCP Force-renew of some sort?

>  If the client is already configured with a non-temporary address that
>  can be used with data communication, it is not required to configure
>  a POPA. 
>
"non-temporary address that can be used with data communication" don't 
you mean "globally routable" or some such here? If so, please say it. 
This phrase is almost impossible to nail down the meaning for. This 
model is particularly useful in an

>Otherwise, the PANA-Bind-Request message allows the PAA to
>  indicate the available configuration methods to the PaC.  The PaC can
>  choose one of the methods and act accordingly.
>
>  1. If the network relies on physical or link layer security, the PaC
>     can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6
>     stateless auto-configuration [RFC2461].  If IPv4 is being used, a
>     PRPA is likely to be a link-local or private address, or an
>     address with a short DHCP lease.
>
Wait, you just said that the PRPA address might be "non-temporary.." 
just above, now you are saying it is likely a short-leased address?

The way I understand it has to work is that the PRPA is either (1) 
temporary, or (2) permanent. If temporary, it must be replaced with a 
POPA. If permanent, it need not be replaced with a POPA.

Use a reference when referring to "private address"

> An IPv4 PRPA SHOULD be
>     unconfigured when the POPA is configured to prevent IPv4 address
>     selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. 
>
Does this draft talk only about unconfiguring a link-local address, or 
also unconfiguring a globally routable address (which I gather a PRPA 
MAY be)?

>If IPv6 is
>     used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484].
>
>     If the PaC is a dual-stacked node, it can configure both IPv4 and
>     IPv6 type POPAs.  The available POPA configuration methods are
>     indicated within the PANA protocol.
>
>  2. If the network uses IPsec for protecting the traffic on the link
>     subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
>     would use the PRPA as the outer address of IPsec tunnel mode SA
>     (IPsec-TOA).  The PaC also needs to configure an inner address
>     (IPsec-TIA).  There are different ways to configure an IPsec-TIA
>     which are indicated in a PANA-Bind-Request message.
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
14]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>     When an IPv4 PRPA is configured, the same address may be used as
>     both IPsec-TOA and IPsec-TIA.  In this case, a POPA is not
>     configured.  Alternatively, an IPsec-TIA can be obtained via the
>     configuration method available within [RFC3456] for IPv4, and
>     [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6.  This newly
>     configured address constitutes a POPA.  Please refer to [I-D.ietf-
>     pana-ipsec] for more details.
>
>     IKEv2 can enable configuration of one IPv4 IPsec-TIA and one IPv6
>     IPsec-TIA for the same IPsec tunnel mode SA.  Therefore, IKEv2 is
>     recommended for handling dual-stacked PaCs where single execution
>     of PANA and IKE is desired.  In this case, the same IP version
>     that has been used for PANA is used for IKE, and the IKE entity on
>     the dual-stack PaC will request one or both of IPv4 and IPv6
>     IPsec-TIAs from the IKE entity on the EP and obtain the one(s)
>     that is(are) available on the EP.
>
>  Although there are potentially a number of different ways to
>  configure a PRPA, and POPA when necessary, it should be noted that
>  the ultimate decision to use one or more of these in a deployment
>  depends on the operator.  The decision is dictated by the operator's
>  choice of per-packet protection capability (physical and link-layer
>  vs network-layer), PRPA type (local and temporary vs global and long-
>  term), and POPA configuration mechanisms available in the network.
>
> 
>
Not to mention the ability of the stack to handle an IP address 
transition. Is there a mandate by PANA that this be possible? For 
interoperability, it may be a good idea. The last think you want is a 
PANA protocol that is configuring PRPA and POPA and an IP stack that 
can't handle it (and I don't think you can avoid PPP here if you really 
want to suggest covering DSL as a use-case).

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
15]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>6.  Data Traffic Protection
>
>  Protecting data traffic of authenticated and authorized client from
>  others is another component of providing a complete secure network
>  access solution.  Authentication, integrity and replay protection of
>  data packets is needed to prevent spoofing when the underlying
>  network is not physically secured.  Encryption is needed when
>  eavesdropping is a concern in the network.
>
>  When the network is physically secured, or the link-layer ciphering
>  is already enabled prior to PANA, data traffic protection is already
>  in place.  In other cases, enabling link-layer ciphering or network-
>  layer ciphering might rely on PANA authentication.  The user and
>  network have to make sure that an appropriate EAP method which
>  generates keying materials is used.  Once the keying material is
>  available, it needs to be provided to the EP(s) for use with data
>  traffic protection.
>
>  Network-layer protection, i.e., IPsec, can be used when data traffic
>  protection is required but link-layer protection is not available.
>  Note that the keying material generated by an EAP method is
>  insufficient to be used alone by IPsec AH/ESP or most link layer
>  mechanisms.  In addition to the fresh and unique session key derived
>  from the EAP method, IPsec also needs both traffic selectors and
>  other IPsec SA parameters are missing.  The shared secret can be used
>  in conjunction with a key management protocol like IKE [RFC2409] to
>  turn a session key into the required IPsec SA.  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; link-
>  layer ciphering is enabled using any of the existing link-layer
>  specific methods.
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
16]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>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 distinguishing authenticated and
>  authorized clients from others and generating filtering information
>  for access control mechanisms.
>
>  Access control can be achieved by placing EPs (Enforcement Points) in
>  the network for policing the traffic flow.  EPs should prevent data
>  traffic from and to any unauthorized client unless it's either PANA
>  or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
>  discovery, DHCP, etc.).
>
>  When a PaC is authenticated and authorized, the PAA should notify
>  EP(s) and ask for installing filtering rules to allow the PaC to send
>  and receive data traffic.  SNMP is used between PAA and EP(s) for
>  this purpose when these entities are not co-located [I-D.ietf-pana-
>  snmp].
>
>  This section describes the possible models on the location of PAA and
>  EP, as well as the basic authorization information that needs to be
>  exchanged between PAA and EP.  When PAA and EP are not co-located in
>  a single device, there are other issues such as dead or rebooted peer
>  detection and consideration for specific authorization and accounting
>  models.  However, these issues are closely related to the PAA-EP
>  protocol solution and thus not discussed in this document.  See
>  [I-D.ietf-pana-snmp] for further discussion.
>
>7.1  PAA and EP Locations
>
>  EPs' location in the network topology should be appropriate for
>  performing access control functionality.  When the access control is
>  performed at link-layer, an IP-capable access device on the same link
>  as the client devices is the logical choice.  When IPsec-based or
>  non-cryptographic access control mechanisms are used, the EPs'
>  location can range from the first-hop router to other routers within
>  the access network.  The first-hop router may be preferred in order
>  to limit the access of unauthorized IP traffic.
>
>  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.
>
>  Since PANA allows the separation of EP and PAA, there are several
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
17]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  models depending on the number of EPs and PAAs and their locations.
>  This section describes all possible models on the placement of PAA(s)
>  and EP(s).
>
>7.1.1  Single PAA, Single EP, Co-located
> 
>

Aha, this I think is what I was asking for earlier in the document.

It occurs to me that several pages could be removed from this document 
by getting to the point here earlier.

>  This model corresponds to the legacy NAS model.
>
Is it a "BAS" a "BRAS" or "legacy NAS"

Also, believe me, the centralized BRAS model is quite alive and being 
installed in brand new DSL networks today.

> 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).
>
Earlier, you called this "API" now it is "IPC" ? Also, again, we are 
being repitious aren't we? If this section existed earlier, much earlier

discussion and background could have been eliminated I think.

> 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 link-layer switches or access points.  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 PAA, which does not
>  correspond to the legacy NAS model.  To prevent this, each PAA/EP
>  device on an link-layer switch or access point should not forward
>  multicast PANA discovery message sent by PaCs attached to it to other
>  devices.
> 
>
Is this a SHOULD or a MUST? Sounds like things may break if PAA/EP 
switches forward PANA messages, which is a serious bit of functionality 
to get right.

>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 
>
You start this section saying you are going to talk about two cases, 
when in fact you have 3 subsections, and 3 figures. This is rather 
confusing.

>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 link-layer switch or an access point (the EP also has an
>  IP stack to communicate with PAA via a PAA-EP protocol).
> 
>

Is the "PAA-EP protocol" always snmp? Why would you allow more than one 
option here?

>            +---+        +---+        +---+
>            |PaC|--------|EP |--------|PAA|
>            +---+        +---+\       +---+
>                               \
>                                +---- Internet
>
>
>                     Figure 3: PAA and EP in Serial
>
>  In the other case, PAA is located in parallel to EP.  Since the EP is
>  not on the communication path between PaC and PAA, the EP does not
>  have to configure to pass through PANA messages or address
>
> 
>
What does "in parallel" mean? No L2 connectivity between the PAA and EP?

Traffic to the Internet does not flow through the PAA (because of clever

routing perhaps?). I seem to be having to make a lot of assumptions here

to really grasp the difference between Parallel and Serial here.

If the PAA and EP are "serial" are you suggesting that some additional 
EP-like functionality may happen at the PAA? If the PAA is never acting 
on traffic beyond simple switching, I cannot see what the functional 
difference is between "serial" and "parallel" beyond, perhaps, whether 
the EP must open up a port of some sort to allow contact with the PAA in

the "serial" case, where in the "parallel" case it seems that there is 
some other separate L2 connectivity to the PAA as is implied by the 
diagram below.

>Jayaraman, et al.       Expires January 12, 2006               [Page
18]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  configuration protocol messages in this case.  This case can
>  typically happen when the EP is a router and the PAA is an
>  authentication gateway without IP routing functionality.
>
>                         +---+
>                   +-----|PAA|
>                  /      +---+
>            +---+/
>            |PaC|
>            +---+\
>                  \      +---+
>                   +-----|EP |---- Internet
>                         +---+
>
>                    Figure 4: PAA and EP in Parallel
>
>
>7.1.2.1  Single PAA, Single EP, Separated
>
>  The model benefits from separation of data traffic handling and AAA.
> 
>
That is perhaps a benefit and a curse. I'd like to see pros and cons of 
each deployment choice.

Also, what are the lines from the PaC trying to signify, two separate L2

connections?

>  The EP does not need to have a AAA protocol implementation which
>  might be updated relatively more frequently than the per-packet
>  access enforcement implementation.
> 
>
The justifications here are weak and difficult to parse. Why would it be

more difficult for an AAA server to update its code to talk to an EP vs.

a PAA?

>7.1.2.2  Single PAA, Multiple EPs
>
>  In this model, a single PAA controls multiple EPs.  The PAA may be
>  separated from any EP or co-located with a particular EP.  This model
>  might be useful where it is preferable to run a AAA protocol at a
>  single, manageable point. 
>
Do you mean, run a AAA "client" protocol from a single point? Isn't AAA 
"management" from the server side, not the client side?

It seems to me that no matter how many clients a AAA server services 
requests from, it is still a single AAA management point. All this seems

to be doing is to aggregate the control stream from EPs at the PAA 
(while translating between one control protocol (snmp?) to another 
(RADIUS or Diameter?).

>  access network that consists of a large number of access points on
>  which per-packet access enforcement is made.  When a PaC is
>  authenticated to the PAA, the PAA should install access control
>  filters on each of the EPs under control of the PAA if the PAA cannot
>  tell which EP the PaC is attached to.  Even if the PAA can tell which
>  EP the PaC is attached to, the PAA may install access control filters
>  to those EPs if the PaC is a mobile device that can roam among the
>  EPs.  Such pre-installation of filters can reduce handoff latency.
>  If different access authorization policies are applied to different
>  EPs, different filter rules for a PaC may be installed on different
>  EPs.
> 
>

So, the PAA is handling which EPs have to carry state for a specific 
user's policy (wherever he may be at a given point in the network at a 
given point in time). I can see how this could be useful in a mobile 
environment, though a fixed environment like DSL it seems to be a lot of

overhead for very little gain.

So, in general, when you point out where something might be useful, 
please provide the counterpoint. This isn't a sales brochure, you are 
expected to point out the negative aspects as well.

>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
19]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>                   +---+
>                   |EP |--+
>                   +---+   \
>                            \
>          +---+    +---+    +---+
>          |PaC|    |EP |----|PAA|
>          +---+    +---+    +---+
>                            /
>                   +---+   /
>                   |EP |--+
>                   +---+
>
> 
>
Other figures include an "internet" connection, and connections to the 
PaC. Why is that missing here?

>      Figure 5: An example model for a single PAA and multiple EPs
>
>
>7.1.2.3  Multiple PAAs
>
>  The PANA protocol allows multiple PAAs to exist on the same IP link
>  and to be visible to PaCs on the link.  PAAs may or may not be co-
>  located with EPs [I-D.ietf-pana-pana].
> 
>
Why the reference to pana-pana? It seems that this section is all about 
PAAs "co-located" or "separate" from EPs.

This section seems to be seriously lacking compared to the others - 
there isn't even a figure as is the case in other sections (though the 
in the previous section it seems the figure is incomplete).

>7.2  Notification of PaC Presence
>
>  When PAA and EP are separated and PAA is configured to be the
>  initiator of the discovery and initial handshake phase of PANA, EP
>  has the responsibility to detect presence of a new PaC and notifies
>  the PAA(s) of the presence [RFC4058].  Such a presence notification
>  is carried in a PAA-EP protocol message [I-D.ietf-pana-snmp].
> 
>
Again, is this always snmp? If so, why not just say that? Opening the 
door to too many options here just complicates deployment options, 
interoperability, etc.

Is the issue that, since SNMP is rarely used for sets in routers today, 
that you want to leave the door open to xml or cli filter config? If 
that is the case, please state it (or if I'm completely out of line, 
state that as well). You can even give the background here, that 
vendor-specific filter installation may be used as it is more commonly 
known, though a standard method such as SNMP MUST be implemented by a 
compliant PANA implementation.

>7.3  Filter Rule Installation
>
>  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.  When
>  IPsec is used the filter rules are applied to IP packets carried
>  inside the IPsec tunnel, otherwise, the filter rules are applied to
>  IP packets that are not protected with IPsec.
> 
>
The above statement needs to be reviewed by someone very knowledgable 
about IPsec. While it may be obvious to some that an IPsec stack should 
have the ability to carry "was this packet decrypted by IPsec or not" to

later processing steps, this is not always the case (and has caused a 
great deal of discussion in the past). I do not know the latest 
consensus on this, but it should be researched as I think it could have 
significant relevance here.

>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
20]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>8.  Network Selection
>
>  The network selection problem statement is made in [I-D.ietf-eap-
>  netsel-problem].  The PANA protocol [I-D.ietf-pana-pana] provides a
>  way for networks to advertise which ISPs are available and for a PaC
>  to choose one ISP from the advertised information.  When the PaC
>  chooses an ISP in the PANA protocol exchange, the ultimate
>  destination of the AAA exchange is determined based on the identity
>  of the chosen service provider.  It is also possible that the PaC
>  does not choose a specific ISP in the PANA protocol exchange.  In
>  this case, both the ISP choice and the AAA destination are determined
>  based on the PaC's identity, where the identifier may be an NAI
>  [RFC2486] or the physical port number or link-layer address of the
>  subscriber.
>
>  As described in [I-D.ietf-eap-netsel-problem], network selection is
>  not only related to AAA routing but also related to payload routing.
>  Once an ISP is chosen and the PaC is successfully authenticated and
>  authorized, the PaC is assigned an address by the ISP.
>
>  Consider a typical DSL network where the AR (access router), EP, and
>  PAA are co-located on a BAS (Broadband Access Server) in the access
>  network operated by a NAP (Network Access Provider).  Figure 6 shows
>  a typical model for ISP selection.
>
>         <---- NAP ----><--------- ISP --------->
>
>                              +---ISP1
>                             /
>        +---+    +---------+/
>        |PaC|----|AR/EP/PAA|
>        +---+    +---------+\
>                     BAS     \
>                              +---ISP2
>
>                   Figure 6: A Network Selection Model
>
>  When network selection is made at network-layer with the use of the
>  PANA protocol instead of link-layer specific authentication
>  mechanisms, the IP link between the PaC and PAA needs to exist prior
>  to doing PANA (and prior to network selection).  In this model, the
>  PRPA is either given by the NAP or a link-local address is auto-
>  configured.  After the successful authentication with the ISP, the
>  PaC may acquire an address (POPA) from the ISP.  It also learns the
>  address of the access router (AR), e.g., through DHCP, to be used as
>  its default router.  The address of the AR may or may not be in the
>  same IP subnet as that of the PaC's POPA.  Note that the physically
>  secured DSL networks do not require IPsec-based access control.
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
21]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  Therefore the PaC uses one IP address at a time where the POPA
>  replaces the PRPA upon configuration.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
22]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>9.  Authentication Method Choice
>
>  Authentication methods' capabilities and therefore applicability to
>  various environments differ among them.  Not all methods provide
>  support for mutual authentication, key derivation or distribution,
>  and DoS attack resiliency that are necessary for operating in
>  insecure networks.  Such networks might be susceptible to
>  eavesdropping and spoofing, therefore a stronger authentication
>  method needs to be used to prevent attacks on the client and the
>  network.
>
>  The authentication method choice is a function of the underlying
>  security of the network (e.g., physically secured, shared link,
>  etc.).  It is the responsibility of the user and the network operator
>  to pick the right method for authentication.  PANA carries EAP
>  regardless of the EAP method used.  It is outside the scope of PANA
>  to mandate, recommend, or limit use of any authentication methods.
> 
>
But the document does in fact do this in section 4 (comment that 
references EAP-MD5).

>  PANA cannot increase the strength of a weak authentication method to
>  make it suitable for an insecure environment.  PANA can carry these
>  EAP encapsulating methods but it does not concern itself with how
>  they achieve protection for the weak methods (i.e., their EAP method
>  payloads).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
23]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>10.  Example Cases
>
>10.1  DSL Access Network
>
>  In a DSL access network, PANA is seen applicable in the following
>  scenarios.
>
>  A typical DSL access consists of a NAS device at the DSL-access
>  provider and a DSL-modem (CPE) at the customer premises.  The CPE
>  devices support multiple modes of operation and PANA is applicable in
>  each of these modes.
> 
>
Again please get the terms "BAS," "NAS device" and "legacy NAS" 
consistent. You might look to the DSL Forum (TR-59, I believe) for 
current terminology for DSL networks. I believe "RG" is used for CPE 
here, and "BRAS" for NAS.

>  In the current DSL deployment, a DSLAM (DSL Access Multiplexor) which
>  is placed between the CPE and NAS is a transparent device from PANA
>  perspective.  In a future DSL model, the PAA may reside in the DSLAM
>  which may directly connect ISP routers through VLANs.
>
>          Host--+                                    +-------- ISP1
>                |              DSL link              |
>                +----- CPE ----- DSLAM ----- NAS ----+-------- ISP2
>                |   (Bridge/                         |
>          Host--+    NAPT/Router)                    +-------- ISP3jG
>
>        <------- customer --> <------- NAP -----> <---- ISP --->
>                 premise
>
> 
>
"jg" looks to be a typo.

>                           Figure 7: DSL Model
>
>  The devices at the customer premises have been shown as "hosts" in
>  the above network.
>
>  DSL networks are protected by physical means.  Eavesdropping and
>  spoofing attacks are prevented by keeping the unintended users
>  physically away from the network media.  Therefore, generally
>  cryptographic protection of data traffic is not necessary.
> 
>
Perhaps "not common" is a better term to use than "not necessary"

>  Nevertheless, if enhanced security is deemed necessary for any
>  reason, IPsec-based access control can be enabled on DSL networks as
>  well by using the method described in [I-D.ietf-pana-ipsec].
>
>10.1.1  Bridging Mode
>
>  In the bridging mode, the CPE acts as a simple link-layer bridge.
>  The hosts at the customer premises will function as clients to obtain
>  addresses from the NAS device by using DHCP or PPPoE.
>
>  If PPPoE is used, authentication is typically performed using CHAP or
>  MS-CHAP.
>
> 
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
24]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PANA will be applicable when the hosts use DHCP to obtain IP address.
>  DHCP does not support authentication of the devices on either side of
>  the DSL access line.  In the simplest method of address assignment,
>  the NAS will allocate the IP address to a host with a lease time
>  reasonably sufficient to complete a full PANA based authentication
>  which will be triggered immediately after the address assignment.
>  The hosts will perform the PaC function and the NAS will perform the
>  PAA, EP and AR functions.
>
>          Host--+
>          (PaC) |
>                +----- CPE ----- DSLAM ----- NAS ------------- ISP
>                |   (Bridge)             (PAA,EP,AR)
>          Host--+
>          (PaC)
>
>                          Figure 8: Bridge Mode
>
>  The DSL service provider's trunk network should not be accessible to
>  any host that has not successfully completed the PANA authentication
>  phase.
>
>10.1.2  Router Mode
>
>  In this mode, the CPE acts as a router for the customer premises
>  network.  The CPE itself may obtain the IP address using DHCP or be
>  configured with a static IP address.  Once the CPE is authenticated
>  using PANA and is provided access to the service provider's network,
>  the NAS should begin exchanging routing updates with the CPE.  All
>  devices at the customer premises will then have access to the service
>  provider's network.
>
>          Host--+
>                |
>                +----- CPE ----- DSLAM ----- NAS ------------- ISP
>                |   (Router, PaC)        (PAA,EP,AR)
>          Host--+
>
>                          Figure 9: Router Mode
>
>  It is possible that both ends of the DSL link are configured with
>  static IP addresses.  PANA-based mutual authentication of CPE and NAS
>  is desirable before data traffic is exchanged between the customer
>  premises network and the service provider network.  The CPE router
>  may also use NAPT (Network Address Port Tranlation).
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
25]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>10.1.3  PANA and Dynamic ISP Selection
>
>  In some installations, a NAS device is shared by multiple service
>  providers.  Each service provider configures the NAS with a certain
>  IP address space.
>
>  The devices at the customer premises network indicate their choice of
>  service provider and the NAS chooses the IP address from the
>  appropriate service provider's pool.  In many cases, the address is
>  assigned not by the NAS but by the AAA server that is managed fully
>  by the service provider.
>
>  This simplifies the management of the DSL access network as it is not
>  always necessary to configure each DSL access line with the service
>  provider's identity.  The service provider is chosen dynamically by
>  the CPE device.  This is typically known as "dynamic Internet Service
>  Provider selection".  The AAA function is usually overloaded to
>  perform dynamic ISP selection.
>
>  If the CPE device uses a PPP based protocol (PPP or PPPoE), the ISP
>  is chosen by mapping the username field of a CHAP response to a
>  provider.
> 
>
Also, a portion of the username (e.g., @domain) may be used, the a 
nas-port-id may be used, etc.

>  If the CPE uses DHCP, the 'client-id' field of the DHCP-discover or
>  DHCP-request packet is mapped to the provider.
> 
>
Or "option 82,"  there are multiple operational models here. I'm not 
sure why you are even detailing these here. I wonder why you are 
detailing these aspects here.

>10.1.3.1  Selection as Part of the DHCP protocol or an Attribute of DSL
>         Access Line
>
>  The ISP selection, therefore the IP address pool, can be conveyed
>  based on the DHCP protocol exchange (as explained earlier), or by
>  associating the DSL access line to the service provider before the
>  PANA authentication begins.  When any of these schemes is used, the
>  IP address used during PANA authentication (PRPA) is the ultimate IP
>  address and it does not have to be changed upon successful
>  authorization.
> 
>
OK, this seems to be a realization that the CHAP username isn't 
necessarily used, though it is now in conflict with the statements
above.

>10.1.3.2  Selection as Part of the PANA Authentication
>
>  The ISP selection of the client can be explicitly conveyed during the
>  PANA authentication. 
>
How?

>In that case, the client can be assigned a
>  temporary IP address (PRPA) prior to PANA authentication.  This IP
>  address might be obtained via DHCP with a lease reasonably long to
>  complete PANA authentication, or via the zeroconf technique
>  [I-D.ietf-zeroconf-ipv4-linklocal].  In either case, successful PANA
>  authentication signalling prompts the client to obtain a new (long
>  term) IP address via DHCP.  This new IP address (POPA) replaces the
>  previously allocated temporary IP address.
> 
>

So, two full DHCP cycles.

Most "ISP selection" deployments today are based on handoff of L2TP 
tunnels (many forced to this model by government regulation). It seems 
that this section is incomplete without covering PPP renegotiation of 
IPCP (and potentially LCP/AUTH), focusing instead on DHCP only.

>Jayaraman, et al.       Expires January 12, 2006               [Page
26]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>10.2  Wireless LAN Example
>
>  This section describes how PANA can be used on WLANs.  In most common
>  WLAN deployments the IP addresses are dynamically configured.
>  Therefore this section does not cover the scenarios where the IP
>  address is statically configured. 
>
"Most" DSL deployments are dynamic as well, this implies that this may 
not be the case. No need to address static IP address deployment here, 
but you might suggest they are "virtually nonexistant" or some such a 
bit more severe than just "Most."

>There are two models depending on
>  which layer security is bootstrapped from PANA authentication, link-
>  layer or IP-layer.  When PANA authentication is used for
>  bootstrapping IP-layer security, link-layer security is not
>  necessarily to exist even after PANA authentication.  Instead, IPsec-
> 
>
>  based data traffic protection is bootstrapped from PANA. 
>
The above two sentences are far more complicated than they need to be. I

think you are just trying to say something like:

IP-Layer security uses IPsec-based data traffic protection, bootstrapped

by PANA. When IP-Layer security is used, link-layer security is not 
necessary.

>The PAA can
>  indicate the PaC as to whether link-layer or IP-layer protection is
>  needed, by including a Protection-Capability AVP in PANA-Bind-Request
>  message. 
>
How about:

"The PAA indicates to the PaC whether IP-layer or Link-Layer protection 
is necessary via the Protection-Capability AVP in..."

>In both cases, the most common deployment would be
>  illustrated in Figure 10, where EP is typically co-located with AP
>  (access point) when PANA is used for bootstrapping link-layer
>  security or with AR when PANA is used for bootstrapping IP-layer
>  security.
> 
>
How about (if this is in fact correct - I'm simply looking for something

that will read a bit more easily):

"PANA may bootstrap either link-layer or IP-Layer security. The most 
common deployment cases are expected to be (1) a co-located EP and 
Access Point (AP) boot-strapping link-layer security, or (2) a Access 
Router (AR) co-located with a PAA (and perhaps an EP) bootstrapping 
IP-Layer security. These cases are depicted together in Figure 10."

>                       +-----+
>                       |AP/EP|----+
>                       +-----+    |
>                                  |
>          +---+        +-----+    |    +---------+
>          |PaC|        |AP/EP|----+----|AR/PAA/EP|----- Internet
>          +---+        +-----+    |    +---------+
>                                  |
>                       +-----+    |
>                       |AP/EP|----+
>                       +-----+
>
>                   Figure 10: PANA Wireless LAN Model
>
>
>10.2.1  PANA with Bootstrapping IPsec
>
>  In this model, data traffic is protected by using IPsec tunnel mode
>  SA and an IP address is used as the device identifier of the PaC (see
>  Section 5 for details).  Some or all of AP, DHCPv4 Server (including
>  PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA
>  and EP may be co-located in a single device.  EP is always co-located
>  with AR and may be co-located with PAA.  When EP and PAA are not co-
>  located, PAA-EP protocol is used for communication between PAA and
>  EP.
>
>  Note that for all of the cases described in this section, a PBR
>  (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA
>  [I-D.ietf-pana-pana] should occur after installing the authorization
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
27]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  parameter to the AR, so that IKE can be performed immediately after
>  the PANA authentication is successfully completed.  The PAA can
>  obtain the required device identifer (i.e., the IPsec-TOA in this
>  case) to be installed on the AR from the IP header of a PANA message
>  sent by the PaC before sending the PBR.  However, when the PBR/PBA
>  exchange fails, the authorization parameters already installed on the
>  AR must be immediately revoked to avoid unauthorized access.
>
>10.2.1.1  IPv4
> 
>
>  Case A: IPsec-TIA obtained by using DHCPv4
>
>     In this case, the IPsec-TIA and IPsec-TOA are the same as the
>     PRPA, and all configuration information including the IP address
> 
>

Are you using IPsec for tunneling, security, or both here? If it is for 
security alone (implied by the fact that the TIA and TOA are the same as

the PRPA) then why not use IPsec transport mode?

>is obtained by using DHCPv4 [RFC2131].  No POPA is configured.
>     Case A is the simplest compared to other ones and might be used in
>     a network where IP address depletion attack on DHCP is not a
>     significant concern.  The PRPA needs to be a routable address
>     unless NAT is performed on AR.
>
>  PaC           AP      DHCPv4 Server      PAA          EP(AR)
>   | Link-layer |             |             |             |
>   | association|             |             |             |
>   |<---------->|             |             |             |
>   |            |             |             |             |
>   |           DHCPv4         |             |             |
>   |<-----------+------------>|             |             |
>   |            |                           |             |
>   |PANA(Discovery and handshake phase      |             |
>   |     & PAR/PAN exchange in authentication             |
>   |       and authorization phase)         |             |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |                           |Authorization|
>   |            |                           |[IKE-PSK,    |
>   |            |                           | PaC-DI,     |
>   |            |                           | Session-Id] |
>   |            |                           |------------>|
>   |            |                           |             |
>   |PANA(PBR/PBA exchange in                |             |
>   |     authentication and authorization phase)          |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |            IKE            |             |
>   |<-----------+---------------------------------------->|
>   |            |                           |             |
>
>       Figure 11: An example case for configuring IPsec-TIA by using
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
28]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>                                   DHCPv4
>
>  Case B: IPsec-TIA obtained by using IKE
>
>     In this case, the PRPA is obtained by using DHCPv4 and used as the
>     IPsec-TOA.  The POPA is obtained by using IKE (via a Configuration
>     Payload exchange or equivalent) and used as the IPsec-TIA.  An
>     example sequence for Case B is shown in Figure 12.
> 
>
The difference between Figure 11 and Figure 12 seem gratuitous at best. 
I stared and stared at these until I found the one line under "IKE" as 
the difference. As a general comment, shorter is better, so you could 
probably consolidate these charts as the difference between them is not 
very significant (also, it seems odd to put fig 12 after Case C when it 
refers to case B, though this should be a moot point if you consolidate 
the charts). Also, remember that one of the ADs that will be reviewing 
this section is blind, it would help if reliance on ASCII art was
limited.

>  Case C: IPsec-TIA obtained by using RFC3456
> 
>
Please don't use RFC numbers as nouns or title describing something, use

them only as references which may be easily updated in the future.

>     Like Case B, the PRPA is obtained by using DHCPv4.  The difference
>     is that the POPA (eventually used as IPsec-TIA) and other
>     configuration parameter are configured by running DHCPv4 over a
>     special IPsec tunnel mode SA [RFC3456].  Note that the PRPA DHCPv4
>     Server and IPsec-TIA DHCPv4 Server may be co-located on the same
>     node.
>
Is it *helpful* if they are co-located? Do they *need* to be co-located?

>     Note: this case may be used only when IKEv1 is used as the IPsec
>     key management protocol (IKEv2 does not seem to support RFC3456
>     equivalent case).
> 
>
Reference for IKEv2? This is a good question for the Sec ADs as well, is

there a plan to update RFC3456 for IKEv2?

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
29]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PaC           AP      DHCPv4 Server      PAA          EP(AR)
>   | Link-layer |             |             |             |
>   | association|             |             |             |
>   |<---------->|             |             |             |
>   |            |             |             |             |
>   |           DHCPv4         |             |             |
>   |<-----------+------------>|             |             |
>   |            |             |             |             |
>   |PANA(Discovery and handshake phase      |             |
>   |     & PAR/PAN exchange in              |             |
>   |       authentication and authorization phase)        |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |                           |Authorization|
>   |            |                           |[IKE-PSK,    |
>   |            |                           | PaC-DI,     |
>   |            |                           | Session-Id] |
>   |            |                           |------------>|
>   |            |                           |             |
>   |PANA(PBR/PBA exchange in                |             |
>   |     authentication and authorization phase)          |
>   |<-----------+-------------------------->|             |
>   |            |                                         |
>   |            |         IKE                             |
>   |      (with Configuration Payload exchange)           |
>   |<-----------+---------------------------------------->|
>   |            |                           |             |
>   |            |                           |             |
>
>       Figure 12: An example case for IPsec-TIA obtained by using IKE
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
30]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PaC           AP   DHCPv4 Server         PAA
>   | Link-layer |         |                 |
>   | association|         |                 |
>   |<---------->|         |                 |
>   |            |         |                 |
>   |         DHCPv4       |                 |
>   |<-----------+-------->|                 |
>   |            |                           |
>   |PANA(Discovery and handshake phase      |
>   |     & PAR/PAN exchange in              |
>   |       authentication and authorization phase)
>   |<-----------+-------------------------->|
>   |            |                           |
>   |            |                           |          EP(AR)
>   |            |                           |            |Authorization
>   |            |                           |            |[IKE-PSK,
>   |            |                           |            | PaC-DI,
>   |            |                           |            | Session-Id]
>   |            |                           |----------->|
>   |            |                           |            |
>   |PANA(PBR/PBA exchange in authentication |            |
>   |     and authorization phase)           |            |
>   |<-----------+-------------------------->|            |
>   |            |                           |            |
>   |  IKEv1 phase I & II                                 |
>   |  (to create DHCP SA)                                |
>   |<-----------+--------------------------------------->|
>   |            |                                        |
>   |      DHCP over DHCP SA                              |
>   |<-----------+--------------------------------------->|
>   |            |                                        |
>   |  IKEv1 phase II                                     |
>   | (to create IPsec SA for data traffic)               |
>   |<-----------+--------------------------------------->|
>
>       Figure 13: An example case for configuring IPsec-TIA by using
>                                  RFC3456
> 
>

Just a question: Is it not more common for extensions to IKE to 
communicate the IP address rather than running DHCP? 

>
>10.2.1.2  IPv6
>
>  IPsec-TIA (POPA) is obtained by using IKE (via a Configuration
>  Payload exchange or equivalent).  Other configuration information may
>  be obtained in the same Configuration Payload exchange or may be
>  obtained by running an additional DHCPv6.
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
31]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PaC           AP           PAA          EP(AR)
>   | Link-layer |             |             |
>   | association|             |             |
>   |<---------->|             |             |
>   |            |             |             |
>   |            |             |             |
>   |PANA(Discovery and handshake phase      |
>   |     & PAR/PAN exchange in              |
>   |       authentication and authorization phase)
>   |<-----------+------------>|             |
>   |            |             |             |
>   |            |             |             |
>   |            |             |Authorization|
>   |            |             |[IKE-PSK,    |
>   |            |             | PaC-DI,     |
>   |            |             | Session-Id] |
>   |            |             |------------>|
>   |            |             |             |
>   |PANA(PBR/PBA exchange in  |             |
>   |     authentication and authorization phase)
>   |<-----------+------------>|             |
>   |            |                           |
>   |                   IKEv2                |
>   |  (with Configuration Payload exchange) |
>   |<-----------+-------------------------->|
>   |            |             |             |
>
>    Figure 14: An example sequence for configuring IPsec-TIA in IPv6
>
>
>10.2.2  PANA with Bootstrapping WPA/IEEE 802.11i
>
>  In this model, PANA is used for authentication and authorization, and
>  link-layer ciphering is used for access control.  Successful PANA
>  authentication enables link-layer ciphering which is based on PSK
>  (Pre-Shared Key) mode of WPA (Wi-Fi Protected Access) [WPA] or IEEE
>  802.11i [802.11i].  In this document, the key shared between a
>  station and an AP is referred to as the PMK (Pair-wise Master Key).
>  The PMK is derived from the EAP AAA-Key as a result of successful
>  PANA authentication.  In this model, MAC addresses are used as the
>  device identifiers in PANA.
>
>  This model allows the separation of PAA from EPs(APs).  A typical
>  purpose of using this model is to reduce AP management cost by
>  allowing physical separation of RADIUS/Diameter client from access
>  points, where AP management can be a significant issue when deploying
>  a large number of access points.  Additionally, this centralized AAA
>  framework enhances mobility-related performance (inter-AP but intra-
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
32]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PAA mobility does not require additional PANA executions).
>
>  By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is
>  also possible to improve wireless LAN security by providing protected
>  disconnection procedure at L3.
>
>  This model does not require any change in the current WPA and IEEE
>  802.11i specifications.  This also means that PANA doesn't provide
>  any link-layer security features beyond those already provided for in
>  WPA and IEEE 802.11i.
>
>  The IEEE 802.11 specification [802.11] allows Class 1 data frames to
>  be received in any state.  Also, IEEE 802.11i [802.11i] optionally
>  allows higher-layer data traffic to be received and processed on the
>  IEEE 802.1X Uncontrolled Ports.  This feature allows processing IP-
>  based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA)
>  on IEEE 802.1X Uncontrolled Port prior to client authentication.
>
>  Until the PaC is successfully authenticated, only a selected type of
>  IP traffic is allowed over the IEEE 802.1X Uncontrolled Port.  Any
>  other IP traffic is dropped at the AP without being forwarded to the
>  DS (Distribution System).  Upon successful PANA authentication, the
>  traffic switches to the controlled port.  Host configuration,
>  including obtaining an (potentially new) IP address, takes place on
>  this port.  Usual DHCP-based, and also in the case of IPv6 stateless
>  autoconfiguration, mechanism is available to the PaC.  After this
>  point, the rest of the IP traffic, including PANA exchanges, are
>  processed on the controlled port.
>
>  When a PaC does not have a PMK for the AP, the following procedure is
>  taken:
>
>  1.  The PaC associates with the AP.
>
>  2.  The PaC configures a PRPA by using DHCP (in the case of IPv4) or
>      configures a link-local address (in the case of IPv6), and then
>      runs PANA.
>
>  3.  Upon successful authentication, the PaC obtains a separate PMK
>      for each AP controlled by the PAA.
>
>  4.  The AP initiates IEEE 802.11i 4-way handshake to establish a PTK
>      (Pair-wise Transient Key) with the PaC, by using the PMK.
>
>  5.  The PaC obtains a POPA by using any method that the client
>      normally uses.
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
33]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>10.2.3  Capability Discovery
>
>  When a PaC is a mobile, there may be multiple APs available in its
>  vicinity.  Each AP are connected to one of the following types of
>  access networks.
>
>  a) Free access network
>
>     There is no IEEE 802.1X or PANA authentication in this access
>     network.
>
>  b) PANA-secured network
>
>     There is PANA authentication in this access network.
>
>  c) IEEE 802.1X-secured network
>
>     There is IEEE 802.1X authentication in this access network.
>
>  Type (c) is distinguished from others by checking the capability
>  information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i
>  defines RSN Information Element for this purpose).  Types (a) and (b)
>  are not distinguishable until the PaC associates with the AP, gets an
>  IP address, and engage in PANA discovery.  The default PaC behavior
>  would be to act as if this is a free network and attempt DHCP.  This
>  would be detected by the access network and trigger unsolicited PANA
>  discovery.  A type (b) network would send a PANA-Start-Request to the
>  client and block general purpose data traffic.  This helps the client
>  discover whether the network is type (a) or type (b).  Or if the PaC
>  is pre-provisioned with the information that this is a PANA enabled
>  network, it can attempt PAA discovery immediately.  The PaC behavior
>  after connecting to an AP of type (b) network is described in
>  Section 10.2, Section 10.2.1 and Section 10.2.2.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
34]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>11.  Security Considerations
>
>  Security is discussed throughout this document.  For protocol-
>  specific security considerations, refer to [I-D.ietf-pana-pana].
> 
>

My guess is that this will need to be expanded, but that advice will 
have to come from the security ADs.

>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
35]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>12.  IANA Considerations
>
>  This document has no actions for IANA.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
36]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>13.  Acknowledgments
>
>  We would like to thank Bernard Aboba, Yacine El Mghazli, Randy
>  Turner, Hannes Tschofenig and Lionel Morand for their valuable
>  comments.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
37]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>14.  References
>
>14.1  Normative References
>
>  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>             Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>  [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
>             Levkowetz, "Extensible Authentication Protocol (EAP)",
>             RFC 3748, June 2004.
>
>  [I-D.ietf-zeroconf-ipv4-linklocal]
>             Aboba, B., "Dynamic Configuration of Link-Local IPv4
>             Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in
>             progress), July 2004.
>
>  [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
>             Autoconfiguration", RFC 2462, December 1998.
>
>  [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
>             Discovery for IP Version 6 (IPv6)", RFC 2461,
>             December 1998.
>
>  [RFC3484]  Draves, R., "Default Address Selection for Internet
>             Protocol version 6 (IPv6)", RFC 3484, February 2003.
>
>  [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
>             (IKE)", RFC 2409, November 1998.
>
>  [I-D.ietf-ipsec-ikev2]
>             Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
>             draft-ietf-ipsec-ikev2-17 (work in progress),
>             October 2004.
>
>  [I-D.ietf-pana-snmp]
>             Mghazli, Y., "SNMP usage for PAA-EP interface",
>             draft-ietf-pana-snmp-04 (work in progress), July 2005.
>
>  [I-D.ietf-pana-pana]
>             Forsberg, D., "Protocol for Carrying Authentication for
>             Network Access (PANA)", draft-ietf-pana-pana-08 (work in
>             progress), May 2005.
>
>  [I-D.ietf-pana-ipsec]
>             Parthasarathy, M., "PANA Enabling IPsec based Access
>             Control", draft-ietf-pana-ipsec-06 (work in progress),
>             May 2005.
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
38]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
>             and M. Carney, "Dynamic Host Configuration Protocol for
>             IPv6 (DHCPv6)", RFC 3315, July 2003.
>
>  [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
>             RFC 2131, March 1997.
>
>  [RFC3456]  Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
>             Host Configuration Protocol (DHCPv4) Configuration of
>             IPsec Tunnel Mode", RFC 3456, January 2003.
>
>14.2  Informative References
>
>  [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
>             "Remote Authentication Dial In User Service (RADIUS)",
>             RFC 2865, June 2000.
>
>  [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
>             Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
>
>  [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
>             E. Lear, "Address Allocation for Private Internets",
>             BCP 5, RFC 1918, February 1996.
>
>  [I-D.ietf-eap-netsel-problem]
>             Arkko, J. and B. Aboba, "Network Discovery and Selection
>             Problem", draft-ietf-eap-netsel-problem-02 (work in
>             progress), October 2004.
>
>  [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
>             RFC 2486, January 1999.
>
>  [RFC4058]  Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
>             "Protocol for Carrying Authentication for Network Access
>             (PANA) Requirements", RFC 4058, May 2005.
>
>  [I-D.ietf-aaa-eap]
>             Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
>             Authentication Protocol (EAP) Application",
>             draft-ietf-aaa-eap-10 (work in progress), November 2004.
>
>  [I-D.yegin-eap-boot-rfc3118]
>             Yegin, A., Tschofenig, H., and D. Forsberg, "Bootstrapping
>             RFC3118 Delayed DHCP Authentication Using EAP-based
>             Network  Access Authentication",
>             draft-yegin-eap-boot-rfc3118-01 (work in progress),
>             January 2005.
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
39]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
>             Messages", RFC 3118, June 2001.
>
>  [DSL]      DSL Forum Architecture and Transport Working Group, "DSL
>             Forum TR-058 Multi-Service Architecture and Framework
>             Requirements", September 2003.
>
>  [802.11i]  Institute of Electrical and Electronics Engineers, "Draft
>             supplement to standard for telecommunications and
>             information exchange between systems - lan/man specific
>             requirements - part 11: Wireless medium access control
>             (mac) and physical layer (phy) specifications:
>             Specification for enhanced security", IEEE 802.11i/D10.0,
>             2004.
>
>  [802.11]   Institute of Electrical and Electronics Engineers,
>             "Information technology - telecommunications and
>             information exchange between systems - local and
>             metropolitan area networks - specific requirements part
>             11: Wireless lan medium access control (mac) and physical
>             layer (phy) specifications", IEEE Standard 802.11,
>             1999(R2003).
>
>  [WPA]      The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-
>             Fi WPA v3.1, 2004.
>
>
>Authors' Addresses
>
>  Prakash Jayaraman
>  Network Equipment Technologies, Inc.
>  6900 Paseo Padre Parkway
>  Fremont, CA  94555
>  USA
>
>  Phone: +1 510 574 2305
>  Email: prakash_jayaraman@net.com
>
>
>  Rafa Marin Lopez
>  University of Murcia
>  30071 Murcia
>  Spain
>
>  Email: rafa@dif.um.es
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
40]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  Yoshihiro Ohba
>  Toshiba America Research, Inc.
>  1 Telcordia Drive
>  Piscateway, NJ  08854
>  USA
>
>  Phone: +1 732 699 5365
>  Email: yohba@tari.toshiba.com
>
>
>  Mohan Parthasarathy
>  Nokia
>  313 Fairchild Drive
>  Mountain View, CA  94043
>  USA
>
>  Phone: +1 408 734 8820
>  Email: mohanp@sbcglobal.net
>
>
>  Alper E. Yegin
>  Samsung Advanced Institute of Technology
>  75 West Plumeria Drive
>  San Jose, CA  95134
>  USA
>
>  Phone: +1 408 544 5656
>  Email: alper.yegin@samsung.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
41]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>Appendix A.  Other Possible Cases for PANA with Bootstrapping IPsec in
>            Wireless LAN
>
>  This section describes other possible cases for PANA with
>  Bootstrapping IPsec in wireless LAN environments.
>
>Appendix A.1  IPv4
>
>  Case D: IPsec-TIA obtained by using RFC3118
> 
>

Why is this singled out in the appendix?

>     In this case, the POPA is configured and used as both IPsec-TIA
>     and IPsec-TOA.  The IPsec-TIA is assigned by using RFC3118
>     (authenticated DHCP) [RFC3118] before running IKE.  The PaC
>     unconfigures the PRPA immediately after the IPsec-TIA is obtained.
>     The DHCP-PSK needed for authenticated DHCP is distributed from the
>     PAA to the POPA DHCPv4 server by using the method specified in
>     [I-D.yegin-eap-boot-rfc3118].  The PRPA is assigned by using
>     DHCPv4 and may be assigned with a short lease period in order to
>     provide some level of robustness against IP address depletion
>     attack.  The IPsec-TIA is bound to an IPsec SA by using specifying
>     the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2
>     CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec].
>     Once the IPsec-TIA is obtained, the PUR (PANA-Update-Request) and
>     PUA (PANA-Update-Answer) exchange is performed with using the
>     obtained IPsec-TIA in order to inform the PAA of the update of the
>     IP address of the PaC.  The IKE procedure should occur after the
>     PANA-Update exchange.
>
>     Note that different DHCP servers may be used for obtaining the
>     PRPA and the POPA, when the PRPA address space and POPA address
>     space are under different administrative domains.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
42]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PaC           AP   DHCPv4 Server         PAA          EP(AR)
>   | Link-layer |          |                |             |
>   | association|          |                |             |
>   |<---------->|          |                |             |
>   |            |          |                |             |
>   |         DHCPv4        |                |             |
>   |<-----------+--------->|                |             |
>   |            |          |                |             |
>   |PANA(Discovery and handshake phase      |             |
>   |     & PAR/PAN exchange in              |             |
>   |       authentication and authorization phase)        |
>   |<-----------+-------------------------->|             |
>   |            |          |                |             |
>   |            |          |                |             |
>   |            |          |Authorization   |             |
>   |            |          |[DHCP-PSK,      |             |
>   |            |          | Session-Id]    |             |
>   |            |          |<---------------|             |
>   |            |          |                |             |
>   |PANA(PBR/PBA exchange in                |             |
>   |     authentication and authorization phase)          |
>   |<-----------+-------------------------->|             |
>   |            |          |                |             |
>   |Authenticated  DHCPv4  |                |             |
>   |      (RFC3118)        |                |             |
>   |<-----------+--------->|                |             |
>   |            |                           |             |
>   | PANA(PUR/PUA exchange in access phase based on POPA) |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |                           |Authorization|
>   |            |                           |[IKE-PSK,    |
>   |            |                           | PaC-DI,     |
>   |            |                           | Session-Id] |
>   |            |                           |------------>|
>   |            |            IKE            |             |
>   |<-----------+---------------------------------------->|
>   |            |                           |             |
>   |            |                           |             |
>
>   Figure 15: An example case for IPsec-TIA obtained by using RFC3118
>
>
>Appendix A.2  IPv6
> 
>
As above, why are these singled out into the appendix?

>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
43]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  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.
>
>     This case is not recommended since there is an ambiguity on
>     whether IPv6 Neighbor Discovery for the POPA should run on the
>     physical interface or inside the IPsec tunnel or both.
>
>  PaC           AP      DHCPv6 Server      PAA          EP(AR)
>   | Link-layer |             |             |             |
>   | association|             |             |             |
>   |<---------->|             |             |             |
>   |            |             |             |             |
>   |            DHCPv6        |             |             |
>   |<-----------+------------>|             |             |
>   |            |                           |             |
>   |PANA(Discovery and handshake phase      |             |
>   |     & PAR/PAN exchange in              |             |
>   |       authentication and authorization phase)        |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |                           |Authorization|
>   |            |                           |[IKE-PSK,    |
>   |            |                           | PaC-DI,     |
>   |            |                           | Session-Id] |
>   |            |                           |------------>|
>   |            |                           |             |
>   |PANA(PBR/PBA exchange in                |             |
>   |     authentication and authorization phase)          |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |            IKE            |             |
>   |<-----------+---------------------------------------->|
>   |            |                           |             |
>   |            |                           |             |
>
>     Figure 16: An example case for IPsec-TIA obtained by using DHCPv6
>
>  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.
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
44]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>     This case is not recommended for the same reason as Case A of
>     IPv6.
> 
>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
45]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PaC           AP                         PAA          EP(AR)
>   | Link-layer |                           |             |
>   | association|                           |             |
>   |<---------->|                           |             |
>   |            |                           |             |
>   |            |                           |             |
>   |PANA(Discovery and handshake phase      |             |
>   |     & PAR/PAN exchange in              |             |
>   |       authentication and authorization phase)        |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |            |                           |Authorization|
>   |            |                           |[IKE-PSK,    |
>   |            |                           | PaC-DI,     |
>   |            |                           | Session-Id] |
>   |            |                           |------------>|
>   |            |                           |             |
>   |PANA(PBR/PBA exchange in                |             |
>   |     authentication and authorization phase)          |
>   |<-----------+-------------------------->|             |
>   |            |                           |             |
>   |      IPv6 stateless address autoconfiguration        |
>   | (can occur at any time after association and before IKE)
>   |<-----------+---------------------------------------->|
>   |            |                           |             |
>   |            |           IKE             |             |
>   |<-----------+---------------------------------------->|
>   |            |                           |             |
>
>       Figure 17: An example sequence for IPsec-TIA obtained by using
>                  IPv6 stateless address autoconfiguration
>
>  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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
46]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>  PaC           AP      DHCPv6 Server      PAA          EP(AR)
>   | Link-layer |             |             |             |
>   | association|             |             |             |
>   |<---------->|             |             |             |
>   |            |             |             |             |
>   |            |             |             |             |
>   |PANA(Discovery and handshake phase      |             |
>   |     & PAR/PAN exchange in              |             |
>   |       authentication and authorization phase)        |
>   |<-----------+-------------------------->|             |
>   |            |             |             |             |
>   |            |             |Authorization|Authorization|
>   |            |             |[DHCP-PSK,   |[IKE-PSK,    |
>   |            |             | Session-Id] | PaC-DI,     |
>   |            |             |             | Session-Id] |
>   |            |             |<------------|------------>|
>   |            |             |             |             |
>   |PANA(PBR/PBA exchange in  |             |             |
>   |     authentication and authorization phase)          |
>   |<-----------+-------------------------->|             |
>   |            |             |             |             |
>   |   Authenticated  DHCPv6  |             |             |
>   |<-----------+------------>|             |             |
>   |            |             |             |Authorization|
>   |            |             |             | [IKE-PSK,   |
>   |            |             |             |  PaC-DI,    |
>   |            |             |             |  Session-Id]|
>   |            |             |             |------------>|
>   |            |            IKE            |             |
>   |<-----------+---------------------------------------->|
>   |            |             |             |             |
>   |            |             |             |             |
>
>       Figure 18: An example case for configuring IPsec-TIA by using
>                            authenticated DHCPv6
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
47]
>
>Internet-Draft               PANA Framework                    July
2005
>
>
>Intellectual Property Statement
>
>  The IETF takes no position regarding the validity or scope of any
>  Intellectual Property Rights or other rights that might be claimed to
>  pertain to the implementation or use of the technology described in
>  this document or the extent to which any license under such rights
>  might or might not be available; nor does it represent that it has
>  made any independent effort to identify any such rights.  Information
>  on the procedures with respect to rights in RFC documents can be
>  found in BCP 78 and BCP 79.
>
>  Copies of IPR disclosures made to the IETF Secretariat and any
>  assurances of licenses to be made available, or the result of an
>  attempt made to obtain a general license or permission for the use of
>  such proprietary rights by implementers or users of this
>  specification can be obtained from the IETF on-line IPR repository at
>  http://www.ietf.org/ipr.
>
>  The IETF invites any interested party to bring to its attention any
>  copyrights, patents or patent applications, or other proprietary
>  rights that may cover technology that may be required to implement
>  this standard.  Please address the information to the IETF at
>  ietf-ipr@ietf.org.
>
>
>Disclaimer of Validity
>
>  This document and the information contained herein are provided on an
>  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
>  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
>  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
>  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>Copyright Statement
>
>  Copyright (C) The Internet Society (2005).  This document is subject
>  to the rights, licenses and restrictions contained in BCP 78, and
>  except as set forth therein, the authors retain all their rights.
>
>
>Acknowledgment
>
>  Funding for the RFC Editor function is currently provided by the
>  Internet Society.
>
>
>
>
>Jayaraman, et al.       Expires January 12, 2006               [Page
48]
>
> 
>

----- End forwarded message -----

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana