--- 1/draft-ietf-shim6-proto-11.txt 2009-02-06 13:12:04.000000000 +0100 +++ 2/draft-ietf-shim6-proto-12.txt 2009-02-06 13:12:04.000000000 +0100 @@ -1,19 +1,19 @@ SHIM6 WG E. Nordmark Internet-Draft Sun Microsystems Intended status: Standards Track M. Bagnulo -Expires: June 18, 2009 UC3M - December 15, 2008 +Expires: August 10, 2009 UC3M + February 6, 2009 Shim6: Level 3 Multihoming Shim Protocol for IPv6 - draft-ietf-shim6-proto-11.txt + draft-ietf-shim6-proto-12.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -22,25 +22,25 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 18, 2009. + This Internet-Draft will expire on August 10, 2009. Copyright Notice - Copyright (c) 2008 IETF Trust and the persons identified as the + Copyright (c) 2009 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. Abstract @@ -59,133 +59,132 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Locators as Upper-layer IDentifiers (ULID) . . . . . . . 6 1.4. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Renumbering Implications . . . . . . . . . . . . . . . . 8 1.6. Placement of the shim . . . . . . . . . . . . . . . . . . 9 1.7. Traffic Engineering . . . . . . . . . . . . . . . . . . . 11 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 17 - 2.3. Conceptual . . . . . . . . . . . . . . . . . . . . . . . 17 - 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 22 - 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 22 - 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 23 - 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 23 - 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 24 - 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 25 - 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 27 - 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 27 - 5.2. Payload Extension Header Format . . . . . . . . . . . . . 28 - 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 28 - 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 30 - 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 31 - 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 33 - 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 35 - 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 36 - 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 38 - 5.10. Update Request Message Format . . . . . . . . . . . . . . 40 - 5.11. Update Acknowledgement Message Format . . . . . . . . . . 41 - 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 42 - 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 43 - 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 43 - 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 44 - 5.15.1. Responder Validator Option Format . . . . . . . . . 47 - 5.15.2. Locator List Option Format . . . . . . . . . . . . . 47 - 5.15.3. Locator Preferences Option Format . . . . . . . . . 49 - 5.15.4. CGA Parameter Data Structure Option Format . . . . . 51 - 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 51 - 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 52 - 5.15.7. Forked Instance Identifier Option Format . . . . . . 53 - 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 53 - 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 54 - 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 54 - 6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 56 - 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 58 - 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 58 - 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 58 - 7.3. Normal context establishment . . . . . . . . . . . . . . 59 - 7.4. Concurrent context establishment . . . . . . . . . . . . 59 - 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 61 - 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 63 - 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 64 - 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 65 - 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 65 - 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 66 - 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 67 - 7.11. Receiving R1 messages and sending I2 messages . . . . . . 67 - 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 68 - 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 69 - 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 70 - 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 71 - 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 71 - 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 72 - 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 73 - 7.18. Receiving R1bis messages and sending I2bis messages . . . 73 - 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 74 - 7.20. Receiving I2bis messages and sending R2 messages . . . . 75 - 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 77 - 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 80 - 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 81 - 10.1. Sending Update Request messages . . . . . . . . . . . . . 81 - 10.2. Retransmitting Update Request messages . . . . . . . . . 81 - 10.3. Newer Information While Retransmitting . . . . . . . . . 82 - 10.4. Receiving Update Request messages . . . . . . . . . . . . 82 - 10.5. Receiving Update Acknowledgement messages . . . . . . . . 84 - 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 86 - 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 86 - 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 88 - 12.1. Receiving payload without extension headers . . . . . . . 88 - 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 88 - 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 89 - 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 89 - 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 92 - 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 93 - 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 94 - 15.1. Congestion Control Considerations . . . . . . . . . . . . 94 - 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 94 - 15.3. Operation and Management Considerations . . . . . . . . . 95 - 15.4. Other considerations . . . . . . . . . . . . . . . . . . 96 - 16. Security Considerations . . . . . . . . . . . . . . . . . . . 98 - 16.1. Interaction with IPsec . . . . . . . . . . . . . . . . . 99 - 16.2. Residual Threats . . . . . . . . . . . . . . . . . . . . 101 - 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 - 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 - Appendix A. Possible Protocol Extensions . . . . . . . . . . 106 - Appendix B. Simplified STATE Machine . . . . . . . . . . . . 108 - Appendix B.1. Simplified STATE Machine diagram . . . . . . . . 113 - Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 115 - Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 115 - Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 115 - Appendix C.3. Three Party Context Confusion . . . . . . . . . . 116 - Appendix C.4. Summary . . . . . . . . . . . . . . . . . . . . . 116 - Appendix D. Design Alternatives . . . . . . . . . . . . . . . 117 - Appendix D.1. Context granularity . . . . . . . . . . . . . . . 117 - Appendix D.2. Demultiplexing of data packets in Shim6 - communications . . . . . . . . . . . . . . . . . 117 - Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 118 - Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 120 - Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 121 - Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 123 - Appendix D.5. ULID-pair context establishment exchange . . . . 126 - Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 127 - Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 127 - Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 130 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 137 - 19.2. Informative References . . . . . . . . . . . . . . . . . 137 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 16 + 2.3. Conceptual . . . . . . . . . . . . . . . . . . . . . . . 16 + 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 21 + 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 21 + 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 22 + 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 22 + 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 23 + 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 24 + 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 26 + 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 26 + 5.2. Payload Extension Header Format . . . . . . . . . . . . . 27 + 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 27 + 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 29 + 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 30 + 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 32 + 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 34 + 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 35 + 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 37 + 5.10. Update Request Message Format . . . . . . . . . . . . . . 39 + 5.11. Update Acknowledgement Message Format . . . . . . . . . . 40 + 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 41 + 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 42 + 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 42 + 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 43 + 5.15.1. Responder Validator Option Format . . . . . . . . . 46 + 5.15.2. Locator List Option Format . . . . . . . . . . . . . 46 + 5.15.3. Locator Preferences Option Format . . . . . . . . . 48 + 5.15.4. CGA Parameter Data Structure Option Format . . . . . 50 + 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 50 + 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 51 + 5.15.7. Forked Instance Identifier Option Format . . . . . . 52 + 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 52 + 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 53 + 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 53 + 6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 55 + 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 57 + 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 57 + 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 57 + 7.3. Normal context establishment . . . . . . . . . . . . . . 58 + 7.4. Concurrent context establishment . . . . . . . . . . . . 58 + 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 60 + 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 62 + 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 63 + 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 64 + 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 64 + 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 65 + 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 66 + 7.11. Receiving R1 messages and sending I2 messages . . . . . . 66 + 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 67 + 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 68 + 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 69 + 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 70 + 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 70 + 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 71 + 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 72 + 7.18. Receiving R1bis messages and sending I2bis messages . . . 72 + 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 73 + 7.20. Receiving I2bis messages and sending R2 messages . . . . 74 + 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 76 + 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 79 + 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 80 + 10.1. Sending Update Request messages . . . . . . . . . . . . . 80 + 10.2. Retransmitting Update Request messages . . . . . . . . . 80 + 10.3. Newer Information While Retransmitting . . . . . . . . . 81 + 10.4. Receiving Update Request messages . . . . . . . . . . . . 81 + 10.5. Receiving Update Acknowledgement messages . . . . . . . . 83 + 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 85 + 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 85 + 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 87 + 12.1. Receiving payload without extension headers . . . . . . . 87 + 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 87 + 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 88 + 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 88 + 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 91 + 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 92 + 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 93 + 15.1. Congestion Control Considerations . . . . . . . . . . . . 93 + 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 93 + 15.3. Operation and Management Considerations . . . . . . . . . 94 + 15.4. Other considerations . . . . . . . . . . . . . . . . . . 95 + 16. Security Considerations . . . . . . . . . . . . . . . . . . . 97 + 16.1. Interaction with IPSec . . . . . . . . . . . . . . . . . 98 + 16.2. Residual Threats . . . . . . . . . . . . . . . . . . . . 99 + 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 + 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 + 19. Appendix: Possible Protocol Extensions . . . . . . . . . . . 104 + 20. Appendix: Simplified STATE Machine . . . . . . . . . . . . . 106 + 20.1. Simplified STATE Machine diagram . . . . . . . . . . . . 111 + 21. Appendix: Context Tag Reuse . . . . . . . . . . . . . . . . . 113 + 21.1. Context Recovery . . . . . . . . . . . . . . . . . . . . 113 + 21.2. Context Confusion . . . . . . . . . . . . . . . . . . . . 113 + 21.3. Three Party Context Confusion . . . . . . . . . . . . . . 114 + 21.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 114 + 22. Appendix: Design Alternatives . . . . . . . . . . . . . . . . 115 + 22.1. Context granularity . . . . . . . . . . . . . . . . . . . 115 + 22.2. Demultiplexing of data packets in Shim6 communications . 115 + 22.2.1. Flow-label . . . . . . . . . . . . . . . . . . . . . 116 + 22.2.2. Extension Header . . . . . . . . . . . . . . . . . . 118 + 22.3. Context Loss Detection . . . . . . . . . . . . . . . . . 119 + 22.4. Securing locator sets . . . . . . . . . . . . . . . . . . 121 + 22.5. ULID-pair context establishment exchange . . . . . . . . 124 + 22.6. Updating locator sets . . . . . . . . . . . . . . . . . . 125 + 22.7. State Cleanup . . . . . . . . . . . . . . . . . . . . . . 125 + 23. Appendix: Change Log . . . . . . . . . . . . . . . . . . . . 128 + 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 + 24.1. Normative References . . . . . . . . . . . . . . . . . . 135 + 24.2. Informative References . . . . . . . . . . . . . . . . . 135 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 1. Introduction This document describes a layer 3 shim approach and protocol for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing properties [10], without assuming that a multihomed site will have a provider independent IPv6 address which is announced in the global IPv6 routing table. The hosts in a site which has multiple provider allocated IPv6 address prefixes, will use the Shim6 protocol @@ -379,68 +378,43 @@ when the ULID becomes invalid. The context recovery mechanism will then make the peer aware that the context is gone, and that the ULID is no longer present at the same locator(s). 1.6. Placement of the shim ----------------------- | Transport Protocols | ----------------------- - ------ ------- -------------- ------------- IP endpoint - | AH | | ESP | | Frag/reass | | Dest opts | sub-layer - ------ ------- -------------- ------------- + -------------- ------------- IP endpoint + | Frag/reass | | Dest opts | sub-layer + -------------- ------------- --------------------- | Shim6 shim layer | --------------------- ------ IP routing | IP | sub-layer ------ Figure 1: Protocol stack The proposal uses a multihoming shim layer within the IP layer, i.e., below the ULPs, as shown in Figure 1, in order to provide ULP independence. The multihoming shim layer behaves as if it is associated with an extension header, which would be placed after any routing-related headers in the packet (such as any hop-by-hop options, or routing header). However, when the locator pair is the ULID pair there is no data that needs to be carried in an extension header, thus none is needed in that case. - For the relative layering of the shim and ESP/AH there are two - choices. - - With a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation - as well as the case of IPsec communication between a host and a - security gateway the layering naturally becomes shim6 over ESP/AH. - This implies that when the shim on the sender changes the ULIDs to - locators after a failure then a different IPsec security assocation - would be used since the SA is tied to the IP addresses in the packet. - But that approach is of low complexity. - - With a native IPsec implementation that communicates end-to-end it is - possible to layer IPsec above the shim. That avoids any key - management actions when the locators change after a failure, and it - fits better with the architectural picture above with IPsec in the - endpoint sublayer. The downside is that it requires some care on the - sender to ensure that the change of the ULIDs to locators underneath - IPsec doesn't cause any violations of IPsec policies. The - implementation of such checks would add some complexity. The details - of needed care is specified in Section 16.1. - - A receiver handles either order of AH/ESP and the shim since the - sender's order of processing is reflected in the order of the shim6 - vs. AH/ESP headers in the packet. - Layering the fragmentation header above the multihoming shim makes reassembly robust in the case that there is broken multi-path routing which results in using different paths, hence potentially different source locators, for different fragments. Thus, the multihoming shim layer is placed between the IP endpoint sublayer, which handles fragmentation, reassembly, and the IP routing sublayer, which selects which next hop and interface to use for sending out packets. Applications and upper layer protocols use ULIDs which the Shim6 layer map to/from different locators. The Shim6 layer maintains @@ -551,21 +526,21 @@ The protocol provides a placeholder, in the form of the Locator Preferences option, which can be used by hosts to express priority and weight values for each locator. This option is merely a place holder when it comes to providing traffic engineering; in order to use this in a large site there would have to be a mechanism by which the host can find out what preference values to use, either statically (e.g., some new DHCPv6 option) or dynamically. Thus traffic engineering is listed as a possible extension in - Appendix A. + Section 19. 2. Terminology 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 [1]. 2.1. Definitions This document introduces the following terms: @@ -939,21 +914,21 @@ Several API extensions have been discussed for Shim6, but their actual specification is out of scope for this document. The simplest one would be to add a socket option to be able to have traffic bypass the shim (not create any state, and not use any state created by other traffic). This could be an IPV6_DONTSHIM socket option. Such an option would be useful for protocols, such as DNS, where the application has its own failover mechanism (multiple NS records in the case of DNS) and using the shim could potentially add extra latency with no added benefits. - Some other API extensions are discussed in Appendix A. The actual + Some other API extensions are discussed in Section 19. The actual API extensions are defined in [22]. 4.4. Securing Shim6 The mechanisms are secured using a combination of techniques: o The HBA technique [3] for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else. o Requiring a Reachability Probe+Reply /defined in [4]) before a new @@ -3439,21 +3414,21 @@ Since there is no explicit, coordinated removal of the context state, there are potential issues around context tag reuse. One end might remove the state, and potentially reuse that context tag for some other communication, and the peer might later try to use the old context (which it didn't remove). The protocol has mechanisms to recover from this, which work whether the state removal was total and accidental (e.g., crash and reboot of the host), or just a garbage collection of shim state that didn't seem to be used. However, the host should try to minimize the reuse of context tags by trying to - randomly cycle through the 2^47 context tag values. (See Appendix C + randomly cycle through the 2^47 context tag values. (See Section 21 for a summary how the recovery works in the different cases.) 10. Updating the Peer The Update Request and Acknowledgement are used both to update the list of locators (only possible when CGA is used to verify the locator(s)), as well as updating the preferences associated with each locator. 10.1. Sending Update Request messages @@ -4146,105 +4121,63 @@ o Every control message of the Shim6 protocol, past the context establishment, carry the context tag assigned to the particular context. This implies that an attacker needs to discover that context tag before being able to spoof any Shim6 control message as described in section 4.4 of [14]. Such discovery probably requires to be along the path in order to be sniff the context tag value. The result is that through this technique, the Shim6 protocol is protected against off-path attackers. -16.1. Interaction with IPsec +16.1. Interaction with IPSec - The Shim6 sub-layer can be implemented either below IPsec sublayer, - or above the IPsec sub-layer, or both. (The latter can occur when - e.g., IPsec is used both end-to-end as well as for IPsec tunnels.) + Shim6 has two modes of processing data packets. If the ULID pair is + as well the locator pair being used, then the data packet is not + modified by Shim6. In this case, the interaction with IPSec is + exactly the same as if the Shim6 layer was not present in the host. - In a "bump-in-the-stack" (BITS) IPsec implementation, IPsec is - implemented "underneath" an existing implementation of an IP protocol - stack, between the native IP and the local network drivers. In that - case it is not possible to make IPsec benefit from the failover - capabilities of shim6; when shim6 fails over to a different locator - pair then the BITS IPsec would end up using a different (and possibly - establish a new) security association for that pair of IP addresses. - Same thing applies to a "bump-in-the-wire" (BITW) IPsec - implementation. In those cases shim6 and IPsec still work, but it is - less efficient to have to use separate security associations as a - result of a shim6 failover. + If the ULID pair differs from the current locator pair for that Shim6 + context, then Shim6 will take the data packet, replace the ULIDs + contained in the IP source and destination address fields by the + current locator pair and add the Shim6 extension with the + correspondent Context Tag. In this case, as it is mentioned in + section 1.6,, Shim6 conceptually works as a tunnel mechanism where + the inner header contains the ULID and the outer header contains the + locators. The main difference being that the inner header is + "compressed" and a compression tag, namely the Context tag, is added + to decompress the inner header at the receiving end. - In order for a BITS and BITW IPsec implementation on the node as well - as a security gateway to be able to look at the same selectors before - and after a failover, their implementation needs to skip the SHIM6 + In this case, the interaction between IPSec and Shim6 is then similar + to the interaction between IPSec and a tunnel mechanism. When the + packet is generated by the upper layer protocol is passed to the IP + layer containing the ULIDs in the IP source and destination field. + IPSec is then applied to this packet. Then, the packet is passed to + the Shim6 sub-layer, which "encapsulates" the received packet and + includes a new IP header containing the locator pair in the IP source + and destination field. This new IP packet is in turn passed to IPSec + for processing, just as in the case of a tunnel. This can be viewed + as if IPSec is located both above and below the Shim6 sublayer and + that IPSec policies apply both to ULIDs and locators. + + When IPSec processed the packet after the Shim6 sublayer has + processed it i.e. the packet carrying the locators in the IP source + and destination address field, the Shim6 sublayer may have added the + Shim6 extension header. In that case, IPSec needs to skip the Shim6 extension header to find the selectors for the next layer protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)) - When the Shim6 sub-layer is implemented below the IPsec sub-layer - within the IP layer we avoid any extra IPsec work due to locator - changes, but the implementation needs to make sure that the locator - changes doesn't cause any violations of the inteded IPsec policy. It - is easiest to explain this issue using an example: - - o Assume a pair of hosts, A and B, in different parts of a company. - The hosts do not implement shim6. - - o H1 has to IP addresses IP1(A) and IP2(A). Ditto IP1(B) and - IP2(B). - - o The routing and firewalls used might be setup so that the path - between IP1(A) and IP1(B) uses a communication path that is - internal to the company. The path between IP2(A) and IP2(B) might - be a fallback path where packets are sent over the public - Internet. - - o In such a case it might make sense to have an IPsec policy on A - and B that all packets between IP1(A) and IP1(B) to be in the - clear while packets between IP2(A) and IP2(B) must be encrypted. - - Should we introduce the shim below ESP/AH on host A and B then - potentially we could have Ls(A) include IP1(A) and IP2(B) and - likewise for B. This means that some communication might start out - between the ULID pair IP1(A) and IP1(B), and IPsec will see those - ULIDs and, based on the policy, send things in the clear. Should - there be a failure then the shim, transparently to IPsec, might fail - over to using the locator pair IP2(A),IP2(B) while still sending the - packets in the clear. That MUST be avoided. - - This implies that when the shim forms a locator set for the host it - MUST NOT include locators for which there exists any differences in - the IPsec policy. And since the shim is independent of any higher - level selectors (protocols, port numbers, ICMP fields), this check - for differences must treat those fields as wildcards. This IPx(A) - and IPy(A) MUST NOT be included in the same locator set if there - exists any IPsec policy in the SPD onthe host that is different - should the local address change between IPx(A) and IPy(A). - - This check MUST be performed for the locators sets that are used - locally as well as the locator sets that are sent to the peer in the - shim6 control messages. In the case that there are such differences - it might make sense to form different locator sets. In the above - example should host A have multiple addresses that can be routed over - the public Internet it can form a locator set with those and use that - locator set for communication that uses a ULID that belongs to the - set. - - The notion of having separate locator sets that have different - security properties is useful in cases that does not involve IPsec. - For instance, a firewall which has a black network interface and a - red network interface, each having some set of assigned IP addresses, - SHOULD form a Lblacks(local) and a Lreds(local) so that the shim - doesn't attempt to use a red locator assigned to the host for a - context pair that has a local black ULID, and vice versa. - - The same constraint applies to shim6 hosts which have interfaces - attached to networks where there are different security - considerations, for instance a host with some interfaces attached to - the public Internet and some interfaces attached to an intranet. + When a packet is received at the other end, it is processed based on + the order of the extension headers. Thus if an ESP or AH header + precedes a Shim6 header that determines the order. Shim6 introduces + the need to do policy checks, analogous to how they are done for + tunnels, when Shim6 receives a packet a the ULID pair for the packet + is not identical to the locator pair in the packet. 16.2. Residual Threats Some of the residual threats in this proposal are: o An attacker which arrives late on the path (after the context has been established) can use the R1bis message to cause one peer to recreate the context, and at that point in time the attacker can observe all of the exchange. But this doesn't seem to open any new doors for the attacker since such an attacker can observe the @@ -4397,24 +4330,24 @@ +------------+--------------------------------------------+ 18. Acknowledgements Over the years many people active in the multi6 and shim6 WGs have contributed ideas a suggestions that are reflected in this specification. Special thanks to the careful comments from Sam Hartman, Cullen Jennings, Magnus Nystrom, Stephen Kent, Geoff Huston, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari Arkko, Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien Barre, - Matthijs Mekking, Dave Thaler, Bob Braden Wesley Eddy and Tom - Henderson on earlier versions of this document. + Matthijs Mekking, Dave Thaler, Bob Braden Wesley Eddy, Pari Eronen + and Tom Henderson on earlier versions of this document. -Appendix A. Possible Protocol Extensions +19. Appendix: Possible Protocol Extensions During the development of this protocol, several issues have been brought up as important one to address, but are ones that do not need to be in the base protocol itself but can instead be done as extensions to the protocol. The key ones are: o As stated in the assumptions in Section 3, the in order for the Shim6 protocol to be able to recover from a wide range of failures, for instance when one of the communicating hosts is single-homed, and cope with a site's ISPs that do ingress @@ -4481,21 +4414,21 @@ o ULP specified timers for the reachability detection mechanism (which can be useful particularly when there are forked contexts). o Pre-verify some "backup" locator pair, so that the failover time can be shorter. o Study how Shim6 and Mobile IPv6 might interact. There existing an initial draft on this topic [16]. -Appendix B. Simplified STATE Machine +20. Appendix: Simplified STATE Machine The STATES are defined in Section 6.2. The intent is that the stylized description below be consistent with the textual description in the specification, but should they conflict, the textual description is normative. The following table describes the possible actions in STATE IDLE and their respective triggers: +---------------------+---------------------------------------------+ @@ -4695,21 +4628,21 @@ +---------------------+---------------------------------------------+ | Trigger | Action | +---------------------+---------------------------------------------+ | Wait for | Go to IDLE | | ICMP_HOLDDOWN_TIME | | | | | | Any packet | Process as in IDLE | +---------------------+---------------------------------------------+ -Appendix B.1. Simplified STATE Machine diagram +20.1. Simplified STATE Machine diagram Timeout/Null +------------+ I1/R1 +------------------| NO SUPPORT | Payload or Control/R1bis | +------------+ +---------+ | ^ | | | ICMP Error/Null| | V V | +-----------------+ Timeout/Null +----------+ | | |<---------------| E-FAILED | | +-| IDLE | +----------+ | I2 or I2bis/R2 | | | ^ | @@ -4743,21 +4676,21 @@ | | R1 or R1bis/Null | | +-------+ (Timeout#>Max)/I1 | | R2/Null| +------------------------------------------+ | V | | +-------------------+ | | |<-+ (Timeout#| I2bis-SENT | | I1 or I2 or I2bis/R2 R1bis/I2bis | |--+ R1 or R1bis/Null +-------------------+ Payload/I2bis -Appendix C. Context Tag Reuse +21. Appendix: Context Tag Reuse The Shim6 protocol doesn't have a mechanism for coordinated state removal between the peers, because such state removal doesn't seem to help given that a host can crash and reboot at any time. A result of this is that the protocol needs to be robust against a context tag being reused for some other context. This section summarizes the different cases in which a tag can be reused, and how the recovery works. The different cases are exemplified by the following case. Assume @@ -4773,43 +4706,43 @@ . We've called this "Context Recovery" in this document. o The context tag is reassigned to a context for a different ULID pair between the same to hosts, e.g., . We've called this "Context Confusion" in this document. o The context tag is reassigned to a context between B and other host C, for instance for the ULID pair . That is a form of three party context confusion. -Appendix C.1. Context Recovery +21.1. Context Recovery This case is relatively simple, and is discussed in Section 7.5. The observation is that since the ULID pair is the same, when either A or B tries to establish the new context, A can keep the old context while B re-creates the context with the same context tag CT(B) = X. -Appendix C.2. Context Confusion +21.2. Context Confusion This cases is a bit more complex, and is discussed in Section 7.6. When the new context is created, whether A or B initiates it, host A can detect when it receives B's locator set (in the I2, or R2 message), that it ends up with two contexts to the same peer host (overlapping Ls(peer) locator sets) that have the same context tag CT(peer) = X. At this point in time host A can clear up any possibility of causing confusion by not using the old context to send any more packets. It either just discards the old context (it might not be used by any ULP traffic, since B had discarded it), or it recreates a different context for the old ULID pair (), for which B will assign a unique CT(B) as part of the normal context establishment mechanism. -Appendix C.3. Three Party Context Confusion +21.3. Three Party Context Confusion The third case does not have a place where the old state on A can be verified, since the new context is established between B and C. Thus when B receives payload extension headers with X as the context tag, it will find the context for , hence rewrite the packets to have C3 in the source address field and B2 in the destination address field before passing them up to the ULP. This rewriting is correct when the packets are in fact sent by host C, but if host A ever happens to send a packet using the old context, then the ULP on A sends a packet with ULIDs and the packet arrives at the ULP @@ -4828,40 +4761,40 @@ for very long. The unreachability detection on host A will kick in, because it does not see any return traffic (payload or Keepalive messages) for the context. This will result in host A sending Probe messages to host B to find a working locator pair. The effect of this is that host B will notice that it does not have a context for the ULID pair and CT(B) = X, which will make host B send an R1bis packet to re-establish that context. The re-established context, just like in the previous section, will get a unique CT(B) assigned by host B, thus there will no longer be any confusion. -Appendix C.4. Summary +21.4. Summary In summary, there are cases where a context tag might be reused while some peer retains the state, but the protocol can recover from it. The probability of these events is low given the 47 bit context tag size. However, it is important that these recovery mechanisms be tested. Thus during development and testing it is recommended that implementations not use the full 47 bit space, but instead keep e.g. the top 40 bits as zero, only leaving the host with 128 unique context tags. This will help test the recovery mechanisms. -Appendix D. Design Alternatives +22. Appendix: Design Alternatives This document has picked a certain set of design choices in order to try to work out a bunch of the details, and stimulate discussion. But as has been discussed on the mailing list, there are other choices that make sense. This appendix tries to enumerate some alternatives. -Appendix D.1. Context granularity +22.1. Context granularity Over the years various suggestions have been made whether the shim should, even if it operates at the IP layer, be aware of ULP connections and sessions, and as a result be able to make separate shim contexts for separate ULP connections and sessions. A few different options have been discussed: o Each ULP connection maps to its own shim context. o The shim is unaware of the ULP notion of connections and just @@ -4879,21 +4812,21 @@ that want different communication to use different locator pairs, for instance for quality or cost reasons. The protocol has a shim which operates with host-level granularity (strictly speaking, with ULID-pair granularity, to be able to amortize the context establishment over multiple ULP connections. This is combined with the ability for shim-aware ULPs to request context forking so that different ULP traffic can use different locator pairs. -Appendix D.2. Demultiplexing of data packets in Shim6 communications +22.2. Demultiplexing of data packets in Shim6 communications Once a ULID-pair context is established between two hosts, packets may carry locators that differ from the ULIDs presented to the ULPs using the established context. One of main functions of the Shim6 layer is to perform the mapping between the locators used to forward packets through the network and the ULIDs presented to the ULP. In order to perform that translation for incoming packets, the Shim6 layer needs to first identify which of the incoming packets need to be translated and then perform the mapping between locators and ULIDs using the associated context. Such operation is called @@ -4918,21 +4851,21 @@ packet to determine the shim context to be used to perform the operation. Two mechanisms for carrying the context tag information have been considered in depth during the shim protocol design. Those carrying the context tag in the flow label field of the IPv6 header and the usage of a new extension header to carry the context tag. In this appendix we will describe the pros and cons of each approach and justify the selected option. -Appendix D.2.1. Flow-label +22.2.1. Flow-label A possible approach is to carry the context tag in the Flow Label field of the IPv6 header. This means that when a Shim6 context is established, a Flow Label value is associated with this context (and perhaps a separate flow label for each direction). The simplest approach that does this is to have the triple identify the context at the receiver. @@ -5027,21 +4960,21 @@ would be the preferred approach if the context tag is to be carried in the Flow Label field. This is not only because it imposes the minimum constraints to the Flow Label allocation strategies, limiting the restrictions only to those packets that need to be translated by the shim, but also because Context Loss detection mechanisms greatly benefit from the fact that shim data packets are identified as such, allowing the receiving end to identify if a shim context associated to a received packet is suppose to exist, as it will be discussed in the Context Loss detection appendix below. -Appendix D.2.2. Extension Header +22.2.2. Extension Header Another approach, which is the one selected for this protocol, is to carry the context tag in a new Extension Header. These context tags are allocated by the receiving end during the Shim6 protocol initial negotiation, implying that each context will have two context tags, one for each direction. Data packets will be demultiplexed using the context tag carried in the Extension Header. This seems a clean approach since it does not overload existing fields. However, it introduces additional overhead in the packet due to the additional header. The additional overhead introduced is 8 octets. However, it @@ -5051,21 +4984,21 @@ ULIDs do not require a context tag, since no rewriting is necessary at the receiver. This approach would reduce the overhead, because the additional header is only required after a failure. On the other hand, this approach would cause changes in the available MTU for some packets, since packets that include the Extension Header will have an MTU 8 octets shorter. However, path changes through the network can result in different MTU in any case, thus having a locator change, which implies a path change, affect the MTU doesn't introduce any new issues. -Appendix D.3. Context Loss Detection +22.3. Context Loss Detection In this appendix we will present different approaches considered to detect context loss and potential context recovery strategies. The scenario being considered is the following: Node A and Node B are communicating using IPA1 and IPB1. Sometime later, a shim context is established between them, with IPA1 and IPB1 as ULIDs and IPA1,...,IPAn and IPB1,...,IPBm as locator set respectively. It may happen, that later on, one of the hosts, e.g. Host A loses the shim context. The reason for this can be that Host A has a more @@ -5165,21 +5098,21 @@ exchange and at this point time may be critical since we are reestablishing a context that is currently needed (because context loss detection may occur after a failure). So, another option, which is the one used in this protocol, is to replace the error message by a modified R1 message, so that the time required to perform the context establishment exchange can be reduced. Upon the reception of this modified R1 message, the end that still has the context state can finish the context establishment exchange and restore the lost context. -Appendix D.4. Securing locator sets +22.4. Securing locator sets The adoption of a protocol like SHIM that allows the binding of a given ULID with a set of locators opens the doors for different types of redirection attacks as described in [14]. The goal in terms of security for the design of the shim protocol is not to introduce any new vulnerability in the Internet architecture. It is a non-goal to provide additional protection than the currently available in the single-homed IPv6 Internet. Multiple security mechanisms were considered to protect the shim @@ -5295,21 +5228,21 @@ So, the design decision adopted was that both mechanisms HBA and CGA are supported, so that when only stable address sets are required, the nodes can benefit from the low computational cost offered by HBA while when dynamic locator sets are required, this can be achieved through CGAs with an additional cost. Moreover, because HBAs are defined as a CGA extension, the addresses available in a node can simultaneously be CGAs and HBAs, allowing the usage of the HBA and CGA functionality when needed without requiring a change in the addresses used. -Appendix D.5. ULID-pair context establishment exchange +22.5. ULID-pair context establishment exchange Two options were considered for the ULID-pair context establishment exchange: a 2-way handshake and a 4-way handshake. A key goal for the design of this exchange was that protection against DoS attacks. The attack under consideration was basically a situation where an attacker launches a great amount of ULID-pair establishment request packets, exhausting victim's resources, similar to TCP SYN flooding attacks. @@ -5344,36 +5277,36 @@ should be noted, that because this is 2-way exchange, it is not possible to use the number of half open sessions (as in TCP) to detect an ongoing attack and different heuristics need to be considered. The design decision taken was that considering the current impact of DoS attacks and the low impact of the 4-way exchange in the shim protocol thanks to the deferred context establishment capability, a 4-way exchange would be adopted for the base protocol. -Appendix D.6. Updating locator sets +22.6. Updating locator sets There are two possible approaches to the addition and removal of locators: atomic and differential approaches. The atomic approach essentially send the complete locators set each time that a variation in the locator set occurs. The differential approach send the differences between the existing locator set and the new one. The atomic approach imposes additional overhead, since all the locator set has to be exchanged each time while the differential approach requires re-synchronization of both ends through changes i.e. that both ends have the same idea about what the current locator set is. Because of the difficulties imposed by the synchronization requirement, the atomic approach was selected. -Appendix D.7. State Cleanup +22.7. State Cleanup There are essentially two approaches for discarding an existing state about locators, keys and identifiers of a correspondent node: a coordinated approach and an unilateral approach. In the unilateral approach, each node discards the information about the other node without coordination with the other node based on some local timers and heuristics. No packet exchange is required for this. In this case, it would be possible that one of the nodes has discarded the state while the other node still hasn't. In this case, @@ -5430,24 +5363,30 @@ coordinated approach using a CLOSE/CLOSE ACK exchange, there is still the possibility of a host rebooting without having the time to perform the CLOSE exchange. So, it is true that the coordinated approach eliminates the possibility of a context confusion situation because premature garbage collection, but it does not prevent the same situations due to a crash and reboot of one of the involved hosts. The result is that even if we went for a coordinated approach, we would still need to deal with context confusion and provide the means to detect and recover from this situations. -Appendix E. Change Log +23. Appendix: Change Log [RFC Editor: please remove this section] + The following changes have been made since draft-ietf-shim6-proto-11: + + o Reworded the placement of shim6 w.r.t. IPsec + + o Updated text on the IPsec considerations + The following changes have been made since draft-ietf-shim6-proto-10: o Reworded the placement of shim6 w.r.t. IPsec o Updated text on the IPsec considerations The following changes have been made since draft-ietf-shim6-proto-09: o Explicitly added a reference to the applicability document @@ -5725,39 +5663,39 @@ context is forked, that is different ULP messages are sent over different locator pairs, things are a lot easier if there is only one current locator pair used for each context. Thus the forking of the context is now causing a new context to be established for the same ULID; the new context having a new context tag. The original context is referred to as the "default" context for the ULID pair. o Added more background material and textual descriptions. -19. References +24. References -19.1. Normative References +24.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [3] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-shim6-hba-05 (work in progress), December 2007. [4] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", draft-ietf-shim6-failure-detection-13 (work in progress), June 2008. -19.2. Informative References +24.2. Informative References [5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [7] Draves, R., "Default Address Selection for Internet Protocol