Add an option to announce support for IKE fragmentation but not sending fragments

This commit is contained in:
Tobias Brunner 2017-05-05 15:48:14 +02:00
parent cbbd34f507
commit 46a3f92a76
6 changed files with 34 additions and 16 deletions

View File

@ -445,22 +445,31 @@ force UDP encapsulation for ESP packets even if no NAT situation is detected.
This may help to surmount restrictive firewalls. In order to force the peer to
encapsulate packets, NAT detection payloads are faked.
.TP
.BR fragmentation " = " yes " | force | no"
.BR fragmentation " = " yes " | accept | force | no"
whether to use IKE fragmentation (proprietary IKEv1 extension or IKEv2
fragmentation as per RFC 7383). Acceptable values are
.B yes
(the default),
.BR accept ,
.B force
and
.BR no .
Fragmented IKE messages sent by a peer are always accepted
irrespective of the value of this option. If set to
.BR yes ,
and the peer supports it, larger IKE messages will be sent in fragments.
If set to
.BR yes ,
and the peer supports it, oversized IKE messages will be sent in fragments. If
set to
.BR accept ,
support for fragmentation is announced to the peer but the daemon does not send
its own messages in fragments. If set to
.B force
(only supported for IKEv1) the initial IKE message will already be fragmented
if required.
if required. Finally, setting the option to
.B no
will disable announcing support for this feature.
Note that fragmented IKE messages sent by a peer are always accepted
irrespective of the value of this option (even when set to
.BR no ).
.TP
.BR ike " = <cipher suites>"
comma-separated list of IKE/ISAKMP SA encryption/authentication algorithms

View File

@ -47,14 +47,16 @@ enum ike_version_t {
};
/**
* Proprietary IKEv1 fragmentation
* Proprietary IKEv1 fragmentation and IKEv2 fragmentation
*/
enum fragmentation_t {
/** disable fragmentation */
FRAGMENTATION_NO,
/** enable fragmentation if supported by peer */
/** announce support, but don't send any fragments */
FRAGMENTATION_ACCEPT,
/** enable fragmentation, if supported by peer */
FRAGMENTATION_YES,
/** force use of fragmentation (even for the first message) */
/** force use of fragmentation (even for the first message for IKEv1) */
FRAGMENTATION_FORCE,
};

View File

@ -1336,6 +1336,7 @@ CALLBACK(parse_frag, bool,
{
enum_map_t map[] = {
{ "yes", FRAGMENTATION_YES },
{ "accept", FRAGMENTATION_ACCEPT },
{ "no", FRAGMENTATION_NO },
{ "force", FRAGMENTATION_FORCE },
};

View File

@ -110,6 +110,7 @@ static const char *LST_authby[] = {
static const char *LST_fragmentation[] = {
"no",
"accept",
"yes",
"force",
NULL

View File

@ -65,6 +65,7 @@ typedef enum {
typedef enum {
/* same as in ike_cfg.h */
FRAGMENTATION_NO,
FRAGMENTATION_ACCEPT,
FRAGMENTATION_YES,
FRAGMENTATION_FORCE,
} fragmentation_t;

View File

@ -154,15 +154,19 @@ connections.<conn>.dpd_timeout = 0s
specified; this option has no effect on connections using IKE2.
connections.<conn>.fragmentation = yes
Use IKE UDP datagram fragmentation. (_yes_, _no_ or _force_).
Use IKE UDP datagram fragmentation. (_yes_, _accept_, _no_ or _force_).
Use IKE fragmentation (proprietary IKEv1 extension or RFC 7383 IKEv2
fragmentation). Acceptable values are _yes_ (the default), _force_ and
_no_. Fragmented IKE messages sent by a peer are always accepted
irrespective of the value of this option. If set to _yes_, and the peer
supports it, oversized IKE messages will be sent in fragments. If set to
_force_ (only supported for IKEv1) the initial IKE message will already
be fragmented if required.
fragmentation). Acceptable values are _yes_ (the default), _accept_,
_force_ and _no_. If set to _yes_, and the peer supports it, oversized IKE
messages will be sent in fragments. If set to _accept_, support for
fragmentation is announced to the peer but the daemon does not send its own
messages in fragments. If set to _force_ (only supported for IKEv1) the
initial IKE message will already be fragmented if required. Finally, setting
the option to _no_ will disable announcing support for this feature.
Note that fragmented IKE messages sent by a peer are always accepted
irrespective of the value of this option (even when set to _no_).
connections.<conn>.send_certreq = yes
Send certificate requests payloads (_yes_ or _no_).