xref: /freebsd/share/man/man4/ipsec.4 (revision 6af83ee0d2941d18880b6aaa2b4facd1d30c6106)
1.\"	$KAME: ipsec.4,v 1.17 2001/06/27 15:25:10 itojun Exp $
2.\"
3.\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. Neither the name of the project nor the names of its contributors
15.\"    may be used to endorse or promote products derived from this software
16.\"    without specific prior written permission.
17.\"
18.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28.\" SUCH DAMAGE.
29.\"
30.\" $FreeBSD$
31.\"
32.Dd January 11, 2005
33.Dt IPSEC 4
34.Os
35.Sh NAME
36.Nm ipsec
37.Nd IP security protocol
38.Sh SYNOPSIS
39.In sys/types.h
40.In netinet/in.h
41.In netinet6/ipsec.h
42.Sh DESCRIPTION
43.Nm
44is a security protocol in Internet Protocol layer.
45.Nm
46is defined for both IPv4 and IPv6
47.Xr ( inet 4
48and
49.Xr inet6 4 ) .
50.Nm
51consists of two sub-protocols, namely
52ESP
53(encapsulated security payload)
54and AH
55(authentication header).
56ESP protects IP payload from wire-tapping by encrypting it by
57secret key cryptography algorithms.
58AH guarantees integrity of IP packet
59and protects it from intermediate alteration or impersonation,
60by attaching cryptographic checksum computed by one-way hash functions.
61.Nm
62has two operation modes: transport mode and tunnel mode.
63Transport mode is for protecting peer-to-peer communication between end nodes.
64Tunnel mode includes IP-in-IP encapsulation operation
65and is designed for security gateways, like VPN configurations.
66.\"
67.Ss Kernel interface
68.Nm
69is controlled by key management engine and policy engine,
70in the operating system kernel.
71.Pp
72Key management engine can be accessed from the userland by using
73.Dv PF_KEY
74sockets.
75The
76.Dv PF_KEY
77socket API is defined in RFC2367.
78.Pp
79Policy engine can be controlled by extended part of
80.Dv PF_KEY
81API,
82.Xr setsockopt 2
83operations, and
84.Xr sysctl 3
85interface.
86The kernel implements
87extended version of
88.Dv PF_KEY
89interface, and allows you to define IPsec policy like per-packet filters.
90.Xr setsockopt 2
91interface is used to define per-socket behavior, and
92.Xr sysctl 3
93interface is used to define host-wide default behavior.
94.Pp
95The kernel code does not implement dynamic encryption key exchange protocol
96like IKE
97(Internet Key Exchange).
98That should be implemented as userland programs
99(usually as daemons),
100by using the above described APIs.
101.\"
102.Ss Policy management
103The kernel implements experimental policy management code.
104You can manage the IPsec policy in two ways.
105One is to configure per-socket policy using
106.Xr setsockopt 2 .
107The other is to configure kernel packet filter-based policy using
108.Dv PF_KEY
109interface, via
110.Xr setkey 8 .
111In both cases, IPsec policy must be specified with syntax described in
112.Xr ipsec_set_policy 3 .
113.Pp
114With
115.Xr setsockopt 2 ,
116you can define IPsec policy in per-socket basis.
117You can enforce particular IPsec policy onto packets that go through
118particular socket.
119.Pp
120With
121.Xr setkey 8
122you can define IPsec policy against packets,
123using sort of packet filtering rule.
124Refer to
125.Xr setkey 8
126on how to use it.
127.Pp
128In the latter case,
129.Dq Li default
130policy is allowed for use with
131.Xr setkey 8 .
132By configuring policy to
133.Li default ,
134you can refer system-wide
135.Xr sysctl 8
136variable for default settings.
137The following variables are available.
138.Li 1
139means
140.Dq Li use ,
141and
142.Li 2
143means
144.Dq Li require
145in the syntax.
146.Bl -column net.inet6.ipsec6.esp_trans_deflev integerxxx
147.It Sy "Name	Type	Changeable"
148.It "net.inet.ipsec.esp_trans_deflev	integer	yes"
149.It "net.inet.ipsec.esp_net_deflev	integer	yes"
150.It "net.inet.ipsec.ah_trans_deflev	integer	yes"
151.It "net.inet.ipsec.ah_net_deflev	integer	yes"
152.It "net.inet6.ipsec6.esp_trans_deflev	integer	yes"
153.It "net.inet6.ipsec6.esp_net_deflev	integer	yes"
154.It "net.inet6.ipsec6.ah_trans_deflev	integer	yes"
155.It "net.inet6.ipsec6.ah_net_deflev	integer	yes"
156.El
157.Pp
158If kernel finds no matching policy system wide default value is applied.
159System wide default is specified by the following
160.Xr sysctl 8
161variables.
162.Li 0
163means
164.Dq Li discard
165which asks the kernel to drop the packet.
166.Li 1
167means
168.Dq Li none .
169.Bl -column net.inet6.ipsec6.def_policy integerxxx
170.It Sy "Name	Type	Changeable"
171.It "net.inet.ipsec.def_policy	integer	yes"
172.It "net.inet6.ipsec6.def_policy	integer	yes"
173.El
174.\"
175.Ss Miscellaneous sysctl variables
176The following variables are accessible via
177.Xr sysctl 8 ,
178for tweaking kernel IPsec behavior:
179.Bl -column net.inet6.ipsec6.inbonud_call_ike integerxxx
180.It Sy "Name	Type	Changeable"
181.It "net.inet.ipsec.ah_cleartos	integer	yes"
182.It "net.inet.ipsec.ah_offsetmask	integer	yes"
183.It "net.inet.ipsec.dfbit	integer	yes"
184.It "net.inet.ipsec.ecn	integer	yes"
185.It "net.inet.ipsec.debug	integer	yes"
186.It "net.inet6.ipsec6.ecn	integer	yes"
187.It "net.inet6.ipsec6.debug	integer	yes"
188.El
189.Pp
190The variables are interpreted as follows:
191.Bl -tag -width 6n
192.It Li ipsec.ah_cleartos
193If set to non-zero, the kernel clears type-of-service field in the IPv4 header
194during AH authentication data computation.
195The variable is for tweaking AH behavior to interoperate with devices that
196implement RFC1826 AH.
197It should be set to non-zero
198(clear the type-of-service field)
199for RFC2402 conformance.
200.It Li ipsec.ah_offsetmask
201During AH authentication data computation, the kernel will include
20216bit fragment offset field
203(including flag bits)
204in IPv4 header, after computing logical AND with the variable.
205The variable is for tweaking AH behavior to interoperate with devices that
206implement RFC1826 AH.
207It should be set to zero
208(clear the fragment offset field during computation)
209for RFC2402 conformance.
210.It Li ipsec.dfbit
211The variable configures the kernel behavior on IPv4 IPsec tunnel encapsulation.
212If set to 0, DF bit on the outer IPv4 header will be cleared.
2131 means that the outer DF bit is set regardless from the inner DF bit.
2142 means that the DF bit is copied from the inner header to the outer.
215The variable is supplied to conform to RFC2401 chapter 6.1.
216.It Li ipsec.ecn
217If set to non-zero, IPv4 IPsec tunnel encapsulation/decapsulation behavior will
218be friendly to ECN
219(explicit congestion notification),
220as documented in
221.Li draft-ietf-ipsec-ecn-02.txt .
222.Xr gif 4
223talks more about the behavior.
224.It Li ipsec.debug
225If set to non-zero, debug messages will be generated via
226.Xr syslog 3 .
227.El
228.Pp
229Variables under
230.Li net.inet6.ipsec6
231tree has similar meaning as the
232.Li net.inet.ipsec
233counterpart.
234.\"
235.Sh PROTOCOLS
236The
237.Nm
238protocol works like plug-in to
239.Xr inet 4
240and
241.Xr inet6 4
242protocols.
243Therefore,
244.Nm
245supports most of the protocols defined upon those IP-layer protocols.
246Some of the protocols, like
247.Xr icmp 4
248or
249.Xr icmp6 4 ,
250may behave differently with
251.Nm .
252This is because
253.Nm
254can prevent
255.Xr icmp 4
256or
257.Xr icmp6 4
258routines from looking into IP payload.
259.\"
260.Sh SEE ALSO
261.Xr ioctl 2 ,
262.Xr socket 2 ,
263.Xr ipsec_set_policy 3 ,
264.Xr icmp6 4 ,
265.Xr intro 4 ,
266.Xr ip6 4 ,
267.Xr setkey 8 ,
268.Xr sysctl 8
269.\".Xr racoon 8
270.Rs
271.%A "S. Kent"
272.%A "R. Atkinson"
273.%T "IP Authentication Header"
274.%O "RFC 2404"
275.Re
276.Rs
277.%A "S. Kent"
278.%A "R. Atkinson"
279.%T "IP Encapsulating Security Payload (ESP)"
280.%O "RFC 2406"
281.Re
282.Sh STANDARDS
283.Rs
284.%A Daniel L. McDonald
285.%A Craig Metz
286.%A Bao G. Phan
287.%T "PF_KEY Key Management API, Version 2"
288.%R RFC
289.%N 2367
290.Re
291.Pp
292.Rs
293.%A "D. L. McDonald"
294.%T "A Simple IP Security API Extension to BSD Sockets"
295.%R internet draft
296.%N "draft-mcdonald-simple-ipsec-api-03.txt"
297.%O work in progress material
298.Re
299.Sh HISTORY
300The implementation described herein appeared in WIDE/KAME IPv6/IPsec stack.
301.Sh BUGS
302The IPsec support is subject to change as the IPsec protocols develop.
303.Pp
304There is no single standard for policy engine API,
305so the policy engine API described herein is just for KAME implementation.
306.Pp
307AH and tunnel mode encapsulation may not work as you might expect.
308If you configure inbound
309.Dq require
310policy against AH tunnel or any IPsec encapsulating policy with AH
311(like
312.Dq Li esp/tunnel/A-B/use ah/transport/A-B/require ) ,
313tunnelled packets will be rejected.
314This is because we enforce policy check on inner packet on reception,
315and AH authenticates encapsulating
316(outer)
317packet, not the encapsulated
318(inner)
319packet
320(so for the receiving kernel there is no sign of authenticity).
321The issue will be solved when we revamp our policy engine to keep all the
322packet decapsulation history.
323.Pp
324Under certain condition,
325truncated result may be raised from the kernel
326against
327.Dv SADB_DUMP
328and
329.Dv SADB_SPDDUMP
330operation on
331.Dv PF_KEY
332socket.
333This occurs if there are too many database entries in the kernel
334and socket buffer for the
335.Dv PF_KEY
336socket is insufficient.
337If you manipulate many IPsec key/policy database entries,
338increase the size of socket buffer.
339