1 | $KAME: TODO,v 1.36 2001/09/19 09:41:39 sakane Exp $ |
---|
2 | |
---|
3 | Please send any questions or bug reports to snap-users@kame.net. |
---|
4 | |
---|
5 | TODO list |
---|
6 | |
---|
7 | URGENT |
---|
8 | o The documents for users convenience. |
---|
9 | o 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(). |
---|
13 | o save decrypted IKE packet in tcpdump format |
---|
14 | o IPComp SA with wellknown CPI in CPI field. how to handle it? |
---|
15 | o better rekey |
---|
16 | |
---|
17 | MUST |
---|
18 | o multiple certificate payload handling. |
---|
19 | o To consider the use with certificate infrastructure. PXIX ??? |
---|
20 | o kmstat should be improved. |
---|
21 | o Informational Exchange processing properly. |
---|
22 | o 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?) |
---|
39 | o more acceptable check. |
---|
40 | |
---|
41 | SHOULD |
---|
42 | o psk.txt should be a database? (psk.db?) psk_mkdb? |
---|
43 | o Dynamically retry to exchange and resend the packet per nodes. |
---|
44 | o To make the list of supported algorithm by sadb_supported payload |
---|
45 | in the SADB_REGISTER message which happens asynchronously. |
---|
46 | o 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 | |
---|
75 | o consistency of function name. |
---|
76 | o deep copy configuration entry to hander. It's easy to reload configuration. |
---|
77 | o don't keep to hold keymat values, do it ? |
---|
78 | o local address's field in isakmpsa handler must be kicked out to rmconf. |
---|
79 | o responder policy and initiator policy should be separated. |
---|
80 | o for lifetime and key length, something like this should be useful. |
---|
81 | - propose N |
---|
82 | - accept between X and Y |
---|
83 | o wildcard "accept any proposal" policy should be allowed. |
---|
84 | o replay prevention |
---|
85 | - limited total number of session |
---|
86 | - limited session per peer |
---|
87 | - number of proposal |
---|
88 | o full support for variable length SPI. quickhack support for IPComp is done. |
---|
89 | |
---|
90 | MAY |
---|
91 | o Effective code. |
---|
92 | o 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 |
---|
108 | o 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. |
---|
111 | o rate-limit log messages from kernel IPsec errors, like "no SA found". |
---|
112 | |
---|
113 | TO BE TESTED. |
---|
114 | o IKE retransmit behavior |
---|
115 | see, draft-*-ipsec-rekeying*.txt |
---|
116 | o Reboot recovery (peer reboot losing it's security associations) |
---|
117 | see, draft-*-ipsec-rekeying*.txt |
---|
118 | o 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 |
---|
128 | o behavior to receive multiple auth method proposals and AND proposal |
---|
129 | |
---|
130 | and to be written many many. |
---|
131 | |
---|