Document: draft-ietf-pana-pana-15 Reviewer: Spencer Dawkins Review Date: 2007-6-14 IETF LC End Date: 2007-06-07 (my bad) IESG Telechat date: 2007-06-21 Summary: This document is almost ready for publication as a Proposed Standard. I do have some questions, but almost all involve either clarifications beyond nits or 2119 language. In general, this document is well-written, clean, and accessible for a non-specialist to understand. Note: 1st LC review of -11 included at the end (search for ====) Comments OBTW, Alper's e-mail address seems to have changed since the draft was submitted... 2. Terminology Enforcement Point (EP): A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of access devices. The EP and the PAA may be co-located. EPs should prevent data traffic from and to any unauthorized client unless it's either PANA or one of the other allowed traffic types (e.g., Spencer (nit): c/it's/that data traffic is/ ARP, IPv6 neighbor discovery, DHCP, etc.) 4.1. Authentication and Authorization Phase The PAA SHOULD limit the rate it processes incoming PANA-Client- Initiation messages to provide robustness against denial-of service (DoS) attacks. Details of rate limiting are outside the scope of this specification. Spencer: Two concerns here - why is this a SHOULD, instead of a MUST (why would you NOT do this?), but more importantly, I'm not sure how you normatively require PAAs to do something that isn't described (how would you know if the PAA is not doing this?) Actually, I'm also not entirely sure how this would provide robustness against denial-of-service attacks, either, now that I'm thinking of it (I tend to visualize DoS attacks as "packet spraying", and DDoS botnets are certainly capable of overrunning almost any single receiver. If the PAA wants to stay stateless in response to a PANA-Client-Initiation message, it SHOULD NOT include an EAP-Payload AVP in the initial PANA-Auth-Request message, and it SHOULD NOT re- Spencer: both of these SHOULDs seem odd - aren't you just saying "if you want to be stateless, here's how that works"? instead of normative language... transmit the message on a timer. For this reason, the PaC MUST retransmit the PANA-Client-Initiation message until it receives the second PANA-Auth-Request message (not a retransmission of the initial one) from the PAA. It is possible that both the PAA and the PaC initiate the PANA session at the same time, i.e., the PAA unsolicitedly sends the initial PANA-Auth-Request message while the PaC sends a PANA-Client-Initiation message. To resolve the race condition, the PAA SHOULD silently discard the PANA-Client-Initiation message Spencer: this SHOULD seems odd. Why not a MUST - simply because you could process the PANA-Client-Initiation message and end up with at least one SA? Or is there something else going on? received from the PaC after it has sent the initial PANA-Auth-Request message. The PAA uses the source IP address and the source port number of the PANA-Client-Initiation message to identify the PaC among multiple PANA-Client-Initiation messages sent from different PaCs. 4.2. Access Phase Once the authentication and authorization phase successfully completes, the PaC gains access to the network and can send and receive IP data traffic through the EP(s) and the PANA session enters the access phase. In this phase, PANA-Notification-Request and PANA-Notification-Answer messages with 'P' (Ping) bit set (ping request and ping answer messages, respectively) can be used for testing the liveness of the PANA session on the PANA peer. Both the PaC and the PAA are allowed to send a ping request to the communicating peer whenever they need to make sure the availability Spencer (nit): /need to make sure/need to ensure/ of the session on the peer and expect the peer to return a ping answer message. The ping request and answer messages MUST be protected with an AUTH AVP when a PANA SA is available. A ping request MUST NOT be sent in the authentication and authorization phase, re-authentication phase and termination phase. 4.3. Re-authentication Phase When the PaC initiates re-authentication, it sends a PANA-Notification-Request message with 'A' bit set (a Spencer (nit): there are places in the text where the bit identifier is immediately expanded, and places where it is not, but I'm not sure from this sentence whether the 'A' bit determines whether the message is a re-authentication request message or not. If this could be a bit clearer, that would be great. If you make sure that all the bit identifiers are expanded, that would be great, too. I find the format "the 'R' (Request) bit" to be the most usable format for the expansion. re-authentication request message) to the PAA. This message MUST contain the session identifier assigned to the session being re-authenticated. If the PAA already has an established PANA session for the PaC with the matching session identifier, it MUST first respond with a PANA-Notification-Answer message with 'A' bit set (a re-authentication answer message), followed by a PANA-Auth-Request message that starts a new EAP authentication. If the PAA cannot identify the session, it MUST silently discard the message. The first PANA-Auth-Request and PANA-Auth-Answer messages in the re-authentication phase MUST have 'S' bit cleared and carry a Nonce AVP. 6.2. PANA Message Header Message Type The Message Type field is two octets, and is used in order to communicate the message type with the message. The 16-bit address Spencer: message type space? This isn't an address, is it? space is managed by IANA [ianaweb]. 7. PANA Messages Every PANA message defined MUST include a corresponding ABNF Spencer: this is probably not a 2119 MUST, I think. [RFC2234] specification, which is used to define the AVPs that MUST or MAY be present. The following format is used in the definition: Spencer: This shouldn't be 2119 language. Aren't you saying "define the AVPs for that PANA message type, and whether or not each AVP is Mandatory", or something like that? 8.5. Nonce AVP The length of the nonces are determined based on the available pseudo-random functions (PRFs) and the degree of trust placed into the two PaC and the PAA to compute random values. The length of the random value for the nonce is determined whether Spencer (nit): determined in one of two ways, depending on whether 1. The PaC and the PAA each are likely to be able to compute a random nonce (according to [RFC4086]). The length of the nonce has to be 1/2 the length of the PRF key (e.g., 10 octets in the case of HMAC-SHA1). 2. The PaC and the PAA each are not trusted with regard to the computation of a random nonce (according to [RFC4086]). The length of the nonce has to have the full length of the PRF key (e.g., 20 octets in the case of HMAC-SHA1). 8.6. Result-Code AVP PANA_AUTHENTICATION_REJECTED 1 Authentication has failed. When this error is returned, it is assumed that authorization is automatically failed. Spencer: this is not entirely clear to me. Is it saying "the requestor can assume that authorization has also failed"? which still seems odd to me - if you're not the entity you claim to be, how could this not be true? Mumble. 9. Retransmission Timers RT for each subsequent message transmission is based on the previous Spencer: is this "message retransmission"? If so, that might be clearer. value of RT: RT = 2*RTprev + RAND*RTprev 10.2. PANA Message Header As defined in Section 6.2, the PANA message header contains two Spencer: this sentence just LOOKS wrong ("two", but looks like three fields) - if it's off by one, that's a nit, but if it's not, it's more than a nit... fields that requires IANA namespace management; the Version, Message Type and Flags fields. 10.2.2. Message Type The Message Type namespace is used to identify PANA messages. Values 0-65,519 are for permanent, standard message types, allocated by IETF Consensus [IANA]. This document defines the Message Types 1-4. See Section 7.1 through Section 7.7 for the assignment of the namespace in this specification. The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are Spencer: is this two values, or a range of values? I'm confused by "and" versus "-". Shouldn't these two clauses match? reserved for experimental messages. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between the communicating PaC and PAA using experimental commands, as outlined in [IANA-EXP]. 10.3.1. AVP Code AVPs may be allocated following Designated Expert with Specification Spencer: is this "Designated Expert Review"? Not sure if this is a nit or not... Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be allocated by Standards Action. 11. Security Considerations An important element in assessing security of PANA design and deployment in a network is the presence of lower-layer (physical and link-layer) security. In the context of this document, lower-layers are said to be secure if they can prevent eavesdropping and spoofing of packets. Examples of such networks are physically-secured DSL networks and 3GPP2 networks with cryptographically-secured cdma2000 link-layer. In these examples, the lower-layer security is enabled even before running the first PANA-based authentication. In the absence of such a pre-established secure channel, one needs to be created in conjunction with PANA using a link-layer or network-layer cryptographic mechanism (e.g., IPsec). Spencer: is this saying that you expect people to be able to set up an SA before they start doing PANA? Does that seem realistic? ================================================================================== 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.