Subject: [Pana] PANA WG last call: draft-ietf-pana-pana-06.txt

From: Alper Yegin <[email-masked]>
Date: Wed, 03 Nov 2004 10:06:01 -0800

Here is Avi Lior's WG LC comments on pana-pana-06.

Alper

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Wednesday, November 03, 2004 9:01 AM
To: 'Alper Yegin'
Subject: My Pana review

Here are my comments on pana-pana-06.
Note I did not review other comments on the list. The comments are made
in
the order that I read the document.

General comments
================

Multiple IPs per Device:

If a user-device has more then one IP address, is the intent to have 
multiple PANA sessions, one per IP address or can a PANA session support
multiple IPs.  For example, in 3GPP2 a mobile device can have several ip
addresses.

Authorization:

Authorization seems to be a big part of the document.  We even have an
authorization phase. Yet in actual fact Authorization seems to be
lacking in
PANA.

It is true that successful authentication results in authorization to
access
the network.  Yet PANA does not seem to carry any Authorization
attributes.

I think that this needs to be cleaned up.  But actually IMO it should be
possible to deliver Authorization attributes from the PAA to the PaC.
This
perhaps will be useful later on.  And if this concept was adopted then
make
sure that we can deliver authorization attributes in all phases and not
just
in the initial authentication phases.

Notification:

It seems to me that it would be useful to use PANA as a means to send
notification to the PAC. So for example, if authentication failed then
we
ought to be able to send information to the PAC as to the reason why
notification has failed.  RADIUS has a Reply-Message attribute.

But even more importantly, as is being done in 3GPP2 hot-line feature.
It
is possible that the network operator may restrict network access to the
user-device because of lack of payment or fraud.  Along with that, we
need a
notification mechanism to indicate to the user-device that we want it to
take some action such as browse to a particular web site. PANA can be
used
as this out-of-band communication channel.

Specific Comments
=================

Introduction
------------

The impression I get from the first paragraph is that all that PANA does
is
enables EAP to be transported over the IP layer.   PANA uses EAP at it's
core but PANA is much more then that no?

Suggestion: re-write the first paragraph and indicate what PANA is
really. 

Terminology
-----------

What is host device? reword the following definition:
PANA Client (PaC)

The client side of the protocol that is responsible for providing the
credentials in order to prove its identity for network access
authorization.
<><><><><>

Device Identifier (DI)
In the definition of device identifier it seems that the device
identifier
can be:
IP or link-layer address or circuit id, PPP interface id of a connected
device.
But later on in the defintion of Device-Id AVP: the device-id is
restricted
to layer-2 address or an IP address.
Is this a problem?

<><><><><>

Missing Definitions
The document uses terms such as EAP-Peer and EAP Server.
Give definitions for these or state where one can find these
definitions.

Protocol Overview
-----------------

Page 8 Change:
PANA helps PaC and PAA establish an EAP session.
To:
PANA helps the PaC and PAA establish an EAP session.

<><><><><>

Page 9 Change:
This optimization allows PaC achieve quicker authorization without
having to
run EAP upon movement (changing PAAs).
To:
This optimization allows the PaC to access the new network without
having to
reauthenticate (run EAP).

Discovery and Handshake Phase
-----------------------------

Page 10:

The PANA PAA discovery assumes that the PaC and the PAA are one hop away
from each other.

Isn't it better to say:

The PANA PAA discovery assumes that the PaC and the PAA are on the same
network segement (or subnet)
<><><><><>

Page 10:
The PAA-to-EP protocol MAY be used for this purpose.
What is the PAA-to-EP protocol? 
Need to define it somewhere and give reference to it.

<><><><><>

Page 10 Change:

By default the PaC MAY choose the PAA that sent the first
   response.
I think we need the default behavior to be stronger then MAY.
To:
By default the PaC SHOULD choose the PAA that sent the first
 response.
<><><><><>

Page: 10
A PANA-Start-Request message MAY carry a Cookie AVP that contains a
   cookie.

A PANA-Start-Request message MAY carry a Cookie AVP.

<><><><><>
Page 10:
The line:
The sequence number is set to a randomly picked initial sequence number.
Seems to be wedged between two sentence talking about the cookie and
therefore is out of place. Delete or move the line elsewhere.

