-
Notifications
You must be signed in to change notification settings - Fork 11
/
Copy pathTODO
89 lines (76 loc) · 5.07 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# $Id: TODO
List of work needed on the racoon2 package
1. Debug and fix the management of the phase 2 SA's in IKEv1 when the peer
terminates the connection and the phase 1 ISAKMP-SA is purged. Currently
only one of the phase 2 SA's is deleted. The other one can be deleted
using the ph1-down hook scripts. It is not clear that ph2handle structures
are being freed when the corresponding phase1 1 is purged. The problem
might be that the phase1 is unbound from the phase 2 too soon.
When running in gdb, at ikev1/handler.c:1543, it was observed that the
ph1 was unound so execution did not enter the path where the ipsec sa
is deleted.
2. Add a racoon2ctl tool to allow an initiator to connect and disconnect
gracefully. With ikev1, there is the further problem that when
SIGTERM is sent to iked according to the iked man page, the connection
is not deleted as it is with IKEv2 connections. Specifically, The ipsec
security associations and the phase 1 security association is not
deleted, and. the notify message with delete payload is not sent
to the peer. Fix this for IKEv1.
3. Debug generate policy for IKEv1. This is supposed to be enabled
with peers ip address set to IP_RW and also both my and peers
sa_ipaddress set to IP_RW in the policy specification, but it is not
functioning.
4. IPv6 support- it is not clear why iked is not using IPv6 addresses
when ike is set to use MY_IP, which is supposed to use all addresses
not just IPv4 addresses. Now, iked is behaving as if we set ike in
the interface section of racoon2.conf to MY_IPV4 instead of MY_IP. It
would be desireable to get iked to use IPv6 addresses so we can test
racoon2 with IPv6.
5. For NAT traversal in transport mode, NAT original address payloads are
ignored on input. Also, iked does not send the NAT original address
payloads to the peer. This can be fixed by using the addresses
in the id payload from the peer at the beginning of phase 2 which are also
the NAT-OA addresses when there is a NAT device. Then we also need to include
the NAT-OA data in the pfkey message to the kernel where the incremental
checksum fixup can be done done. Racoon does send this pfkey message, so we
can use that as a starting point. This will make it possible to optimize the
checksum fixup in the kernel, eliminating the need to recompute the checksum
over the entire packet and replace that expensive computation with an
incremental checksum over just a few bytes.
6. For the IKEv1 NAT-T transport mode case, investigate why it is necessary to
have selectors on the responder's for the addresses that are valid only
the initiator side. According to RFC 7296 [1], these should not be necessary.
If a better way to pass the selector check at the beginning of phase 2
exists for the NAT-T transport mode case that will eliminate the need for
the additional seclectors we are currently adding to the configuration in the
transport_ike_natt.conf file, implement it. This can probably be accomplished
by implementing address substition on the traffic selectors, as described
in RFC 7296.
7. Deal with packet fragmentation. The code looks old/incomplete.
8. Fix IP_ANY/IP_RW confusion. This is the cause of many configuration-related
bugs. We already have a patch which modifies a portion of the code to treat
IP_RW as IP_ANY at:
https://github.com/zoulasc/racoon2/commit/1623aefa49ed4f0e4e86418c61c62d736b306137
The way the code is structured, it is not clear that to treat IP_RW as IP_ANY is
the same thing as treating IP_ANY as IP_RW. Perhaps it is better to rewrite
so that IP_ANY is always treated as IP_RW, and then eliminate IP_RW as a
configuration option or as simply an alias for IP_ANY? No, it is more complicated
than that. In some cases, IP_ANY means that since we do not yet know the address
that an actual connection will be using, we need to wait until we are
establishing a connection and know the address for that connection before updating
the SPD in the kernel. In other cases, we can do the configuration correctly
without knowing the actual address that is used by a connection.
Fixed issues:
1. Relax the matching that racoon2 does at the beginning of the phase2 exchange
when we are acting as a passive responder. Previously the selectors need to
exactly match the traffic the client/peer is proposing to send to us and
receive from us. For example, if our selectors specify that we want to
require esp in transport mode for the udp upper layer protocol and any
port but the peer specifies only udp port 1701, the L2TP port, then
racoon2 failed to find a matching selector. Racoon is much more forgiving
at this stage of the negotiations with the peer. This behavior made it
virtually impossible to craft a flexible configuration that supports
multiple types of clients, such as both Windows and iPhone L2TP/IPSec
clients using racoon2. This problem was fixed at:
https://github.com/zoulasc/racoon2/commit/bbd6fb8e15a60dd439e19e0fa79aa4b4445d4ec9
[1] https://tools.ietf.org/html/rfc7296#section-2.23.1