Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
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
> -Original Message-
> From: Paul Wouters [mailto:paul.wout...@aiven.io]
> Sent: Monday, July 12, 2021 11:35 AM
> To: Panwei (William)
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] I-D Action:
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
>
> 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
>
>
>
> >
> > Regards & Thanks!
> > Wei Pan
> >
> >> -Original Message-
> >> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On
> Behalf
> >> Of internet-dra...@ietf.org
> >> Sent: Monday, July 5, 2021 12:24 PM
> >> To: i-d-annou...@ietf.org
> >> Subject: I-D Action:
> >> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
> >&
Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
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 :/
-- Forwarded message -
From: *Paul Wouters* <mailto:paul.wout...@aiven.io>>
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) <mailto:william.pan...@huawei.com>>
Cc: ipsec@ietf.org <mailto:ipsec@ietf.org> <mailto:ipsec@ietf.org>>
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
>
> Regards & Thanks!
> Wei Pan
>
>> -Original Message-
>> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org
<mailto:i-d-announce-boun...@ietf.org>] On Behalf
>> Of internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>> Sent: Monday, July 5, 2021 12:24 PM
>> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
>> 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 Payloads in Child
>> Exchange
>> Autho
Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
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
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)
Cc: ipsec@ietf.org
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
>
> Regards & Thanks!
> Wei Pan
>
>> -Original Message-
>> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf
>> Of internet-dra...@ietf.org
>> Sent: Monday, July 5, 2021 12:24 PM
>> To: i-d-annou...@ietf.org
>> 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 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
>>
>> Abst
Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
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:i-d-announce-boun...@ietf.org] On Behalf > Of internet-dra...@ietf.org > Sent: Monday, July 5, 2021 12:24 PM > To: i-d-annou...@ietf.org > 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 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 > i-d-annou...@ietf.org > 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