<><><><><>

Page 14 Change (editorial):
   Additionally, PANA-Bind-Request MUST include a
   Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC
   about whether a new IP address MUST be configured and the available
   methods to do so.  PaC MUST include a PPAC AVP in order to indicate
   its choice of method when there is a match between the methods
   offered by the PAA and the methods available on the PaC.  When there
   is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP
   MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the
   PANA-Bind-Answer message.
to:
   Additionally, PANA-Bind-Request MUST include a
   Post-PANA-Address-Configuration AVP (PPAC AVP) ...
   
   The PaC MUST include a PPAC AVP .....  When there
   is no match, a PPAC AVP MUST NOT be included in the PANA-Bind-Answer
and
the Result-Code AVP
   MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the
   PANA-Bind-Answer message.
<><><><><>

Page 14 Change(editorial):  
  When this occurs, the PAA SHOULD send a PANA-Error-Request message to
the
   PaC with using PANA_UNABLE_TO_COMPLY result code.
to:
   When this occurs, the PAA SHOULD send a PANA-Error-Request message to
the
   PaC with PANA_UNABLE_TO_COMPLY result code.
<><><><><>

Page 14:
   
In any case, a more appropriate way is to rely on a timeout on the PaC.
   
  Explain this further.....

<><><><><>

Page 14: Change(editorial): 
   ,this PANA-Bind message exchange MUST be protected with a MAC AVP and
with carrying a
   Key-Id AVP.
to:
   ,this PANA-Bind message MUST contain the Key-Id AVP and MUST be
protected
with a MAC AVP.
   
Authorization Phase
====================

Page 15:

"PaC gains access to the network and can send and receive IP data
traffic."

Are you distinguishing between PaC and the Device here?  That is,
The PaC has access but not the other (general) application running on 
the device right?
If not, then the application can also get access to the network and that
would 
be wrong because this is the authorization phase.  Which would imply
that
the device is not yet authorized for access.

If you distinguishing between the PaC and other applications, then how
are
we distinguishing between PaC access and Application access?

<><><><><>

PANA-Ping-Request should be available at any phase after Authentication
right?
Then we should talk about that in general and not specifically tie it
down
to Authorization phase.

In fact, one can argue that PANA-Ping-Request/Answer should only be done
after authorization phase.

<><><><><>
Also note that later on in the document, we don't refer to an 
authorization phase but rather to an after authentication phase.
See section 5.5

4.4 Re-Authentication phase
===========================
Page 15:

Please mention that the PAA can initiate Re-Auth in the first paragraph.

Say "either the PaC or the PAA may initiate reauthentication."

Another problem is, its not clear how soon before the Session lifetime
expires 
should the PAA initiate re-authentication?

What happens if we start a re-authentication phase and Session lifetime 
expires?

Why not have both a session time and a reauthentication time?

5.1 Payload Encoding
====================

This section does not talk about payload encoding at all.  Please
rename this to Attribute Summary.

<><><>
Cookie AVP is a bad name for what PANA uses it for.  Normally,
one thinks of a Cookie AVP as something opaque that the Server
can pass to a client such that it is delivered back to the Server
unmodified. But more importantly, the server can put what it wants
in the cookie.

Interestingly enough, in the Cookie-AVP definition the cookie is defined
exactly like an opaque value.

So I suggest two things. Rename the cookie to something else
and also provide a Cookie attribute.  The cookie attribute can be 
usefull to the PAA for maintaining state etc.  Similar to the Class
attribute in the RADIUS.

Transport Layer
===============
Does PANA or should PANA propose a maximum packet size?

Sequence Numbers
================
Page 20:
"Retransmission maintain the same sequence number"  this is okay
providing that the retransmitted packets are all the same. Is that the
case?

<><><>
Page 20:

PANA-PAA-Discover message alway carry sequence number 0.  I assume, that
this means that it doesn't ever change right?

When wraparound happens in normal sequence numbers we should
not wrap around to zero then right?

<><><>

Page 21:

PANA MUST NOT generate EAP message duplication.

This probably applies to other applications (EAP being one but there
maybe
others)
In otherwords while the transport machinary of PANA responds to 
duplicate messages, the PaC and PAA should not act on duplicate
messages.
I think something like that should be stated in general. The EAP being
an example of that.

