aboutsummaryrefslogtreecommitdiffstats
path: root/src/libcharon/encoding/message.c
Commit message (Collapse)AuthorAgeFilesLines
* message: Limit maximum number of IKEv2 fragmentsTobias Brunner2014-10-101-1/+11
| | | | | | | | The maximum for IKEv1 is already 255 due to the 8-bit fragment number. With an overhead of 17 bytes (x64) per fragment and a default maximum of 10000 bytes per packet the maximum memory required is 14 kB for a fragmented message.
* packet: Define a global default maximum size for IKE packetsTobias Brunner2014-10-101-6/+1
|
* message: Ensure a minimum fragment lengthTobias Brunner2014-10-101-8/+18
|
* message: Fragment and reassemble IKEv2 messagesTobias Brunner2014-10-101-128/+366
|
* message: Handle encrypted fragment payload similar to the encrypted payloadTobias Brunner2014-10-101-16/+91
|
* message: Split generate() in multiple functionsTobias Brunner2014-10-101-67/+122
|
* ikev1: Move defragmentation to message_tTobias Brunner2014-10-101-2/+194
|
* message: fragment() generates message and fragments and caches themTobias Brunner2014-10-101-20/+71
|
* message: Make packet argument optional in generate()Tobias Brunner2014-10-101-1/+4
|
* ikev1: Move fragment generation to message_tTobias Brunner2014-10-101-1/+105
|
* ike: Rename encryption_payload to encrypted_payloadTobias Brunner2014-10-101-13/+13
|
* ikev1: Don't cache last block of INFORMATIONAL messages as IVTobias Brunner2014-09-121-2/+2
| | | | | | | | | We don't expect a response with the same MID, but apparently some devices (e.g. FRITZ!Box) do that for DPDs, while still treating the response as a new exchange. By storing the last message block as IV we can't decrypt the first block of such a response. Fixes #661.
* payload: Use common prefixes for all payload type identifiersMartin Willi2014-06-041-367/+367
| | | | | The old identifiers did not use a proper namespace and often clashed with other defines.
* ikev1: Add an option to accept unencrypted ID/HASH payloadsMartin Willi2014-04-171-1/+20
| | | | | | | | | Even in Main Mode, some Sonicwall boxes seem to send ID/HASH payloads in unencrypted form, probably to allow PSK lookup based on the ID payloads. We by default reject that, but accept it if the charon.accept_unencrypted_mainmode_messages option is set in strongswan.conf. Initial patch courtesy of Paul Stewart.
* iv_gen: Provide external sequence number (IKE, ESP)Tobias Brunner2013-10-111-1/+1
| | | | This prevents duplicate sequential IVs in case of a HA failover.
* ikev1: Accept more than two certificate payloadsMartin Willi2013-10-111-2/+2
|
* message: print type of configuration payloadMartin Willi2013-09-031-1/+21
|
* message: print attributes for IKEv1 configuration payloads as wellMartin Willi2013-09-031-1/+2
|
* linked-list: Remove barely used has_more() methodTobias Brunner2013-07-171-83/+105
| | | | | | | | This required some refactoring when handling encrypted payloads. Also changed log messages so that "encrypted payload" is logged instead of "encryption payload" (even if we internally still call it that) as that's the name used in RFC 5996.
* Allow up to 10 NAT-D payloads in IKEv1 messagesTobias Brunner2013-03-201-1/+1
|
* Allow more than one CERTREQ payload for IKEv2Tobias Brunner2013-02-081-2/+2
| | | | | | There is no reason not to do so (RFC 5996 explicitly mentions multiple CERTREQ payloads) and some implementations seem to use the same behavior as had to be used with IKEv1 (i.e. each CA in its own CERTREQ payload).
* Add message rules to properly handle IKE fragmentsTobias Brunner2012-12-241-0/+8
| | | | | These are sent in unencrypted messages and are the only payload contained in such messages.
* Reset the encrypted flag when handling IKE messages that contain a fragmentTobias Brunner2012-12-241-0/+6
| | | | | Racoon sets the encrypted bit for messages containing a fragment, but these messages are not really encrypted (the fragmented message is though).
* Add support for draft-ietf-ipsec-nat-t-ike-03 and earlierVolker Rümelin2012-12-191-0/+12
| | | | | This adds support for early versions of the draft that eventually resulted in RFC 3947.
* Increase the limit of acceptable IKEv1 CERTREQ payloads to 20Martin Willi2012-10-241-1/+1
|
* Don't print hexdumps on loglevel 1 if hash verification failsMartin Willi2012-07-201-3/+3
|
* Cleaned up memory management and return values for encryption payloadMartin Willi2012-07-161-14/+11
|
* Add a return value to keymat_v1_t.{get,update,confirm}_ivMartin Willi2012-07-161-9/+36
|
* Use a bool return value in keymat_v1_t.get_hash_phase2()Martin Willi2012-07-161-4/+2
|
* Store the major IKE version on ike_sa_id_t.Tobias Brunner2012-03-201-0/+1
|
* Print IKEv1 notify types in message summaryMartin Willi2012-03-201-1/+2
|
* Support IKEv1 notifies in message_t.get_notify()Martin Willi2012-03-201-1/+2
|
* Accept unencrypted Aggressive Mode messages.Tobias Brunner2012-03-201-1/+2
| | | | Racoon does not encrypt the third message during Aggressive Mode.
* Encrypt payloads of third aggressive mode messageMartin Willi2012-03-201-3/+3
|
* Cast keymat safely, not based on external inputMartin Willi2012-03-201-36/+44
|
* Accept NULL as keymat when generating a messageMartin Willi2012-03-201-4/+10
|
* Separated libcharon/sa directory with ikev1 and ikev2 subfoldersMartin Willi2012-03-201-1/+1
|
* Another set of cleanups in message.cMartin Willi2012-03-201-18/+19
|
* Some coding style cleanupsMartin Willi2012-03-201-3/+6
|
* Do not trust unprotected INFORMATIONALS, just print that we got oneMartin Willi2012-03-201-13/+18
|
* Remove executable flag from source code filesMartin Willi2012-03-201-0/+0
|
* Encrypt INFORMATIONAL exchange if neededClavister OpenSource2012-03-201-11/+22
|
* Handle incoming delete messagesClavister OpenSource2012-03-201-0/+25
|
* certificate handling for XAuth responder.Clavister OpenSource2012-03-201-2/+2
|
* IKEv1: Added basic support for INFORMATIONAL exchange types, and for ↵Clavister OpenSource2012-03-201-9/+13
| | | | NOTIFY_V1 messages in the 3rd message in quick_mode.
* Message rules for IKEv1 NAT-T payloads added.Tobias Brunner2012-03-201-0/+17
|
* Added payloads for IKEv1 NAT-Traversal negotiation.Tobias Brunner2012-03-201-1/+1
|
* Handle invalid IKEv1 hashes more specifically.Tobias Brunner2012-03-201-1/+1
|
* Handle unsupported IKEv1 exchange types more specifically.Tobias Brunner2012-03-201-1/+1
|
* Handle INFORMATIONAL_V1 messages when no keys have been derived yet.Tobias Brunner2012-03-201-2/+3
| | | | | | | | This allows to gracefully process the INFORMATIONAL_V1 message rules which require the payloads to be encrypted and thus the exchange to be authenticated with a HASH payload. If such an exchange is now initiated before the ISAKMP_SA is established, the message is simply sent unencrypted and without HASH payload.