Re: [IPsec] IPsec Digest, Vol 181, Issue 4

"Panwei (William)" <william.panwei@huawei.com> Thu, 01 August 2019 08:13 UTC

Return-Path: <william.panwei@huawei.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C91120075 for <ipsec@ietfa.amsl.com>; Thu, 1 Aug 2019 01:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU0e8YEDwwMm for <ipsec@ietfa.amsl.com>; Thu, 1 Aug 2019 01:12:58 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081A512006E for <ipsec@ietf.org>; Thu, 1 Aug 2019 01:12:58 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 732E26F51B2E41EC887F; Thu, 1 Aug 2019 09:12:55 +0100 (IST)
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 1 Aug 2019 09:12:55 +0100
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 1 Aug 2019 09:12:53 +0100
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 1 Aug 2019 09:12:52 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.136]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Thu, 1 Aug 2019 16:12:48 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: shubham mamodiya <shubhammamodiya@gmail.com>
CC: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] IPsec Digest, Vol 181, Issue 4
Thread-Index: AQHVSDbWMKNqODm8FUSYFkgXS7z0Aqbl5f6w
Date: Thu, 1 Aug 2019 08:12:47 +0000
Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A6DE200B0@nkgeml513-mbx.china.huawei.com>
References: <mailman.79.1558551616.30519.ipsec@ietf.org> <CAPz_mZMX_HP-PxktZyxHyOOEZW=Dx8E1jd0F+y51CZnbqUGnaw@mail.gmail.com>
In-Reply-To: <CAPz_mZMX_HP-PxktZyxHyOOEZW=Dx8E1jd0F+y51CZnbqUGnaw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.37.117]
Content-Type: multipart/alternative; boundary="_000_30E95A901DB42F44BA42D69DB20DFA6A6DE200B0nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/DZ4qCifpBCI921rMXvu3ZVns0_U>
Subject: Re: [IPsec] IPsec Digest, Vol 181, Issue 4
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 08:13:02 -0000

Hi Shubham,

Thanks for your review and comments. We’ll fix them in next version.

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of shubham mamodiya
Sent: Thursday, August 01, 2019 3:00 PM
To: ipsec@ietf.org
Subject: Re: [IPsec] IPsec Digest, Vol 181, Issue 4


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 <ipsec-request@ietf.org<mailto:ipsec-request@ietf.org>> wrote:
Send IPsec mailing list submissions to
        ipsec@ietf.org<mailto:ipsec@ietf.org>

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
        ipsec-request@ietf.org<mailto:ipsec-request@ietf.org>

You can reach the person managing the list at
        ipsec-owner@ietf.org<mailto:ipsec-owner@ietf.org>

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)" <william.panwei@huawei.com<mailto:william.panwei@huawei.com>>
To: Paul Wouters <paul@nohats.ca<mailto:paul@nohats.ca>>, Y Sowji <sowji_eluri@yahoo.com<mailto:sowji_eluri@yahoo.com>>,
        "ipsec@ietf.org<mailto:ipsec@ietf.org>" <ipsec@ietf.org<mailto:ipsec@ietf.org>>
Cc: Sandeep Kampati <sandeepkampati@huawei.com<mailto:sandeepkampati@huawei.com>>, "Meduri S S Bharath
        (A)" <MeduriS.Bharath@huawei.com<mailto:MeduriS.Bharath@huawei.com>>
Subject: [IPsec] Fwd: New Version Notification for
        draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
Message-ID:
        <30E95A901DB42F44BA42D69DB20DFA6A69F68ABE@nkgeml513-mbx.china.huawei.com<mailto:30E95A901DB42F44BA42D69DB20DFA6A69F68ABE@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: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
Sent: Wednesday, May 22, 2019 2:17 PM
To: Meduri S S Bharath (A) <MeduriS.Bharath@huawei.com<mailto:MeduriS.Bharath@huawei.com>>; Meduri S S Bharath (A) <MeduriS.Bharath@huawei.com<mailto:MeduriS.Bharath@huawei.com>>; Panwei (William) <william.panwei@huawei.com<mailto:william.panwei@huawei.com>>; Sandeep Kampati <sandeepkampati@huawei.com<mailto:sandeepkampati@huawei.com>>
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<http://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
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec


------------------------------

End of IPsec Digest, Vol 181, Issue 4
*************************************