IPSECME Working Group J. Song Internet-Draft T. Tsou Intended status: Standards Track Huawei Technologies Expires: October 31, 2013 V. Manral Hewlett-Packard Company April 29, 2013 IPsec sequence number integrity check value draft-song-ipsecme-seq-icv-00 Abstract This document specifies an IPsec AH and ESP sequence number validation scheme, which is complementary to the existing ICV mechanism and anti-replay mechanism of AH and ESP in defense against DOS attack. It is an optional feature negotiable through IKE, for this feature to be negotiated, both sender and receiver must implement it. If any party doesn't support it, then this feature should be excluded from negotiation. The rationale for such a scheme is discussed first; then requirements and guidelines for design of the scheme are laid out. There can be various ways to implement the scheme, some reference designs are discussed to set the base for effort of identifying best practice and eventually establishing a standard on the subject. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 31, 2013. Song, et al. Expires October 31, 2013 [Page 1] Internet-Draft IPsec SEQ-ICV April 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction As defense against replay attack, IPsec, both AH and ESP, uses anti- replay window to keep track of the sequence numbers of received packets, and reject packets with sequence number that is either too old (below anti-replay window) or duplicate (within anti-replay window, but marked as received). Anti-replay window is not effective against DOS attack by packets with sequence number that are above anti-replay window, in which case the sequence number is neither considered too old, nor duplicate. Attack packets with sequence number above anti-replay window would penetrate anti-replay check and only be rejected after failing ICV check. The issue is that ICV check, which involves hashing operation, is rather expensive in terms of resource and time consumption. In case of ESP, when hardware crypto acceleration engine is used, ICV check and decryption often need to be performed together to optimize bandwidth efficiency, which makes the operation even more expensive. Large number of such packets would cause recevier's service degradation or interruption because significant amount of receiver's resource and time would be consumed by performing expensive ICV check on these packets. An inexpensive mechanism to check sequence number would allow rejecting such packets without causing service degradation or interruption. This check can be performed either before or after anti-replay check depending on policy and situation, but must be performed before ICV check. Such check doesn't have to be 100% accurate as long as it doesn't yield false positive result, i.e. mistaking correct sequence number as incorrect sequence number, since the packet with false negative result, i.e. incorrect sequence number passing the check, will be caught by ICV check eventually. But it must be significantly more resource and time efficient than ICV check to be beneficial. Song, et al. Expires October 31, 2013 [Page 2] Internet-Draft IPsec SEQ-ICV April 2013 This check will increase packet length slightly, and incur slight computation overhead per packet, but greatly improve IPsec's capability to withstand DOS attack. This check would not be effective if attacker can prevent original packets from reaching destination, since in such case the attacker doesn't need to change sequence number, instead he or she can change payload, then the packet would pass both anti-replay check and this proposed sequence number check. But in order to shoot down original packets, attacker must compromise intermediate router. The proposed sequence number check is not designed to defend against attacks that involves compromised intermediate router, instead it is designed against attacks where attacker does not control intermediate router, but is able to obtain copy of original packets and launch attack by changing sequence number of the original packets to values that are greater so that anti-replay check would pass and ICV check is required. The latter is simpler attack and easier to carry out therefore is a more serious threat. This check is not designed for systems that are capable of line rate ICV check; instead it is designed for systems that are not capable of line rate ICV check. This check makes it possible for systems that are not capable of line rate ICV check to continue with normal function when under attacks, as long as the original packets are still being delivered, or in another words, as long as the network in between is not compromised. Systems that are capable of line rate ICV check should decline SEQ-ICV in negotiation. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. SEQ-ICV A value generated by sender for each IPsec packet based on packet sequence number and some secret known and only known to sender and receiver. The value is transmitted together with the packet to receiver, which generates its own value locally the same way as sender, then compares with the transmitted value. If the value is the same, then the sequence number is considered to be good, otherwise the sequence number is considered to be bad. 3. SEQ-ICV type SEQ-ICV type is defined by its length and how it is transmitted. SEQ-ICV can be arbitrary number of bytes long and transmitted in band or out of band. Ease of generation and transmission should be the major factors in choosing SEQ-ICV type. Following are some recommended SEQ-ICV types, a solution can pick and choose to support Song, et al. Expires October 31, 2013 [Page 3] Internet-Draft IPsec SEQ-ICV April 2013 one or more of them. For each type, different algorithms can be used to generate SEQ-ICV. SEQ-ICV type and generation algorithm should be negotiated through IKE. An algorithm to generate SEQ-ICV-4 is defined in Appendix A. 1. SEQ-ICV-1 : 1 byte is generated and embedded anywhere after AH/ ESP header 2. SEQ-ICV-2 : 2 bytes are generated and embedded anywhere after AH /ESP header 3. SEQ-ICV-3 : 3 bytes are generated and embedded anywhere after AH /ESP header 4. SEQ-ICV-4 : 4 bytes are generated and embedded anywhere after AH /ESP header 5. SEQ-ICV-1-1 : 2 bytes are generated and embedded as two 1 byte separately anywhere after AH/ESP header 6. SEQ-ICV-1-2 : 3 bytes are generated and embedded as an 1 byte and a 2 byte separately anywhere after AH/ESP header 7. SEQ-ICV-1-1-1 : 3 bytes are generated and embedded as three 1 byte separately anywhere after AH/ESP header 8. SEQ-ICV-1-3 : 4 bytes are generated and embedded as an 1 byte and a three byte separately anywhere after AH/ESP header 9. SEQ-ICV-2-2 : 4 bytes are generated and embedded as two 2 byte separately anywhere after AH/ESP header 10. SEQ-ICV-1-1-2 : 4 bytes are generated and embedded as two 1 byte and one 2 byte separately anywhere after AH/ESP header 11. SEQ-ICV-1-1-1-1 : 4 bytes are generated and embedded as four 1 byte separately anywhere after AH/ESP header 4. SEQ generation rules 1. part or whole of sequence number must be used 2. must be significantly more memory and time efficient than whole packet ICV check 5. SEQ SEQ-ICV transmission rules 1. can be embedded anywhere after AH/ESP header Song, et al. Expires October 31, 2013 [Page 4] Internet-Draft IPsec SEQ-ICV April 2013 2. can be embedded as whole, or pieces 6. SEQ-ICV retrieval and check rules 1. must be checked before ICV check 2. can be checked either before or after anti-replay check if enabled 7. Relation to IKE Like authentication and encryption, type of SEQ-ICV and algorithm used to generate/transmit SEQ-ICV should all be negotiable through IKE. Following information should be negotiated as part of SA, 1. whether SEQ-ICV is supported 2. operation mode of SEQ-ICV : static - SEQ-ICV is always enabled; dynamic - SEQ-ICV is enabled and disabled dynamically by receiver based on whether it is under attack 3. type of SEQ-ICV chosen 4. algorithm for SEQ-ICV generation and transmission 5. key, if needed, for SEQ-ICV generation 8. Outbound processing AH transport/tunnel mode 1. generate ICV 2. generate SEQ-ICV 3. embed SEQ-ICV 4. adjust packet length in IP header Packet length field can only be adjusted after generating ICV, which must be based on the packet length without SEQ-ICV ESP transport/tunnel mode 1. encrypt packet payload 2. generate ICV Song, et al. Expires October 31, 2013 [Page 5] Internet-Draft IPsec SEQ-ICV April 2013 3. generate SEQ-ICV 4. embed SEQ-ICV 9. Inbound processing AH transport/tunnel mode 1. reject if failed anti-replay check 2. generate SEQ-ICV 3. retrieve, in reverse order if consists of multiple parts, transmitted SEQ-ICV 4. Compare locally generated SEQ-ICV with transmitted SEQ-ICV 5. Reject packet if not same, otherwise adjust packet length field of IP header proceed to AH processing Packet length field must be adjusted before AH processing ESP transport/tunnel mode 1. reject if failed anti-replay check 2. generate SEQ-ICV 3. retrieve, in reverse order if consists of multiple parts, transmitted SEQ-ICV 4. Compare locally generated SEQ-ICV with transmitted SEQ-ICV 5. Reject packet if not same, otherwise proceed to ESP processing In calculating ESP payload length, SEQ-ICV must be excluded. Enable SEQ-ICV dynamically If too many packets passed anti-replay but failed ICV check, then notify sender to enable SEQ-ICV, and receiver begins SEQ-ICV check but would not reject packets that failed SEQ-ICV check, once receiver no longer observes packets passing ICV check but failing SEQ-ICV check, then receiver considers SEQ-ICV has been enabled, and begins to reject packet that failed SEQ-ICV check. Disable SEQ-ICV dynamically Song, et al. Expires October 31, 2013 [Page 6] Internet-Draft IPsec SEQ-ICV April 2013 If no packets passed anti-replay but failed SEQ-ICV, then notify sender to disable SEQ-ICV, and receiver stops rejecting packets that failed SEQ-ICV check, once receiver no longer observes packets passing both SEQ-ICV and ICV check, but only packets passing ICV check, then receiver considers SEQ-ICV has been disabled, and stops checking SEQ-ICV Following is summary of conditions that could occur throughout the whole process of dynamically enabling and disabling SEQ-ICV with assumption that original packets are delivered, -------------------------------------------------------------- | id |condition | packet |anti-replay|seq-icv| icv | action | |----|----------|--------|-----------|-------|------|--------| | | normal, |original| pass | skip | pass | accept | | 1 | seq-icv | | | | | | | | disabled | | | | | | |----|----------|--------|-----------|-------|------|--------| | | under |original| pass | skip | pass | accept | | | attack, | | | | | | | | seq-icv | | | | | | | | disabled | | | | | | | 2 |----------|--------|-----------|-------|------|--------| | |under | with | pass | skip | fail | reject | | |attack, | fake | | | | | | |seq-icv | seq | | | | | | |disabled | | | | | | |----|----------|--------|-----------|-------|------|--------| | | under |original| pass | fail | pass | accept | | | attack, | | | | | | | | enabling | | | | | | | | seq-icv | | | | | | | 3 |----------|--------|-----------|-------|------|--------| | | under | with | pass | fail | fail | reject | | | attack, | fake | | | | | | | enabling | seq | | | | | | | seq-icv | | | | | | |----|----------|--------|-----------|-------|------|--------| | | under |original| pass | pass | pass | accept | | | attack, | | | | | | | | enabling | | | | | | | | seq-icv | | | | | | | | ready | | | | | | | 4 |----------|--------|-----------|-------|------|--------| | | under | with | pass | fail | fail | reject | | | attack, | fake | | | | | | | enabling | seq | | | | | | | seq-icv | | | | | | Song, et al. Expires October 31, 2013 [Page 7] Internet-Draft IPsec SEQ-ICV April 2013 | | ready | | | | | | |----|----------|--------|-----------|-------|------|--------| | | under |original| pass | pass | pass | accept | | | attack, | | | | | | | | seq-icv | | | | | | | | enabled | | | | | | | 5 |----------|--------|-----------|-------|------|--------| | | under | with | pass | fail | skip | reject | | | attack, | fake | | | | | | | seq-icv | seq | | | | | | | enabled | | | | | | |----|----------|--------|-----------|-------|------|--------| | | normal, |original| pass | pass | pass | accept | | 6 | seq-icv | | | | | | | | enabled | | | | | | |----|----------|--------|-----------|-------|------|--------| | | normal, |original| pass | fail | pass | accept | | 7 | disabling| | | | | | | | seq-icv | | | | | | -------------------------------------------------------------- 1 - normal, seq-icv disabled 2 - under attack, seq-icv disabled 3 - under attack, enabling seq-icv 4 - under attack, enabling seq-icv ready 5 - under attack, seq-icv enabled 6 - normal, seq-icv enabled 7 - normal, disabling seq-icv SEQ-ICV enabling process is 1 through 5 SEQ-ICV disabling process is 6 -> 7 -> 1 10. Appendix A : An Algorithm for SEQ-ICV-4 generation and transmission 1. SEQ is sequence number 2. AK is authentication key 3. CIPHER is the encrypted payload Song, et al. Expires October 31, 2013 [Page 8] Internet-Draft IPsec SEQ-ICV April 2013 4. SEQ-ICV-4 is generated as follows : SEQ-ICV-4[n] = (AK[n] + CIPHER[n]) ^ (AK[n+4] + SEQ[n]), 0 <= n <= 3 5. Location of SEQ-ICV-4 is derived as follows : offset-in- encrypted-payload = max(SEQ-ICV-4 % payload-length , 4) 6. Increase Packet length of IP header by 4 to account for SEQ-ICV-4 11. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 12. Security Considerations 13. Acknowledgments Robert Moskowitz reminded us of importance of grammatical integrity. Tero Kivinen pointed out issue with original sample SEQ-ICV-4 generation algorithm and provided insightful feedback on issues like compatibility with existing standard and usage scenario of SEQ-ICV. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 14.2. Informative References [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Song, et al. Expires October 31, 2013 [Page 9] Internet-Draft IPsec SEQ-ICV April 2013 Appendix A. Encapsulation Mode Appendix B. Justification Authors' Addresses Jifei Song Huawei Technologies Email: jifei.song@huawei.com Tina Tsou Huawei Technologies 2330 Central Expressway Santa Clara USA Phone: +1-408-330-4424 Email: tina.tsou.zouting@huawei.com Vishwas Manral Hewlett-Packard Company 3000 Hanover St. Palo Alto USA Email: vishwas.manral@hp.com Song, et al. Expires October 31, 2013 [Page 10]