Thanks Paul,
We wil change and post again by fixing all your comments.
Please find our opinion on your comments below.
1) Omitting the TS payload in ESP transport mode for rekeying seems okay as
well,but does seem to be a bit of a corner case to optimize for. But I can't
come up with a strong reason not to do it. There is an issue when there are
multiple IPsec SA's - you need the TS to see which one is being
rekeyed. So when omitted, you need to send the old SPI?
-------> The SA can be identified by old SPI , the exchange shown might be
taken from Normal Child SA Creation
we can update with new diagram for IPSEC SA Rekey by Child Exchange
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA), N(NEW_SPI), Ni} -->
<-- HDR, SK {N(NEW_SPI), Nr}
The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an existing ESP
or AH SA. The SA being rekeyed is identified by the SPI field in the
Notify payload; this is the SPI the exchange initiator would expect
in inbound ESP or AH packets. There is no data associated with this
Notify message type. The Protocol ID field of the REKEY_SA
notification is set to match the protocol of the SA we are rekeying,
for example, 3 for ESP and 2 for AH.
2)Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT, it
should be send in IKE_AUTH because we can fragment in IKE_AUTH and
not in IKE_INIT. It also reduces what a passive attacker can see and
fingerprint users/implementations on.
-------> this sugg is OK
This can be avoided in INIT and Once Auth is getting Success it will be
more appropriate as we are supporting for the authenticated peer.
3)I'd also prefer a shorter name than
IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED, perhaps call it
MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 in
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16
-------> Ok , Just referred IKEV2_MESSAGE_ID_SYNC something like this But
can always make Short names . we will change
4)Section 3.1
should clarify the payload length is 0?
It should clarify the setting of the Critical flag (off)
Some clarification should be needed on whether sending the notify means the
rekeys MAY or MUST use this new feature.
The NEW_SPI should probably have the critical flag set?
---> This point we can discuss , Critical bit is not required as per my
understanding as Initially only we negotiated for this Optional Support.
What is the chance that in middle of the operation peer stop supporting
it.
The example talks about there being a KEi payload, but if there is no
PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only
covers ike rekey, so then this is right. maybe clarify :)
---> Ok our intention there is for IKE rekey we can make more specific
the text states "initiator will send initiator IKE SPI" but that is only
true for IKE rekey, not IPsec rekey where it needs to send the IPsec
SPI.
---> yes we can make specific
If there is more than one IPsec SA, then omiting the TS would lead to
the responder no longer knowing which IPsec SA is being rekeyed. So
perhaps sending the old SPI would be needed. Or if we decide this is
too much of a corner case, perhaps we should not allow omittig the TS?
--> we go with old SPI inclusion , and it is normal convention to find old
SA for Rekey
I think 3.2.1 should named better, eg "IKE SA rekey without SA" and
3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 is
a bit odd.
---> Ok
I think a more clear split between ike/child rekey is needed. Currently
3.2.1 is about IKE, 3.2.2. about both?
--> ok separate heading and separate procedures
Section 4 needs work :) But in a way it is more secure agains accidental
downgrade of cryptographic strength. But also it prevents upgrade of
cryptographic strength.
-------> ok , preventing downgrade is a kind of good option :) from
security prespective.
Prevents Upgrade for better algorithams this part how to support we will
see but usually our thought is that smaller devices or iot devices
should have a initial config with best cryptographic strength and cannot
change so frequently.
Thanks&Rgs
Bharath M
On Fri, Feb 22, 2019 at 1:32 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. Re: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt
> (Paul Wouters)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 Feb 2019 15:40:11 -0500 (EST)
> From: Paul Wouters <[email protected]>
> To: Sandeep Kampati <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [IPsec]
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> On Wed, 20 Feb 2019, Sandeep Kampati wrote:
>
> > Htmlized:??
> https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00
> ??
>
> I read the draft and I think it has some good ideas, and a few things I
> don't like as much :)
>
> The idea of not including the SA when rekeying for the identical
> IPsec or IKE SA looks good to me.
>
> Omitting the TS payload in ESP transport mode for rekeying seems okay as
> well,
> but does seem to be a bit of a corner case to optimize for. But I can't
> come up with a strong reason not to do it. There is an issue when there
> are multiple IPsec SA's - you need the TS to see which one is being
> rekeyed. So when omitted, you need to send the old SPI?
>
> Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT,
> it should be send in IKE_AUTH because we can fragment in IKE_AUTH and
> not in IKE_INIT. It also reduces what a passive attacker can see and
> fingerprint users/implementations on.
>
> I'd also prefer a shorter name than IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED,
> perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 in
>
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16
>
> Section 3.1 should clarify the payload length is 0?
>
> It should clarify the setting of the Critical flag (off)
>
> Some clarification should be needed on whether sending the notify means
> the rekeys MAY or MUST use this new feature.
>
>
> The NEW_SPI should probably have the critical flag set?
>
> The example talks about there being a KEi payload, but if there is no
> PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only
> covers ike rekey, so then this is right. maybe clarify :)
>
>
> the text states "initiator will send initiator IKE SPI" but that is only
> true for IKE rekey, not IPsec rekey where it needs to send the IPsec
> SPI.
>
>
> If there is more than one IPsec SA, then omiting the TS would lead to
> the responder no longer knowing which IPsec SA is being rekeyed. So
> perhaps sending the old SPI would be needed. Or if we decide this is
> too much of a corner case, perhaps we should not allow omittig the TS?
>
>
> I think 3.2.1 should named better, eg "IKE SA rekey without SA" and
> 3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 is
> a bit odd.
>
> (i misread 3.2.1 making assumptions about child sa)
>
> I think a more clear split between ike/child rekey is needed. Currently
> 3.2.1 is about IKE, 3.2.2. about both?
>
>
> 3.3 again ensure to tell critical flag must be set.
>
> I think an OLD_SPI() payload is needed here too.
>
>
> Section 4 needs work :) But in a way it is more secure agains accidental
> downgrade of cryptographic strength. But also it prevents upgrade of
> cryptographic strength.
>
>
> Paul
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> ------------------------------
>
> End of IPsec Digest, Vol 178, Issue 7
> *************************************
>
--
with regards
Bharath.Meduri
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
