Subject: [IPsec] how common is ESP TFC support (and signaling of non-support) ?

From: Paul Wouters <[email-masked]>
Date: Tue, 31 May 2016 12:15:07 -0400 (EDT)

Hi vendors,

I am wondering how common it is for stacks to support ESP TFC ?

And also, how common it is for stacks that do NOT support ESP TFC, to
properly signal that with ESP_TFC_PADDING_NOT_SUPPORTED.

That is, has anyone ever encountered an interop problem when enabling
ESP TFC?

I would be interested in hearing from vendors (offlist or onlist)

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 31 May 2016 18:08:57 -0700

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.

Thanks,
Tommy

> On May 31, 2016, at 9:15 AM, Paul Wouters <[email-masked]> wrote:
> 
> 
> Hi vendors,
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 May 2016 22:28:27 -0400 (EDT)

> 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