Return to TODO CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ipsec-tools / src / racoon

ipsec-tools

    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: