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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 Apr 2006 10:43:40 -0500

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.

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.

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.

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.

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

   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.

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.

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.

   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.

   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. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Alper Yegin <[email-masked]>
Date: Wed, 05 Apr 2006 18:15:30 +0300

Thank you Spencer and David for this very valuable review and comments! This
is extremely useful.

The authors will be working on the documents to reflect your input.

- PANA WG chairs