Subject: [Pana] Re: Gen-ART Review of draft-ietf-pana-pana-11

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 03 May 2006 17:46:22 -0400

Hello Spencer Dawkins,

Thank you for revewing the PANA specification draft and sorry for 
delayed response.

Please see my comments in line.

On Mon, Apr 03, 2006 at 10:43:40AM -0500, Spencer Dawkins wrote:
> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Summary: This document is almost ready for publication as a Proposed 
> Standard. It is clearly written and complete in most sections. I do have a 
> small number of questions, listed below.
> 
> This document was very clear. A small number of editorial comments (not 
> part of the Gen-ART review for Brian) are flagged separately. I hope they 
> are useful.
> 
> Thanks,
> 
> Spencer
> 
> 4.2.  Payload Encoding
> 
> Spencer (Editorial): This section is extremely useful, but it's not about 
> "payload encoding" - more like "high-level Attribute-Value Pair 
> description". I'd change the section title for clarity.

I agree.  We will change the section title accordingly.

> 
> 4.3.  Discovery and Handshake Phase
> 
> Spencer: I don't believe this MUST is a 2119 MUST - I'd shift it to lower 
> case.
> 
>   When the PaC knows the IP address of the PAA, it can send a unicast
>   PANA-PAA-Discover message and initiate the PANA exchange.  In other
>   cases, the PaC MUST rely on dynamic discovery methods, such as
>   multicast-based and a traffic-driven discovery.

I agree.  We will change it to lower case.

> 
> Spencer: the following paragraph seems strange. (1) I don't believe that 
> the MAY is a 2119 MAY, and (2) it may be clearer if the last sentence is 
> simply deleted (if I understand the paragraph so far, it's saying "the PaC 
> needs to choose some PAA, and if multiple PAAs are available, any of them 
> should provide the same authentication and authorization result". Is there 
> any reason the PaC would NOT choose the PAA that sent the first 
> PANA-Start-Request message?).
> 
>   There can be multiple PAAs in the access network and the PaC may
>   receive multiple PANA-Start-Request messages from those PAAs.  The
>   authentication and authorization result does not depend on which PAA
>   is chosen by the PaC.  By default the PaC MAY choose the PAA that
>   sent the first PANA-Start-Request message.

I agree.  The last sentence can simply be deleted without any harm.

> 
> Spencer (Editorial): Later in the document (in Section 8.3), text on the 
> following point also refers to Section 4.3 for an example stateless 
> discovery agorithm. It would be nice to have the same reference in this 
> paragraph, as "hence is not specified here. See Section 4.3 for one 
> algorithm that satisfies this requirement".
> 
>   A PANA-Start-Request message MAY carry a Cookie AVP that contains a
>   random value generated by the PAA.  The random value is referred to
>   as a cookie.  The cookie is used for preventing the PAA from resource
>   consumption DoS attacks by blind attackers which bombard the PAA with
>   PANA-PAA-Discover messages.  By relying on a cookie mechanism the PAA
>   can avoid per-PaC state creation until after the PaC can produce the
>   same cookie in its PANA-Start-Answer message.  In order to do that,
>   the cookie MUST be computed in such a way that it does not require
>   any per-session state maintenance on the PAA in order to verify the
>   cookie returned in the PANA-Start-Answer message.  The PAA discovery
>   that takes advantage of cookies is called "stateless PAA discovery".
>   The exact algorithms and syntax used by the PAA to generate cookies
>   does not affect interoperability and hence is not specified here.
>   Additionally, the PAA MAY limit the rate it processes incoming PANA-
>   PAA-Discover messages.

The last sentence of Section 8.3 quoted below is a leftover of older
version of the document which had an example cookie generation
algorithm that was removed now.  I think we can simply delete the last
sentence of Section 8.3.

"
8.3.  Cookie AVP

   The Cookie AVP (AVP Code 3) is used for carrying a random value
   generated by the PAA according to [RFC4086].  The AVP data is of type
   OctetString.  The random value is referred to as a cookie and used
   for making PAA discovery robust against blind resource consumption
   DoS attacks.  The exact algorithms and syntax used by the PAA to
   generate a cookie does not affect interoperability and not specified
   in this document.  An example cookie generation algorithm is shown in
   Section 4.3.
"

> 
> Spencer: I was slightly confused by the following paragraph, because it 
> seems that any modern protocol would use stateless discovery for greater 
> resistence to DOS attacks, as PANA does, but PANA then allows a 
> state-creating EAP Request to be included in a PANA-Start-Request message 
> with forged source destination addresses, etc. 

This is because stateless PAA discovery with cookie is an optional
feature.  This is similar to how cookie mechanism is optional in
IKEv2.  My personal opinion is, as long as the PAA does not find
something strange that makes its resource usage unreasonably high in a
short period, stateless PAA discovery can be turned off.

