Return to TODO CVS log

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

Annotation of embedaddon/ipsec-tools/src/racoon/TODO, revision 1.1.1.1

1.1       misho       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: