summaryrefslogtreecommitdiffstats
path: root/ipsec-tools/src/racoon/TODO
diff options
context:
space:
mode:
Diffstat (limited to 'ipsec-tools/src/racoon/TODO')
-rw-r--r--ipsec-tools/src/racoon/TODO131
1 files changed, 131 insertions, 0 deletions
diff --git a/ipsec-tools/src/racoon/TODO b/ipsec-tools/src/racoon/TODO
new file mode 100644
index 00000000..1507167e
--- /dev/null
+++ b/ipsec-tools/src/racoon/TODO
@@ -0,0 +1,131 @@
+$KAME: TODO,v 1.36 2001/09/19 09:41:39 sakane Exp $
+
+Please send any questions or bug reports to snap-users@kame.net.
+
+TODO list
+
+URGENT
+o The documents for users convenience.
+o split log file based on client. printf-like config directive, i.e.
+ "logfile racoon.%s.log", should be useful here.
+ -> beware of possible security issue, don't use sprintf() directly!
+ make validation before giving a string to sprintf().
+o save decrypted IKE packet in tcpdump format
+o IPComp SA with wellknown CPI in CPI field. how to handle it?
+o better rekey
+
+MUST
+o multiple certificate payload handling.
+o To consider the use with certificate infrastructure. PXIX ???
+o kmstat should be improved.
+o Informational Exchange processing properly.
+o require less configuration. phase 2 is easier (as kernel presents racoon
+ some hints), phase 1 is harder. for example,
+ - grab phase 2 lifetime and algorith configuration from sadb_comb payloads in
+ ACQUIRE message.
+ - give reasonable default behavior when no configuration file is present.
+ - difficult items:
+ how to guess a reasonable phase 1 SA lifetime
+ (hardcoded default? guess from phase 2 lifetime?)
+ guess what kind of ID payload to use
+ guess what kind of authentication to be used
+ guess phase 1 DH group (for aggressive mode, we cannot negotiate it)
+ guess if we need phase 2 PFS or not (we cannot negotiate it. so
+ we may need to pick from "no PFS" or "same as phase 1 DH group")
+ guess how we should negotiate lifetime
+ (is "strict" a reasonable default?)
+ guess which mode to use for phase 1 negotiation (is main mode useful?
+ is base mode popular enough?)
+o more acceptable check.
+
+SHOULD
+o psk.txt should be a database? (psk.db?) psk_mkdb?
+o Dynamically retry to exchange and resend the packet per nodes.
+o To make the list of supported algorithm by sadb_supported payload
+ in the SADB_REGISTER message which happens asynchronously.
+o fix the structure of ph2handle.
+ We can handle the below case.
+
+ node A node B
+ +--------------SA1----------------+
+ +--------------SA2----------------+
+
+ at node A:
+ kernel
+ acquire(A-B) ------> ph2handle(A=B) -----> ph1handle
+ |
+ policy
+ A=B
+ A=B
+
+ But we can not handle the below case because there is no x?handle.
+
+ node A node B node C
+ +--------------SA1----------------+
+ +------------------------------------------------SA2---------------+
+
+ at node A:
+ kernel
+ acquire(A-C) ---+---> x?handle ---+---> ph2handle(A=B) -------> ph1handle
+ | | |
+ acquire(A-B) ---+ policy +---> ph2handle(A=C) -------> ph1handle
+ A=B
+ A=C
+
+o consistency of function name.
+o deep copy configuration entry to hander. It's easy to reload configuration.
+o don't keep to hold keymat values, do it ?
+o local address's field in isakmpsa handler must be kicked out to rmconf.
+o responder policy and initiator policy should be separated.
+o for lifetime and key length, something like this should be useful.
+ - propose N
+ - accept between X and Y
+o wildcard "accept any proposal" policy should be allowed.
+o replay prevention
+ - limited total number of session
+ - limited session per peer
+ - number of proposal
+o full support for variable length SPI. quickhack support for IPComp is done.
+
+MAY
+o Effective code.
+o interaction between IKE/IPsec and socket layer.
+ at this moment, IKE/IPsec failure is modeled as total packet loss to other
+ part of network subsystem, including socket layer. this presents the
+ following behaviors:
+ - annoyingly long timeouts on tcp connection attempt, and IKE failure;
+ need to wait till tcp socket timeouts.
+ - blackhole if there's mismatching SAs.
+ we may be able to give socket layer some feedback from IKE/IPsec layer.
+ still not sure if those make sense or not.
+ for example:
+ - send PRU_HOSTDEAD to sockets if IKE negotiation failed
+ (sys/netkey/key.c:key_acquire2)
+ to do this, we need to remember which ACQUIRE was caused by which socket,
+ possibly into larval SAs.
+ - PRU_QUENCH on "no SA found on output"
+ - kick tcp retransmission timer on first SA establishment
+o IKE daemon should handle situations where peer does not run IKE daemon
+ (UDP port unreach for port 500) better.
+ should use connected UDP sockets for sending IKE datagrams.
+o rate-limit log messages from kernel IPsec errors, like "no SA found".
+
+TO BE TESTED.
+o IKE retransmit behavior
+ see, draft-*-ipsec-rekeying*.txt
+o Reboot recovery (peer reboot losing it's security associations)
+ see, draft-*-ipsec-rekeying*.txt
+o Scenarios
+ - End-to-End transport long lived security associations
+ (over night, data transfer >1Gb) with frequent dynamic rekey
+ - End-to-GW tunnel long lived security associations
+ (over night, data transfer >1Gb) with frequent dynamic rekey
+ - Policy change events while under SA load
+ - End-to-End SA through IPsec tunnels, initiation both ways
+ - Client End-to-End through client-to-GW tunnel SA, initiate from
+ client for tunnel, then initiation both ways for end-to-end
+ - Client-to-GW transport SA for secure management
+o behavior to receive multiple auth method proposals and AND proposal
+
+and to be written many many.
+