3.2.3. Rekeying IKE SAs When Responder's Cryptographic Suites Changed
At the time of or before rekeying IKE SAs, the responder's
cryptographic suites may be changed while there is no change of
initiator's cryptographic suites. New cryptographic suites may be
added to the responder, or some outdated cryptographic suites may be
deleted from the responder.
In this situation, the initiator sends the SA_UNCHANGED notification
payload instead of the SA payloads in the CREATE_CHILD_SA request
message at the time of rekeying IKE SAs.
Kampati, et al. Expires November 22, 2019 [Page
5]Internet-Draft IKEv2 Optional Child SA&TS Payloads May
2019
If the responder decides to continue using the previously negotiated
cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED
notification payload in the CREATE_CHILD_SA response message, then
the rekeying is conducted like Section 3.2.1.
If the responder decides to re-negotiate the cryptographic suite, it
MUST send NO_PROPOSAL_CHOSEN notification payload in the
CREATE_CHILD_SA response message. After receiving this error
notification, the initiator MUST retry the CREATE_CHILD_SA exchange
with the SA payloads. Then the rekeying is conducted in the original
way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in
this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
Nr, KEr}
HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {SA, *Ni, KEi*}
Comment :
1. If the responder decides to continue using the previously negotiated
cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED
notification payload in the CREATE_CHILD_SA response message, then
the rekeying is conducted like Section 3.2.1.
>> Better to put exchange diagram for this case also.
2. Nonce and KE notations are not correct in the response message
If the responder decides to re-negotiate the cryptographic suite, it
MUST send NO_PROPOSAL_CHOSEN notification payload in the
CREATE_CHILD_SA response message. After receiving this error
notification, the initiator MUST retry the CREATE_CHILD_SA exchange
with the SA payloads. Then the rekeying is conducted in the original
way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in
this case is shown below:
Initiator Responder
--------------------------------------------------------------------
HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
<-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
Nr, KEr}
HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {SA, *Ni, KEi*}
>> In CREATE_CHILD_SA response message, responder MUST not send the same Nonce
>> and KE received from initiator (Ni, KEi).
It MUST be Nr and KEr in the response message.
On Thu, May 23, 2019 at 12:30 AM <[email protected]> wrote:
> Send IPsec mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IPsec digest..."
>
>
> Today's Topics:
>
> 1. Fwd: New Version Notification for
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
> (Panwei (William))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 22 May 2019 07:37:17 +0000
> From: "Panwei (William)" <[email protected]>
> To: Paul Wouters <[email protected]>, Y Sowji <[email protected]>,
> "[email protected]" <[email protected]>
> Cc: Sandeep Kampati <[email protected]>, "Meduri S S Bharath
> (A)" <[email protected]>
> Subject: [IPsec] Fwd: New Version Notification for
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
> Message-ID:
> <
> 30e95a901db42f44ba42d69db20dfa6a69f68...@nkgeml513-mbx.china.huawei.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Paul, Sowjanya and folks,
>
>
>
> Thanks a lot for Paul and Sowjanya?s reviews, we have modified our draft
> based on your comments.
>
>
>
> The new version draft includes the following main changes:
>
> 1. Redesign the sections to make the structure more reasonable and the
> draft more readable.
>
> 2. Change the negotiation of support to the IKE_AUTH phase, and change the
> support notification?s name.
>
> 3. Detail the optimization for rekeying IKE SAs, and use SA_UNCHANGED
> notification payload to replace SA payloads.
>
> 4. Detail the optimization for rekeying Child SAs, and use SA_TS_UNCHANGED
> notification payload to replace SA and TS payload.
>
> 5. For rekeying Child SAs, we currently remove the consideration that only
> omitting TS payloads, because we think this kind omitting will introduce
> more complexities. Initiator SA payload, Initiator TS payload, Responder SA
> payload and Responder TS payload, if either of these four payloads can be
> omitted, there will be up to 16 circumstances, that will be too complex.
>
>
>
> Comments and reviews for the new version draft are very welcome.
>
>
>
> Best Regards
>
> Wei Pan
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, May 22, 2019 2:17 PM
> To: Meduri S S Bharath (A) <[email protected]>; Meduri S S
> Bharath (A) <[email protected]>; Panwei (William) <
> [email protected]>; Sandeep Kampati <[email protected]>
> Subject: New Version Notification for
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
>
>
>
>
>
> A new version of I-D, draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
>
> has been successfully submitted by Wei Pan and posted to the IETF
> repository.
>
>
>
> Name: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
>
> Revision: 01
>
> Title: IKEv2 Optional SA&TS Payloads in Child Exchange
>
> Document date: 2019-05-21
>
> Group: Individual Submission
>
> Pages: 11
>
> URL:
> https://www.ietf.org/internet-drafts/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt/
>
> Htmlized:
> https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01
>
>
>
> Abstract:
>
> This document describes a method for reducing the size of the
>
> Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying
>
> IKE SAs and Child SAs by removing or making optional of SA & TS
>
> payloads. Reducing size of IKEv2 exchanges is desirable for low
>
> power consumption battery powered devices. It also helps to avoid IP
>
> fragmentation of IKEv2 messages.
>
>
>
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
>
>
> The IETF Secretariat
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/ipsec/attachments/20190522/fa389580/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> ------------------------------
>
> End of IPsec Digest, Vol 181, Issue 4
> *************************************
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
