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