ipsec_set_policy - manipulate IPsec policy specification structure from readable string  




#include netinet6/ipsec.h
char * ipsec_set_policy ( char *policy, int len )
int ipsec_get_policylen ( char *buf )
char * ipsec_dump_policy ( char *buf, char *delim )  


ipsec_set_policy generates IPsec policy specification structure, namely struct sadb_x_policy and/or struct sadb_x_ipsecrequest from human-readable policy specification. policy specification must be given as C string policy and length len of policy.

ipsec_set_policy will return the buffer of IPsec policy specification structure. The buffer is dynamically allocated, and must be freed by the caller by calling free(3). You may want the length of the generated buffer such when calling setsockopt(2). ipsec_get_policylen will return the length.

ipsec_dump_policy converts IPsec policy structure into readable form. Therefore, ipsec_dump_policy can be regarded as inverse conversion of ipsec_set_policy. buf points to a IPsec policy structure, struct sadb_x_policy delim is a delimiter string, which is usually a blank character. If you set delim to NULL, single whitespace is assumed. ipsec_dump_policy returns a pointer to a dynamically allocated string. It is the caller's responsibility to reclaim the region, by using free(3).

policy is formatted as either of the following:

direction discard
direction must be in or out direction specifies which direction the policy needs to be applied. With discard policy, packets will be dropped if they match the policy.
direction entrust
entrust means to consult to SPD defined by setkey(8).
direction bypass
bypass means to be bypassed the IPsec processing. (packet will be transmitted in clear) This is for privileged socket.
direction ipsec request ...
means that the matching packets are subject to IPsec processing. ipsec can be followed by one or more request string, which is formatted as below:

protocol / mode / src - dst [/level ]
is either ah esp or ipcomp

mode is either transport or tunnel

src and dst specifies IPsec endpoint. src always means ``sending node'' and dst always means ``receiving node'' Therefore, when direction is in dst is this node and src is the other node (peer) If mode is transport Both src and dst can be omitted.

level must be set to one of the following: default , use , require or unique default means that the kernel should consult the system default policy use means that a relevant SA can be used when available, since the kernel may perform IPsec operation against packets when possible. In this case, packets can be transmitted in clear (when SA is not available) or encrypted (when SA is available) require means that a relevant SA is required, since the kernel must perform IPsec operation against packets. unique is the same as require but adds the restriction that the SA for outbound traffic is used only for this policy. You may need the identifier in order to relate the policy and the SA when you define the SA by manual keying. You can put the decimal number as the identifier after unique like unique : number number must be between 1 and 32767 . If the request string is kept unambiguous, level and slash prior to level can be omitted. However, it is encouraged to specify them explicitly to avoid unintended behaviors. If level is omitted, it will be interpreted as default

Note that there is a bit difference of specification from setkey(8). In specification by setkey(8), both entrust and bypass are not used. Refer to setkey(8) for detail.

Here are several examples (long lines are wrapped for readability)

in discard
out ipsec esp/transport//require
in ipsec ah/transport//require
out ipsec esp/tunnel/
in ipsec ipcomp/transport//use


ipsec_set_policy returns a pointer to the allocated buffer of policy specification if successful; otherwise a NULL pointer is returned. ipsec_get_policylen returns with positive value (meaning the buffer size) on success, and negative value on errors. ipsec_dump_policy returns a pointer to dynamically allocated region on success, and NULL on errors.  


ipsec_strerror(3) setkey(8)  


The functions first appeared in WIDE/KAME IPv6 protocol stack kit.

This document was created by man2html.
Copyright (C) 1995, 1996, 1997, 1998, and 1999 WIDE Project. All rights reserved.