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

From: Avi Lior <[email-masked]>
Date: Mon, 8 Nov 2004 13:43:28 -0500

Thanks Alper,

See comments inline.

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Friday, November 05, 2004 6:34 PM
> To: [email-masked]
> Cc: 'Avi Lior'
> Subject: RE: [Pana] PANA WG last call: draft-ietf-pana-pana-06.txt
> 
> 
> Let me take a stab at Avi's comments.
> I'll just respond to those that require an answer or discussion. 
> 
> > 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.
> 
> 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".

Okay.  I don't remember if this is clear in the text.
I wonder how this would work for 3GPP2 when we move to PPP free operations.
What device id would I use to make sure I don't have to run PANA more then
once per device?

> > 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.
> 
> 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?

Okay. 
 
> > 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?
> 
> 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.

I see lots of messages on this topic so hopefully this will get resolved.
IMO there is no authorization phase. Authorization is built into a
successful authentication.
 
> 
> > 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?
> 
> 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).

Okay. 
> 
> > <><><>
> > 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.
> 
> 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".

Sorry for not being clear.
There are several issues with this attribute.

First, the definition of the Cookie-AVP and the earlier description of what
is in the cookie are not in synch in PANA-06. 
Section 4.1 defines that this cookie is used for prevention of DoS attacks.
And it suggests what should go in the cookie.

In section 5.1 It states
" Cookie AVP: contains a random value that is used for making
      handshake robust against blind resource consumption DoS attacks." 

In section 8.3.4 It states,
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.

I think that section 8.3.4 should be more descriptive about the purpose of
this attribute so that it lines up with the real intent as described in
section 4.1 and 5.1.

Second, cookies usually refers to something that a server (PAA) can put in
the client (PaC) that the server wishes to receive back in subsequent
interactions. They are very generic. But in PANA they use of a cookie plays
a very distictive role.  Why not give that AVP a better name.

> > 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?
> 
> I think this is limited by max. UDP payload. We can state that.

OKAY.

> > 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?
> 
> Yes. We can state that.

OKAY.
 
> > <><><>
> > 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?
> 
> 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.

OKAY.
 
> > <><><>
> > 
> > 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?
> 
> 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.
>  
> > 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.
> 
> 
> > 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?
> 
> Yes. We shall state that.

OKAY

> > 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.
> 
> .... 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).
> 
> > 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.
> 
> 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).

Lets see what happens....
> 
> > 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.
> 
> We shall ask Dan Forsberg to take a look at this.

OKAY
> > 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 you can.....
> 
> > 
> > I think we need to be more descriptive of what the cookie 
> is used for.
> > 
> 
> > 
> > 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.
> 
> 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
> 
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 Nov 2004 10:07:58 -0500

Hi Avi, 

I have just a few comments.

> > "notification". I see this can be useful. What do others think?

You mentioned about PAA-to-PaC notification.  But I think PaC-to-PAA
notification could also be defined.  What do you think?

> this attribute so that it lines up with the real intent as described in

I agree.  Section 8.3.4 shoule be more descriptive as such.

> a very distictive role.  Why not give that AVP a better name.

Note that IKEv2 also uses the term "cookie" for the exchange used 
for the same purpose as PANA cookie.  

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Nov 2004 17:15:24 -0800

Hi Avi,

> What device id would I use to make sure I don't have to run PANA more
then

Per section 5.8, if the L2 design has MAC addresses, they should be used
as DIs. If not, some locally significant identifier is needed (e.g.,
interface id). Such locally significant IDs are carried neither in
packet headers nor in PANA payloads (i.e., no Device ID AVP).
Implementation retrieves them from lower-layers.

Alper