Home | History | Annotate | Download | only in racoon
      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 (a] 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 
    132