On Tue, 31 May 2016, Tommy Pauly wrote:
iOS and Mac OS X do not support ESP TFC, and mark ESP_TFC_PADDING_NOT_SUPPORTED in the IKE_AUTH packets. I have not heard of problems with interop in this area.
So I just did an interop, enabled TFC and it worked great with iOS :) 22:10:29.449629 IP 193.110.157.103.ipsec-nat-t > 206.248.139.105.ipsec-nat-t: UDP-encap: ESP(spi=0x0ac48b5c,seq=0x33), length 1460 22:10:29.626665 IP 206.248.139.105.ipsec-nat-t > 193.110.157.103.ipsec-nat-t: UDP-encap: ESP(spi=0x7c5c55a3,seq=0x36), length 132 22:10:30.450711 IP 193.110.157.103.ipsec-nat-t > 206.248.139.105.ipsec-nat-t: UDP-encap: ESP(spi=0x0ac48b5c,seq=0x34), length 1460 22:10:30.627503 IP 206.248.139.105.ipsec-nat-t > 193.110.157.103.ipsec-nat-t: UDP-encap: ESP(spi=0x7c5c55a3,seq=0x37), length 132 This is a ping and you can see the linux server sending pings padded to 1460 bytes and the iphone replying with 132 byte ESP packets. I guess the kernel is properly handling ESP decryption, grabbing the length field and decrypting the packet, and doesn't care about the extra bytes at the end. This was using IKEv1, which prevented me from seeing the notify payload for it not being supported. But I assume ESP is handled identically on iOS regardless of IKE version, so I think for IKEv2 you do not need to send ESP_TFC_PADDING_NOT_SUPPORTED, since you support it fine :) I noticed you said you send the notify in IKE_AUTH. In my code I had added it to IKE_INIT. Reading 7296 is a bit unclear on this, since it only mentions ESP_TFC_PADDING_NOT_SUPPORTED for the CREATE_CHILD exchange, and not the Initial Exchanges. Although it does become clear when you read the appendix examples where these appear in IKE_AUTH. It seems RFC 4718 had clarified this, but somehow we missed including that clarified text in either 5996 or 7296 :/ https://tools.ietf.org/html/rfc4718#section-4.5 And it makes sense since it is supposed to be a "per SA" option, even though I'd guess that support for it would depend on the OS/kernel so it seems a little odd to make it a per-SA option. I guess "supported" really means "desired". And iOS sending the notify might be because they prefer to do less traffic to save on battery and data usage even though they support it? So I'll update my code. Of course, I'm still curious about other vendors too. And still wondering if TFC should be enabled per default if not ESP_TFC_PADDING_NOT_SUPPORTED is received. Thanks, Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
