Draft: draft-ietf-pana-pana-11 Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Monday 4/3/2006 10:44 AM CST IETF LC Date: 4/1/2006 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.