Annotation of embedaddon/ipsec-tools/src/racoon/TODO, revision 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:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to TODO CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ipsec-tools / src / racoon