5.7 Error Handling
==================

Badly formed Error messages should not generate an Error-Message-Request
right?  That should be stated in the text.

<><><>

Regarding the defense against DoS attacks with a timer.  Is it that the 
receipient of an Error-Request should not have to receive more then a 
message each second?

N is configurable but wouldnt it have to be aggreed upon by both
parties?
If yes? then how is this to be done and in particular how is it to be 
done for roaming in foreign networks.

5.11 Network Selection
======================

"When a AAA backend is used, the identity of the destination AAA server 
or realm MUST be determined based on the explicitly chosen ISP."

Need to clarify that:

The AAA MUST honor the PaC selection (contained in the ISP-Information
AVP)
only if it was in the PANA-Start-Request message.

But I think it should be a SHOULD not a MUST.

There is also a race condition here.  What if at the time
of reception the choosen ISP is not available.  We should
state what the behavior is.

"  The PaC can choose an ISP and contain an
   ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message
   even when there is no ISP-Information AVP contained in the
   PANA-Start-Request message."

If the AAA does not know the ISP chosen we should state what it
should do.

The document addresses what should be done when
AAA backend is used.  What do we do if a AAA backend is not
used?  We need to be clear. Shouldn't the behavior be transparent from
the point of view of the PaC?

5.12 Separate NAP and ISP Authentication
========================================
"Currently, running multiple EAP
   sessions in sequence in an authentication phase is designed only for
   separate NAP and ISP authentication."

change to:

"Running multiple EAP
   sessions in sequence in an authentication phase is designed only for
   separate NAP and ISP authentication."

<><><>

Negotiating Separate NAP and ISP Authentication

My reading is that the PaC is the ultimate decider
of whether or not we use sepearete NAP and ISP authentication.

Shouldn't the PAA be the deciding entity?

Can the PAA refuse to authenticate if the PaC sets S-Flag to 0 in 
the answer message?  If yes, there should be a way to indicate this
decision by the PAA to the PaC.
<><><>

Page 37:

"The Sequence Number field contains a 32 bit value."
Should this be an Unsigned 32bit value?

7.3 AVP Header

Page 37:

"A number of
   zero-valued bytes are added to the end of the AVP Data field till a
   word boundary is reached."

change to:

"A number of
   zero-valued bytes are added to the end of the AVP Data field untill 
   alignment to a 32-bit boundary is reached."

<><><>
  
The length of the padding is not reflected
   in the AVP Length field [RFC3588].
   
Why is there a reference to RFC3588 here?  Remove it.

If the intent is to align with Diameter then state this
at the start of this section.

<><><>

Page 38:

AVP Length:

Add the blurb about padding here instead of at the start of section 7.3

"The AVP Length field is four octets, and indicates the number of
      octets in this AVP including the AVP Code, AVP Length, AVP Flags,
      and the AVP data."

change to:

"The AVP Length field is four octets, and indicates the number of
      octets in this AVP including the AVP Code, AVP Length, AVP Flags,
      and the AVP data and excludes any padding."

8.2 Message Specfication
========================

 Every PANA message MUST include a corresponding ABNF [RFC2234]
   specification found in [RFC3588].
   
So they are not the same right? Diameter starts with Diameter-Header
and there are other differences.  We should state the differences. 
Present the ABNF for PANA and dont leave it up to deduction.

AVPs in PANA
============

It would be useful if the Table in this section listed 
the AVP codes as well.

Otherwise we have to dig in the document to find out the code for the
AVPs.

8.3.1  MAC AVP

The payload must be aligned to a 32 bit boundary.  So it can be padded
yes?  So is MAC AVP of type OctetString?

8.3.4  Cookie AVP

   The Cookie AVP (AVP Code 4) is of type OctetString.  The data is
   opaque and the exact content is outside the scope of this protocol.

Not true.  I wish it was true. The content is may not be specified in
the
document
by how the cookie is to be used is specified.  I can't just put anything
in
the cookie right?

I think we need to be more descriptive of what the cookie is used for.

Protection-Capability AVP
=========================

Why is this value not an Enumeration?

Result-Code AVP
===============
Why is the Result-Code AVP not of type Enumeration?

