[IPsec] RFC8229 (IKE over TCP) and retransmissions

[WG chair hat off] Valery Smyslov writes: > TCP provides reliable transport, so there is no need for application to > deal with retransmissions. Moreover, performing retransmissions by IKE > in case of TCP on congested networks could further increase congestion > and degrade

Re: [IPsec] PLMTUD probes for IPsec

Folks, In the first version of this draft, we leveraged IKE to exchange messages. And provided with a good enough reason, we might go back to that position! We moved away from IKE for the following reasons: - The path between the encrypting and decrypting nodes might include ECMP. If so, IKE

Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions

Hi Valery, Thanks for bringing this up with the WG! I agree that retransmissions of IKE packets within the TCP stream may be pointless, and add to congestion. We do mention this for ESP packets over the TCP stream (Section 12.2 Added Reliability for Unreliable Protocols), but it doesn’t call

Re: [IPsec] PLMTUD probes for IPsec

Valery Smyslov wrote: >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica >> > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu- >> discovery-01 >> >> > Problem: IPsec Tunnel has an PMTU as

Re: [IPsec] PLMTUD probes for IPsec

Hi Paul, > > Why IKE messages cannot be used for this purpose? > > IKE messages might not take the same path, eg ESP goes through hardware > offload or other things, or intermediary routers might have different > rules for UDP vs ESP. True, unless UDP encapsulation is used... Regards, Valery.

Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions

Hi Valery, I agree that generally retransmits are not useful or needed with TCP encapsulation. But as I see it, retransmits might actually be required in some situations. If the client sends e.g. a CREATE_CHILD_SA request but the TCP connection is closed or gets unusable for some reason before

Re: [IPsec] PLMTUD probes for IPsec

On Thu, 5 Apr 2018, Valery Smyslov wrote: Why IKE messages cannot be used for this purpose? IKE messages might not take the same path, eg ESP goes through hardware offload or other things, or intermediary routers might have different rules for UDP vs ESP. Paul

[IPsec] RFC8229 (IKE over TCP) and retransmissions

Hi, after re-reading RFC8229 several times I cannot find any language about retransmitting IKE messages in case of TCP. Clearly, the behavior described in Section 2.1 is wrong in case of TCP, since TCP provides a reliable transport. Blindly following these recommendations would only make things

Re: [IPsec] PLMTUD probes for IPsec

Hi Michael, > > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu- > discovery-01 > > > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > Solution in Transport

Re: [IPsec] initiator privacy vs responder stealth

Hi Michael, > > IKE_SA_INIT privacy concerns - David Schinazi > > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2- > ike-sa-init-exchange-00 > > > Concerns around privacy of the peers (who the initiator is, and if the > >

Re: [IPsec] use of IKE_AUX vs rekey of IKE Parent SA in draft-smyslov-ipsecme-ikev2-aux

Hi Michael, > > Michael R.: > > - doesn't seem to be generic cause of the re-key. > > - why not do a re-key after IKE_AUTH > > - As DH is broken, this approach does not seem to protect it. > > I suggested in the mic line that the use of IKE_AUX seemed to introduce more > issues