Subject: Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt

From: "Panwei (William)" <[email-masked]>
Date: Mon, 5 Jul 2021 08:05:59 +0000

Hi,

According to the discussion on the mailing list, I update the draft to version 05. In this version, I deleted the unnecessary considerations for the configuration changes. For now, the solution is very simple and just includes the negotiation at creating IKE SAs and optimization at rekeying IKE and Child SAs.

Comments and feedbacks are more than welcome.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Monday, July 5, 2021 12:24 PM
> To: [email-masked]
> Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : IKEv2 Optional SA&TS Payloads in Child
> Exchange
>         Authors         : Sandeep Kampati
>                           Wei Pan
>                           Meduri S S Bharath
>                           Meiling Chen
> 	Filename        :
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
> 	Pages           : 9
> 	Date            : 2021-07-04
> 
> 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.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa
> ds-opt/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p
> ayloads-opt-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo
> ads-opt-05
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Wouters <[email-masked]>
Date: Sun, 11 Jul 2021 23:38:21 -0400

Hmm, it used to be that if you are subscribed to one IETF list, you can
post to any of them. That does not seem to work for the ipsec list :/

---------- Forwarded message ---------
From: Paul Wouters <[email-masked]>
Date: Sun, Jul 11, 2021 at 11:34 PM
Subject: Re: [IPsec] I-D Action:
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
To: Panwei (William) <[email-masked]>
Cc: [email-masked] <[email-masked]>

On Mon, 5 Jul 2021, Panwei (William) wrote:

Hi Wei Pan,

> According to the discussion on the mailing list, I update the draft to
version 05. In this version, I deleted the unnecessary considerations for
the configuration changes. For now, the solution is very simple and just
includes the negotiation at creating IKE SAs and optimization at rekeying
IKE and Child SAs.
> Comments and feedbacks are more than welcome.

It is lookger much better and simpler, but I still had a few issues and
wanted to make the document a bit shorter and clearer.  I made some
changes for your consideration. I've attached an updated xml and txt file
in case you would like to use my changes. The changes are:

- Reduced the text that was used to explain a lot of IKEv2 basics.

Instead, a reference to IKEv2 should be enough. This greatly simplifies
the text.

- Remove the parts about "changed configuration".

If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296
says this:

    In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
    different Traffic Selectors and algorithms than the old one" was
    changed to "Note that, when rekeying, the new Child SA SHOULD NOT
    have different Traffic Selectors and algorithms than the old one".

So if the configuration has changed, you should not do any kind of REKEY,
whether it is OPTIMIZED or not. You should do a re-authentication (in
other words, a new IKE from scratch)

- IKE REKEY MUST contain KE, because RFC 7296 says:

    The main reason for rekeying the IKE SA is to ensure that the
    compromise of old keying material does not provide information about
    the current keys, or vice versa.  Therefore, implementations MUST
    perform a new Diffie-Hellman exchange when rekeying the IKE SA.  In
    other words, an initiator MUST NOT propose the value "NONE" for the
    Diffie-Hellman transform, and a responder MUST NOT accept such a
    proposal.  This means that a successful exchange rekeying the IKE SA
    always includes the KEi/KEr payloads.

- Removed: It also helps to avoid IP fragmentation of IKEv2 messages

I don't think this is actually true, since on rekey there are no required
CERT payloads, which is the vast majority of the payload size in IKE_AUTH
that causes fragmentation.

- Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED}

This matches better with the OPTIMIZED_REKEY notify. Also, I find that
"minimum" is a little confusing. It could mean "minimum lifetime" or
"minimum of the previous one". I find "optimized" covers this better
than "minium".

- Shortened titles

For improved readability of Table of Contents

- Some grammar and style

Open questions to the working group:

1) Should the SUPPORTED notify mean that peers MAY use this method or MUST
    use this method? There could be a use for making it MUST, as a peer
    could then eventually stop supporting the "old method". Initiators
    would know by the lack of the notify that they might not be able to
    rekey in the old way, and must add/delete or re-auth the SA.

2) Alternatively, the SUPPORTED notify could have a payload that signifies
    whether the old method is supported or not.

3) Should we look at supporting rekeying multiple Child SAs at once? Or
    should we tell people they should have used additional Traffic
    Selectors and combined the Child SAs into one ?

4) When a Child SA was negotiated with PFS, what should an optimized rekey
    do when there is no KE payload? Send INVALID_KE_PAYLOAD ?

Paul

>> Subject: I-D Action:
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Dan Harkins <[email-masked]>
Date: Sun, 11 Jul 2021 21:18:44 -0700

Gee maybe someone is blocking email :/

On 7/11/21 8:38 PM, Paul Wouters wrote:
> Hmm, it used to be that if you are subscribed to one IETF list, you 
> can post to any of them. That does not seem to work for the ipsec list :/
>
>
> From: *Paul Wouters* <[email-masked] 
> <mailto:[email-masked]>>
> To: Panwei (William) <[email-masked] 
> <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] 
> <mailto:[email-masked]>>
>
>
> > According to the discussion on the mailing list, I update the draft 
> to version 05. In this version, I deleted the unnecessary 
> considerations for the configuration changes. For now, the solution is 
> very simple and just includes the negotiation at creating IKE SAs and 
> optimization at rekeying IKE and Child SAs.
> >
> >> From: I-D-Announce [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf
> >> Of [email-masked] <mailto:[email-masked]>
> >> To: [email-masked] <mailto:[email-masked]>
> >> Subject: I-D Action: 
> <https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa>
> >> ds-opt/
> >>
> <https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p>
> >> ayloads-opt-05
> >>
> <https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo>
> >> ads-opt-05
> >>
> >>
> <ftp://ftp.ietf.org/internet-drafts/>
> >>
> >>
> >> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/i-d-announce>
> >> Internet-Draft directories: http://www.ietf.org/shadow.html 
> <http://www.ietf.org/shadow.html> or
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> >
> > [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/ipsec>
> >
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 12 Jul 2021 14:54:25 +0000

Hi Paul,

Thanks very much for your suggestion. I've updated the 06 version based on your changes. The draft looks much simpler now.

Regards & Thanks!
Wei Pan

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Monday, July 12, 2021 11:35 AM
> Cc: [email-masked]
> version 05. In this version, I deleted the unnecessary considerations for the
> configuration changes. For now, the solution is very simple and just
> It is lookger much better and simpler, but I still had a few issues and wanted
> to make the document a bit shorter and clearer.  I made some changes for
> your consideration. I've attached an updated xml and txt file in case you
> would like to use my changes. The changes are:
> 
> Instead, a reference to IKEv2 should be enough. This greatly simplifies the
> text.
> 
> If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC
> 7296 says this:
> 
> whether it is OPTIMIZED or not. You should do a re-authentication (in other
> words, a new IKE from scratch)
> 
> I don't think this is actually true, since on rekey there are no required CERT
> payloads, which is the vast majority of the payload size in IKE_AUTH that
> causes fragmentation.
> 
> "minimum of the previous one". I find "optimized" covers this better than
> "minium".
> 
> - Shortened titles
>