8.3.18  IP-Address AVP

   The IP-Address (AVP Code 18) contains an IP address of n a PaC or
   PAA.
   
fix typo:

The IP-Address (AVP Code 18) contains an IP address of the PaC or
   PAA. 
   
PANA Protocol Message Retransmissions
=====================================

How does this relate to RFC2988 and congestion control.
(As mentioned on bottom of page 20)

2988 requires that we measure the response of the network and
make adjustements accordingly.  Unless I am missing something
we are not doing this here and neither is RFC3315.

So how is this "shaping" to network congestion?

Take a look at RFC3748 4.3 Retransmission Behavior for an example on how
to
do this.

-----------------------------
Avi Lior
Bridgewater Systems Corp.
Phone: 613.591.9104 x 6417
Cell   : 613.297.2177

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 05 Nov 2004 15:34:28 -0800

Let me take a stab at Avi's comments.
I'll just respond to those that require an answer or discussion. 

> General comments

When device ID is L2 address or some local identifier (e.g., PPP
interface number), any IP address can be used with the session. If the
DI is an IP address (the case with IPsec-based access control), then any
IP address configured inside the tunnel is OK. So, multiple IP addresses
per PANA session can be used... You don't need to run PANA "per IP
address".
 
> as this out-of-band communication channel.

The design has messages to convey failed authentication, or asynchronous
termination, but not a general purpose "notification". I see this can be
useful. What do others think?

> Authorization Phase

Sorry for the confusing. We didn't mean to differentiate PaC
implementation from other applications running on the host. The term
"authorization phase" is the culprit, imo. We just wanted to refer to
the state where the PaC is "already authorized" and allowed send/receive
general purpose data packets.

> Why not have both a session time and a reauthentication time?

We are leaving the decision (how soon to start re-auth) to deployments.
This is because it is hard to suggest something and this does not impact
interoperability. (you are right about the operational impact of picking
the right value).

> exactly like an opaque value.

Sorry, I didn't quite understand the difference. Are you suggesting we
rename the AVP to something like Cookie-Carrying-AVP and keep the same
format? Yes, the data field carries the "cookie value".

> Transport Layer

I think this is limited by max. UDP payload. We can state that.

> Sequence Numbers

Yes. We can state that.

> not wrap around to zero then right?

Hmmmm... I think we don't need that. Seq. no 0 does not have any
significance to the protocol processing. Discovery implies seq 0, but
seq 0 does not necessarily imply discovery.

> receipient of an Error-Request should not have to receive more then a

The DoS protection is for the peer that is forced to generate PANA-Error
messages due to receipt of faulty messages (likely tools of attack). So,
it is not the recipient of the error message, but the generator of the
error message.

> the point of view of the PaC?

Yes. We shall state that.

> of whether or not we use sepearete NAP and ISP authentication.

.... given that this option is presented by the PAA.

> Shouldn't the PAA be the deciding entity?

First PAA has to offer this. Only after than the PaC has an option
(separate vs. single authentication).

> decision by the PAA to the PaC.

Hmmm. I never thought that the PAA may want to mandate separate
authentication. What do you/others think? If this is a useful/practical
scenario, we may need to add one more bit (like Mandatory/Optional).

> 8.2 Message Specfication

We shall ask Dan Forsberg to take a look at this.

> by how the cookie is to be used is specified.  I can't just put
anything

I think you can.....

> PANA Protocol Message Retransmissions

I think you are right. Although we are referring to RFC2988, we are not
doing what it suggests. But we are exponentially backing off. I wonder
if this is sufficient. Note that typically TCP and EAP run across
Internet, whereas DHCP and PANA run on-link. Maybe that difference is
the lead cause of simplified retransmission mechanism with DHCP, IPv6
Neighbor Discovery, etc. Maybe someone who is more knowledgeable on the
congestion control can comment on this.

Thank you Avi.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Nov 2004 03:38:45 -0500

Hi Avi and Alper,

My comments to specific issues:

> useful. What do others think?

I think having information exchange specialized for notification is
useful.

> scenario, we may need to add one more bit (like Mandatory/Optional).

I don't know whether this is useful/practical, but it would be easy to
modify the specification to support the case.  I don't mind adding
such functionality.

Regards,
Yoshihiro Ohba