Project

General

Profile

Feature #943

Increase stroke message size limit again?

Added by Michael Tremer over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Low
Category:
starter
Target version:
Start date:
29.04.2015
Due date:
Estimated time:
Resolution:
Fixed

Description

Hello guys,

recently, in bug #844, the stroke message size was increased, which is good.

However it still is not big enough for my use case. In IPFire, we allow users to check the ciphers and hashes from a list that they want to allow being used for the VPN connections. Some software will then add them all together as required by the strongswan configuration. Those are the ike= and esp= configuration directives.

If someone selects a huge number of options (lets say all versions of AES with 256 bits key lengths of which there are a couple: CBC and GCM with various ICV sizes, with all versions of SHA* and some IKE group types) this will result in a pretty large number of possible combinations of that. If that connection is then read from the configuration, it does not get correctly imported because of the new message size limit in strongswan 5.3.0.

I made a patch that increases the message size limit once again to 8k. I would like it even larger. So my question is if there are any downsides or if you guys would accept a patch that sets the size to 16k?

Associated revisions

Revision d8fe354a (diff)
Added by Tobias Brunner over 4 years ago

stroke: Dynamically resize stroke messages

The maximum size of a stroke message is currently 64k due to the 2 byte
length field.

Fixes #943.

History

#1 Updated by Tobias Brunner over 4 years ago

  • Tracker changed from Issue to Feature
  • Status changed from New to Feedback

If someone selects a huge number of options (lets say all versions of AES with 256 bits key lengths of which there are a couple: CBC and GCM with various ICV sizes, with all versions of SHA* and some IKE group types) this will result in a pretty large number of possible combinations of that. If that connection is then read from the configuration, it does not get correctly imported because of the new message size limit in strongswan 5.3.0.

For IKEv2 you can define quite compact proposals if you don't want to enforce specific combinations of algorithms. You can basically put all algorithms in one proposal, or rather two, as AEAD algorithms have to be sent in a separate proposal to be RFC compliant (strongSwan currently does not enforce this). And regarding ICV sizes should the use of lengths shorter than 16 bytes generally be discouraged (see Appendix C of NIST SP 800-38D). So a possible esp config might look like this: aes256-aes256ctr-sha256-sha512-sha1-ecp521-ecp256-modp4096-modp2048,aes256gcm16-aes256ccm16-ecp521-ecp256-modp4096-modp2048

For IKEv1 the situation is different, there you actually have to define separate proposals for each combination of algorithms (not all of them might actually make sense, though).

I made a patch that increases the message size limit once again to 8k. I would like it even larger. So my question is if there are any downsides or if you guys would accept a patch that sets the size to 16k?

Not sure what the impact is when a UNIX socket is used. But 8k should probably be fine. Usually, there aren't that many messages exchanged via stroke socket, but all messages currently have the same size (e.g. even simple status requests or control commands). So perhaps a dynamically sized buffer might be a better approach.

#2 Updated by Michael Tremer over 4 years ago

Thank you for your reply.

I wanted to avoid having different configurations for IKEv2 and IKEv1. That would unnecessarily increase the size of my code and increasing the buffer size seemed to be better solution to me.

I would agree that a dynamically sized buffer would be a much better solution after all. That parts of a connection or the entire connection is getting lost was something I certainly did not expect and the issue in #844 was also very severe. A dynamically sized buffer would avoid that, too.

Not sure how I can contribute to that. I guess you guys would be faster implementing that as you know your code better than me.

#3 Updated by Tobias Brunner over 4 years ago

  • Category set to starter
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.3.1
  • Resolution set to Fixed

I would agree that a dynamically sized buffer would be a much better solution after all. That parts of a connection or the entire connection is getting lost was something I certainly did not expect and the issue in #844 was also very severe. A dynamically sized buffer would avoid that, too.

The referenced patch implements this, the maximum message size is now 64k.

#4 Updated by Michael Tremer over 4 years ago

Wonderful. Thank you.

Also available in: Atom PDF