| < draft-smyslov-ipsecme-ikev2-r-mobike-01.txt | draft-smyslov-ipsecme-ikev2-r-mobike-02.txt > | |||
|---|---|---|---|---|
| Network Working Group V. Smyslov | Network Working Group V. Smyslov | |||
| Internet-Draft ELVIS-PLUS | Internet-Draft ELVIS-PLUS | |||
| Updates: 4555, 6311 (if approved) November 30, 2017 | Updates: 4555, 6311 (if approved) May 30, 2018 | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: June 3, 2018 | Expires: December 1, 2018 | |||
| Responder Initiated IP Addresses Update in MOBIKE | Responder Initiated IP Addresses Update in MOBIKE | |||
| draft-smyslov-ipsecme-ikev2-r-mobike-01 | draft-smyslov-ipsecme-ikev2-r-mobike-02 | |||
| Abstract | Abstract | |||
| IKEv2 Mobility and Multihoming Protocol (MOBIKE) allows peers to | IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in | |||
| update their IP addresses without re-establishing IKE and IPsec | [RFC4555] allows peers to update their IP addresses without re- | |||
| Security Associations (SAs). In the MOBIKE protocol it is the | establishing IKE and IPsec Security Associations (SAs). In the | |||
| Initiator of the IKE SA, who is responsible for selecting new SA | MOBIKE protocol it is the Initiator of the IKE SA, who is responsible | |||
| addresses and for initiating the IP addresses update procedure. This | for selecting new SA addresses and for initiating the IP addresses | |||
| document presents an extension to the MOBIKE protocol that allows the | update procedure. This document presents an extension to the MOBIKE | |||
| Responder to initiate the update. | protocol that allows the Responder to initiate IP address update. | |||
| The document updates [RFC4555] and [RFC6311]. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on June 3, 2018. | This Internet-Draft will expire on December 1, 2018. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| skipping to change at page 3, line 26 ¶ | skipping to change at page 3, line 27 ¶ | |||
| IP addresses to move an SA to and the VPN gateway has no means to | IP addresses to move an SA to and the VPN gateway has no means to | |||
| provide the client with this information. | provide the client with this information. | |||
| This specification extends the MOBIKE protocol by adding ability for | This specification extends the MOBIKE protocol by adding ability for | |||
| the Responder to ask the Initiator for IP address update and to | the Responder to ask the Initiator for IP address update and to | |||
| provide it with the new IP address to use. | provide it with the new IP address to use. | |||
| 2. Terminology and Notation | 2. Terminology and Notation | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| document are to be interpreted as described in [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
| capitals, as shown here. | ||||
| In this document the term "Initiator" means the party who originally | In this document the term "Initiator" means the party who originally | |||
| initiated the first IKE SA (in a series of possibly several rekeyed | initiated the first IKE SA (in a series of possibly several rekeyed | |||
| IKE SAs), and "Responder" means the other party. This is consistent | IKE SAs), and "Responder" means the other party. This is consistent | |||
| with a way these terms are used in [RFC4555]. Note, that in | with a way these terms are used in [RFC4555]. Note, that in | |||
| [RFC7296] the terms "original initiator" and "original responder" | [RFC7296] the terms "original initiator" and "original responder" | |||
| mean the party, who initiated (or responded to) the latest IKE SA in | mean the party, who initiated (or responded to) the latest IKE SA in | |||
| a series of possibly several rekeyed IKE SAs. | a series of possibly several rekeyed IKE SAs. | |||
| 3. Protocol Overview | 3. Protocol Overview | |||
| skipping to change at page 8, line 7 ¶ | skipping to change at page 8, line 7 ¶ | |||
| Availability (HA) goals may be achieved. For the purposes of HA all | Availability (HA) goals may be achieved. For the purposes of HA all | |||
| the nodes share an IKE SA state while only one of them communicate | the nodes share an IKE SA state while only one of them communicate | |||
| with an IKE SA peer at any given time. If an active node fails, the | with an IKE SA peer at any given time. If an active node fails, the | |||
| other nodes detect this fact and select a new active node for the SAs | other nodes detect this fact and select a new active node for the SAs | |||
| the failed node served. The selected node must then instruct the | the failed node served. The selected node must then instruct the | |||
| failed node peers to switch their SAs to a new IP address using this | failed node peers to switch their SAs to a new IP address using this | |||
| specification. | specification. | |||
| Since some exchanges might be in progress when the active node fails, | Since some exchanges might be in progress when the active node fails, | |||
| special measures must be taken to ensure that the IKE SA state is | special measures must be taken to ensure that the IKE SA state is | |||
| synchronised between the new active cluster node and the client. | synchronized between the new active cluster node and the client. | |||
| Protocol Support for High Availability of IKEv2/IPsec [RFC6311] | Protocol Support for High Availability of IKEv2/IPsec [RFC6311] | |||
| describes the necessary measures. In particular, the new active node | describes the necessary measures. In particular, the new active node | |||
| initiates the INFORMATIONAL exchange containing the | initiates the INFORMATIONAL exchange containing the | |||
| IKEV2_MESSAGE_ID_SYNC notification and optionally the | IKEV2_MESSAGE_ID_SYNC notification and optionally the | |||
| IPSEC_REPLAY_COUNTER_SYNC notification. [RFC6311] states that no | IPSEC_REPLAY_COUNTER_SYNC notification. [RFC6311] states that no | |||
| other payload must be included in this exchange. However, in case | other payload must be included in this exchange. However, in case | |||
| the IP address of the new active node differs from the IP address of | the IP address of the new active node differs from the IP address of | |||
| the failed active node it is necessary to combine the | the failed active node it is necessary to combine the | |||
| IKEV2_MESSAGE_ID_SYNC and the SWITCH_TO_IP_ADDRESS notifications in | IKEV2_MESSAGE_ID_SYNC and the SWITCH_TO_IP_ADDRESS notifications in | |||
| one exchange. So, this specification updates [RFC6311] in this | one exchange. So, this specification updates [RFC6311] in this | |||
| skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 5 ¶ | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | |||
| editor.org/info/rfc2119>. | editor.org/info/rfc2119>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | |||
| (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | |||
| <https://www.rfc-editor.org/info/rfc4555>. | <https://www.rfc-editor.org/info/rfc4555>. | |||
| [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. | [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. | |||
| Zhang, "Protocol Support for High Availability of IKEv2/ | Zhang, "Protocol Support for High Availability of IKEv2/ | |||
| IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, | IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, | |||
| <https://www.rfc-editor.org/info/rfc6311>. | <https://www.rfc-editor.org/info/rfc6311>. | |||
| [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
| End of changes. 9 change blocks. | ||||
| 15 lines changed or deleted | 22 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||