> I also did not see a 
> description of how a PAA would tell a PaC "stateless discovery is required, 
> and you didn't set the L bit, so you're not doing stateless discovery" - is 
> there text for this that I missed? Mumble.

There are some text on this, for example, 

in Section 4.3:

"
   The PaC can determine whether the PAA is using stateless PAA discovery by
   looking at the L-flag in the PANA header.  The PANA-Start-Request
   message MUST be retransmitted instead of the PANA-Start-Answer
   message when stateful PAA discovery is used (L-flag is not set).
"

in Section 6.2:

"
      L(stateLess discovery)

         When the L-flag is set in a PANA-Start-Request message it
         indicates that the PAA is performing stateless discovery.
         Cookie AVP MUST be included in both the PANA-Start-Request and
         the PANA-Start-Answer messages when performing stateless
         discovery.
"

> 
>   The initial EAP Request message MAY be optionally carried by the
>   PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
>   message in order to reduce the number of round-trips.  This
>   optimization SHOULD NOT be used if the PAA discovery is desired to be
>   stateless since transmission of an EAP Request message creates a
>   state at EAP layer.  See [RFC4137] for more information on the EAP
>   state machine and the allocation of state information in the
>   respective protocol steps.
> 
> 5.2.  Sequence Number and Retransmission
> 
> Spencer: If the retransmission timer calculation is a SHOULD, some guidance 
> about when to use different timer calculations needs to be given ("why is 
> this not a MUST?"). At the very least, these retransmission timers (as 
> computed in these documents) are specified to include a randomization 
> factor to prevent sustained synchronization - I'm assuming that any 
> alternative method chosen should include a randomization factor, but it 
> would be good to provide explicit guidance.
> 
>   The retransmission timers SHOULD be calculated as described in
>   [RFC2988] to provide congestion control.  See Section 9 for default
>   timer and maximum retransmission count parameters.

I don't come up with a special circumstance where different timer
calculation algorithms are used.  We can simply make it a MUST if
there is no objection.

> 
> 5.8.  PaC Updating its IP Address
> 
> Spencer (Editorial): There are a couple of places in this specification 
> (including the following paragraph) that refer to IKE generically. Most 
> references are to IKEv2. If these could be consistent, that would be 
> helpful. (David Black pointed out the same comment on the PANA framework 
> draft).
> 
>   If the device identifier of the PaC is the IP address, it is also
>   subject to the same change.  The PAA needs to be notified about the
>   change of device identifier as well so that the PAA can update the
>   EP(s).  If IPsec is used between the PaC and the EPs, an IKE or
>   MOBIKE [I-D.ietf-mobike-protocol] run is needed following such a
>   change.

I went through the document.  All references to IKEv2 in the PANA
specification document is specific to IKEv2.  Only the above mentioned
usage of the term "IKE" is common to both IKEv1 and IKEv2.  So my
suggestion is to revise the above text to explicitly mention both
IKEv1 (RFC 2409) and IKEv2 (RFC 4306).

> 
> 5.9.  Session Lifetime
> 
> Spencer: In the following paragraph, a PANA peer is actually using the 
> PANA-ping to verify the DEADNESS of a peer before taking action. And, 
> again, this is a SHOULD. Why is it not a MUST ("when is it OK to just 
> decide that a peer is dead?" In context, I'm guessing that the statement is 
> "A PANA peer SHOULD use the PANA-Ping message exchange to verify that a 
> peer is, in fact, no longer alive, unless information obtained outside PANA 
> is being used to expedite the detection of a disconnected peer". But I'm 
> guessing.

I think this SHOULD should not be a MUST, and your text looks better
than the current one as it explains other alternatives for liveness
test.  We will revise the paragraph to replace the current text with
your text above.

> 
>   The PaC and the PAA MAY use information obtained outside PANA (e.g.,
>   lower-layer indications) to expedite the detection of a disconnected
>   peer.  Availability and reliability of such indications MAY depend on
>   a specific link layer or network topology and are therefore only
>   hints.  A PANA peer SHOULD use the PANA-Ping message exchange to
>   verify the liveness of a peer before taking an action.
> 
> 5.10.  Network Selection
> 
> Spencer (Editorial): it would be clearer to use consistent phrasing in this 
> paragraph. Suggest "need not use the alternative ISP discovery mechanism" 
> in the last sentence.

I agree.

> 
>   An alternative ISP discovery mechanism is outlined in [RFC4284] which
>   suggests advertising ISP information in-band with the ongoing EAP
>   method execution.  Deployments using the PANA's built-in ISP
>   discovery mechanism need not use the other mechanism. 
> 

Best regads,
Yoshihiro Ohba

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

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 7 May 2006 14:15:25 +0300

> calculation algorithms are used.  We can simply make it a MUST if

A given deployment may take into account things like the link
characteristics (radio behavior) and choose to have its own retransmission
timers -- possibly more optimized. In order to leave the door open to such
enhancements, I think it is best if we don't mandate retransmission timers.

Alper