Subject: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt

From: Sandeep Kampati <[email-masked]>
Date: Wed, 20 Feb 2019 05:48:36 +0000

Folks,

I posted the following draft:

URL:        https://www.ietf.org/id/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt
Htmlized:   https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00
Htmlized:   https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt/

We would appreciate any discussion and feedback.

In 4G network security gateways/ePDG and in 5G networks cRAN/Cloud will support more than 100000 IKE/IPSEC tunnels. So on an average, for every second we encounter many rekeys. This takes huge amount of bandwidth, packet fragmentation and more processing. This can be solved by introducing this draft.

This is also useful in Internet of Things (IoT) devices which utilizing lower power consumption technology.

Thanks,
Sandeep kampati
Email: [email-masked]<mailto:[email-masked]>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Feb 2019 15:40:11 -0500 (EST)

> 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