--- 1/draft-ietf-shim6-proto-10.txt 2008-12-16 00:12:07.000000000 +0100 +++ 2/draft-ietf-shim6-proto-11.txt 2008-12-16 00:12:07.000000000 +0100 @@ -1,48 +1,54 @@ SHIM6 WG E. Nordmark Internet-Draft Sun Microsystems -Expires: August 17, 2008 M. Bagnulo - UC3M - February 14, 2008 +Intended status: Standards Track M. Bagnulo +Expires: June 18, 2009 UC3M + December 15, 2008 Shim6: Level 3 Multihoming Shim Protocol for IPv6 - draft-ietf-shim6-proto-10.txt + draft-ietf-shim6-proto-11.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + 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. 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." 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 August 17, 2008. + This Internet-Draft will expire on June 18, 2009. Copyright Notice - Copyright (C) The IETF Trust (2008). + Copyright (c) 2008 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 This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing properties, without assuming that a multihomed site will have a provider independent IPv6 address prefix 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 @@ -53,174 +59,177 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13 - 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 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 - 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 - 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 - Appendix A. Possible Protocol Extensions . . . . . . . . . . 104 - Appendix B. Simplified STATE Machine . . . . . . . . . . . . 106 - Appendix B.1. Simplified STATE Machine diagram . . . . . . . . 111 - Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 113 - Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 113 - Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 113 - Appendix C.3. Three Party Context Confusion . . . . . . . . . . 114 - Appendix D. Design Alternatives . . . . . . . . . . . . . . . 115 - Appendix D.1. Context granularity . . . . . . . . . . . . . . . 115 + 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 . . . . . . . . . . . . . . . . . 115 - Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 116 - Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 118 - Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 119 - Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 121 - Appendix D.5. ULID-pair context establishment exchange . . . . 124 - Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 125 - Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 125 - Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 128 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 135 - 19.2. Informative References . . . . . . . . . . . . . . . . . 135 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 - Intellectual Property and Copyright Statements . . . . . . . . . 138 + 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 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 [11], without assuming that a multihomed site will have a + 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 specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original one stop working (the term locator is defined in Section 2). The Shim6 protocol is a site multihoming solution in the sense that it allows existing communication to continue when a site that has multiple connections to the internet experiences an outage on a subset of these connections or further upstream. However, Shim6 processing is performed in individual hosts rather than through site- wide mechanisms. We assume that redirection attacks are prevented using Hash Based - Addresses (HBA) as defined in [4]. + Addresses (HBA) as defined in [3]. The reachability and failure detection mechanisms, including how a new working locator pair is discovered after a failure, are specified - in a separate document [5]. This document allocates message types + in a separate document [4]. This document allocates message types and option types for that sub-protocol, and leaves the specification of the message and option formats as well as the protocol behavior to that document. 1.1. Goals The goals for this approach are to: o Preserve established communications in the presence of certain classes of failures, for example, TCP connections and UDP streams. o Have minimal impact on upper layer protocols in general and on transport protocols and applications in particular. - o Address the security threats in [15] through the combination of - the HBA/CGA approach specified in a separate document [4] and + o Address the security threats in [14] through the combination of + the HBA/CGA approach specified in a separate document [3] and techniques described in this document. o Not require extra roundtrip up front to setup shim specific state. Instead allow the upper layer traffic (e.g., TCP) to flow as normal and defer the setup of the shim state until some number of packets have been exchanged. o Take advantage of multiple locators/addresses for load spreading so that different sets of communication to a host (e.g., different connections) might use different locators of the host. Note that @@ -268,40 +277,40 @@ The approach described in this document does not introduce a new identifier name space but instead uses the locator that is selected in the initial contact with the remote peer as the preserved Upper- Layer Identifier (ULID). While there may be subsequent changes in the selected network level locators over time in response to failures in using the original locator, the upper level protocol stack elements will continue to use this upper level identifier without change. This implies that the ULID selection is performed as today's default - address selection as specified in RFC 3484 [8]. Some extensions are + address selection as specified in RFC 3484 [7]. Some extensions are needed to RFC 3484 to try different source addresses, whether or not - the Shim6 protocol is used, as outlined in [9]. Underneath, and + the Shim6 protocol is used, as outlined in [8]. Underneath, and transparently, the multihoming shim selects working locator pairs with the initial locator pair being the ULID pair. If communication subsequently fails the shim can test and select alternate locators. A subsequent section discusses the issues when the selected ULID is not initially working hence there is a need to switch locators up front. Using one of the locators as the ULID has certain benefits for applications which have long-lived session state or performs callbacks or referrals, because both the FQDN and the 128-bit ULID work as handles for the applications. However, using a single 128- bit ULID doesn't provide seamless communication when that locator is - unreachable. See [18] for further discussion of the application + unreachable. See [17] for further discussion of the application implications. There has been some discussion of using non-routable addresses, such - as Unique-Local Addresses (ULAs) [14], as ULIDs in a multihoming + as Unique-Local Addresses (ULAs) [13], as ULIDs in a multihoming solution. While this document doesn't specify all aspects of this, it is believed that the approach can be extended to handle the non- routable address case. For example, the protocol already needs to handle ULIDs that are not initially reachable. Thus the same mechanism can handle ULIDs that are permanently unreachable from outside their site. The issue becomes how to make the protocol perform well when the ULID is known a priori to be not reachable (e.g. the ULID is a ULA), for instance, avoiding any timeout and retries in this case. In addition one would need to understand how the ULAs would be entered in the DNS to avoid a performance impact on @@ -309,28 +318,28 @@ communicate to the (unreachable) ULA. 1.4. IP Multicast IP Multicast requires that the IP source address field contain a topologically correct locator for interface that is used to send the packet, since IP multicast routing uses both the source address and the destination group to determine where to forward the packet. In particular, it need to be able to do the RPF check. (This isn't much different than the situation with widely implemented ingress - filtering [7] for unicast.) + filtering [6] for unicast.) While in theory it would be possible to apply the shim re-mapping of the IP address fields between ULIDs and locators, the fact that all the multicast receivers would need to know the mapping to perform, makes such an approach difficult in practice. Thus it makes sense to have multicast ULPs operate directly on locators and not use the - shim. This is quite a natural fit for protocols which use RTP [10], + shim. This is quite a natural fit for protocols which use RTP [9], since RTP already has an explicit identifier in the form of the SSRC field in the RTP headers. Thus the actual IP address fields are not important to the application. In summary, IP multicast will not need the shim to remap the IP addresses. This doesn't prevent the receiver of multicast to change its locators, since the receiver is not explicitly identified; the destination address is a multicast address and not the unicast @@ -393,37 +402,52 @@ 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. - Layering AH and ESP above the multihoming shim means that for a - native implementation of IPsec, IPsec can be made to be unaware of - locator changes the same way that transport protocols can be unaware. + For the relative layering of the shim and ESP/AH there are two + choices. - A "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation is - layered in the same place as the application of IPsec in security - gateways. In that case there might be separate security associations - for different locators. + 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, effectively the - multihoming shim layer is placed between the IP endpoint sublayer, - which handles fragmentation, reassembly, and IPsec, and the IP - routing sublayer, which selects which next hop and interface to use - for sending out packets. + 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 state, called ULID-pair context, per ULID pair (that is, applies to all ULP connections between the ULID pair) in order to perform this mapping. The mapping is performed consistently at the sender and the receiver so that ULPs see packets that appear to be sent using ULIDs from end to end. This property is maintained even though the packets travel through the network containing locators in the IP address fields, and even though those locators may be changed by the @@ -465,23 +489,23 @@ correct ULIDs there is a need to include some "compression tag" in the data packets. This serves to indicate the correct context to use for decompression when the locator pair in the packet is insufficient to uniquely identify the context. There are different types of interactions between the Shim6 layer and other protocols. Those intereactions are influenced by the usage of the addresses that these other protocols do and the impact of the Shim6 mapping on these usages. A detailed analysis of the interactions of different portocols, including SCTP, MIP and HIP can - be found in [19]. Moreover, some applications may need to have a + be found in [18]. Moreover, some applications may need to have a richer interaction with the Shim6 sub-layer. In order to enable - that, a API [23] has been defined to enable greater control and + that, a API [22] has been defined to enable greater control and information exchange for those applications that need it. 1.7. Traffic Engineering At the time of this writing it is not clear what requirements for traffic engineering make sense for the Shim6 protocol, since the requirements must both result in some useful behavior as well as be implementable using a host-to-host locator agility mechanism like Shim6. @@ -643,50 +667,55 @@ communication when some ULP decides to start communicating with a peer by sending and receiving ULP packets. Typically this would not invoke any operations in the shim, since the shim can defer the context establishment until some arbitrary later point in time. Hash Based Addresses (HBA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of all the - prefixes assigned to the host. See [4]. + prefixes assigned to the host. See [3]. Cryptographically Generated Addresses (CGA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of the public key. See [2]. CGA Parameter Data Structure (PDS) The information that CGA and HBA exchanges in order to inform the peer of how the interface ID - was computed. See [2], [4]. + was computed. See [2], [3]. 2.2. Notational Conventions A, B, and C are hosts. X is a potentially malicious host. FQDN(A) is the Fully qualified Domain Name for A. Ls(A) is the locator set for A, which consists of the locators L1(A), L2(A), ... Ln(A). The locator set in not ordered in any particular - way other than maybe what is returned by the DNS. + way other than maybe what is returned by the DNS. A host might form + different locators sets containing different subnets of the hosts IP + addresses. This is necessary in some cases for security reasons. + See Section 16.1. ULID(A) is an upper-layer ID for A. In this proposal, ULID(A) is always one member of A's locator set. CT(A) is a context tag assigned by A. STATE (in uppercase) refers to the the specific state of the state machine described in Section 6.2 +2.3. Conceptual + This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. See Section 6 for a description of the conceptual data structures. @@ -726,42 +755,42 @@ (node B in the previous paragraph) to select a source address that corresponds to the operational egress, in order to pass the ISP's ingress filters. The Shim6 approach assumes that there are no IPv6-to-IPv6 NATs on the paths, i.e., that the two ends can exchange their own notion of their IPv6 addresses and that those addresses will also make sense to their peer. The security of the Shim6 protocol relies on the usage of Hash Based - Addresses (HBA) [4] and/or Cryptographically Generated Addresses + Addresses (HBA) [3] and/or Cryptographically Generated Addresses (CGA) [2]. In the case that HBAs are used, all the addresses assigned to the host that are included in the Shim6 protocol (either as a locator or as a ULID) must be part of the same HBA set. In the case that CGAs are used, the address used as ULID must be a CGA but the other addresses that are used as locators do not need to be neither CGAs nor HBAs. It should be noted that it is perfectly acceptable to run the Shim6 protocol between a host that has multiple locators and another host that has a single IP address. In this case, the address of the host with a single address does not need to be an HBA nor a CGA. 4. Protocol Overview The Shim6 protocol operates in several phases over time. The following sequence illustrates the concepts: o An application on host A decides to contact an application on host B using some upper-layer protocol. This results in the ULP on host A sending packets to host B. We call this the initial contact. Assuming the IP addresses selected by Default Address - Selection [8] and its extensions [9] work, then there is no action + Selection [7] and its extensions [8] work, then there is no action by the shim at this point in time. Any shim context establishment can be deferred until later. o Some heuristic on A or B (or both) determine that it is appropriate to pay the Shim6 overhead to make this host-to-host communication robust against locator failures. For instance, this heuristic might be that more than 50 packets have been sent or received, or a timer expiration while active packet exchange is in place. This makes the shim initiate the 4-way context establishment exchange. The purpose of this heuristic is to avoid @@ -911,30 +940,30 @@ 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 - API extensions are defined in [23]. + API extensions are defined in [22]. 4.4. Securing Shim6 The mechanisms are secured using a combination of techniques: - o The HBA technique [4] for verifying the locators to prevent an + 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 [5]) before a new + o Requiring a Reachability Probe+Reply /defined in [4]) before a new locator is used as the destination, in order to prevent 3rd party flooding attacks. o The first message does not create any state on the responder. Essentially a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all of memory on the responder) at least provides an IPv6 address that the attacker was using. o The context establishment messages use nonces to prevent replay @@ -950,21 +979,21 @@ result is that through this technique, the Shim6 protocol is protected against off-path attackers. 4.5. Overview of Shim Control Messages The Shim6 context establishment is accomplished using four messages; I1, R1, I2, R2. Normally they are sent in that order from initiator and responder, respectively. Should both ends attempt to set up context state at the same time (for the same ULID pair), then their I1 messages might cross in flight, and result in an immediate R2 - message. [The names of these messages are borrowed from HIP [20].] + message. [The names of these messages are borrowed from HIP [19].] R1bis and I2bis messages are defined, which are used to recover a context after it has been lost. A R1bis message is sent when a Shim6 control or Payload extension header arrives and there is no matching context state at the receiver. When such a message is received, it will result in the re-creation of the Shim6 context using the I2bis and R2 messages. The peers' lists of locators are normally exchanged as part of the context establishment exchange. But the set of locators might be @@ -975,34 +1004,34 @@ some preferences might have changed. For instance, it might determine that there is a locally visible failure that implies that some locator(s) are no longer usable. This uses a Locator Preferences option in the Update Request message. The mechanism for (un)reachability detection is called Forced Bidirectional Communication (FBD). FBD uses a Keepalive message which is sent when a host has received packets from its peer but has not yet sent any packets from its ULP to the peer. The message type is reserved in this document, but the message format and processing - rules are specified in [5]. + rules are specified in [4]. In addition, when the context is established and there is a subsequent failure there needs to be a way to probe the set of locator pairs to efficiently find a working pair. This document reserves a Probe message type, with the packet format and processing - rules specified in [5]. + rules specified in [4]. The above probe and keepalive messages assume we have an established ULID-pair context. However, communication might fail during the initial contact (that is, when the application or transport protocol is trying to setup some communication). This is handled using the mechanisms in the ULP to try different address pairs as specified in - [8] [9]. In the future versions of the protocol, and with a richer + [7] [8]. In the future versions of the protocol, and with a richer API between the ULP and the shim, the shim might be help optimize discovering a working locator pair during initial contact. This is for further study. 4.6. Extension Header Order Since the shim is placed between the IP endpoint sub-layer and the IP routing sub-layer, the shim header will be placed before any endpoint extension headers (fragmentation headers, destination options header, AH, ESP), but after any routing related headers (hop-by-hop @@ -1753,32 +1782,32 @@ Request message. No options are currently defined for this message. Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15. 5.12. Keepalive Message Format - This message format is defined in [5]. + This message format is defined in [4]. The message is used to ensure that when a peer is sending ULP packets on a context, it always receives some packets in the reverse direction. When the ULP is sending bidirectional traffic, no extra packets need to be inserted. But for a unidirectional ULP traffic pattern, the shim will send back some Keepalive messages when it is receiving ULP packets. 5.13. Probe Message Format - This message and its semantics are defined in [5]. + This message and its semantics are defined in [4]. The goal of this mechanism is to test whether locator pairs work or not in the general case. In particular, this mechanism is to be able to handle the case when one locator pair works in from A to B, and another locator pair works from B to A, but there is no locator pair which works in both directions. The protocol mechanism is that as A is sending probe messages to B, B will observe which locator pairs it has received from and report that back in probe messages it is sending to A. @@ -1850,21 +1879,21 @@ | | option | | | | | 120-127 | Reserved for debugging purposes | +---------+---------------------------------------------------------+ Table 2 5.15. Option Formats The format of the options is a snapshot of the current HIP option - format [20]. However, there is no intention to track any changes to + format [19]. However, there is no intention to track any changes to the HIP option format, nor is there an intent to use the same name space for the option type values. But using the same format will hopefully make it easier to import HIP capabilities into Shim6 as extensions to Shim6, should this turn out to be useful. All of the TLV parameters have a length (including Type and Length fields) which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. Any @@ -2057,21 +2086,21 @@ Table 4 5.15.3. Locator Preferences Option Format The Locator Preferences option can have some flags to indicate whether or not a locator is known to work. In addition, the sender can include a notion of preferences. It might make sense to define "preferences" as a combination of priority and weight the same way that DNS SRV records has such information. The priority would provide a way to rank the locators, and within a given priority, the - weight would provide a way to do some load sharing. See [6] for how + weight would provide a way to do some load sharing. See [5] for how SRV defines the interaction of priority and weight. The minimum notion of preferences we need is to be able to indicate that a locator is "dead". We can handle this using a single octet flag for each locator. We can extend that by carrying a larger "element" for each locator. This document presently also defines 2-octet and 3-octet elements, and we can add more information by having even larger elements if need be. @@ -2159,21 +2188,21 @@ | Type = 4 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CGA Parameter Data Structure ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: CGA Parameter Data Structure: Variable length content. Content - defined in [2] and [4]. + defined in [2] and [3]. Padding: Padding, 0-7 bytes, added if needed. See Section 5.15. 5.15.5. CGA Signature Option Format When CGA is used for verification of one or more of the locators in the Locator List option, then the message in question will need to contain this option. @@ -2256,21 +2285,21 @@ | Forked Instance Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Forked Instance Identifier: 32-bit field containing the identifier of the particular forked instance. 5.15.8. Keepalive Timeout Option Format - This option is defined in [5]. + This option is defined in [4]. 6. Conceptual Model of a Host This section describes a conceptual model of one possible data structure organization that hosts will maintain for the purposes of Shim6. The described organization is provided to facilitate the explanation of how the Shim6 protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. @@ -2318,24 +2347,24 @@ o The context to expect in received control messages and payload extension headers - allocated by the local host; CT(local) o Timers for retransmission of the messages during context establishment and update messages. o Depending how an implementation determines whether a context is still in use, there might be a need to track the last time a packet was sent/received using the context. - o Reachability state for the locator pairs as specified in [5]. + o Reachability state for the locator pairs as specified in [4]. o During pair exploration, information about the probe messages that - have been sent and received as specified in [5]. + have been sent and received as specified in [4]. o During context establishment phase, Init Nonce, Responder Nonce, Responder Validator and timers related to the different packets sent (I1,I2, R2), as described in Section 7 6.2. Context STATES The STATES that are used to describe the Shim6 protocol are as follows: @@ -2410,93 +2439,93 @@ It is important that context tags are hard to guess for off-path attackers. Therefore, if an implementation uses structure in the context tag to facilitate efficient lookups, at least 30 bits of the context tag MUST be unstructured and populated by random or pseudo- random bits. In addition, in order to minimize the reuse of context tags, the host SHOULD randomly cycle through the unstructured tag name space reserved for randomly assigned context tag values,(e.g. following the - guidelines described in [13]). + guidelines described in [12]). 7.2. Locator Verification The peer's locators might need to be verified during context establishment as well as when handling locator updates in Section 10. There are two separate aspects of locator verification. One is to verify that the locator is tied to the ULID, i.e., that the host which "owns" the ULID is also the one that is claiming the locator "ownership". The Shim6 protocol uses the HBA or CGA techniques for doing this verification. The other is to verify that the host is indeed reachable at the claimed locator. Such verification is needed both to make sure communication can proceed, but also to prevent 3rd - party flooding attacks [15]. These different verifications happen at + party flooding attacks [14]. These different verifications happen at different times, since the first might need to be performed before packets can be received by the peer with the source locator in question, but the latter verification is only needed before packets are sent to the locator. Before a host can use a locator (different than the ULID) as the source locator, it must know that the peer will accept packets with that source locator as being part of this context. Thus the HBA/CGA verification SHOULD be performed by the host before the host acknowledges the new locator, by sending an Update Acknowledgement message, or an R2 message. Before a host can use a locator (different than the ULID) as the destination locator it MUST perform the HBA/CGA verification if this was not performed before upon the reception of the locator set. In addition, it MUST verify that the ULID is indeed present at that locator. This verification is performed by doing a return- - routability test as part of the Probe sub-protocol [5]. + routability test as part of the Probe sub-protocol [4]. If the verification method in the Locator List option is not supported by the host, or if the verification method is not consistent with the CGA Parameter Data Structure (e.g., the Parameter Data Structure doesn't contain the multiprefix extension, and the verification method says to use HBA), then the host MUST ignore the Locator List and the message in which it is contained, and the host SHOULD generate a Shim6 Error Message with Error Code=2, with the Pointer referencing the octet in the Verification method that was found inconsistent. 7.3. Normal context establishment The normal context establishment consists of a 4 message exchange in - the order of I1, R1, I2, R2 as can be seen in Figure 25. + the order of I1, R1, I2, R2 as can be seen in Figure 3. Initiator Responder IDLE IDLE ------------- I1 --------------> I1-SENT <------------ R1 --------------- IDLE ------------- I2 --------------> I2-SENT <------------ R2 --------------- ESTABLISHED ESTABLISHED - Figure 25: Normal context establishment + Figure 3: Normal context establishment 7.4. Concurrent context establishment When both ends try to initiate a context for the same ULID pair, then we might end up with crossing I1 messages. Alternatively, since no state is created when receiving the I1, a host might send a I1 after having sent a R1 message. Since a host remembers that it has sent an I1, it can respond to an I1 from the peer (for the same ULID-pair), with a R2, resulting in - the message exchange shown in Figure 26. Such behavior is needed for + the message exchange shown in Figure 4. Such behavior is needed for other reasons such as to correctly respond to retransmitted I1 messages, which occur when the R2 message has been lost. Host A Host B IDLE IDLE -\ I1-SENT---\ ---\ /--- --- I1 ---\ /--- I1-SENT @@ -2508,27 +2537,27 @@ -\ I1-SENT---\ ---\ /--- --- R2 ---\ /--- I1-SENT ---\ /--- R2 ---/ ---\ /--- --> <--- ESTABLISHED ESTABLISHED - Figure 26: Crossing I1 messages + Figure 4: Crossing I1 messages If a host has received an I1 and sent an R1, it has no state to remember this. Thus if the ULP on the host sends down packets, this might trigger the host to send an I1 message itself. Thus while one end is sending an I1 the other is sending an I2 as can be seen in - Figure 27. + Figure 5. Host A Host B IDLE IDLE -\ ---\ I1-SENT ---\ --- I1 ---\ ---\ ---\ @@ -2553,21 +2582,21 @@ -\ I2-SENT---\ ---\ /--- --- R2 ---\ /--- ---\ /--- R2 ---/ ---\ /--- --> <--- ESTABLISHED ESTABLISHED - Figure 27: Crossing I2 and I1 + Figure 5: Crossing I2 and I1 7.5. Context recovery Due to garbage collection, we can end up with one end having and using the context state, and the other end not having any state. We need to be able to recover this state at the end that has lost it, before we can use it. This need can arise in the following cases: @@ -2581,48 +2610,48 @@ o The host that retained the state sends a control message (e.g. an Update Request message). In all the cases the result is that the peer without state receives a shim message for which it has no context for the context tag. In all of those cases we can recover the context by having the node which doesn't have a context state, send back an R1bis message, and have then complete the recovery with a I2bis and R2 message as can be - seen in Figure 28. + seen in Figure 6. Host A Host B Context for CT(peer)=X Discards context for CT(local)=X ESTABLISHED IDLE ---- payload, probe, etc. -----> No context state for CT(local)=X <------------ R1bis ------------ IDLE ------------- I2bis -----------> I2BIS_SENT <------------ R2 --------------- ESTABLISHED ESTABLISHED - Figure 28: Context loss at receiver + Figure 6: Context loss at receiver If one end has garbage collected or lost the context state, it might try to create a new context state (for the same ULID pair), by sending an I1 message. The peer (that still has the context state) will reply with an R1 message and the full 4-way exchange will be - performed again in this case as can be seen in Figure 29. + performed again in this case as can be seen in Figure 7. Host A Host B Context for CT(peer)=X Discards context for ULIDs A1, B1 CT(local)=X ESTABLISHED IDLE Finds <------------ I1 --------------- Tries to setup @@ -2637,21 +2666,21 @@ <------------ I2 --------------- Recreate context with new CT(peer) I2-SENT and Ls(peer). ESTABLISHED ------------- R2 --------------> ESTABLISHED ESTABLISHED - Figure 29: Context loss at sender + Figure 7: Context loss at sender 7.6. Context confusion Since each end might garbage collect the context state we can have the case when one end has retained the context state and tries to use it, while the other end has lost the state. We discussed this in the previous section on recovery. But for the same reasons, when one host retains context tag X as CT(peer) for ULID pair , the other end might end up allocating that context tag as CT(local) for another ULID pair, e.g., between the same hosts. In this @@ -3268,77 +3297,52 @@ with the data contained in the I2 message and the host MUST send a R2 message back as specified in Section 7.14. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time as specified in Section 7.2. The context STATE remains unchanged. 8. Handling ICMP Error Messages The routers in the path as well as the destination might generate - various ICMP error messages, such as destination unreachable, packet - too big, and Unrecognized Next Header type. In some cases, it is - critical that these packets make it back up to the ULPs so that they - can take appropriate action. In other cases, it is probably the best - option to process these packets locally at the Shim6 layer and not - inform to the ULP. + ICMP error messages. In some cases, the Shim6 can take action and + solve the solve the problem that resulted in the error. In other + cases, the Shim6 layer can not solve the problem and it is critical + that these packets make it back up to the ULPs so that they can take + appropriate action. This is an implementation issue in the sense that the mechanism is completely local to the host itself. But the issue of how ICMP errors are correctly dispatched to the ULP on the host are important, hence this section specifies the issue. - The main issue to be consider is whether the reported error can be - solved by the Shim6 layer or not. In some cases, it is clear that - the shim6 layer cannot do anything to solve the problem reported by - the ICMP error e.g. Port unreachable, Packet too big error. In - these cases, the Shim6 layer should pass these messages to the ULP. - However, in some other cases, the reported error can be solved by the - Shim6 layer. For instance, in many of the cases, the Destination - unreachable error will be solved by the Shim6 layer by changing the - communication path. In this case, it maynot make sense to pass the - ICMP error to the ULP, since the problem will be solved by the Shim6 - layer. Nevertheless, it is not clear whether the Shim6 will be able - to actually solve the problem, since it may be the case that there is - no communication path available. So the basic guideline to handle - this situation is: if the Shim6 layer cannot do anything to solve the - problem reported in the ICMP error, then pass the error to the ULP as - described below. If the Shim6 layer can try to solve the problem, it - may make sense to not pass the error to the ULP. This, on the other - hand, may be implementations specific, meaning that depending what is - the response of the ULP to the ICMP error, it may be more or less - critical to actually passing or not the ICMP errors back. In other - words, if the response of a given ULP to the reception of an ICMP - error is to close the communication, it is very important that the - Shim6 layer does not passes the ICMP error unless it is certain that - there is no alternative path available. If the response of the ULP - is simply to ignore ICMP error, it may make sense to always pass the - ICMP errors to the ULP. In any case, we reccommend that the Shim6 - layer provides a configuration interface, so it is possible to - configure how to process the different ICMP error messages. Below, - we provide some guidelines on how to process the different ICMP - errors. + All ICMP messages MUST be delivered to the ULP in all cases except + when Shim6 successfully acts on the message (e.g. selects a new + path). There SHOULD be a configuration option to unconditionally + deliver all ICMP messages (including ones acted on by shim6) to the + ULP. - The following ICMP error messages should be processed by the Shim6 - layer and not passed to the ULP: ICMP error Destiantion unreachable - with codes 0 (No route to destination), 1 (Communication with - destination administratively prohibited), 2 (Beyond scope of source - address), 3 (Address unreachable), 5 (Source address failed ingress/ - egress policy), 6 (Reject route to destination), ICMP Time exceeded - error, ICMP Parameter problem error with the paramter that caused the - error being a Shim6 paramter. + According to that recommendation, the following ICMP error messages + should be processed by the Shim6 layer and not passed to the ULP: + ICMP error Destination unreachable with codes 0 (No route to + destination), 1 (Communication with destination administratively + prohibited), 2 (Beyond scope of source address), 3 (Address + unreachable), 5 (Source address failed ingress/egress policy), 6 + (Reject route to destination), ICMP Time exceeded error, ICMP + Parameter problem error with the parameter that caused the error + being a Shim6 parameter. The following ICMP error messages report problems that cannot be addressed by the Shim6 layer and that should be passed to the ULP (as described below): ICMP Packet too big error, ICMP Destination - Unreachable with Code 4 (Port unreachable) ICMP Paramenter problem - (if the paramter that caused the problem is not a Shim6 parameter). + Unreachable with Code 4 (Port unreachable) ICMP Parameter problem (if + the parameter that caused the problem is not a Shim6 parameter). +--------------+ | IPv6 Header | | | +--------------+ | ICMPv6 | | Header | - - +--------------+ - - | IPv6 Header | | src, dst as | Can be dispatched @@ -3346,34 +3350,34 @@ | on host | ICMP error handler Packet +--------------+ | ULP | in | Header | +--------------+ Error | | ~ Data ~ | | - - +--------------+ - - - Figure 30: ICMP error handling without payload extension header + Figure 8: ICMP error handling without payload extension header When the ULP packets are sent without the payload extension header, that is, while the initial locators=ULIDs are working, this introduces no new concerns; an implementation's existing mechanism - for delivering these errors to the ULP will work. See Figure 30. + for delivering these errors to the ULP will work. See Figure 8. But when the shim on the transmitting side inserts the payload extension header and replaces the ULIDs in the IP address fields with some other locators, then an ICMP error coming back will have a "packet in error" which is not a packet that the ULP sent. Thus the implementation will have to apply the reverse mapping to the "packet in error" before passing the ICMP error up to the ULP, including the - ICMP extensions defined in [25]. See Figure 31. + ICMP extensions defined in [24]. See Figure 9. +--------------+ | IPv6 Header | | | +--------------+ | ICMPv6 | | Header | - - +--------------+ - - | IPv6 Header | | src, dst as | Needs to be @@ -3384,21 +3388,21 @@ | Header | header removed in +--------------+ before it can be | Transport | dispatched to the ULP Error | Header | ICMP error handler. +--------------+ | | ~ Data ~ | | - - +--------------+ - - - Figure 31: ICMP error handling with payload extension header + Figure 9: ICMP error handling with payload extension header Note that this mapping is different than when receiving packets from the peer with a payload extension headers, because in that case the packets contain CT(local). But the ICMP errors have a "packet in error" with an payload extension header containing CT(peer). This is because they were intended to be received by the peer. In any case, since the has to be unique when received by the peer, the local host should also only be able to find one context that matches this tuple. @@ -3593,21 +3597,21 @@ Once the Locator List option (if present) has been verified and any new locator list or locator preferences have been recorded, the host sends an Update Acknowledgement message, copying the nonce from the request, and using the CT(peer) in as the Receiver Context Tag. Any new locators, or more likely new locator preferences, might result in the host wanting to select a different locator pair for the context. For instance, if the Locator Preferences lists the current Lp(peer) as BROKEN. The host uses the reachability exploration - procedure described in [5] to verify that the new locator is + procedure described in [4] to verify that the new locator is reachable before changing Lp(peer). 10.5. Receiving Update Acknowledgement messages A host MUST silently discard any received Update Acknowledgement messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3: o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets. @@ -3659,21 +3663,21 @@ needs to verify whether context uses the ULIDs as locators, that is, whether Lp(peer) == ULID(peer) and Lp(local) == ULID(local). If this is the case, then packets can be sent unmodified by the shim. If it is not the case, then the logic in Section 11.1 will need to be used. There will also be some maintenance activity relating to (un)reachability detection, whether packets are sent with the original locators or not. The details of this is out of scope for - this document and is specified in [5]. + this document and is specified in [4]. 11.1. Sending ULP Payload after a Switch When sending packets, if there is a ULID-pair context for the ULID pair, and the ULID pair is no longer used as the locator pair, then the sender needs to transform the packet. Apart from replacing the IPv6 source and destination fields with a locator pair, an 8-octet header is added so that the receiver can find the context and inverse the transformation. @@ -3716,21 +3720,21 @@ packet must be passed to the Shim6 payload handling for rewriting. Otherwise, the packet is passed to the Shim6 control handling. 12.1. Receiving payload without extension headers The receiver extracts the IPv6 source and destination fields, and uses this to find a ULID-pair context, such that the IPv6 address fields match the ULID(local) and ULID(peer). If such a context is found, the context appears not to be quiescent and this should be remembered in order to avoid tearing down the context and for - reachability detection purposes as described in [5]. The host + reachability detection purposes as described in [4]. The host continues with the normal processing of the IP packet. 12.2. Receiving Payload Extension Headers The receiver extracts the context tag from the payload extension header, and uses this to find a ULID-pair context. If no context is found, the receiver SHOULD generate a R1bis message (see Section 7.17). Then, depending on the STATE of the context: @@ -3853,21 +3857,21 @@ as described in Section 2. At that point in time there is no activity in the shim. Whether the shim ends up being used or not (e.g., the peer might not support Shim6) it is highly desirable that the initial contact can be established even if there is a failure for one or more IP addresses. The approach taken is to rely on the applications and the transport protocols to retry with different source and destination addresses, consistent with what is already specified in Default Address - Selection [8], and some fixes to that specification [9] to make it + Selection [7], and some fixes to that specification [8] to make it try different source addresses and not only different destination addresses. The implementation of such an approach can potentially result in long timeouts. For instance, a naive implementation at the socket API which uses getaddrinfo() to retrieve all destination addresses and then tries to bind() and connect() to try all source and destination address combinations waiting for TCP to time out for each combination before trying the next one. @@ -3923,21 +3927,21 @@ 15. Implications Elsewhere 15.1. Congestion Control Considerations When the locator pair currently used for exchanging packets in a Shim6 context becomes unreachable, the Shim6 layer will divert the communication through an alternative locator pair, which in most cases will result in redirecting the packet flow through an alternative network path. In this case, it recommended that the - Shim6 follows the recommendation defined in [21] and it informs the + Shim6 follows the recommendation defined in [20] and it informs the upper layers about the path change, in order to allow the congestion control mechanisms of the upper layers to react accordingly. 15.2. Middle-boxes considerations Data packets belonging to a Shim6 context carrying the Shim6 Payload Header contain alternative locators other than the ULIDs in the source and destination address fields of the IPv6 header. On the other hand, the upper layers of the peers involved in the communication operate on the ULID pair presented by the Shim6 layer @@ -4035,30 +4039,30 @@ configuration can increase the operation work in a network. However, it should be noted that the capability of having multiupl prefixes in a site and multiple addresses assigned to an interface is an IPv6 capability that goes beyond the Shim6 case and it is expected to be widely used. So, even though this is the case for Shim6, we consider that the implications of such a configuration is beyond the particular case of Shim6 and must be addressed for the generic IPv6 case. Nevertheless, Shim6 also assumes the usage of CGA/HBA addresses by Shim6 hosts. this implies that Shim6 capable hosts should configure addresses using HBA/CGA generation mechanims. - Additional consideration about this issue can be found at [19] + Additional consideration about this issue can be found at [18] 15.4. Other considerations The general Shim6 approach, as well as the specifics of this proposed solution, has implications elsewhere, including: o Applications that perform referrals, or callbacks using IP addresses as the 'identifiers' can still function in limited ways, - as described in [18]. But in order for such applications to be + as described in [17]. But in order for such applications to be able to take advantage of the multiple locators for redundancy, the applications need to be modified to either use fully qualified domain names as the 'identifiers', or they need to pass all the locators as the 'identifiers' i.e., the 'identifier' from the applications perspective becomes a set of IP addresses instead of a single IP address. o Signaling protocols for QoS or other things that involve having devices in the network path look at IP addresses and port numbers, or IP addresses and Flow Labels, need to be invoked on the hosts @@ -4071,37 +4075,37 @@ the flow label stays the same. o MTU implications. The path MTU mechanisms we use are robust against different packets taking different paths through the Internet, by computing a minimum over the recently observed path MTUs. When Shim6 fails over from using one locator pair to another pair, this means that packets might travel over a different path through the Internet, hence the path MTU might be quite different. In order to deal with this changes in the MTU, the usage of Packetization Layer Path MTU Discovery as defined in - [24] is reccommended. + [23] is reccommended. The fact that the shim will add an 8 octet Payload Extension header to the ULP packets after a locator switch, can also affect the usable path MTU for the ULPs. In this case the MTU change is local to the sending host, thus conveying the change to the ULPs is an implementation matter. By conveying the information to the transport layer, it can adapt and reduce the MSS accordingly. 16. Security Considerations - This document satisfies the concerns specified in [15] as follows: + This document satisfies the concerns specified in [14] as follows: - o The HBA [2] and CGA technique [4] for verifying the locators to + o The HBA [2] and CGA technique [3] for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else, preventing threats described in sections 4.1.1, - 4.1.2, 4.1.3 and 4.2 of [15]. These two approaches provide a + 4.1.2, 4.1.3 and 4.2 of [14]. These two approaches provide a similar level of protection but they provide different functionality with a different computational cost. The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix-set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using the shim protocol node can efficiently verify that the @@ -4110,93 +4114,140 @@ calculation. In a CGA based approach the address used as ULID is a CGA that contains a hash of a public key in its interface identifier. The result is a secure binding between the ULID and the associated key pair. This allows each peer to use the corresponding private key to sign the shim messages that convey locator set information. The trust chain in this case is the following: the ULID used for the communication is securely bound to the key pair because it contains the hash of the public key, and the locator set is bound to the public key through the signature. Any of these two mechanisms HBA and CGA provide time- - shifted attack protection (as described in section 4.1.2 of [15]), + shifted attack protection (as described in section 4.1.2 of [14]), since the ULID is securely bound to a locator set that can only be defined by the owner of the ULID. The minimum acceptable key length for RSA keys used in the generation of CGAs MUST be at least 1024 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths. - o 3rd party flooding attacks described in section 4.3 of [15] are + o 3rd party flooding attacks described in section 4.3 of [14] are prevented by requiring a Shim6 peer to perform a successful Reachability probe + reply exchange before accepting a new locator for use as a packet destination.. o The first message does not create any state on the responder. Essentially a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all of memory on the responder) at least requires the attacker to create state, consuming his own resources and also it provides an IPv6 address that the attacker was using. o The context establishment messages use nonces to prevent replay - attacks as described in section 4.1.4 of [15], and to prevent off- + attacks as described in section 4.1.4 of [14], and to prevent off- path attackers from interfering with the establishment. 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 [15]. Such discovery probably + 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. - Interaction with IPsec - - The Shim6 sub-layer is implemented below the IPsec layer within the - IP layer. This deserves some additional considerations for a couple - of specific cases: First, it should be noted that the Shim6 approach - does not preclude using IPsec tunnels on Shim6 packets within the - network transit path. Second, in case that IPsec is implemented as - Bump-In-The-Wire (BITW) [3], either the shim MUST be disabled, or the - shim MUST also be implemented as Bump-In-The-Wire, in order to - satisfy the requirement that IPsec is layered above the shim. - - If a shim6 node has some protected and some unprotected interfaces - [RFC 4301] for the purposes of IPsec, then it MUST treat the locator - sets for the protected and unprotected interfaces as separate locator - sets and not intermix them. This ensures that shim6 will never - failover from using a protected interface to using an unprotected - interface and vice versa. +16.1. Interaction with IPsec - 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. + 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.) 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. - In order for a BITS and BITW IPsec implementation on a host as well + 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 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. + +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 context tags that are being used, and once known it can use those to send bogus messages. @@ -4362,21 +4413,21 @@ 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 filtering based on the source IPv6 address, there is a need for the host to be able to influence the egress selection from its - site. Further discussion of this issue is captured in [16]. + site. Further discussion of this issue is captured in [15]. o Is there need for keeping the list of locators private between the two communicating endpoints? We can potentially accomplish that when using CGA but not with HBA, but it comes at the cost of doing some public key encryption and decryption operations as part of the context establishment. The suggestion is to leave this for a future extension to the protocol. o Defining some form of end-to-end "compression" mechanism that removes the need for including the Shim6 Payload extension header @@ -4428,21 +4479,21 @@ host". But if we don't expect more than a handful locators per host, then we don't need this added complexity. 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 [17]. + initial draft on this topic [16]. Appendix B. 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: @@ -4777,20 +4828,22 @@ 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 + 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 @@ -4939,21 +4992,21 @@ the communication and it also allows nodes to define at which stage of the communication they decide, based on their own policies, that a given communication requires to be protected by the shim. In order to cope with the identified limitations, an alternative approach that does not constraints the flow label values used by communications that are using ULIDs equal to the locators (i.e. no shim translation) is to only require that different flow label values are assigned to different shim contexts. In such approach communications start with unmodified flow label usage (could be zero, - or as suggested in [12]). The packets sent after a failure when a + or as suggested in [11]). The packets sent after a failure when a different locator pair is used would use a completely different flow label, and this flow label could be allocated by the receiver as part of the shim context establishment. Since it is allocated during the context establishment, the receiver of the "failed over" packets can pick a flow label of its choosing (that is unique in the sense that no other context is using it as a context tag), without any performance impact, and respecting that for each locator pair, the flow label value used for a given locator pair doesn't change due to the operation of the multihoming shim. @@ -5116,21 +5169,21 @@ 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 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 [15]. The goal in terms of + 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 protocol. In this appendix we will present some of them. The simplest option to protect the shim protocol was to use cookies i.e. a randomly generated bit string that is negotiated during the @@ -5183,30 +5236,30 @@ set that can be used to exchange packets. The mechanism provided by IPsec to securely bind the address used with the cryptographic keys is the usage of digital certificates. This implies that an IPsec based solution would require that the generation of digital certificates that bind the key and the ULID by a common third trusted party for both parties involved in the communication. Considering that the scope of application of the shim protocol is global, this would imply a global public key infrastructure. The major issues with this approach are the deployment difficulties associated with a global PKI. The other possibility would be to use some form of - opportunistic IPSec, like BTNS [22]. However, this would still + opportunistic IPSec, like BTNS [21]. However, this would still present some issues, in particular, this approach requires a leap-of- faith in order to bind a given address to the public ky that is being used, which would actually prevent from providing the most critical security feature that a Shim6 security solution needs to achieve, i.e. proving identifier ownership. On top of that, using IPsec would require to turn on per-packet AH/ESP just for multihoming to occur. Finally two different technologies were selected to protect the shim - protocol: HBA [4] and CGA [2]. These two approaches provide a + protocol: HBA [3] and CGA [2]. These two approaches provide a similar level of protection but they provide different functionality with a different computational cost. The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix-set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using @@ -5321,21 +5374,21 @@ 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, a No-Context error message may be required to inform about the situation and possibly a recovery mechanism is also needed. A coordinated approach would use an explicit CLOSE mechanism, akin to - the one specified in HIP [20]. If an explicit CLOSE handshake and + the one specified in HIP [19]. If an explicit CLOSE handshake and associated timer is used, then there would no longer be a need for the No Context Error message due to a peer having garbage collected its end of the context. However, there is still potentially a need to have a No Context Error message in the case of a complete state loss of the peer (also known as a crash followed by a reboot). Only if we assume that the reboot takes at least the CLOSE timer, or that it is ok to not provide complete service until CLOSE timer minutes after the crash, can we completely do away with the No Context Error message. @@ -5381,43 +5434,49 @@ 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 [RFC Editor: please remove this section] + 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 o Added text on why oportunistic IPSec was not used for securing locator sets o Reowrded the Validator generation text to make it clearer o Reworded security considerations to explicitly address RFC 4218 threats o Added OandM section o Added text on TE considerations o Added requirement to properly support RFC4884 icmp messages - o added th usage of Packetization Layer Path MTU Discovery + o Added th usage of Packetization Layer Path MTU Discovery - o reworded the placement of shim6 w.r.t. ipsec + o Reworded the placement of shim6 w.r.t. IPsec - o added text on the IPsec considerations + o Added text on the IPsec considerations The following changes have been made since draft-ietf-shim6-proto-08: o Clarified that the validator option must be included in R1 and I2 messages o changed preferred peer/local locator to current peer/local locator to align it with faliure detection draft o Reworded sections describing the generation and reception of @@ -5575,21 +5633,21 @@ o Replaced the Context Error message with the R1bis message. o Removed the Packet In Error option, since it was only used in the Context Error message. o Introduced a I2bis message which is sent in response to an I1bis message, since the responders processing is quite in this case than in the regular R1 case. o Moved the packet formats for the Keepalive and Probe message types - and Event option to [5]. Only the message type values and option + and Event option to [4]. Only the message type values and option type value are specified for those in this document. o Removed the unused message types. o Added a state machine description as an appendix. o Filled in all the TBDs - except the IANA assignment of the protocol number. o Specified how context recovery and forked contexts work together. @@ -5677,104 +5735,101 @@ 19. References 19.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] Kent, S. and K. Seo, "Security Architecture for the Internet - Protocol", RFC 4301, December 2005. - - [4] Bagnulo, M., "Hash Based Addresses (HBA)", + [3] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-shim6-hba-05 (work in progress), December 2007. - [5] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair + [4] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", - draft-ietf-shim6-failure-detection-11 (work in progress), - February 2008. + draft-ietf-shim6-failure-detection-13 (work in progress), + June 2008. 19.2. Informative References - [6] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + [5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. - [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: + [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. - [8] Draves, R., "Default Address Selection for Internet Protocol + [7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. - [9] Bagnulo, M., "Updating RFC 3484 for multihoming support", + [8] Bagnulo, M., "Updating RFC 3484 for multihoming support", draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), December 2005. - [10] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + [9] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. - [11] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- + [10] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. - [12] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 + [11] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. - [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + [12] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. - [14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. - [15] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming + [14] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. - [16] Huitema, C., "Ingress filtering compatibility for IPv6 + [15] Huitema, C., "Ingress filtering compatibility for IPv6 multihomed sites", draft-huitema-shim6-ingress-filtering-00 (work in progress), September 2005. - [17] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", + [16] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", draft-bagnulo-shim6-mip-00 (work in progress), July 2005. - [18] Nordmark, E., "Shim6 Application Referral Issues", + [17] Nordmark, E., "Shim6 Application Referral Issues", draft-ietf-shim6-app-refer-00 (work in progress), July 2005. - [19] Bagnulo, M. and J. Abley, "Applicability Statement for the + [18] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", draft-ietf-shim6-applicability-03 (work in progress), July 2007. - [20] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, + [19] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-10 (work in progress), October 2007. - [21] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., + [20] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change - Indications", draft-schuetz-tcpm-tcp-rlci-02 (work in - progress), November 2007. + Indications", draft-schuetz-tcpm-tcp-rlci-03 (work in + progress), February 2008. - [22] Williams, N. and M. Richardson, "Better-Than-Nothing-Security: - An Unauthenticated Mode of IPsec", draft-ietf-btns-core-06 - (work in progress), January 2008. + [21] Williams, N. and M. Richardson, "Better-Than-Nothing-Security: + An Unauthenticated Mode of IPsec", draft-ietf-btns-core-07 + (work in progress), August 2008. - [23] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket + [22] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket Application Program Interface (API) for Multihoming Shim", - draft-ietf-shim6-multihome-shim-api-04 (work in progress), - February 2008. + draft-ietf-shim6-multihome-shim-api-07 (work in progress), + November 2008. - [24] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + [23] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. - [25] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended + [24] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. Authors' Addresses Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA @@ -5783,55 +5838,10 @@ Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: +34 91 6248814 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).