1$KAME: TODO,v 1.36 2001/09/19 09:41:39 sakane Exp $
2
3Please send any questions or bug reports to snap-users@kame.net.
4
5TODO list
6
7URGENT
8o The documents for users convenience.
9o split log file based on client.  printf-like config directive, i.e.
10  "logfile racoon.%s.log", should be useful here.
11  -> beware of possible security issue, don't use sprintf() directly!
12     make validation before giving a string to sprintf().
13o save decrypted IKE packet in tcpdump format
14o IPComp SA with wellknown CPI in CPI field.  how to handle it?
15o better rekey
16
17MUST
18o multiple certificate payload handling.
19o To consider the use with certificate infrastructure.  PXIX ???
20o kmstat should be improved.
21o Informational Exchange processing properly.
22o require less configuration.  phase 2 is easier (as kernel presents racoon
23  some hints), phase 1 is harder.  for example,
24  - grab phase 2 lifetime and algorith configuration from sadb_comb payloads in
25    ACQUIRE message.
26  - give reasonable default behavior when no configuration file is present.
27  - difficult items:
28	how to guess a reasonable phase 1 SA lifetime
29		(hardcoded default?  guess from phase 2 lifetime?)
30	guess what kind of ID payload to use
31	guess what kind of authentication to be used
32	guess phase 1 DH group (for aggressive mode, we cannot negotiate it)
33	guess if we need phase 2 PFS or not (we cannot negotiate it. so
34		we may need to pick from "no PFS" or "same as phase 1 DH group")
35	guess how we should negotiate lifetime
36		(is "strict" a reasonable default?)
37	guess which mode to use for phase 1 negotiation (is main mode useful?
38		is base mode popular enough?)
39o more acceptable check.
40
41SHOULD
42o psk.txt should be a database? (psk.db?)  psk_mkdb?
43o Dynamically retry to exchange and resend the packet per nodes.
44o To make the list of supported algorithm by sadb_supported payload
45  in the SADB_REGISTER message which happens asynchronously.
46o fix the structure of ph2handle.
47  We can handle the below case.
48
49  node A                            node B
50    +--------------SA1----------------+
51    +--------------SA2----------------+
52
53  at node A:
54  kernel
55    acquire(A-B) ------> ph2handle(A=B) -----> ph1handle
56                              |
57                            policy
58                             A=B
59                             A=B
60
61  But we can not handle the below case because there is no x?handle.
62
63  node A                            node B                           node C
64    +--------------SA1----------------+
65    +------------------------------------------------SA2---------------+
66
67  at node A:
68  kernel
69    acquire(A-C) ---+---> x?handle ---+---> ph2handle(A=B) -------> ph1handle
70                    |        |        |
71    acquire(A-B) ---+      policy     +---> ph2handle(A=C) -------> ph1handle
72                            A=B
73                            A=C
74
75o consistency of function name.
76o deep copy configuration entry to hander.  It's easy to reload configuration.
77o don't keep to hold keymat values, do it ?
78o local address's field in isakmpsa handler must be kicked out to rmconf.
79o responder policy and initiator policy should be separated.
80o for lifetime and key length, something like this should be useful.
81  - propose N
82  - accept between X and Y
83o wildcard "accept any proposal" policy should be allowed.
84o replay prevention
85  - limited total number of session
86  - limited session per peer
87  - number of proposal
88o full support for variable length SPI.  quickhack support for IPComp is done.
89
90MAY
91o Effective code.
92o interaction between IKE/IPsec and socket layer.
93  at this moment, IKE/IPsec failure is modeled as total packet loss to other
94  part of network subsystem, including socket layer.  this presents the
95  following behaviors:
96  - annoyingly long timeouts on tcp connection attempt, and IKE failure;
97    need to wait till tcp socket timeouts.
98  - blackhole if there's mismatching SAs.
99  we may be able to give socket layer some feedback from IKE/IPsec layer.
100  still not sure if those make sense or not.
101  for example:
102  - send PRU_HOSTDEAD to sockets if IKE negotiation failed
103    (sys/netkey/key.c:key_acquire2)
104    to do this, we need to remember which ACQUIRE was caused by which socket,
105    possibly into larval SAs.
106  - PRU_QUENCH on "no SA found on output"
107  - kick tcp retransmission timer on first SA establishment
108o IKE daemon should handle situations where peer does not run IKE daemon
109  (UDP port unreach for port 500) better.
110  should use connected UDP sockets for sending IKE datagrams.
111o rate-limit log messages from kernel IPsec errors, like "no SA found".
112
113TO BE TESTED.
114o IKE retransmit behavior
115	see, draft-*-ipsec-rekeying*.txt
116o Reboot recovery (peer reboot losing it's security associations)
117	see, draft-*-ipsec-rekeying*.txt
118o Scenarios
119	- End-to-End transport long lived security associations
120	  (over night, data transfer >1Gb) with frequent dynamic rekey
121	- End-to-GW tunnel long lived security associations
122	  (over night, data transfer >1Gb) with frequent dynamic rekey
123	- Policy change events while under SA load
124	- End-to-End SA through IPsec tunnels, initiation both ways
125	- Client End-to-End through client-to-GW tunnel SA, initiate from
126	  client for tunnel, then initiation both ways for end-to-end
127	- Client-to-GW transport SA for secure management
128o behavior to receive multiple auth method proposals and AND proposal
129
130and to be written many many.
131
132