Adding sequence number to PANA for carrying EAP April 26, 2004 Note: The contents were originally described in an appendix of PANA specification draft and moved here as the resolution of PANA issue 80 (http://danforsberg.info:8080/pana-issues/issue80). 1 Why is sequence number needed for PANA to carry EAP? EAP requires underlying transports to provide ordered-delivery of messages. If an underlying transport does not satisfy the ordering requirement, the following situation could happen: EAP Peer EAP Authenticator -------------------------------------------- 1. (got req 1) <------- Request ID=1 2. Response ID=1 ---+ | (timeout) 3. | +-- Request ID=1 | | +-|--> (got resp 1) 4. (got req 2) <----|-- Request ID=2 | 5. Response ID=2 -----|--> (got resp 2) | 6. (got req 1) <----+ 7. Response ID=1 --------> [discarded due to unexpected ID] Figure 1: Undesirable scenario In Figure 1, the second EAP Request message with Identifier=1 arrives at the EAP peer after the third EAP Request message with Identifier=2. As a result, the EAP peer accepts the second EAP Request as a new EAP Request while it is just an old EAP Request that was already responded and the authentication might be totally messed up. This problem occurs due to the fact that EAP doesn't recognize duplicate packets in the scope of one EAP protocol run, but only in the scope of current and previous packet (i.e., request and response message matching). When EAP is running over PPP or IEEE 802 links, this is not a problem, because those link-layers have the ordering invariant characteristic. On the other hand, the PANA design has chosen UDP as its transport. Given that UDP does not provide ordered delivery of packets and PANA does not assume any specific link-layer technology to carry EAP, PANA messages need to have a sequence number. In the following text we describe two possible approaches for sequence number handling in PANA. The first one makes use of a single sequence number whereas the latter utilizes two. Finally a comparison between the two approaches is provided. The method described in section 3.1 (i.e., the dual sequence number with orderly-delivery method) is suggested as the preferred method for PANA transport. 2 Single sequence number approach This section discusses several methods based on using a single sequence number for providing orderly message delivery. Sequence number handling for all methods discussed in section 2 must comply to the following rules: Rule 1: The sequence number starts from initial sequence number (ISN) and is monotonically increased by 1. The arithmetic defined in RFC 1982 is used for sequence number operation. Rule 2: When a PAA sends an EAP message passed from EAP layer to a PaC, a new sequence number is placed in the message, regardless of whether it is sent as a result of a retransmission at the EAP layer or not. Note: It might be possible to define other mechanisms for sequence number handling if it can be assumed that a PAA detects EAP retransmissions. However, such an assumption heavily depends on EAP implementation details in particular on EAP APIs, thus it was decided not to use such an assumption. 2.1 Single sequence number with EAP retransmission method Again, the following rules must hold: Rule 3: Use EAP layer retransmission for retransmitting EAP messages (based on a timer expiration). Rule 4: When the PaC receives a message from the PAA, it checks the sequence number and discards the message if the sequence number is not greater than that of the last accepted message. Rule 5: When the PAA receives a message from the PaC, it checks the sequence number and discards the message if the sequence number does not match a pending request message. PaC PAA Seq# Message -------------------------------------------- 1. <------- (x) PANA-Auth-Request[EAP Req ID=1] 2. ---+ (x) PANA-Auth-Answer[EAP Res ID=1] | (retransmission timeout at EAP-layer) 3. | +-- (x+1) PANA-Auth-Request[EAP Req ID=1] | | +-|--> (discarded due to Rule 5) | (retransmission timeout at EAP-layer) 4. <----|-- (x+2) PANA-Auth-Request[EAP Req ID=1] | 5. -----|--> (x+2) PANA-Auth-Answer[EAP Res ID=1] | 6. <----+ (discarded due to Rule 4) 7. <------- (x+3) PANA-Auth-Request[EAP Req ID=2] . . Figure 2: Example for Single sequence number with EAP retransmission This method is vulnerable to a blind DoS attack on the sequence number since the PaC will accept quite a wide range of sequence numbers. For example, if an attacker blindly sends a bogus message to a legitimate PaC with a randomly chosen sequence number, it will be accepted by the PaC with 50% probability, and once this happens, all messages sent from the communicating PAA will be discarded as long as they have a sequence number smaller than the accepted value. The problem of this method leads to a requirement for PaC to have a narrow range of acceptable sequence numbers to make the blind DoS attack difficult. Note that the DoS attack cannot be prevented if the attacker is on the same IP link as PaC and able to eavesdrop the PANA conversation. However, the attacker needs to put itself in promiscuous mode and thus spend more resources to eavesdrop and launch the attack (in other words, non-blind DoS attack is still possible as long as sequence numbers are unprotected.) 2.2 Single sequence number with PANA-layer retransmission method The next method is still based on using a single sequence number but the PANA-layer takes the responsibility of retransmission. The method uses the following rules in addition to the common rules described in section 2. Rule 3: Use PANA-layer retransmission for retransmitting both EAP and non-EAP messages (based on a timer expiration). EAP layer retransmission is turned off. Retransmission based on timer occurs both on PaC and PAA side, but not on both sides simultaneously. PAA does retransmission at least for PANA_Termination and PANA_Reauth messages, otherwise PaC takes care of retransmission. Rule 4: When the PaC receives a message from the PAA, it accepts the message if the sequence number is equal to that of the last accepted message + 1. If the sequence number is equal to that of the last accepted message, the PaC retransmits the last transmitted message. Otherwise, it silently discards the message. Rule 5: When the PAA receives a message from the PaC, it accepts the message if the sequence number is equal to that of the last transmitted message. If the receiving sequence number is equal to that of the last transmitted message - 1, the PAA retransmits the last transmitted message and discard the received message. Otherwise, it silently discards the message. Rule 6: The PaC retransmits the last transmitted EAP Response until a new EAP Request message or an EAP Success/Failure message is received and accepted. Rule 7: PAA must keep the copy of the last transmitted message and must be able to retransmit it until either a valid message is received and accepted by the PAA or a timer expires. The timer is used if no new message will be sent from the PaC. PaC PAA Seq# Message -------------------------------------------- 1. <-------- (x) PANA-Auth-Request[EAP Req ID=1] 2. ---+ (x) PANA-Auth-Answer[EAP Resp ID=1] | (retransmission timeout at PaC) 3. ---|----> (x) PANA-Auth-Answer[EAP Resp ID=1] 4. | +--- (x+1) PANA-Auth-Request[EAP Req ID=2] | | +-|--> (duplicate detected) 5. <----|--- (x+1) PANA-Auth-Request[EAP Req ID=2] | 6. -----|--> (x+1) PANA-Auth-Answer[EAP Resp ID=2] | <----|--- (x+2) PANA-Auth-Request[EAP Req ID=3] 7. -----|--> (x+2) PANA-Auth-Answer[EAP Resp ID=3] <----+ (discarded by PaC) (retransmission timeout at PaC) 8. --------> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 9. lost<---- (x+3) PANA-Auth-Request[EAP Succ ID=3] (retransmission timeout at PaC) 10.---->lost (x+2) PANA-Auth-Answer[EAP Resp ID=3] (retransmission timeout at PaC) 11.--------> (x+2) PANA-Auth-Answer[EAP Resp ID=3] 12.<-------- (x+3) PANA-Bind-Request[EAP Succ ID=3] (retransmission timer stopped at PaC) (deletion timeout at PAA) (message (x+3) deleted at PAA) 13.lost<---- (x+4) PANA-Termination-Request (retransmission timeout at PAA) 14.<-------- (x+4) PANA-Termination-Request 15.---->lost (x+4) PANA-Termination-Answer (retransmission timeout at PAA) 16.<-------- (x+4) PANA-Termination-Request 17.--------> (x+4) PANA-Termination-Answer (retransmission timer stopped at PAA) Figure 3: Example for Single sequence number with PANA-layer retransmission This method has an advantage of eliminating EAP layer retransmission by providing reliability at the PANA layer. Retransmission at the EAP layer has a problem with determining an appropriate retransmission timer value, which occurs when the lower-layer is unreliable. In this case an EAP authenticator cannot distinguish between (i) EAP Request or EAP Response message loss (in this case the retransmission timer should be calculated based on network characteristics) and (ii) long latency for EAP Response generation due to e.g., user input etc. (in this case the retransmission timer should be calculated based on user or application characteristics). In general, the retransmission timer for case (ii) is longer than that for case (i). If case (i) happens while the retransmission timer is calculated based on user or application characteristics, then it might frustrate an end user since the completion of the authentication procedure takes unnecessarily long. If case (ii) happens while the retransmission timer is calculated based on network characteristics (i.e., RTT), then unnecessarily traffic is generated by retransmission. Note that in this method a PaC still cannot distinguish case (i) and case (iii) the EAP authenticator or a backend authentication server is taking time to generate an EAP Request. A problem of this method is that it is based on the assumption that EAP authenticator does not send a new EAP message until an EAP Response to the outstanding EAP Request is received. However, this assumption does not hold at least EAP Success/Failure message which does not need the outstanding EAP Request to be responded before sending the EAP Success/Failure message. This would require timer-based retransmission not only at PaC side but also at PAA side. Another problem occurs when a new EAP message overrides the outstanding EAP Request, the PaC cannot assume any more that the sequence number of the next message to be accepted is the last accepted message + 1. So the PaC needs to accept a range of sequence numbers, instead of a single sequence number. These two additional things would increase the complexity of this method. 3 Dual sequence number approach Based on the analysis of previous schemes, it is recognized that two sequence numbers are needed anyway, one for each direction. Two different methods are proposed based on this approach. Both methods have the following rules in common. Rule 1: A PANA packet carries two sequence numbers: transmitted sequence number (tseq) and received sequence number (rseq). tseq starts from initial sequence number (ISN) and is monotonically increased by 1. The arithmetic defined in [RFC1982] is used for sequence number operation. It is assumed that the two sequence numbers have the same length for simplicity. Rule 2: When PAA or PAC sends a new message, a new sequence number is placed on the tseq field of message. Every transmitted message is given a new sequence number. Rule 3: When a message is sent from PaC or PAA, rseq is copied from the tseq field of the last accepted message. Rule 4: For messages which experience a PANA layer retransmission, the retransmission timer is stopped when the message is acknowledged. It is possible to carry multiple EAP sequences in a single PANA sequence, with using EAP Success/Failure message as a delimiter of each EAP sequence. In this case, EAP Success/Failure message needs to be reliably delivered. 3.1 Dual sequence number with orderly-delivery method This method relies on EAP layer retransmission for EAP messages. This method is referred to as orderly-delivery method. The following rules are used in addition to the common rules. Rule 5: Use the EAP-layer retransmission for retransmitting EAP Requests (based on a timer expiration). For other PANA layer messages that require a response from the peer, PANA layer has its own mechanism to retransmit the request until it gets a response or gives up. A new tseq value is always used when sending any message even when it is retransmitted at PANA layer. Rule 6: When a message is received, it is accepted if (i) the tseq value is greater than the tseq of the last accepted message and (ii) the rseq falls in the range between the tseq of the last acknowledged message + 1 and the tseq of the last transmitted message. Otherwise, the received message is discarded. PaC PAA (tseq,rseq) Message -------------------------------------------------- 1. <------- (x,y) PANA-Auth-Request[EAP Req, ID=1] 2. -------> (y+1,x) PANA-Auth-Answer[EAP Resp, ID=1] 3. <------- (x+1,y+1) PANA-Auth-Request[EAP Req, ID=2] 4. --->lost (y+2,x+1) PANA-Auth-Answer[EAP Resp, ID=2] (retransmission timeout at EAP layer) 5. <------- (x+2,y+1) PANA-Auth-Request [EAP Req, ID=2] 6. -------> (y+3,x+2) PANA-Auth-Answer[EAP Resp, ID=2] 7. lost<--- (x+3,y+3) PANA-Auth-Request[EAP Req, ID=3] (retransmission timeout at EAP layer) 8. +---- (x+4,y+3) PANA-Auth-Answer[EAP Req, ID=3] | (retransmission timeout at EAP layer) 9. <--|---- (x+5,y+3) PANA-Auth-Request[EAP Req, ID=3] 10.---|---> (y+4,x+5) PANA-Auth-Answer[EAP Resp, ID=3] | <--+ (out of order. discarded) 11.lost<--- (x+6,y+4) PANA-Bind-Request[EAP Succ, ID=3] (retransmission timeout at PAA) 12.<------- (x+7,y+4) PANA-Bind-Request[EAP Succ, ID=3] 13.--->lost (y+5,x+7) PANA-Bind-Answer (retransmission timeout at PAA) 14.<------- (x+8,y+4) PANA-Bind-Request[EAP Succ, ID=3] (duplicate detected by PaC) 15.-------> (y+6,x+8) PANA-Bind-Answer Figure 4: Example for Dual sequence number with orderly-delivery 3.2 Dual sequence number with reliable-delivery method This method relies solely on PANA layer retransmission for all messages. This method is referred to as reliable-delivery method. The following additional rules are applied in addition to the common rules. Rule 5: Use the PANA layer retransmission for retransmitting all messages (based on a timer expiration). EAP retransmission is turned off. Rule 6: Either an ACK message is used for acknowledgment or an acknowledgment can be piggybacked with data. ACK messages are not retransmitted. An ACK message is sent if no the acknowledgement cannot be piggybacked with a data within a given time frame W. Rule 7: When a message is received, it is accepted if (i) the tseq value is greater than the tseq of the last accepted message and (ii) the rseq falls in the range between the tseq of the last acknowledged message and the tseq of the last transmitted message. Otherwise, the received message is discarded. Rule 8: When a duplicate message is received, the last transmitted message is retransmitted if the received message is not an ACK. A message is considered as duplicate if its tseq value is equal to the tseq of the last accepted message. PaC PAA (tseq,rseq) Message -------------------------------------------------- 1. <------- (x,y) PANA-Auth-Request[EAP Req, ID=1] (user input ongoing) 2. -------> (y+1,x) PANA-Auth-Answer (user input completed) 3. -------> (y+2,x) PANA-Auth-Answer[EAP Resp, ID=1] 4. <------- (x+1,y+2) PANA-Auth-Request [EAP Req, ID=2] 5. --->lost (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] (retransmission timeout at PAA) 6. <------- (x+1,y+2) PANA-Auth-Request [EAP Req, ID=2] (duplicate detected by PaC) 7. -------> (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] 8. lost<--- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] (retransmission timeout at PaC) 9. -------> (y+3,x+1) PANA-Auth-Answer[EAP Resp, ID=2] (duplicate detected at PAA) 10.<------- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] 11.---+ (y+4,x+2) PANA-Auth-Answer[EAP Resp, ID=3] | (retransmission timeout at PAA) 12.<--|---- (x+2,y+3) PANA-Auth-Request [EAP Req, ID=3] | (duplicate detected at PaC) 13.---|---> (y+4,x+2) PANA-Auth-Answer[EAP Resp, ID=3] 14.<--|---- (x+3,y+4) PANA-Bind-Request[EAP Succ, ID=3] 15.---|---> (y+5,x+3) PANA-Bind-Answer +---> (out of order. discarded) Figure 5: Example for Dual sequence number with reliable-delivery method 3.3 Comparison of the dual sequence number methods The orderly-delivery method is simpler than the reliable-delivery method in that the former does not allow sending a separate ACK while the latter does. In terms of authentication performance, the reliable-delivery method is better than the orderly-delivery method in that the former gives more detailed status of the link than the latter, e.g., an entity can know whether a request has reached the communicating peer without before receiving a response. The reliable-delivery can reduce retransmission traffic and communication delay that would occur if there is no reliability, as described in section section 2.2. 4 Consensus Although it is recognizable that the reliable-delivery method would be important in terms of improvement of overall authentication latency, we believe that this is a performance problem of EAP and not a problem of PANA. It is agreed that solving the EAP problem is not the scope of PANA and simplicity is more important factor in the PANA design. As a consequence, the orderly-delivery method is chosen as the message transport part of PANA.