denozord/strongswan-ext
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
Martin Willi
2006-04-28 09:07:55 +00:00
parent a06e45dc9c
commit 83cb0b0e8c
370 changed files with 35 additions and 194736 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Makefile
+5 -565
View File
@@ -19,584 +19,24 @@ export FREESWANSRCDIR
include Makefile.inc
PATCHES=linux
# where KLIPS goes in the kernel
# note, some of the patches know the last part of this path
KERNELKLIPS=$(KERNELSRC)/net/ipsec
KERNELCRYPTODES=$(KERNELSRC)/crypto/ciphers/des
KERNELLIBFREESWAN=$(KERNELSRC)/lib/libfreeswan
KERNELLIBZLIB=$(KERNELSRC)/lib/zlib
KERNELLIBCRYPTO=$(KERNELSRC)/lib/libcrypto
KERNELINCLUDE=$(KERNELSRC)/include
KERNELALG=$(KERNELKLIPS)/alg
MAKEUTILS=packaging/utils
ERRCHECK=${MAKEUTILS}/errcheck
KVUTIL=${MAKEUTILS}/kernelversion
KVSHORTUTIL=${MAKEUTILS}/kernelversion-short
# kernel details
# what variant of our patches should we use, and where is it
KERNELREL=$(shell ${KVSHORTUTIL} ${KERNELSRC}/Makefile)
# directories visited by all recursion
SUBDIRS=doc lib programs linux
SUBDIRS=lib programs linux
# declaration for make's benefit
.PHONY: def insert kpatch klink klibcryptolink patches _patches _patches2.2 _patches2.4 \
klipsdefaults programs install clean distclean \
ogo oldgo menugo xgo \
omod oldmod menumod xmod \
pcf ocf mcf xcf rcf nopromptgo \
precheck verset confcheck kernel module kinstall minstall \
backup unpatch uinstall install_file_list \
snapready relready ready buildready devready uml check taroldinstall \
umluserland
# dummy default rule
def:
@echo "Please read doc/intro.html or INSTALL before running make"
@false
# everything that's necessary to put Klips into the kernel
insert: patches klink klipsdefaults
kpatch: unapplypatch applypatch klipsdefaults
unapplypatch:
-if [ -f ${KERNELSRC}/freeswan.patch ]; then \
echo Undoing previous patches; \
cat ${KERNELSRC}/freeswan.patch | (cd ${KERNELSRC} && patch -p1 -R --force -E -z .preipsec --reverse --ignore-whitespace ); \
fi
applypatch:
echo Now performing forward patches;
make kernelpatch${KERNELREL} | tee ${KERNELSRC}/freeswan.patch | (cd ${KERNELSRC} && patch -p1 -b -z .preipsec --forward --ignore-whitespace )
kdiff:
echo Comparing ${KERNELSRC} to ${FREESWANSRCDIR}/linux.
packaging/utils/kerneldiff ${KERNELSRC}
# create KERNELKLIPS and populate it with symlinks to the sources
klink:
-[ -L $(KERNELKLIPS)/ipsec_init.c ] && rm -rf ${KERNELKLIPS}
-[ -L $(KERNELCRYPTODES)/cbc_enc.c ] && rm -rf ${KERNELCRYPTODES}
-[ -L $(KERNELLIBFREESWAN)/subnettoa.c ] && rm -rf ${KERNELLIBFREESWAN}
-[ -L ${KERNELLIBZLIB}/deflate.c ] && rm -rf ${KERNELLIBZLIB}
-[ -L ${KERNELINCLUDE}/freeswan.h ] && for i in linux/include/*; do rm -f ${KERNELINCLUDE}/$$i; done
-[ -L $(KERNELALG)/Makefile ] && rm -rf $(KERNELALG)
-[ -L $(KERNELLIBCRYPTO) ] && rm -f $(KERNELLIBCRYPTO)
mkdir -p $(KERNELKLIPS)
mkdir -p $(KERNELCRYPTODES)
mkdir -p $(KERNELLIBFREESWAN)
mkdir -p $(KERNELLIBZLIB)
mkdir -p $(KERNELALG)
$(KLIPSLINK) `pwd`/Makefile.ver $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/include/* $(KERNELINCLUDE)
$(KLIPSLINK) `pwd`/linux/net/ipsec/Makefile* $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/Config.in $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/defconfig $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/*.[ch] $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/Makefile* $(KERNELALG)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/Config.* $(KERNELALG)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/ipsec_alg*.[ch] $(KERNELALG)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/scripts $(KERNELALG)
# Each ALGo does it own symlinks
$(KLIPSLINK) `pwd`/lib/libcrypto $(KERNELLIBCRYPTO)
$(KLIPSLINK) `pwd`/linux/lib/zlib/*.[ch] $(KERNELLIBZLIB)
$(KLIPSLINK) `pwd`/linux/lib/zlib/Makefile* $(KERNELLIBZLIB)
$(KLIPSLINK) `pwd`/linux/lib/libfreeswan/*.[ch] $(KERNELLIBFREESWAN)
$(KLIPSLINK) `pwd`/linux/lib/libfreeswan/Makefile* $(KERNELLIBFREESWAN)
$(KLIPSLINK) `pwd`/linux/crypto/ciphers/des/*.[chsS] $(KERNELCRYPTODES)
$(KLIPSLINK) `pwd`/linux/crypto/ciphers/des/Makefile* $(KERNELCRYPTODES)
sed '/"/s/xxx/$(IPSECVERSION)/' linux/lib/libfreeswan/version.in.c >$(KERNELKLIPS)/version.c
# create libcrypto symlink
klibcryptolink:
-[ -L $(KERNELLIBCRYPTO) ] && rm -f $(KERNELLIBCRYPTO)
$(KLIPSLINK) `pwd`/lib/libcrypto $(KERNELLIBCRYPTO)
# patch kernel
PATCHER=packaging/utils/patcher
patches:
@echo \"make patches\" is obsolete. See \"make kpatch\".
exit 1
_patches:
echo "===============" >>out.kpatch
echo "`date` `cd $(KERNELSRC) ; pwd`" >>out.kpatch
$(MAKE) __patches$(KERNELREL) >>out.kpatch
# Linux-2.0.x version
__patches __patches2.0:
@$(PATCHER) -v $(KERNELSRC) Documentation/Configure.help \
'CONFIG_IPSEC' $(PATCHES)/Documentation/Configure.help.fs2_0.patch
@$(PATCHER) -v $(KERNELSRC) net/Config.in \
'CONFIG_IPSEC' $(PATCHES)/net/Config.in.fs2_0.patch
@$(PATCHER) -v $(KERNELSRC) net/Makefile \
'CONFIG_IPSEC' $(PATCHES)/net/Makefile.fs2_0.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/af_inet.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/af_inet.c.fs2_0.patch
# Removed patches, will unpatch automatically.
@$(PATCHER) -v $(KERNELSRC) include/linux/proc_fs.h
@$(PATCHER) -v $(KERNELSRC) net/core/dev.c
@$(PATCHER) -v $(KERNELSRC) net/ipv4/protocol.c
@$(PATCHER) -v $(KERNELSRC) drivers/net/Space.c
@$(PATCHER) -v $(KERNELSRC) net/netlink.c
@$(PATCHER) -v $(KERNELSRC) drivers/isdn/isdn_net.c
# Linux-2.2.x version
PATCHES24=klips/patches2.3
__patches2.2:
@$(PATCHER) -v -c $(KERNELSRC) Documentation/Configure.help \
'CONFIG_IPSEC' $(PATCHES)/Documentation/Configure.help.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/Config.in \
'CONFIG_IPSEC' $(PATCHES)/net/Config.in.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/Makefile \
'CONFIG_IPSEC' $(PATCHES)/net/Makefile.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/af_inet.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/af_inet.c.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/udp.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/udp.c.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) include/net/sock.h \
'CONFIG_IPSEC' $(PATCHES)/net/include.net.sock.h.fs2_2.patch
# Removed patches, will unpatch automatically.
@$(PATCHER) -v $(KERNELSRC) include/linux/proc_fs.h
@$(PATCHER) -v $(KERNELSRC) net/core/dev.c
@$(PATCHER) -v $(KERNELSRC) net/ipv4/protocol.c
@$(PATCHER) -v $(KERNELSRC) drivers/net/Space.c
@$(PATCHER) -v $(KERNELSRC) include/linux/netlink.h
@$(PATCHER) -v $(KERNELSRC) net/netlink/af_netlink.c
@$(PATCHER) -v $(KERNELSRC) net/netlink/netlink_dev.c
@$(PATCHER) -v $(KERNELSRC) include/linux/socket.h
@$(PATCHER) -v $(KERNELSRC) drivers/isdn/isdn_net.c
# Linux-2.4.0 version
PATCHES22=klips/patches2.2
__patches2.3 __patches2.4:
@$(PATCHER) -v -c $(KERNELSRC) Documentation/Configure.help \
'CONFIG_IPSEC' $(PATCHES)/Documentation/Configure.help.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/Config.in \
'CONFIG_IPSEC' $(PATCHES)/net/Config.in.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) net/Makefile \
'CONFIG_IPSEC' $(PATCHES)/net/Makefile.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/af_inet.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/af_inet.c.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/udp.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/udp.c.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) include/net/sock.h \
'CONFIG_IPSEC' $(PATCHES)/net/include.net.sock.h.fs2_4.patch
# Removed patches, will unpatch automatically.
@$(PATCHER) -v $(KERNELSRC) include/linux/proc_fs.h
@$(PATCHER) -v $(KERNELSRC) net/core/dev.c
@$(PATCHER) -v $(KERNELSRC) net/ipv4/protocol.c
@$(PATCHER) -v $(KERNELSRC) drivers/net/Space.c
@$(PATCHER) -v $(KERNELSRC) include/linux/netlink.h
@$(PATCHER) -v $(KERNELSRC) net/netlink/af_netlink.c
@$(PATCHER) -v $(KERNELSRC) net/netlink/netlink_dev.c
@$(PATCHER) -v $(KERNELSRC) drivers/isdn/isdn_net.c
klipsdefaults:
@KERNELDEFCONFIG=$(KERNELSRC)/arch/$(ARCH)/defconfig ; \
KERNELCONFIG=$(KCFILE) ; \
if ! egrep -q 'CONFIG_IPSEC' $$KERNELDEFCONFIG ; \
then \
set -x ; \
cp -a $$KERNELDEFCONFIG $$KERNELDEFCONFIG.orig ; \
chmod u+w $$KERNELDEFCONFIG ; \
cat $$KERNELDEFCONFIG $(KERNELKLIPS)/defconfig \
>$$KERNELDEFCONFIG.tmp ; \
rm -f $$KERNELDEFCONFIG ; \
cp -a $$KERNELDEFCONFIG.tmp $$KERNELDEFCONFIG ; \
rm -f $$KERNELDEFCONFIG.tmp ; \
fi ; \
if ! egrep -q 'CONFIG_IPSEC' $$KERNELCONFIG ; \
then \
set -x ; \
cp -a $$KERNELCONFIG $$KERNELCONFIG.orig ; \
chmod u+w $$KERNELCONFIG ; \
cat $$KERNELCONFIG $(KERNELKLIPS)/defconfig \
>$$KERNELCONFIG.tmp ; \
rm -f $$KERNELCONFIG ; \
cp -a $$KERNELCONFIG.tmp $$KERNELCONFIG ; \
rm -f $$KERNELCONFIG.tmp ; \
fi
.PHONY: programs install clean distclean \
uninstall install_file_list
# programs
checkv199install:
if [ -f ${LIBDIR}/pluto ]; \
then \
echo WARNING: FreeS/WAN 1.99 still installed. ;\
echo WARNING: moving ${LIBDIR} to ${LIBDIR}.v1 ;\
mv ${LIBDIR} ${LIBDIR}.v1 ;\
fi
all: programs
install:: checkv199install
programs install clean checkprograms::
programs install install_file_list clean::
@for d in $(SUBDIRS) ; \
do \
(cd $$d && $(MAKE) FREESWANSRCDIR=.. $@ ) || exit 1; \
done; \
clean::
rm -rf $(RPMTMPDIR) $(RPMDEST)
rm -f out.*build out.*install # but leave out.kpatch
rm -f rpm.spec
distclean: clean
rm -f out.kpatch
if [ -f umlsetup.sh ]; then source umlsetup.sh; if [ -d "$$POOLSPACE" ]; then rm -rf $$POOLSPACE; fi; fi
# proxies for major kernel make operations
# do-everything entries
KINSERT_PRE=precheck verset insert
PRE=precheck verset kpatch klibcryptolink
POST=confcheck programs kernel install
MPOST=confcheck programs module install
ogo: $(PRE) pcf $(POST)
oldgo: $(PRE) ocf $(POST)
nopromptgo: $(PRE) rcf $(POST)
menugo: $(PRE) mcf $(POST)
xgo: $(PRE) xcf $(POST)
omod: $(PRE) pcf $(MPOST)
oldmod: $(PRE) ocf $(MPOST)
menumod: $(PRE) mcf $(MPOST)
xmod: $(PRE) xcf $(MPOST)
# preliminaries
precheck:
@if test ! -d $(KERNELSRC) -a ! -L $(KERNELSRC) ; \
then \
echo '*** cannot find directory "$(KERNELSRC)"!!' ; \
echo '*** may be necessary to add symlink to kernel source' ; \
exit 1 ; \
fi
@if ! cd $(KERNELSRC) ; \
then \
echo '*** cannot "cd $(KERNELSRC)"!!' ; \
echo '*** may be necessary to add symlink to kernel source' ; \
exit 1 ; \
fi
@if test ! -f $(KCFILE) ; \
then \
echo '*** cannot find "$(KCFILE)"!!' ; \
echo '*** perhaps kernel has never been configured?' ; \
echo '*** please do that first; the results are necessary.' ; \
exit 1 ; \
fi
@if test ! -f $(VERFILE) ; \
then \
echo '*** cannot find "$(VERFILE)"!!' ; \
echo '*** perhaps kernel has never been compiled?' ; \
echo '*** please do that first; the results are necessary.' ; \
exit 1 ; \
fi
# set version code if this is a fresh CVS checkout
ifeq ($(wildcard cvs.datemark),cvs.datemark)
verset Makefile.ver: cvs.datemark
echo IPSECVERSION=`date -r cvs.datemark +cvs%Y%b%d_%H:%M:%S` >Makefile.ver
rm -f cvs.datemark;
else
verset Makefile.ver:
@grep IPSECVERSION Makefile.ver
endif
Makefile: Makefile.ver
# configuring (exit statuses disregarded, something fishy here sometimes)
xcf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) xconfig
mcf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) menuconfig
pcf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) config
ocf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) oldconfig
rcf:
cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) oldconfig_nonint </dev/null
cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) dep >/dev/null
confcheck:
@if test ! -f $(KCFILE) ; \
then echo '*** no kernel configuration file written!!' ; exit 1 ; \
fi
@if ! egrep -q '^CONFIG_IPSEC=[my]' $(KCFILE) ; \
then echo '*** IPsec not in kernel config ($(KCFILE))!!' ; exit 1 ; \
fi
@if ! egrep -q 'CONFIG_IPSEC[ ]+1' $(ACFILE) && \
! egrep -q 'CONFIG_IPSEC_MODULE[ ]+1' $(ACFILE) ; \
then echo '*** IPsec in kernel config ($(KCFILE)),' ; \
echo '*** but not in config header file ($(ACFILE))!!' ; \
exit 1 ; \
fi
@if egrep -q '^CONFIG_IPSEC=m' $(KCFILE) && \
! egrep -q '^CONFIG_MODULES=y' $(KCFILE) ; \
then echo '*** IPsec configured as module in kernel with no module support!!' ; exit 1 ; \
fi
@if ! egrep -q 'CONFIG_IPSEC_AH[ ]+1' $(ACFILE) && \
! egrep -q 'CONFIG_IPSEC_ESP[ ]+1' $(ACFILE) ; \
then echo '*** IPsec configuration must include AH or ESP!!' ; exit 1 ; \
fi
# kernel building, with error checks
kernel:
rm -f out.kbuild out.kinstall
# undocumented kernel folklore: clean BEFORE dep.
# we run make dep seperately, because there is no point in running ERRCHECK
# on the make dep output.
# see LKML thread "clean before or after dep?"
( cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) $(KERNCLEAN) $(KERNDEP) )
( cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) $(KERNEL) ) 2>&1 | tee out.kbuild
@if egrep -q '^CONFIG_MODULES=y' $(KCFILE) ; \
then set -x ; \
( cd $(KERNELSRC) ; \
$(MAKE) $(KERNMAKEOPTS) modules 2>&1 ) | tee -a out.kbuild ; \
fi
${ERRCHECK} out.kbuild
# this target takes a kernel source tree and it builds a link tree,
# and then does make oldconfig for each .config file that was found in configs.
# The location for the disk space required for the link tree is found via
# $RH_KERNELSRC_POOL
preprhkern4module:
if [ -z "${RH_KERNELSRC_POOL}" ]; then echo Please set RH_KERNELSRC_POOL.; exit 1; fi
mkdir -p ${RH_KERNELSRC_POOL}
KV=`${KVUTIL} $(RH_KERNELSRC)/Makefile` ; \
cd ${RH_KERNELSRC_POOL} && \
mkdir -p $$KV && cd $$KV && \
for config in ${RH_KERNELSRC}/configs/*; do \
basecfg=`basename $$config` ;\
mkdir -p ${RH_KERNELSRC_POOL}/$$KV/$$basecfg && \
cd ${RH_KERNELSRC_POOL}/$$KV/$$basecfg && \
lndir ${RH_KERNELSRC} . && \
rm -rf include/asm && \
(cd include/linux && sed -e '/#include "\/boot\/kernel.h"/d' <rhconfig.h >rhconfig.h-new && mv rhconfig.h-new rhconfig.h ) && \
rm -f include/linux/modules/*.stamp && \
make dep && \
make oldconfig; \
done;
# module-only building, with error checks
ifneq ($(strip $(MODBUILDDIR)),)
${MODBUILDDIR}/Makefile : ${FREESWANSRCDIR}/packaging/makefiles/module.make
mkdir -p ${MODBUILDDIR}
cp ${FREESWANSRCDIR}/packaging/makefiles/module.make ${MODBUILDDIR}/Makefile
echo "# " >>${MODBUILDDIR}/Makefile
echo "# Local Variables: " >>${MODBUILDDIR}/Makefile
echo "# compile-command: \"${MAKE} FREESWANSRCDIR=${FREESWANSRCDIR} ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} ipsec.o\"" >>${MODBUILDDIR}/Makefile
echo "# End: " >>${MODBUILDDIR}/Makefile
# clean out the linux/net/ipsec directory so that VPATH will work properly
module: ${MODBUILDDIR}/Makefile
${MAKE} -C linux/net/ipsec ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} clean
${MAKE} -C ${MODBUILDDIR} ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} ipsec.o
${MAKE} -C ${MODBUILDDIR} ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} LIBCRYPTO=${FREESWANSRCDIR}/lib/libcrypto MODULE_FLAGS="$(MODULE_FLAGS)" alg_modules
modclean: ${MODBUILDDIR}/Makefile
${MAKE} -C ${MODBUILDDIR} clean
# module-only install, with error checks
minstall:
( FSMODLIB=`make -C $(KERNELSRC) -p dummy | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
if [ -z "$$FSMODLIB" ] ; then \
FSMODLIB=`make -C $(KERNELSRC) -n -p modules_install | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
fi ; \
if [ -z "$$FSMODLIB" ] ; then \
echo "No known place to install module. Aborting." ; \
exit 93 ; \
fi ; \
set -x ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec ; \
cp $(MODBUILDDIR)/ipsec.o $$FSMODLIB/kernel/net/ipsec ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec/alg ; \
for i in `sed -n '/IPSEC_ALG/s/CONFIG_IPSEC_ALG_\(.*\)=[Mm]/ipsec_\1.o/p' $(KCFILE) | tr '[A-Z]' '[a-z]'`;do \
echo "installing $$i"; \
cp $(MODBUILDDIR)/alg/$$i $$FSMODLIB/kernel/net/ipsec/alg ;\
done )
else
module:
${MAKE} -C linux/net/ipsec ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} ipsec.o
${MAKE} -C linux/net/ipsec ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} LIBCRYPTO=${FREESWANSRCDIR}/lib/libcrypto MODULE_FLAGS="$(MODULE_FLAGS)" alg_modules
modclean:
${MAKE} -C linux/net/ipsec ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} clean
# module-only install, with error checks
minstall:
( FSMODLIB=`make -C $(KERNELSRC) -p dummy | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
if [ -z "$$FSMODLIB" ] ; then \
FSMODLIB=`make -C $(KERNELSRC) -n -p modules_install | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
fi ; \
if [ -z "$$FSMODLIB" ] ; then \
echo "No known place to install module. Aborting." ; \
exit 93 ; \
fi ; \
set -x ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec ; \
cp linux/net/ipsec/ipsec.o $$FSMODLIB/kernel/net/ipsec ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec/alg ; \
for i in `sed -n '/IPSEC_ALG/s/CONFIG_IPSEC_ALG_\(.*\)=[Mm]/ipsec_\1.o/p' $(KCFILE) | tr '[A-Z]' '[a-z]'`;do \
echo "installing $$i"; \
cp linux/net/ipsec/alg/$$i $$FSMODLIB/kernel/net/ipsec/alg ;\
done )
endif
# kernel install, with error checks
kinstall:
rm -f out.kinstall
>out.kinstall
# undocumented kernel folklore: modules_install must precede install (observed on RHL8.0)
@if egrep -q '^CONFIG_MODULES=y' $(KCFILE) ; \
then set -x ; \
( cd $(KERNELSRC) ; \
$(MAKE) $(KERNMAKEOPTS) modules_install 2>&1 ) | tee -a out.kinstall ; \
fi
( cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) install ) 2>&1 | tee -a out.kinstall
${ERRCHECK} out.kinstall
kernelpatch2.5:
packaging/utils/kernelpatch 2.5
kernelpatch2.4 kernelpatch:
packaging/utils/kernelpatch 2.4
kernelpatch2.2:
packaging/utils/kernelpatch 2.2
kernelpatch2.0:
packaging/utils/kernelpatch 2.0
install_file_list:
@for d in $(SUBDIRS) ; \
do \
(cd $$d && $(MAKE) --no-print-directory FREESWANSRCDIR=.. install_file_list ) || exit 1; \
done;
# take all the patches out of the kernel
# (Note, a couple of files are modified by non-patch means; they are
# included in "make backup".)
unpatch:
@echo \"make unpatch\" is obsolete. See make unapplypatch.
exit 1
_unpatch:
for f in `find $(KERNELSRC)/. -name '*.preipsec' -print` ; \
do \
echo "restoring $$f:" ; \
dir=`dirname $$f` ; \
core=`basename $$f .preipsec` ; \
cd $$dir ; \
mv -f $$core.preipsec $$core ; \
rm -f $$core.wipsec $$core.ipsecmd5 ; \
done
# uninstall, as much as possible
uninstall:
$(MAKE) --no-print-directory install_file_list | egrep -v '(/ipsec.conf$$|/ipsec.d/)' | xargs rm -f
taroldinstall:
tar --ignore-failed-read -c -z -f oldFreeSWAN.tar.gz `$(MAKE) --no-print-directory install_file_list`
# some oddities meant for the developers, probably of no use to users
# make tags and TAGS files from ctags and etags for vi and emacs, respectively.
tags TAGS: dummy
etags `find lib programs linux -name '*.[ch]'`
ctags `find lib programs linux -name '*.[ch]'`
dummy:
# at the moment there is no difference between snapshot and release build
snapready: buildready
relready: buildready
ready: devready
# set up for build
buildready:
rm -f dtrmakefile cvs.datemark
cd doc ; $(MAKE) -s
uml: programs checkprograms
@echo XXX do some checks to see if all the manual pieces are done.
-chmod +x testing/utils/make-uml.sh
testing/utils/make-uml.sh `pwd`
umluserland:
(touch Makefile.inc && source umlsetup.sh && cd $$POOLSPACE && make $$FREESWANHOSTS $$REGULARHOSTS )
# DESTDIR is normally set in Makefile.inc
# These recipes explicitly pass it to the second-level makes so that
# DESTDIR can be adjusted for building for UML without changing Makefile.inc
# See testing/utils/functions.sh
# testing/utils/make-uml.sh
# testing/utils/uml-functions.sh
check: uml Makefile.ver
ifneq ($(strip(${REGRESSRESULTS})),)
mkdir -p ${REGRESSRESULTS}
endif
@for d in $(SUBDIRS); do (cd $$d && $(MAKE) DESTDIR=${DESTDIR} checkprograms || exit 1); done
@for d in $(SUBDIRS); \
do \
echo ===================================; \
echo Now making check in $$d; \
echo ===================================; \
(cd $$d && $(MAKE) DESTDIR=${DESTDIR} check || exit 1);\
done
ifneq ($(strip(${REGRESSRESULTS})),)
-perl testing/utils/regress-summarize-results.pl ${REGRESSRESULTS}
endif
rpm:
@echo please cd packaging/redhat and
@echo run "make RH_KERNELSRC=/some/path/to/kernel/src rpm"
ipkg_strip:
@echo "Minimizing size for ipkg binaries..."
@cd $(DESTDIR)$(INC_USRLOCAL)/lib/ipsec && \
for f in *; do (if file $$f | grep ARM > /dev/null; then ( $(STRIP) --strip-unneeded $$f); fi); done
@rm -r $(DESTDIR)$(INC_USRLOCAL)/man
@rm -f $(DESTDIR)$(INC_RCDEFAULT)/*.old
@rm -f $(DESTDIR)$(INC_USRLOCAL)/lib/ipsec/*.old
@rm -f $(DESTDIR)$(INC_USRLOCAL)/libexec/ipsec/*.old
@rm -f $(DESTDIR)$(INC_USRLOCAL)/sbin/*.old
ipkg_module:
@echo "Moving ipsec.o into temporary location..."
KV=$(shell ${KVUTIL} ${KERNELSRC}/Makefile) && \
mkdir -p $(FREESWANSRCDIR)/packaging/ipkg/kernel-module/lib/modules/$$KV/net/ipsec
KV=$(shell ${KVUTIL} ${KERNELSRC}/Makefile) && \
cp linux/net/ipsec/ipsec.o $(FREESWANSRCDIR)/packaging/ipkg/kernel-module/lib/modules/$$KV/net/ipsec/
KV=$(shell ${KVUTIL} ${KERNELSRC}/Makefile)
ipkg_clean:
rm -rf $(FREESWANSRCDIR)/packaging/ipkg/kernel-module/
rm -rf $(FREESWANSRCDIR)/packaging/ipkg/ipkg/
rm -f $(FREESWANSRCDIR)/packaging/ipkg/control-freeswan
rm -f $(FREESWANSRCDIR)/packaging/ipkg/control-freeswan-module
ipkg: programs install ipkg_strip ipkg_module
@echo "Generating ipkg...";
DESTDIR=${DESTDIR} FREESWANSRCDIR=${FREESWANSRCDIR} ARCH=${ARCH} IPSECVERSION=${IPSECVERSION} ./packaging/ipkg/generate-ipkg
Makefile.inc
+2 -103
View File
@@ -33,9 +33,6 @@ SHELL=/bin/sh
### paths within the source tree
KLIPSINC=${FREESWANSRCDIR}/linux/include
KLIPSSRC=${FREESWANSRCDIR}/linux/net/ipsec
LIBFREESWANDIR=${FREESWANSRCDIR}/linux/lib/libfreeswan
FREESWANLIB=${FREESWANSRCDIR}/lib/libfreeswan/libfreeswan.a
@@ -139,25 +136,6 @@ RCDIR=$(DESTDIR)$(FINALRCDIR)
### kernel pathnames
# Kernel location: where patches are inserted, where kernel builds are done.
# this is a hack using the wildcard to look for existence of a file/dir
ifneq ($(wildcard /usr/src/linux-2.4),)
KERNELSRC?=/usr/src/linux-2.4
else
KERNELSRC?=/usr/src/linux
endif
# where kernel configuration outputs are located
KCFILE=$(KERNELSRC)/.config
ACFILE=$(KERNELSRC)/include/linux/autoconf.h
VERFILE=$(KERNELSRC)/include/linux/version.h
### misc installation stuff
# what program to use when installing things
@@ -179,59 +157,6 @@ INSTCONFFLAGS=
# extra compile flags, for userland and kernel stuff, e.g. -g for debug info
# (caution, this stuff is still being sorted out, will change in future)
USERCOMPILE?=-g -O3
KLIPSCOMPILE=-O3
# command used to link/copy KLIPS into kernel source tree
# There are good reasons why this is "ln -s"; only people like distribution
# builders should ever change it.
KLIPSLINK=ln -s -f
# extra options for use in kernel build
KERNMAKEOPTS=
# kernel Makefile targets to be done before build
# Can be overridden if you are *sure* your kernel doesn't need them. (2.2.xx
# and later reportedly do not.)
KERNDEP=dep
KERNCLEAN=clean
# kernel make name: zImage for 2.0.xx, bzImage for 2.2.xx and later, and
# boot on non-x86s (what ever happened to standards?)
INC_B=$(shell test -d $(DIRIN22) && echo b)
KERNEL=$(shell if expr " `uname -m`" : ' i.86' >/dev/null ; \
then echo $(INC_B)zImage ; \
else echo boot ; \
fi)
# temporary directory to be used when building RPMs, and where to put the
# resulting RPM tree
RPMKERNDIR := $(shell echo `pwd`/tmp.rpmkernel)
RPMTMPDIR := $(shell echo `pwd`/tmp.rpmbuild)
RPMDEST := $(shell echo `pwd`/rpms)
# Newer versions of RPM do not permit building of packages with the "rpm"
# command. For RedHat systems with older version of RPM, use:
# RPMBUILD=rpm
# instead.
RPMBUILD=rpmbuild
### paths to resources on the host system
#
# Set this to a RedHat kernel-sources RPM. This normally extracts into
# /usr/src/linux-2.4, but you might have extracted it elsewhere with
# rpm2cpio.
#
RH_KERNELSRC?=/usr/src/linux-2.4
## build environment variations
##
# set this to a place where you have installed a bind9.3
# snapshot (20021115 or better). A bind 9.2, particularly a RedHat
# installed one in RH 7.2, won't work - you wind up depending upon
# openssl.
BIND9STATICLIBDIR?=/usr/local/lib
# FreeSWAN 3.x will require bind9.
USE_LWRES?=false
@@ -250,9 +175,6 @@ IPSEC_FIREWALLTYPE=iptables
# false for now, since it is still experimental.
USE_IPSECPOLICY?=false
# include IKEPING in the distribution
USE_IKEPING?=false
# include support for KEY RR
# this will become false in late 2003.
USE_KEYRR?=true
@@ -291,38 +213,15 @@ USE_IKEV2?=true
# Default PKCS11 library
# Uncomment this line if using OpenSC <= 0.9.6
PKCS11_DEFAULT_LIB=\"/usr/lib/pkcs11/opensc-pkcs11.so\"
#PKCS11_DEFAULT_LIB=\"/usr/lib/pkcs11/opensc-pkcs11.so\"
# Uncomment this line if using OpenSC >= 0.10.0
#PKCS11_DEFAULT_LIB=\"/usr/lib/opensc-pkcs11.so\"
PKCS11_DEFAULT_LIB=\"/usr/lib/opensc-pkcs11.so\"
# Uncomment and complete this line if using another default library
#PKCS11_DEFAULT_LIB=\"/usr/lib/...\"
# Enable the leak detective to find memory leaks
USE_LEAK_DETECTIVE?=false
# set this to space where a linked/configured tree can be created by
# preprhkern4module. Only needed if you are going to be created RPMs
# outside of a distribution (as the FS team does for RedHat).
#RH_KERNELSRC_POOL=/c2/freeswan/rh_kern
# the following is a list of symbols which will be used to construct
# the module goo to identify which module goes with each kernel.
MODULE_GOO_LIST=irq_stat netif_rx register_sysctl_table send_sig
MODULE_GOO_LIST+=kmalloc __kfree_skb __ip_select_ident alloc_skb
MODULE_GOO_LIST+=icmp_send ip_fragment sock_register
MODULE_DEF_INCLUDE=${FREESWANSRCDIR}/packaging/linus/config-all.h
MODULE_DEFCONFIG?=${KLIPSSRC}/defconfig
MODULE_FLAGS:=KLIPSMODULE=true TOPDIR=${KERNELSRC} -f ${MODULE_DEFCONFIG} -f Makefile
# supply kernel-configuration ARCH defaults
ifeq ($(ARCH),)
ARCH := $(shell uname -m)
endif
# always sanitize $(ARCH)
ARCH := $(shell echo $(ARCH) | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
# export everything so that scripts can use them.
export LIBFREESWANDIR FREESWANSRCDIR FREESWANLIB
README → README.pluto
View File
doc/.cvsignore
-66
View File
@@ -1,66 +0,0 @@
HowTo.html
HowTo.html
adv_config.html
adv_config.html
background.html
background.html
biblio.html
biblio.html
compat.html
compat.html
config.html
config.html
draft-richardson-ipsec-opportunistic.nr
draft-richardson-ipsec-rr.nr
draft-richardson-ipsec-rr.txt
faq.html
faq.html
firewall.html
firewall.html
glossary.html
glossary.html
index.html
index.html
install.html
install.html
interop.html
interop.html
intro.html
intro.html
ipsec.html
ipsec.html
kernel.html
kernel.html
mail.html
mail.html
makecheck.html
manpage.d
manpage.d
manpages.html
manpages.html
multi_netjig.png
nightly.html
performance.html
performance.html
policygroups.html
politics.html
politics.html
quickstart.html
rfc.html
rfc.html
rfc_pg
roadmap.html
roadmap.html
single_netjig.png
testing.html
testing.html
toc.html
toc.html
trouble.html
trouble.html
umltesting.html
upgrading.html
user_examples.html
user_examples.html
web.html
web.html
doc/2.6.known-issues
-112
View File
@@ -1,112 +0,0 @@
Known issues with FreeS/WAN on a 2.6 kernel Claudia Schmeing
-------------------------------------------
This is an overview of known issues with FreeS/WAN on the 2.6 kernel codebase
(also 2.5.x), which includes native Linux IPsec code.
More information on the native IPsec code is available here:
http://lartc.org/howto/lartc.ipsec.html
Tools for use with that code are here:
http://ipsec-tools.sourceforge.net/
* As of FreeS/WAN 2.03, FreeS/WAN ships with some support for the 2.6 kernel
IPsec code. In 2.03, this support is preliminary, but we expect to develop
it fully. Many thanks to Herbert Xu for the initial code patches.
* Use the most recent Linux FreeS/WAN 2.x release from ftp.xs4all.nl
to try our 2.6 kernel support.
* The installation procedure for use with 2.6 kernel IPsec is a little
different from a traditional FreeS/WAN installation. Please see
the latest doc/install.html.
* Please see the design and users' mailing lists
(http://www.freeswan.org/mail.html) for more detail and the latest reports.
DESIGN-RELATED ISSUES
* In 2.6, IPsec policies are detached from routing decisions. Because of this
design, Opportunistic Encryption on the local LAN will be possible with 2.6.
One side effect: When contacting a node on the local LAN which is protected
by gateway OE, you will get asymmetrical routing (one way through the gateway,
one way direct), and IPsec will drop the return packets.
CURRENT ISSUES
* For the moment, users wishing to test FreeS/WAN with 2.6 will require
ipsec-tools' "setkey" program. Though FreeS/WAN's keying daemon, Pluto,
directly sets IPsec policy, setkey is currently required to reset kernel SPD
(Security Policy Database) states when Pluto restarts. We will likely add
this basic functionality to an upcoming FreeS/WAN release.
* State information is not available to the user, eg. ipsec
eroute/ipsec spi/ipsec look do not work. The exception: ipsec auto --status
This will be fixed in a future release.
* If you're running Opportunistic Encryption, connectivity to new hosts will
immediately fail. You may receive a message similar to this:
connect: Resource temporarily unavailable
The reason for this lies in the kernel code. Fairly complex discussion:
http://lists.freeswan.org/archives/design/2003-September/msg00073.html
As of 2.6.0-test6, this has not been fixed.
* This initial connectivity failure has an unintended side effect on DNS queries.
This will result in a rekey failure for OE connections; a %pass will be
installed for your destination IP before a %pass is re-instituted to your
DNS server. As a workaround, please add your DNS servers to
/etc/ipsec.d/policies/clear.
* Packets on all interfaces are considered for OE, including loopback. If you're
running a local nameserver, you'll still need to exempt localhost DNS traffic
as per the previous point. Since this traffic has a source of 127.0.0.1/32,
the "clear" policy group will not suffice; you'll need to add the following
%passthrough conn to ipsec.conf:
conn exclude-lo
authby=never
left=127.0.0.1
leftsubnet=127.0.0.0/8
right=127.0.0.2
rightsubnet=127.0.0.0/8
type=passthrough
auto=route
OLD ISSUES
None, yet.
RELATED DOCUMENTS
FreeS/WAN Install web page doc/install.html
FreeS/WAN Install guide INSTALL
FreeS/WAN mailing list posts, including:
http://lists.freeswan.org/archives/design/2003-September/msg00057.html
To sign up for our mailing lists, see http://www.freeswan.org/mail.html
doc/HowTo.html
-18733
View File
File diff suppressed because it is too large Load Diff
doc/Makefile
-167
View File
@@ -1,167 +0,0 @@
# Makefile to generate various formats from HTML source
#
# Assumes the htmldoc utility is available.
# This can be downloaded from www.easysw.com
#
# Also needs lynx(1) for HTML-to-text conversion
.SUFFIXES: .png .fig
FREESWANSRCDIR=..
include ${FREESWANSRCDIR}/Makefile.inc
# Format arguments for htmldoc
F="--toclevels 4 --header 1cd"
# source files in subdirectory
# basic stuff
a=src/intro.html src/upgrading.html src/quickstart.html \
src/policygroups.html src/faq.html
# related
b=src/manpages.html src/firewall.html src/trouble.html
# more advanced
c=src/compat.html src/interop.html src/performance.html \
src/testing.html src/kernel.html src/adv_config.html \
src/install.html src/config.html \
src/background.html src/user_examples.html \
src/makecheck.html src/umltesting.html \
# background and reference material
d=src/politics.html src/ipsec.html \
src/mail.html src/web.html src/glossary.html src/biblio.html \
src/rfc.html src/roadmap.html
# build and release related
e=src/umltesting.html src/makecheck.html src/nightly.html
sections=$a $b $c $d $e
# separate HTML files built in current directory
separate=intro.html install.html config.html manpages.html \
firewall.html trouble.html kernel.html roadmap.html \
compat.html interop.html politics.html ipsec.html \
mail.html performance.html testing.html web.html \
glossary.html biblio.html rfc.html faq.html \
adv_config.html user_examples.html background.html \
quickstart.html umltesting.html makecheck.html nightly.html \
upgrading.html policygroups.html
# various one-big-file formats
howto=HowTo.html HowTo.ps HowTo.pdf HowTo.txt
alldocs=${seperate} ${howto} index.html toc.html
srcdir=..
# where are scripts
SCRIPTDIR=utils
# where
TESTINGDIR=${srcdir}/testing
# where do we put HTML manpages?
HMANDIR=manpage.d
# default, build HTML only
# dependencies build most of it
# then we add index
index.html: toc.html HowTo.html manpages src/index.html
cp src/index.html index.html
# separate files plus table of contents
# and then remove HTML formatting added by htmldoc
toc.html : $(sections)
@htmldoc -t html --path ".;${TESTINGDIR}/doc" -d . $(sections)
@$(SCRIPTDIR)/cleanhtml.sh $(SCRIPTDIR)/cleanhtml.sed $(separate)
# one big HTML file
HowTo.html : $(sections)
@htmldoc -t html --toclevels 4 --header ' cf' -f $@ $(sections)
# other HowTo formats
HowTo.txt: HowTo.html
lynx -dump $< > $@
HowTo.ps : $(sections)
htmldoc -f $@ $(sections)
HowTo.pdf : $(sections)
@htmldoc -f $@ $(sections)
manpages: manp
manp: $(SCRIPTDIR)/mkhtmlman
@$(SCRIPTDIR)/mkhtmlman $(HMANDIR) `find ../programs ../lib ../linux -type f -name '*.[1-8]' -print | grep -v lwres | grep -v CVS`
programs:
all: #$(howto) $(manpages) index.html
clean:
@rm -f $(howto) $(separate) toc.html index.html
@rm -rf $(HMANDIR)
install:
#install: ${alldocs} manpages
# @mkdir -p ${DOCDIR}
# @$(foreach f, $(alldocs), \
# $(INSTALL) $f ${DOCDIR} || exit 1;\
# )
# @find ${HMANDIR} -type f -name "*.html" -print | while read file; \
# do \
# $(INSTALL) $$file ${DOCDIR} || exit 1;\
# done;
install_file_list:
@$(foreach f, $(alldocs), \
echo ${DOCDIR}/$f; \
)
@if [ -d ${HMANDIR} ]; then find ${HMANDIR} -type f -name "*.html" -print | while read file; \
do \
echo ${DOCDIR}/$$file; \
done; fi;
checkprograms: ;
check: ;
# not enabled by default, because xml2rfc must be installed first.
drafts: draft-richardson-ipsec-opportunistic.txt src/draft-richardson-ipsec-opportunistic.html \
draft-richardson-ipsec-rr.txt src/draft-richardson-ipsec-rr.html
draft-richardson-ipsec-opportunistic.txt: src/draft-richardson-ipsec-opportunistic.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2rfc $? $@
draft-richardson-ipsec-rr.txt: src/draft-richardson-ipsec-rr.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2rfc $? $@
draft-%.nr: src/draft-%.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2nroff $? $@
draft-%.html: draft-%.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2html $? $@
.fig.eps:
fig2dev -L ps $< $@
.fig.png:
fig2dev -L png $< $@
single_netjig.png: testing/single_netjig.fig
multi_netjig.png: testing/multi_netjig.fig
makecheck.html: single_netjig.png multi_netjig.png
#
# DocBook based documentation
#
xmldocs: mast.html klips/mast.4
mast.html: klips/mast.xml
xmlto html klips/mast.xml
klips/mast.4: klips/mast.xml
xmlto -o klips man klips/mast.xml
doc/README
-39
View File
@@ -1,39 +0,0 @@
This directory has the HTML FreeS/WAN documentation.
Start from either of:
toc.html table of contents for HTML docs
index.html pointers to everything, including
text files not in HTML docs
The Makefile in this directory can generate various
things from the HTML source:
./*.html individual HTML files
with previous/contents/next links
toc.html table of contents
HowTo.html one big HTML file
HowTo.ps Postscript
HowTo.pdf PDF
HowTo.txt ASCII text
Not all of the above are in the shipped version. All but
text are on our website, www.freeswan.org. To get PDF or
Postscript, either grab them from the web or install
htmldoc from www.easysw.com, then use the Makefile.
Subdirectories are:
src/*.html HTML source files
manpage.d/*.html HTML versions of man pages
You should not need to look at these, except for following
links to HTML man pages.
The Internet Drafts are natively in XML format. They have been
converted with Marshall Rose's xml2rfc.
xml2rfc is available at xml.resource.org.
You may have to install the TclXML package by symlinking it into
/usr/lib/tcl8.3 or some such.
doc/adv_config.html
-1232
View File
File diff suppressed because it is too large Load Diff
doc/background.html
-323
View File
@@ -1,323 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="config.html">Previous</A>
<A HREF="user_examples.html">Next</A>
<HR>
<H1><A name="background">Linux FreeS/WAN background</A></H1>
<P>This section discusses a number of issues which have three things in
common:</P>
<UL>
<LI>They are not specifically FreeS/WAN problems</LI>
<LI>You may have to understand them to get FreeS/WAN working right</LI>
<LI>They are not simple questions</LI>
</UL>
<P>Grouping them here lets us provide the explanations some users will
need without unduly complicating the main text.</P>
<P>The explanations here are intended to be adequate for FreeS/WAN
purposes (please comment to the<A href="mail.html"> users mailing list</A>
if you don't find them so), but they are not trying to be complete or
definitive. If you need more information, see the references provided
in each section.</P>
<H2><A name="dns.background">Some DNS background</A></H2>
<P><A href="glossary.html#carpediem">Opportunistic encryption</A>
requires that the gateway systems be able to fetch public keys, and
other IPsec-related information, from each other's DNS (Domain Name
Service) records.</P>
<P><A href="glossary.html#DNS">DNS</A> is a distributed database that
maps names to IP addresses and vice versa.</P>
<P>Much good reference material is available for DNS, including:</P>
<UL>
<LI>the<A href="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"> DNS HowTo</A>
</LI>
<LI>the standard<A href="biblio.html#DNS.book"> DNS reference</A> book</LI>
<LI><A href="http://www.linuxdoc.org/LDP/nag2/index.html">Linux Network
Administrator's Guide</A></LI>
<LI><A href="http://www.nominum.com/resources/whitepapers/bind-white-paper.html">
BIND overview</A></LI>
<LI><A href="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">
BIND 9 Administrator's Reference</A></LI>
</UL>
<P>We give only a brief overview here, intended to help you use DNS for
FreeS/WAN purposes.</P>
<H3><A name="forward.reverse">Forward and reverse maps</A></H3>
<P>Although the implementation is distributed, it is often useful to
speak of DNS as if it were just two enormous tables:</P>
<UL>
<LI>the forward map: look up a name, get an IP address</LI>
<LI>the reverse map: look up an IP address, get a name</LI>
</UL>
<P>Both maps can optionally contain additional data. For opportunistic
encryption, we insert the data need for IPsec authentication.</P>
<P>A system named gateway.example.com with IP address 10.20.30.40 should
have at least two DNS records, one in each map:</P>
<DL>
<DT>gateway.example.com. IN A 10.20.30.40</DT>
<DD>used to look up the name and get an IP address</DD>
<DT>40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</DT>
<DD>used for reverse lookups, looking up an address to get the
associated name. Notice that the digits here are in reverse order; the
actual address is 10.20.30.40 but we use 40.30.20.10 here.</DD>
</DL>
<H3><A NAME="17_1_2">Hierarchy and delegation</A></H3>
<P>For both maps there is a hierarchy of DNS servers and a system of
delegating authority so that, for example:</P>
<UL>
<LI>the DNS administrator for example.com can create entries of the form<VAR>
name</VAR>.example.com</LI>
<LI>the example.com admin cannot create an entry for counterexample.com;
only someone with authority for .com can do that</LI>
<LI>an admin might have authority for 20.10.in-addr.arpa.</LI>
<LI>in either map, authority can be delegated
<UL>
<LI>the example.com admin could give you authority for
westcoast.example.com</LI>
<LI>the 20.10.in-addr.arpa admin could give you authority for
30.20.10.in-addr.arpa</LI>
</UL>
</LI>
</UL>
<P>DNS zones are the units of delegation. There is a hierarchy of zones.</P>
<H3><A NAME="17_1_3">Syntax of DNS records</A></H3>
<P>Returning to the example records:</P>
<PRE> gateway.example.com. IN A 10.20.30.40
40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</PRE>
<P>some syntactic details are:</P>
<UL>
<LI>the IN indicates that these records are for<STRONG> In</STRONG>
ternet addresses</LI>
<LI>The final periods in '.com.' and '.arpa.' are required. They
indicate the root of the domain name system.</LI>
</UL>
<P>The capitalised strings after IN indicate the type of record.
Possible types include:</P>
<UL>
<LI><STRONG>A</STRONG>ddress, for forward lookups</LI>
<LI><STRONG>P</STRONG>oin<STRONG>T</STRONG>e<STRONG>R</STRONG>, for
reverse lookups</LI>
<LI><STRONG>C</STRONG>anonical<STRONG> NAME</STRONG>, records to support
aliasing, multiple names for one address</LI>
<LI><STRONG>M</STRONG>ail e<STRONG>X</STRONG>change, used in mail
routing</LI>
<LI><STRONG>SIG</STRONG>nature, used in<A href="glossary.html#SDNS">
secure DNS</A></LI>
<LI><STRONG>KEY</STRONG>, used in<A href="glossary.html#SDNS"> secure
DNS</A></LI>
<LI><STRONG>T</STRONG>e<STRONG>XT</STRONG>, a multi-purpose record type</LI>
</UL>
<P>To set up for opportunistic encryption, you add some TXT records to
your DNS data. Details are in our<A href="quickstart.html"> quickstart</A>
document.</P>
<H3><A NAME="17_1_4">Cacheing, TTL and propagation delay</A></H3>
<P>DNS information is extensively cached. With no caching, a lookup by
your system of &quot;www.freeswan.org&quot; might involve:</P>
<UL>
<LI>your system asks your nameserver for &quot;www.freeswan.org&quot;</LI>
<LI>local nameserver asks root server about &quot;.org&quot;, gets reply</LI>
<LI>local nameserver asks .org nameserver about &quot;freeswan.org&quot;, gets
reply</LI>
<LI>local nameserver asks freeswan.org nameserver about
&quot;www.freeswan.org&quot;, gets reply</LI>
</UL>
<P>However, this can be a bit inefficient. For example, if you are in
the Phillipines, the closest a root server is in Japan. That might send
you to a .org server in the US, and then to freeswan.org in Holland. If
everyone did all those lookups every time they clicked on a web link,
the net would grind to a halt.</P>
<P>Nameservers therefore cache information they look up. When you click
on another link at www.freeswan.org, your local nameserver has the IP
address for that server in its cache, and no further lookups are
required.</P>
<P>Intermediate results are also cached. If you next go to
lists.freeswan.org, your nameserver can just ask the freeswan.org
nameserver for that address; it does not need to query the root or .org
nameservers because it has a cached address for the freeswan.org zone
server.</P>
<P>Of course, like any cacheing mechanism, this can create problems of
consistency. What if the administrator for freeswan.org changes the IP
address, or the authentication key, for www.freeswan.org? If you use
old information from the cache, you may get it wrong. On the other
hand, you cannot afford to look up fresh information every time. Nor
can you expect the freeswan.org server to notify you; that isn't in the
protocols.</P>
<P>The solution that is in the protocols is fairly simple. Cacheable
records are marked with Time To Live (TTL) information. When the time
expires, the caching server discards the record. The next time someone
asks for it, the server fetches a fresh copy. Of course, a server may
also discard records before their TTL expires if it is running out of
cache space.</P>
<P>This implies that there will be some delay before the new version of
a changed record propagates around the net. Until the TTLs on all
copies of the old record expire, some users will see it because that is
what is in their cache. Other users may see the new record immediately
because they don't have an old one cached.</P>
<H2><A name="MTU.trouble">Problems with packet fragmentation</A></H2>
<P>It seems, from mailing list reports, to be moderately common for
problems to crop up in which small packets pass through the IPsec
tunnels just fine but larger packets fail.</P>
<P>These problems are caused by various devices along the way
mis-handling either packet fragments or<A href="glossary.html#pathMTU">
path MTU discovery</A>.</P>
<P>IPsec makes packets larger by adding an ESP or AH header. This can
tickle assorted bugs in fragment handling in routers and firewalls, or
in path MTU discovery mechanisms, and cause a variety of symptoms which
are both annoying and, often, quite hard to diagnose.</P>
<P>An explanation from project technical lead Henry Spencer:</P>
<PRE>The problem is IP fragmentation; more precisely, the problem is that the
second, third, etc. fragments of an IP packet are often difficult for
filtering mechanisms to classify.
Routers cannot rely on reassembling the packet, or remembering what was in
earlier fragments, because the fragments may be out of order or may even
follow different routes. So any general, worst-case filtering decision
pretty much has to be made on each fragment independently. (If the router
knows that it is the only route to the destination, so all fragments
*must* pass through it, reassembly would be possible... but most routers
don't want to bother with the complications of that.)
All fragments carry roughly the original IP header, but any higher-level
header is (for IP purposes) just the first part of the packet data... so
only the first fragment carries that. So, for example, on examining the
second fragment of a TCP packet, you could tell that it's TCP, but not
what port number it is destined for -- that information is in the TCP
header, which appears in the first fragment only.
The result of this classification difficulty is that stupid routers and
over-paranoid firewalls may just throw fragments away. To get through
them, you must reduce your MTU enough that fragmentation will not occur.
(In some cases, they might be willing to attempt reassembly, but have very
limited resources to devote to it, meaning that packets must be small and
fragments few in number, leading to the same conclusion: smaller MTU.)</PRE>
<P>In addition to the problem Henry describes, you may also have trouble
with<A href="glossary.html#pathMTU"> path MTU discovery</A>.</P>
<P>By default, FreeS/WAN uses a large<A href="glossary.html#MTU"> MTU</A>
for the ipsec device. This avoids some problems, but may complicate
others. Here's an explanation from Claudia:</P>
<PRE>Here are a couple of pieces of background information. Apologies if you
have seen these already. An excerpt from one of my old posts:
An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this
high MTU so that it does not fragment incoming packets before encryption
and encapsulation. If after IPSec processing packets are larger than 1500,
[ie. the mtu of eth0] then eth0 will fragment them.
Adding IPSec headers adds a certain number of bytes to each packet.
The MTU of the IPSec interface refers to the maximum size of the packet
before the IPSec headers are added. In some cases, people find it helpful
to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
That way, the resulting encapsulated packets don't exceed 1500. On most
networks, packets less than 1500 will not need to be fragmented.
and... (from Henry Spencer)
The way it *ought* to work is that the MTU advertised by the ipsecN
interface should be that of the underlying hardware interface, less a
pinch for the extra headers needed.
Unfortunately, in certain situations this breaks many applications.
There is a widespread implicit assumption that the smallest MTUs are
at the ends of paths, not in the middle, and another that MTUs are
never less than 1500. A lot of code is unprepared to handle paths
where there is an &quot;interior minimum&quot; in the MTU, especially when it's
less than 1500. So we advertise a big MTU and just let the resulting
big packets fragment.
This usually works, but we do get bitten in cases where some intermediate
point can't handle all that fragmentation. We can't win on this one.</PRE>
<P>The MTU can be changed with an<VAR> overridemtu=</VAR> statement in
the<VAR> config setup</VAR> section of<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf.5</A>.</P>
<P>For a discussion of MTU issues and some possible solutions using
Linux advanced routing facilities, see the<A href="http://www.linuxguruz.org/iptables/howto/2.4routing-15.html#ss15.6">
Linux 2.4 Advanced Routing HOWTO</A>. For a discussion of MTU and NAT
(Network Address Translation), see<A HREF="http://harlech.math.ucla.edu/services/ipsec.html">
James Carter's MTU notes</A>.</P>
<H2><A name="nat.background">Network address translation (NAT)</A></H2>
<P><STRONG>N</STRONG>etwork<STRONG> A</STRONG>ddress<STRONG> T</STRONG>
ranslation is a service provided by some gateway machines. Calling it
NAPT (adding the word<STRONG> P</STRONG>ort) would be more precise, but
we will follow the widespread usage.</P>
<P>A gateway doing NAT rewrites the headers of packets it is forwarding,
changing one or more of:</P>
<UL>
<LI>source address</LI>
<LI>source port</LI>
<LI>destination address</LI>
<LI>destination port</LI>
</UL>
<P>On Linux 2.4, NAT services are provided by the<A href="http://netfilter.samba.org">
netfilter(8)</A> firewall code. There are several<A href="http://netfilter.samba.org/documentation/index.html#HOWTO">
Netfilter HowTos</A> including one on NAT.</P>
<P>For older versions of Linux, this was referred to as &quot;IP masquerade&quot;
and different tools were used. See this<A href="http://www.e-infomax.com/ipmasq/">
resource page</A>.</P>
<P>Putting an IPsec gateway behind a NAT gateway is not recommended. See
our<A href="firewall.html#NAT"> firewalls document</A>.</P>
<H3><A NAME="17_3_1">NAT to non-routable addresses</A></H3>
<P>The most common application of NAT uses private<A href="glossary.html#non-routable">
non-routable</A> addresses.</P>
<P>Often a home or small office network will have:</P>
<UL>
<LI>one connection to the Internet</LI>
<LI>one assigned publicly visible IP address</LI>
<LI>several machines that all need access to the net</LI>
</UL>
<P>Of course this poses a problem since several machines cannot use one
address. The best solution might be to obtain more addresses, but often
this is impractical or uneconomical.</P>
<P>A common solution is to have:</P>
<UL>
<LI><A href="glossary.html#non-routable">non-routable</A> addresses on
the local network</LI>
<LI>the gateway machine doing NAT</LI>
<LI>all packets going outside the LAN rewritten to have the gateway as
their source address</LI>
</UL>
<P>The client machines are set up with reserved<A href="glossary.html#non-routable">
non-routable</A> IP addresses defined in RFC 1918. The masquerading
gateway, the machine with the actual link to the Internet, rewrites
packet headers so that all packets going onto the Internet appear to
come from one IP address, that of its Internet interface. It then gets
all the replies, does some table lookups and more header rewriting, and
delivers the replies to the appropriate client machines.</P>
<P>As far as anyone else on the Internet is concerned, the systems
behind the gateway are completely hidden. Only one machine with one IP
address is visible.</P>
<P>For IPsec on such a gateway, you can entirely ignore the NAT in:</P>
<UL>
<LI><A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></LI>
<LI>firewall rules affecting your Internet-side interface</LI>
</UL>
<P>Those can be set up exactly as they would be if your gateway had no
other systems behind it.</P>
<P>You do, however, have to take account of the NAT in firewall rules
which affect packet forwarding.</P>
<H3><A NAME="17_3_2">NAT to routable addresses</A></H3>
<P>NAT to routable addresses is also possible, but is less common and
may make for rather tricky routing problems. We will not discuss it
here. See the<A href="http://netfilter.samba.org/documentation/index.html#HOWTO">
Netfilter HowTos</A>.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="config.html">Previous</A>
<A HREF="user_examples.html">Next</A>
</BODY>
</HTML>
doc/biblio.html
-274
View File
@@ -1,274 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="glossary.html">Previous</A>
<A HREF="rfc.html">Next</A>
<HR>
<H1><A name="biblio">Bibliography for the Linux FreeS/WAN project</A></H1>
<P>For extensive bibliographic links, see the<A href="http://liinwww.ira.uka.de/bibliography/index.html">
Collection of Computer Science Bibliographies</A></P>
<P>See our<A href="web.html"> web links</A> for material available
online.</P>
<HR><A name="adams"> Carlisle Adams and Steve Lloyd<CITE> Understanding
Public Key Infrastructure</CITE>
<BR></A> Macmillan 1999 ISBN 1-57870-166-x
<P>An overview, mainly concentrating on policy and strategic issues
rather than the technical details. Both authors work for<A href="glossary.html#PKI">
PKI</A> vendor<A href="http://www.entrust.com/"> Entrust</A>.</P>
<HR><A name="DNS.book"> Albitz, Liu &amp; Loukides<CITE> DNS &amp; BIND</CITE>
3rd edition
<BR></A> O'Reilly 1998 ISBN 1-56592-512-2
<P>The standard reference on the<A href="glossary.html#DNS"> Domain Name
Service</A> and<A href="glossary.html#BIND"> Berkeley Internet Name
Daemon</A>.</P>
<HR><A name="anderson"> Ross Anderson</A>,<CITE> Security Engineering -
a Guide to Building Dependable Distributed Systems</CITE>
<BR> Wiley, 2001, ISBN 0471389226
<P>Easily the best book for the security professional I have seen.<STRONG>
Highly recommended</STRONG>. See the<A href="http://www.cl.cam.ac.uk/~rja14/book.html">
book web page</A>.</P>
<P>This is quite readable, but Schneier's<A href="#secrets"> Secrets and
Lies</A> might be an easier introduction.</P>
<HR><A name="puzzle"> Bamford<CITE> The Puzzle Palace, A report on NSA,
Americas's most Secret Agency</CITE>
<BR> Houghton Mifflin 1982 ISBN 0-395-31286-8</A>
<HR> Bamford<CITE> Body of Secrets</CITE>
<P>The sequel.</P>
<HR><A name="bander"> David Bander</A>,<CITE> Linux Security Toolkit</CITE>
<BR> IDG Books, 2000, ISBN: 0764546902
<P>This book has a short section on FreeS/WAN and includes Caldera Linux
on CD.</P>
<HR><A name="CZR"> Chapman, Zwicky &amp; Russell</A>,<CITE> Building
Internet Firewalls</CITE>
<BR> O'Reilly 1995 ISBN 1-56592-124-0
<HR><A name="firewall.book"> Cheswick and Bellovin</A><CITE> Firewalls
and Internet Security: Repelling the Wily Hacker</CITE>
<BR> Addison-Wesley 1994 ISBN 0201633574
<P>A fine book on firewalls in particular and security in general from
two of AT&amp;T's system adminstrators.</P>
<P>Bellovin has also done a number of<A href="web.html#papers"> papers</A>
on IPsec and co-authored a<A href="intro.html#applied"> paper</A> on a
large FreeS/WAN application.</P>
<HR><A name="comer"> Comer<CITE> Internetworking with TCP/IP</CITE>
<BR> Prentice Hall</A>
<UL>
<LI>Vol. I: Principles, Protocols, &amp; Architecture, 3rd Ed. 1995
ISBN:0-13-216987-8</LI>
<LI>Vol. II: Design, Implementation, &amp; Internals, 2nd Ed. 1994
ISBN:0-13-125527-4</LI>
<LI>Vol. III: Client/Server Programming &amp; Applications
<UL>
<LI>AT&amp;T TLI Version 1994 ISBN:0-13-474230-3</LI>
<LI>BSD Socket Version 1996 ISBN:0-13-260969-X</LI>
<LI>Windows Sockets Version 1997 ISBN:0-13-848714-6</LI>
</UL>
</LI>
</UL>
<P>If you need to deal with the details of the network protocols, read
either this series or the<A href="#stevens"> Stevens and Wright</A>
series before you start reading the RFCs.</P>
<HR><A name="diffie"> Diffie and Landau</A><CITE> Privacy on the Line:
The Politics of Wiretapping and Encryption</CITE>
<BR> MIT press 1998 ISBN 0-262-04167-7 (hardcover) or 0-262-54100-9
<BR>
<HR><A name="d_and_hark"> Doraswamy and Harkins<CITE> IP Sec: The New
Security Standard for the Internet, Intranets and Virtual Private
Networks</CITE>
<BR> Prentice Hall 1999 ISBN: 0130118982</A>
<HR><A name="EFF"> Electronic Frontier Foundation<CITE> Cracking DES:
Secrets of Encryption Research, Wiretap Politics and Chip Design</CITE>
<BR></A> O'Reilly 1998 ISBN 1-56592-520-3
<P>To conclusively demonstrate that DES is inadequate for continued use,
the<A href="glossary.html#EFF"> EFF</A> built a machine for just over
$200,000 that breaks DES encryption in under five days on average,
under nine in the worst case.</P>
<P>The book provides details of their design and, perhaps even more
important, discusses why they felt the project was necessary.
Recommended for anyone interested in any of the three topics mentioned
in the subtitle.</P>
<P>See also the<A href="http://www.eff.org/descracker.html"> EFF page on
this project</A> and our discussion of<A href="politics.html#desnotsecure">
DES insecurity</A>.</P>
<HR> Martin Freiss<CITE> Protecting Networks with SATAN</CITE>
<BR> O'Reilly 1998 ISBN 1-56592-425-8
<BR> translated from a 1996 work in German
<P>SATAN is a Security Administrator's Tool for Analysing Networks. This
book is a tutorial in its use.</P>
<HR> Gaidosch and Kunzinger<CITE> A Guide to Virtual Private Networks</CITE>
<BR> Prentice Hall 1999 ISBN: 0130839647
<HR><A name="Garfinkel"> Simson Garfinkel</A><CITE> Database Nation: the
death of privacy in the 21st century</CITE>
<BR> O'Reilly 2000 ISBN 1-56592-653-6
<P>A thoughtful and rather scary book.</P>
<HR><A name="PGP"> Simson Garfinkel</A><CITE> PGP: Pretty Good Privacy</CITE>
<BR> O'Reilly 1995 ISBN 1-56592-098-8
<P>An excellent introduction and user manual for the<A href="glossary.html#PGP">
PGP</A> email-encryption package. PGP is a good package with a complex
and poorly-designed user interface. This book or one like it is a must
for anyone who has to use it at length.</P>
<P>The book covers using PGP in Unix, PC and Macintosh environments,
plus considerable background material on both the technical and
political issues around cryptography.</P>
<P>The book is now seriously out of date. It does not cover recent
developments such as commercial versions since PGP 5, the Open PGP
standard or GNU PG..</P>
<HR><A name="practical"> Garfinkel and Spafford</A><CITE> Practical Unix
Security</CITE>
<BR> O'Reilly 1996 ISBN 1-56592-148-8
<P>A standard reference.</P>
<P>Spafford's web page has an excellent collection of<A href="http://www.cs.purdue.edu/coast/hotlist">
crypto and security links</A>.</P>
<HR><A name="Kahn"> David Kahn</A><CITE> The Codebreakers: the
Comprehensive History of Secret Communications from Ancient Times to
the Internet</CITE>
<BR> second edition Scribner 1996 ISBN 0684831309
<P>A history of codes and code-breaking from ancient Egypt to the 20th
century. Well-written and exhaustively researched.<STRONG> Highly
recommended</STRONG>, even though it does not have much on computer
cryptography.</P>
<HR> David Kahn<CITE> Seizing the Enigma, The Race to Break the German
U-Boat codes, 1939-1943</CITE>
<BR> Houghton Mifflin 1991 ISBN 0-395-42739-8
<HR><A name="kirch"> Olaf Kirch</A><CITE> Linux Network Administrator's
Guide</CITE>
<BR> O'Reilly 1995 ISBN 1-56592-087-2
<P>Now becoming somewhat dated in places, but still a good introductory
book and general reference.</P>
<HR><A name="LinVPN"> Kolesnikov and Hatch</A>,<CITE> Building Linux
Virtual Private Networks (VPNs)</CITE>
<BR> New Riders 2002
<P>This has had a number of favorable reviews, including<A href="http://www.slashdot.org/article.pl?sid=02/02/27/0115214&amp;mode=thread&amp;tid=172">
this one</A> on Slashdot. The book has a<A href="http://www.buildinglinuxvpns.net/">
web site</A>.</P>
<HR><A name="RFCs"> Pete Loshin<CITE> Big Book of IPsec RFCs</CITE>
<BR> Morgan Kaufmann 2000 ISBN: 0-12-455839-9</A>
<HR><A name="crypto"> Steven Levy<CITE> Crypto: How the Code Rebels Beat
the Government -- Saving Privacy in the Digital Age</CITE></A>
<BR> Penguin 2001, ISBN 0-670--85950-8
<P><STRONG>Highly recommended</STRONG>. A fine history of recent (about
1970-2000) developments in the field, and the related political
controversies. FreeS/WAN project founder and leader John Gilmore
appears several times.</P>
<P>The book does not cover IPsec or FreeS/WAN, but this project is very
much another battle in the same war. See our discussion of the<A href="politics.html">
politics</A>.</P>
<HR><A name="GTR"> Matyas, Anderson et al.</A><CITE> The Global Trust
Register</CITE>
<BR> Northgate Consultants Ltd 1998 ISBN: 0953239705
<BR> hard cover edition MIT Press 1999 ISBN 0262511053
<P>From<A href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register">
their web page:</A></P>
<BLOCKQUOTE> This book is a register of the fingerprints of the world's
most important public keys; it implements a top-level certification
authority (CA) using paper and ink rather than in an electronic system.</BLOCKQUOTE>
<HR><A name="handbook"> Menezies, van Oorschot and Vanstone<CITE>
Handbook of Applied Cryptography</CITE></A>
<BR> CRC Press 1997
<BR> ISBN 0-8493-8523-7
<P>An excellent reference. Read<A href="#schneier"> Schneier</A> before
tackling this.</P>
<HR> Michael Padlipsky<CITE> Elements of Networking Style</CITE>
<BR> Prentice-Hall 1985 ISBN 0-13-268111-0 or 0-13-268129-3
<P>Probably<STRONG> the funniest technical book ever written</STRONG>,
this is a vicious but well-reasoned attack on the OSI &quot;seven layer
model&quot; and all that went with it. Several chapters of it are also
available as RFCs 871 to 875.</P>
<HR><A name="matrix"> John S. Quarterman</A><CITE> The Matrix: Computer
Networks and Conferencing Systems Worldwide</CITE>
<BR> Digital Press 1990 ISBN 155558-033-5
<BR> Prentice-Hall ISBN 0-13-565607-9
<P>The best general treatment of computer-mediated communication we have
seen. It naturally has much to say about the Internet, but also covers
UUCP, Fidonet and so on.</P>
<HR><A name="ranch"> David Ranch</A><CITE> Securing Linux Step by Step</CITE>
<BR> SANS Institute, 1999
<P><A href="http://www.sans.org/">SANS</A> is a respected organisation,
this guide is part of a well-known series, and Ranch has previously
written the useful<A href=" http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
Trinity OS</A> guide to securing Linux, so my guess would be this is a
pretty good book. I haven't read it yet, so I'm not certain. It can be
ordered online from<A href="http://www.sans.org/"> SANS</A>.</P>
<P>Note (Mar 1, 2002): a new edition with different editors in the
works. Expect it this year.</P>
<HR><A name="schneier"> Bruce Schneier</A><CITE> Applied Cryptography,
Second Edition</CITE>
<BR> John Wiley &amp; Sons, 1996
<BR> ISBN 0-471-12845-7 hardcover
<BR> ISBN 0-471-11709-9 paperback
<P>A standard reference on computer cryptography. For more recent
essays, see the<A href="http://www.counterpane.com/"> author's
company's web site</A>.</P>
<HR><A name="secrets"> Bruce Schneier</A><CITE> Secrets and Lies</CITE>
<BR> Wiley 2000, ISBN 0-471-25311-1
<P>An interesting discussion of security and privacy issues, written
with more of an &quot;executive overview&quot; approach rather than a narrow
focus on the technical issues.<STRONG> Highly recommended</STRONG>.</P>
<P>This is worth reading even if you already understand security issues,
or think you do. To go deeper, follow it with Anderson's<A href="#anderson">
Security Engineering</A>.</P>
<HR><A name="VPNbook"> Scott, Wolfe and Irwin<CITE> Virtual Private
Networks</CITE></A>
<BR> 2nd edition, O'Reilly 1999 ISBN: 1-56592-529-7
<P>This is the only O'Reilly book, out of a dozen I own, that I'm
disappointed with. It deals mainly with building VPNs with various
proprietary tools --<A href="glossary.html#PPTP"> PPTP</A>,<A href="glossary.html#SSH">
SSH</A>, Cisco PIX, ... -- and touches only lightly on IPsec-based
approaches.</P>
<P>That said, it appears to deal competently with what it does cover and
it has readable explanations of many basic VPN and security concepts.
It may be exactly what some readers require, even if I find the
emphasis unfortunate.</P>
<HR><A name="LASG"> Kurt Seifried<CITE> Linux Administrator's Security
Guide</CITE></A>
<P>Available online from<A href="http://www.securityportal.com/lasg/">
Security Portal</A>. It has fairly extensive coverage of IPsec.</P>
<HR><A name="Smith"> Richard E Smith<CITE> Internet Cryptography</CITE>
<BR></A> ISBN 0-201-92480-3, Addison Wesley, 1997
<P>See the book's<A href="http://www.visi.com/crypto/inet-crypto/index.html">
home page</A></P>
<HR><A name="neal"> Neal Stephenson<CITE> Cryptonomicon</CITE></A>
<BR> Hardcover ISBN -380-97346-4, Avon, 1999.
<P>A novel in which cryptography and the net figure prominently.<STRONG>
Highly recommended</STRONG>: I liked it enough I immediately went out
and bought all the author's other books.</P>
<P>There is also a paperback edition. Sequels are expected.</P>
<HR><A name="stevens"> Stevens and Wright</A><CITE> TCP/IP Illustrated</CITE>
<BR> Addison-Wesley
<UL>
<LI>Vol. I: The Protocols 1994 ISBN:0-201-63346-9</LI>
<LI>Vol. II: The Implementation 1995 ISBN:0-201-63354-X</LI>
<LI>Vol. III: TCP for Transactions, HTTP, NNTP, and the UNIX Domain
Protocols 1996 ISBN: 0-201-63495-3</LI>
</UL>
<P>If you need to deal with the details of the network protocols, read
either this series or the<A href="#comer"> Comer</A> series before you
start reading the RFCs.</P>
<HR><A name="Rubini"> Rubini</A><CITE> Linux Device Drivers</CITE>
<BR> O'Reilly &amp; Associates, Inc. 1998 ISBN 1-56592-292-1
<HR><A name="Zeigler"> Robert Zeigler</A><CITE> Linux Firewalls</CITE>
<BR> Newriders Publishing, 2000 ISBN 0-7537-0900-9
<P>A good book, with detailed coverage of ipchains(8) firewalls and of
many related issues.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="glossary.html">Previous</A>
<A HREF="rfc.html">Next</A>
</BODY>
</HTML>
doc/compat.html
-707
View File
@@ -1,707 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="trouble.html">Previous</A>
<A HREF="interop.html">Next</A>
<HR>
<H1><A name="compat">Linux FreeS/WAN Compatibility Guide</A></H1>
<P>Much of this document is quoted directly from the Linux FreeS/WAN<A href="mail.html">
mailing list</A>. Thanks very much to the community of testers,
patchers and commenters there, especially the ones quoted below but
also various contributors we haven't quoted.</P>
<H2><A name="spec">Implemented parts of the IPsec Specification</A></H2>
<P>In general, do not expect Linux FreeS/WAN to do everything yet. This
is a work-in-progress and some parts of the IPsec specification are not
yet implemented.</P>
<H3><A name="in">In Linux FreeS/WAN</A></H3>
<P>Things we do, as of version 1.96:</P>
<UL>
<LI>key management methods
<DL>
<DT>manually keyed</DT>
<DD>using keys stored in /etc/ipsec.conf</DD>
<DT>automatically keyed</DT>
<DD>Automatically negotiating session keys as required. All connections
are automatically re-keyed periodically. The<A href="glossary.html#Pluto">
Pluto</A> daemon implements this using the<A href="glossary.html#IKE">
IKE</A> protocol.</DD>
</DL>
</LI>
<LI>Methods of authenticating gateways for IKE
<DL>
<DT>shared secrets</DT>
<DD>stored in<A href="manpage.d/ipsec.secrets.5.html"> ipsec.secrets(5)</A>
</DD>
<DT><A href="glossary.html#RSA">RSA</A> signatures</DT>
<DD>For details, see<A href="manpage.d/ipsec_pluto.8.html"> pluto(8)</A>
.</DD>
<DT>looking up RSA authentication keys from<A href="glossary.html#DNS">
DNS</A>.</DT>
<DD>Note that this technique cannot be fully secure until<A href="glossary.html#SDNS">
secure DNS</A> is widely deployed.</DD>
</DL>
</LI>
<LI>groups for<A href="glossary.html#DH"> Diffie-Hellman</A> key
negotiation
<DL>
<DT>group 2, modp 1024-bit</DT>
<DT>group 5, modp 1536-bit</DT>
<DD>We implement these two groups.
<P>In negotiating a keying connection (ISAKMP SA, Phase 1) we propose
both groups when we are the initiator, and accept either when a peer
proposes them. Once the keying connection is made, we propose only the
alternative agreed there for data connections (IPsec SA's, Phase 2)
negotiated over that keying connection.</P>
</DD>
</DL>
</LI>
<LI>encryption transforms
<DL>
<DT><A href="glossary.html#DES">DES</A></DT>
<DD>DES is in the source code since it is needed to implement 3DES, but
single DES is not made available to users because<A href="politics.html#desnotsecure">
DES is insecure</A>.</DD>
<DT><A href="glossary.html#3DES">Triple DES</A></DT>
<DD>implemented, and used as the default encryption in Linux FreeS/WAN.</DD>
</DL>
</LI>
<LI>authentication transforms
<DL>
<DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#MD5">
MD5</A></DT>
<DD>implemented, may be used in IKE or by by AH or ESP transforms.</DD>
<DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#SHA">
SHA</A></DT>
<DD>implemented, may be used in IKE or by AH or ESP transforms.</DD>
</DL>
<P>In negotiations, we propose both of these and accept either.</P>
</LI>
<LI>compression transforms
<DL>
<DT>IPComp</DT>
<DD>IPComp as described in RFC 2393 was added for FreeS/WAN 1.6. Note
that Pluto becomes confused if you ask it to do IPComp when the kernel
cannot.</DD>
</DL>
</LI>
</UL>
<P>All combinations of implemented transforms are supported. Note that
some form of packet-level<STRONG> authentication is required whenever
encryption is used</STRONG>. Without it, the encryption will not be
secure.</P>
<H3><A name="dropped">Deliberately omitted</A></H3>
We do not implement everything in the RFCs because some of those things
are insecure. See our discussions of avoiding<A href="politics.html#weak">
bogus security</A>.
<P>Things we deliberately omit which are required in the RFCs are:</P>
<UL>
<LI>null encryption (to use ESP as an authentication-only service)</LI>
<LI>single DES</LI>
<LI>DH group 1, a 768-bit modp group</LI>
</UL>
<P>Since these are the only encryption algorithms and DH group the RFCs
require, it is possible in theory to have a standards-conforming
implementation which will not interpoperate with FreeS/WAN. Such an
implementation would be inherently insecure, so we do not consider this
a problem.</P>
<P>Anyway, most implementations sensibly include more secure options as
well, so dropping null encryption, single DES and Group 1 does not
greatly hinder interoperation in practice.</P>
<P>We also do not implement some optional features allowed by the RFCs:</P>
<UL>
<LI>aggressive mode for negotiation of the keying channel or ISAKMP SA.
This mode is a little faster than main mode, but exposes more
information to an eavesdropper.</LI>
</UL>
<P>In theory, this should cause no interoperation problems since all
implementations are required to support the more secure main mode,
whether or not they also allow aggressive mode.</P>
<P>In practice, it does sometimes produce problems with implementations
such as Windows 2000 where aggressive mode is the default. Typically,
these are easily solved with a configuration change that overrides that
default.</P>
<H3><A name="not">Not (yet) in Linux FreeS/WAN</A></H3>
<P>Things we don't yet do, as of version 1.96:</P>
<UL>
<LI>key management methods
<UL>
<LI>authenticate key negotiations via local<A href="glossary.html#PKI">
PKI</A> server, but see links to user<A href="web.html#patch"> patches</A>
</LI>
<LI>authenticate key negotiations via<A href="glossary.html#SDNS">
secure DNS</A></LI>
<LI>unauthenticated key management, using<A href="glossary.html#DH">
Diffie-Hellman</A> key agreement protocol without authentication.
Arguably, this would be worth doing since it is secure against all
passive attacks. On the other hand, it is vulnerable to an active<A href="glossary.html#middle">
man-in-the-middle attack</A>.</LI>
</UL>
</LI>
<LI>encryption transforms
<P>Currently<A href="glossary.html#3DES"> Triple DES</A> is the only
encryption method Pluto will negotiate.</P>
<P>No additional encryption transforms are implemented, though the RFCs
allow them and some other IPsec implementations support various of
them. We are not eager to add more. See this<A href="faq.html#other.cipher">
FAQ question</A>.</P>
<P><A href="glossary.html#AES">AES</A>, the successor to the DES
standard, is an excellent candidate for inclusion in FreeS/WAN, see
links to user<A href="web.html#patch"> patches</A>.</P>
</LI>
<LI>authentication transforms
<P>No optional additional authentication transforms are currently
implemented. Likely<A href="glossary.html#SHA-256"> SHA-256, SHA-384
and SHA-512</A> will be added when AES is.</P>
</LI>
<LI>Policy checking on decrypted packets
<P>To fully comply with the RFCs, it is not enough just to accept only
packets which survive any firewall rules in place to limit what IPsec
packets get in, and then pass KLIPS authentication. That is what
FreeS/WAN currently does.</P>
<P>We should also apply additional tests, for example ensuring that all
packets emerging from a particular tunnel have source and destination
addresses that fall within the subnets defined for that tunnel, and
that packets with those addresses that did not emerge from the
appropriate tunnel are disallowed.</P>
<P>This will be done as part of a KLIPS rewrite. See these<A href="intro.html#applied">
links</A> and the<A href="mail.html"> design mailing list</A> for
discussion.</P>
</LI>
</UL>
<H2><A name="pfkey">Our PF-Key implementation</A></H2>
<P>We use PF-key Version Two for communication between the KLIPS kernel
code and the Pluto Daemon. PF-Key v2 is defined by<A href="http://www.normos.org/ietf/rfc/rfc2367.txt">
RFC 2367</A>.</P>
<P>The &quot;PF&quot; stands for Protocol Family. PF-Inet defines a
kernel/userspace interface for the TCP/IP Internet protocols (TCP/IP),
and other members of the PF series handle Netware, Appletalk, etc.
PF-Key is just a PF for key-related matters.</P>
<H3><A name="pfk.port">PF-Key portability</A></H3>
<P>PF-Key came out of Berkeley Unix work and is used in the various BSD
IPsec implementations, and in Solaris. This means there is some hope of
porting our Pluto(8) to one of the BSD distributions, or of running
their photurisd(8) on Linux if you prefer<A href="glossary.html#photuris">
Photuris</A> key management over IKE.</P>
<P>It is, however, more complex than that. The PK-Key RFC deliberately
deals only with keying, not policy management. The three PF-Key
implementations we have looked at -- ours, OpenBSD and KAME -- all have
extensions to deal with security policy, and the extensions are
different. There have been discussions aimed at sorting out the
differences, perhaps for a version three PF-Key spec. All players are
in favour of this, but everyone involved is busy and it is not clear
whether or when these discussions might bear fruit.</P>
<H2><A name="otherk">Kernels other than the latest 2.2.x and 2.4.y</A></H2>
<P>We develop and test on Redhat Linux using the most recent kernel in
the 2.2 and 2.4 series. In general, we recommend you use the latest
kernel in one of those series. Complications and caveats are discussed
below.</P>
<H3><A name="kernel.2.0">2.0.x kernels</A></H3>
<P>Consider upgrading to the 2.2 kernel series. If you want to stay with
the 2.0 series, then we strongly recommend 2.0.39. Some useful security
patches were added in 2.0.38.</P>
<P>Various versions of the code have run at various times on most 2.0.xx
kernels, but the current version is only lightly tested on 2.0.39, and
not at all on older kernels.</P>
<P>Some of our patches for older kernels are shipped in 2.0.37 and
later, so they are no longer provided in FreeS/WAN. This means recent
versions of FreeS/WAN will probably not compile on anything earlier
than 2.0.37.</P>
<H3><A name="kernel.production">2.2 and 2.4 kernels</A></H3>
<DL>
<DT>FreeS/WAN 1.0</DT>
<DD>ran only on 2.0 kernels</DD>
<DT>FreeS/WAN 1.1 to 1.8</DT>
<DD>ran on 2.0 or 2.2 kernels
<BR> ran on some development kernels, 2.3 or 2.4-test</DD>
<DT>FreeS/WAN 1.9 to 1.96</DT>
<DD>runs on 2.0, 2.2 or 2.4 kernels</DD>
</DL>
<P>In general,<STRONG> we suggest the latest 2.2 kernel or 2.4 for
production use</STRONG>.</P>
<P>Of course no release can be guaranteed to run on kernels more recent
than it is, so quite often there will be no stable FreeS/WAN for the
absolute latest kernel. See the<A href="faq.html#k.versions"> FAQ</A>
for discussion.</P>
<H2><A name="otherdist">Intel Linux distributions other than Redhat</A></H2>
<P>We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat 7.1
or 7.2 for 2.4, so minor changes may be required for other
distributions.</P>
<H3><A name="rh7">Redhat 7.0</A></H3>
<P>There are some problems with FreeS/WAN on Redhat 7.0. They are
soluble, but we recommend you upgrade to a later Redhat instead..</P>
<P>Redhat 7 ships with two compilers.</P>
<UL>
<LI>Their<VAR> gcc</VAR> is version 2.96. Various people, including the
GNU compiler developers and Linus, have said fairly emphatically that
using this was a mistake. 2.96 is a development version, not intended
for production use. In particular, it will not compile a Linux kernel.</LI>
<LI>Redhat therefore also ship a separate compiler, which they call<VAR>
kgcc</VAR>, for compiling kernels.</LI>
</UL>
<P>Kernel Makefiles have<VAR> gcc</VAR> as a default, and must be
adjusted to use<VAR> kgcc</VAR> before a kernel will compile on 7.0.
This mailing list message gives details:</P>
<PRE>Subject: Re: AW: Installing IPsec on Redhat 7.0
Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
From: Mads Rasmussen &lt;[email protected]&gt;
&gt; From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
cd to /usr/src/linux and open the Makefile in your favorite editor. You
will need to look for a line similar to this:
CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
This line specifies which C compiler to use to build the kernel. It should
be changed to:
CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
proceed with the typical compiling steps.</PRE>
<P>Check the<A href="mail.html"> mailing list</A> archive for more
recent news.</P>
<H3><A name="suse">SuSE Linux</A></H3>
<P>SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN
included.</P>
<P>FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow
miscompiled. You can find fixed packages on<A HREF="http://www.suse.de/~garloff/linux/FreeSWAN">
Kurt Garloff's page</A>.</P>
<P>Here are some notes for an earlier SuSE version.</P>
<H4>SuSE Linux 5.3</H4>
<PRE>Date: Mon, 30 Nov 1998
From: Peter Onion &lt;[email protected]&gt;
... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
The mods to the install process are quite simple. From memory and looking at
the files on the SUSE53 machine here at work....
And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
which SUSE use to shut a service down.
A few mods in /etc/init.d/ipsec to cope with the different places that SUSE
put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
insert &quot;. /etc/rc.config&quot; to pick up the SUSE config info and use
if test -n &quot;$NETCONFIG&quot; -a &quot;$NETCONFIG&quot; != &quot;YAST_ASK&quot; ; then
to replace
[ ${NETWORKING} = &quot;no&quot; ] &amp;&amp; exit 0
Create /etc/sysconfig as SUSE doesn't have one.
I think that was all (but I prob forgot something)....</PRE>
<P>You may also need to fiddle initialisation scripts to ensure that<VAR>
/var/run/pluto.pid</VAR> is removed when rebooting. If this file is
present, Pluto does not come up correctly.</P>
<H3><A name="slack">Slackware</A></H3>
<PRE>Subject: Re: linux-IPsec: Slackware distribution
Date: Thu, 15 Apr 1999 12:07:01 -0700
From: Evan Brewer &lt;[email protected]&gt;
&gt; Very shortly, I will be needing to install IPsec on at least gateways that
&gt; are running Slackware. . . .
The only trick to getting it up is that on the slackware dist there is no
init.d directory in /etc/rc.d .. so create one. Then, what I do is take the
IPsec startup script which normally gets put into the init.d directory, and
put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
in init.d. The only file in the dist you need to really edit is the
utils/Makefile, setup4:
Everything else should be just fine.</PRE>
<P>A year or so later:</P>
<PRE>Subject: Re: HTML Docs- Need some cleanup?
Date: Mon, 8 Jan 2001
From: Jody McIntyre &lt;[email protected]&gt;
I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
FreeS/WAN installed its rc.ipsec file in /etc/rc.d. I had to manually call
this script from rc.inet2. This seems to be an easier method than Evan
Brewer's.</PRE>
<H3><A name="deb">Debian</A></H3>
<P>A recent (Nov 2001) mailing list points to a<A href="http://www.thing.dyndns.org/debian/vpn.htm">
web page</A> on setting up several types of tunnel, including IPsec, on
Debian.</P>
<P>Some older information:</P>
<PRE>Subject: FreeS/WAN 1.0 on Debian 2.1
Date: Tue, 20 Apr 1999
From: Tim Miller &lt;[email protected]&gt;
Compiled and installed without error on a Debian 2.1 system
with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
/etc/init.d.
/var/lock/subsys/ doesn't exist on Debian boxen, needs to be
created; not a fatal error.
Finally, IPsec scripts appear to be dependant on GNU awk
(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
operation appears flawless.</PRE>
<P>The scripts in question have been modified since this was posted. Awk
versions should no longer be a problem.</P>
<H3><A name="caldera">Caldera</A></H3>
<PRE>Subject: Re: HTML Docs- Need some cleanup?
Date: Mon, 08 Jan 2001
From: Andy Bradford &lt;[email protected]&gt;
On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
&gt; Intel Linux distributions other than Redhat 5.x and 6.x
&gt; Redhat 7.0
&gt; SuSE Linux
&gt; SuSE Linux 5.3
&gt; Slackware
&gt; Debian
Can you please include Caldera in this list? I have tested it since
FreeS/Wan 1.1 and it works great with our systems---provided one
follows the FreeS/Wan documentation. :-)
Thank you,
Andy</PRE>
<H2><A name="CPUs">CPUs other than Intel</A></H2>
<P>FreeS/WAN has been run sucessfully on a number of different CPU
architectures. If you have tried it on one not listed here, please post
to the<A href="mail.html"> mailing list</A>.</P>
<H3><A name=" strongarm">Corel Netwinder (StrongARM CPU)</A></H3>
<PRE>Subject: linux-ipsec: Netwinder diffs
Date: Wed, 06 Jan 1999
From: [email protected]
I had a mistake in my IPsec-auto, so I got things working this morning.
Following are the diffs for my changes. Probably not the best and cleanest way
of doing it, but it works. . . . </PRE>
<P>These diffs are in the 0.92 and later distributions, so these should
work out-of-the-box on Netwinder.</P>
<H3><A name="yellowdog">Yellow Dog Linux on Power PC</A></H3>
<PRE>Subject: Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
Date: 11 Dec 1999
From: Darron Froese &lt;[email protected]&gt;
I'm summarizing here for the record - because it's taken me many hours to do
this (multiple times) and because I want to see IPsec on more linuxes than
just x86.
Also, I can't remember if I actually did summarize it before... ;-) I'm
working too many late hours.
That said - here goes.
1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
&lt;http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2&gt;
2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
&lt;ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz&gt;
3. Get the gmp src rpm from here:
&lt;ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm&gt;
4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
You will see a lot of text fly by and when you start to see the rpm
recompiling like this:
Executing: %build
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd gmp-2.0.2
+ libtoolize --copy --force
Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
You should add the contents of `/usr/share/aclocal/libtool.m4' to
`aclocal.m4'.
+ CFLAGS=-O2 -fsigned-char
+ ./configure --prefix=/usr
Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
ydl.
cd /usr/src/redhat/BUILD/
cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
cd /usr/src/freeswan-1.1/
rm -rf gmp
mv gmp-2.0.2 gmp
5. Open the freeswan Makefile and change the line that says:
KERNEL=$(b)zimage (or something like that) to
KERNEL=vmlinux
6. cd ../linux/
7. make menuconfig
Select an option or two and then exit - saving your changes.
8. cd ../freeswan-1.1/ ; make menugo
That will start the whole process going - once that's finished compiling,
you have to install your new kernel and reboot.
That should build FreeS/WAN on ydl (I tried it on 1.1).</PRE>
And a later message on the same topic:
<PRE>Subject: Re: FreeS/WAN, PGPnet and E-mail
Date: Sat, 22 Jan 2000
From: Darron Froese &lt;[email protected]&gt;
on 1/22/00 6:47 PM, Philip Trauring at [email protected] wrote:
&gt; I have a PowerMac G3 ...
The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
FreeS/WAN 1.2patch1 with a couple minor modifications:
1. In the Makefile it specifies a bzimage for the kernel compile - you have
to change that to vmlinux for the PPC.
2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
compile. I have gotten around this by getting the gmp src rpm from here:
ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
If you rip the source out of there - and place it where the gmp source
resides it will compile just fine.</PRE>
<P>FreeS/WAN no longer includes GMP source.</P>
<H3><A name="mklinux">Mklinux</A></H3>
<P>One user reports success on the Mach-based<STRONG> m</STRONG>icro<STRONG>
k</STRONG>ernel Linux.</P>
<PRE>Subject: Smiles on sparc and ppc
Date: Fri, 10 Mar 2000
From: Jake Hill &lt;[email protected]&gt;
You may or may not be interested to know that I have successfully built
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
works, mostly, with few changes.</PRE>
<H3><A name="alpha">Alpha 64-bit processors</A></H3>
<PRE>Subject: IT WORKS (again) between intel &amp; alpha :-)))))
Date: Fri, 29 Jan 1999
From: Peter Onion &lt;[email protected]&gt;
Well I'm happy to report that I've got an IPsec connection between by intel &amp; alpha machines again :-))
If you look back on this list to 7th of December I wrote...
-On 07-Dec-98 Peter Onion wrote:
-&gt;
-&gt; I've about had enuf of wandering around inside the kernel trying to find out
-&gt; just what is corrupting outgoing packets...
-
-Its 7:30 in the evening .....
-
-I FIXED IT :-))))))))))))))))))))))))))))))))
-
-It was my own fault :-((((((((((((((((((
-
-If you ask me very nicly I'll tell you where I was a little too over keen to
-change unsigned long int __u32 :-) OPSE ...
-
-So tomorrow it will full steam ahead to produce a set of diffs/patches against
-0.91
-
-Peter Onion.</PRE>
<P>In general (there have been some glitches), FreeS/WAN has been
running on Alphas since then.</P>
<H3><A name="SPARC">Sun SPARC processors</A></H3>
<P>Several users have reported success with FreeS/WAN on SPARC Linux.
Here is one mailing list message:</P>
<PRE>Subject: Smiles on sparc and ppc
Date: Fri, 10 Mar 2000
From: Jake Hill &lt;[email protected]&gt;
You may or may not be interested to know that I have successfully built
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
works, mostly, with few changes.
I have a question, before I make up some patches. I need to hack
gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
trivial, but could I also use a different version of gmp? Is it vanilla
here?
I guess my only real headache is from ipchains, which appears to stop
running when IPsec has been started for a while. This is with 2.2.14 on
sparc.</PRE>
<P>This message, from a different mailing list, may be relevant for
anyone working with FreeS/WAN on Suns:</P>
<PRE>Subject: UltraSPARC DES assembler
Date: Thu, 13 Apr 2000
From: [email protected] (Svend Olaf Mikkelsen)
To: [email protected]
An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
file is available at http://inet.uni2.dk/~svolaf/des.htm.
This brings DES on UltraSPARC from slower than Pentium at the same
clock speed to significantly faster.</PRE>
<H3><A name="mips">MIPS processors</A></H3>
<P>We know FreeS/WAN runs on at least some MIPS processors because<A href="http://www.lasat.com">
Lasat</A> manufacture an IPsec box based on an embedded MIPS running
Linux with FreeS/WAN. We have no details.</P>
<H3><A name="crusoe">Transmeta Crusoe</A></H3>
<P>The Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
Firecard</A>, a Linux firewall on a PCI card, is based on a Crusoe
processor and supports FreeS/WAN.</P>
<H3><A name="coldfire">Motorola Coldfire</A></H3>
<PRE>Subject: Re: Crypto hardware support
Date: Mon, 03 Jul 2000
From: Dan DeVault &lt;[email protected]&gt;
.... I have been running
uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay (
http://www.moretonbay.com ) and it was using a Coldfire processor
and was able to do the Triple DES encryption at just about
1 mbit / sec rate....... they put a Hi/Fn 7901 hardware encryption
chip on their board and now their system does over 25 mbit of 3DES
encryption........ pretty significant increase if you ask me.</PRE>
<H2><A name="multiprocessor">Multiprocessor machines</A></H2>
<P>FreeS/WAN is designed to work on SMP (symmetric multi-processing)
Linux machines and is regularly tested on dual processor x86 machines.</P>
<P>We do not know of any testing on multi-processor machines with other
CPU architectures or with more than two CPUs. Anyone who does test
this, please report results to the<A href="mail.html"> mailing list</A>
.</P>
<P>The current design does not make particularly efficient use of
multiprocessor machines; some of the kernel work is single-threaded.</P>
<H2><A name="hardware">Support for crypto hardware</A></H2>
<P>Supporting hardware cryptography accelerators has not been a high
priority for the development team because it raises a number of fairly
complex issues:</P>
<UL>
<LI>Can you trust the hardware? If it is not Open Source, how do you
audit its security? Even if it is, how do you check that the design has
no concealed traps?</LI>
<LI>If an interface is added for such hardware, can that interface be
subverted or misused?</LI>
<LI>Is hardware acceleration actually a performance win? It clearly is
in many cases, but on a fast machine it might be better to use the CPU
for the encryption than to pay the overheads of moving data to and from
a crypto board.</LI>
<LI>the current KLIPS code does not provide a clean interface for
hardware accelerators</LI>
</UL>
<P>That said, we have a<A href="#coldfire"> report</A> of FreeS/WAN
working with one crypto accelerator and some work is going on to modify
KLIPS to create a clean generic interface to such products. See this<A href="http://www.jukie.net/~bart/linux-ipsec/">
web page</A> for some of the design discussion.</P>
<P>More recently, a patch to support some hardware accelerators has been
posted:</P>
<PRE>Subject: [Design] [PATCH] H/W acceleration patch
Date: Tue, 18 Sep 2001
From: &quot;Martin Gadbois&quot; &lt;[email protected]&gt;
Finally!!
Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including
S/W and Hifn 7901 crypto support.
http://sources.colubris.com/
Martin Gadbois</PRE>
<P>Hardware accelerators could take performance well beyond what
FreeS/WAN can do in software (discussed<A href="performance.html"> here</A>
). Here is some discussion off the IETF IPsec list, October 2001:</P>
<PRE> ... Currently shipping chips deliver, 600 mbps throughput on a single
stream of 3DES IPsec traffic. There are also chips that use multiple
cores to do 2.4 gbps. We (Cavium) and others have announced even faster
chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192)
IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.</PRE>
<P>The patches to date support chips that have been in production for
some time, not the state-of-the-art latest-and-greatest devices
described in that post. However, they may still outperform software and
they almost certainly reduce CPU overhead.</P>
<H2><A name="ipv6">IP version 6 (IPng)</A></H2>
<P>The Internet currently runs on version four of the IP protocols. IPv4
is what is in the standard Linux IP stack, and what FreeS/WAN was built
for. In IPv4, IPsec is an optional feature.</P>
<P>The next version of the IP protocol suite is version six, usually
abbreviated either as &quot;IPv6&quot; or as &quot;IPng&quot; for &quot;IP: the next
generation&quot;. For IPv6, IPsec is a required feature. Any machine doing
IPv6 is required to support IPsec, much as any machine doing (any
version of) IP is required to support ICMP.</P>
<P>There is a Linux implementation of IPv6 in Linux kernels 2.2 and
above. For details, see the<A href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">
FAQ</A>. It does not yet support IPsec. The<A href="http://www.linux-ipv6.org/">
USAGI</A> project are also working on IPv6 for Linux.</P>
<P>FreeS/WAN was originally built for the current standard, IPv4, but we
are interested in seeing it work with IPv6. Some progress has been
made, and a patched version with IPv6 support is<A href="http://www.ipv6.iabg.de/downloadframe/index.html">
available</A>. For more recent information, check the<A href="mail.html">
mailing list</A>.</P>
<H3><A name="v6.back">IPv6 background</A></H3>
<P>IPv6 has been specified by an IETF<A href="http://www.ietf.org/html.charters/ipngwg-charter.html">
working group</A>. The group's page lists over 30 RFCs to date, and
many Internet Drafts as well. The overview is<A href="http://www.ietf.org/rfc/rfc2460.txt">
RFC 2460</A>. Major features include:</P>
<UL>
<LI>expansion of the address space from 32 to 128 bits,</LI>
<LI>changes to improve support for
<UL>
<LI>mobile IP</LI>
<LI>automatic network configuration</LI>
<LI>quality of service routing</LI>
<LI>...</LI>
</UL>
</LI>
<LI>improved security via IPsec</LI>
</UL>
<P>A number of projects are working on IPv6 implementation. A prominent
Open Source effort is<A href="http://www.kame.net/"> KAME</A>, a
collaboration among several large Japanese companies to implement IPv6
for Berkeley Unix. Other major players are also working on IPv6. For
example, see pages at:</P>
<UL>
<LI><A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">Sun</A>
</LI>
<LI><A href="http://www.cisco.com/warp/public/732/ipv6/index.html">Cisco</A>
</LI>
<LI><A href="http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/IPv6.asp">
Microsoft</A></LI>
</UL>
<P>The<A href="http://www.6bone.net/"> 6bone</A> (IPv6 backbone) testbed
network has been up for some time. There is an active<A href="http://www.ipv6.org/">
IPv6 user group</A>.</P>
<P>One of the design goals for IPv6 was that it must be possible to
convert from v4 to v6 via a gradual transition process. Imagine the
mess if there were a &quot;flag day&quot; after which the entire Internet used
v6, and all software designed for v4 stopped working. Almost every
computer on the planet would need major software changes! There would
be huge costs to replace older equipment. Implementers would be worked
to death before &quot;the day&quot;, systems administrators and technical support
would be completely swamped after it. The bugs in every implementation
would all bite simultaneously. Large chunks of the net would almost
certainly be down for substantial time periods. ...</P>
<P>Fortunately, the design avoids any &quot;flag day&quot;. It is therefore a
little tricky to tell how quickly IPv6 will take over. The transition
has certainly begun. For examples, see announcements from<A href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">
NTT</A> and<A href="http://www.vnunet.com/News/1102383"> Nokia</A>.
However, it is not yet clear how quickly the process will gain
momentum, or when it will be completed. Likely large parts of the
Internet will remain with IPv4 for years to come.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="trouble.html">Previous</A>
<A HREF="interop.html">Next</A>
</BODY>
</HTML>
doc/config.html
-308
View File
@@ -1,308 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="install.html">Previous</A>
<A HREF="background.html">Next</A>
<HR>
<H1><A NAME="config">How to configure FreeS/WAN</A></H1>
<P>This page will teach you how to configure a simple network-to-network
link or a Road Warrior connection between two Linux FreeS/WAN boxes.</P>
<P>See also these related documents:</P>
<UL>
<LI>our<A HREF="quickstart.html#quickstart"> quickstart</A> guide to<A HREF="glossary.html#carpediem">
opportunistic encryption</A></LI>
<LI>our guide to configuration with<A HREF="policygroups.html#policygroups">
policy groups</A></LI>
<LI>our<A HREF="adv_config.html#adv_config"> advanced configuration</A>
document</LI>
</UL>
<P> The network-to-network setup allows you to connect two office
networks into one Virtual Private Network, while the Road Warrior
connection secures a laptop's telecommute to work. Our examples also
show the basic procedure on the Linux FreeS/WAN side where another
IPsec peer is in play.</P>
<P> Shortcut to<A HREF="#config.netnet"> net-to-net</A>.
<BR> Shortcut to<A HREF="#config.rw"> Road Warrior</A>.</P>
<H2><A NAME="16_1">Requirements</A></H2>
<P>To configure the network-to-network connection you must have:</P>
<UL>
<LI>two Linux gateways with static IPs</LI>
<LI>a network behind each gate. Networks must have non-overlapping IP
ranges.</LI>
<LI>Linux FreeS/WAN<A HREF="install.html#install"> installed</A> on both
gateways</LI>
<LI><A HREF="http://www.tcpdump.org"><VAR>tcpdump</VAR></A> on the local
gate, to test the connection</LI>
</UL>
<P>For the Road Warrior you need:</P>
<UL>
<LI>one Linux box with a static IP</LI>
<LI>a Linux laptop with a dynamic IP</LI>
<LI>Linux FreeS/WAN installed on both</LI>
<LI>for testing,<VAR> tcpdump</VAR> on your gateway or laptop</LI>
</UL>
<P>If both IPs are dynamic, your situation is a bit trickier. Your best
bet is a variation on the<A HREF="#config.rw"> Road Warrior</A>, as
described in<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00282.html">
this mailing list message</A>.</P>
<H2><A name="config.netnet"></A>Net-to-Net connection</H2>
<H3><A name="netnet.info.ex">Gather information</A></H3>
<P>For each gateway, compile the following information:</P>
<UL>
<LI>gateway IP</LI>
<LI>IP range of the subnet you will be protecting. This doesn't have to
be your whole physical subnet.</LI>
<LI>a name by which that gateway can identify itself for IPsec
negotiations. Its form is a Fully Qualified Domain Name preceded by an
@ sign, ie. @xy.example.com.
<BR> It does not need to be within a domain that you own. It can be a
made-up name.</LI>
</UL>
<H4>Get your leftrsasigkey</H4>
<P>On your local Linux FreeS/WAN gateway, print your IPsec public key:</P>
<PRE> ipsec showhostkey --left</PRE>
<P>The output should look like this (with the key shortened for easy
reading):</P>
<PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002
leftrsasigkey=0sAQOnwiBPt...</PRE>
<P>Don't have a key? Use<A HREF="manpage.d/ipsec_newhostkey.8.html"><VAR>
ipsec newhostkey</VAR></A> to create one.</P>
<H4>...and your rightrsasigkey</H4>
<P>Get a console on the remote side:</P>
<PRE> ssh2 ab.example.com</PRE>
<P>In that window, type:</P>
<PRE> ipsec showhostkey --right</PRE>
<P>You'll see something like:</P>
<PRE> # RSA 2192 bits ab.example.com Thu May 16 15:26:20 2002
rightrsasigkey=0sAQOqH55O...</PRE>
<H3><A NAME="16_2_2">Edit<VAR> /etc/ipsec.conf</VAR></A></H3>
<P>Back on the local gate, copy our template to<VAR> /etc/ipsec.conf</VAR>
. (on Mandrake,<VAR> /etc/freeswan/ipsec.conf</VAR>). Substitute the
information you've gathered for our example data.</P>
<PRE>conn net-to-net
left=192.0.2.2 # Local vitals
leftsubnet=192.0.2.128/29 #
[email protected] #
leftrsasigkey=0s1LgR7/oUM... #
leftnexthop=%defaultroute # correct in many situations
right=192.0.2.9 # Remote vitals
rightsubnet=10.0.0.0/24 #
[email protected] #
rightrsasigkey=0sAQOqH55O... #
rightnexthop=%defaultroute # correct in many situations
auto=add # authorizes but doesn't start this
# connection at startup</PRE>
<P> &quot;Left&quot; and &quot;right&quot; should represent the machines that have FreeS/WAN
installed on them, and &quot;leftsubnet&quot; and &quot;rightsubnet&quot; machines that are
being protected. /32 is assumed for left/right and left/rightsubnet
parameters.</P>
<P>Copy<VAR> conn net-to-net</VAR> to the remote-side /etc/ipsec.conf.
If you've made no other modifications to either<VAR> ipsec.conf</VAR>,
simply:</P>
<PRE> scp2 ipsec.conf [email protected]:/etc/ipsec.conf</PRE>
<H3><A NAME="16_2_3">Start your connection</A></H3>
<P>Locally, type:</P>
<PRE> ipsec auto --up net-to-net</PRE>
<P>You should see:</P>
<PRE> 104 &quot;net-net&quot; #223: STATE_MAIN_I1: initiate
106 &quot;net-net&quot; #223: STATE_MAIN_I2: sent MI2, expecting MR2
108 &quot;net-net&quot; #223: STATE_MAIN_I3: sent MI3, expecting MR3
004 &quot;net-net&quot; #223: STATE_MAIN_I4: ISAKMP SA established
112 &quot;net-net&quot; #224: STATE_QUICK_I1: initiate
004 &quot;net-net&quot; #224: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE>
<P>The important thing is<VAR> IPsec SA established</VAR>. If you're
unsuccessful, see our<A HREF="trouble.html#trouble"> troubleshooting
tips</A>.</P>
<H3><A NAME="16_2_4">Do not MASQ or NAT packets to be tunneled</A></H3>
<P>If you are using<A HREF="glossary.html#masq"> IP masquerade</A> or<A HREF="glossary.html#NAT.gloss">
Network Address Translation (NAT)</A> on either gateway, you must now
exempt the packets you wish to tunnel from this treatment. For example,
if you have a rule like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
</PRE>
<P>change it to something like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE>
<P>This may be necessary on both gateways.</P>
<H3><A NAME="16_2_5">Test your connection</A></H3>
<P>Sit at one of your local subnet nodes (not the gateway), and ping a
subnet node on the other (again, not the gateway).</P>
<PRE> ping fileserver.toledo.example.com</PRE>
<P>While still pinging, go to the local gateway and snoop your outgoing
interface, for example:</P>
<PRE> tcpdump -i ppp0</PRE>
<P>You want to see ESP (Encapsulating Security Payload) packets moving<B>
back and forth</B> between the two gateways at the same frequency as
your pings:</P>
<PRE> 19:16:32.046220 192.0.2.2 &gt; 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
19:16:32.085630 192.0.2.9 &gt; 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE>
<P>If you see this, congratulations are in order! You have a tunnel
which will protect any IP data from one subnet to the other, as it
passes between the two gates. If not, go and<A HREF="trouble.html#trouble">
troubleshoot</A>.</P>
<P>Note: your new tunnel protects only net-net traffic, not
gateway-gateway, or gateway-subnet. If you need this (for example, if
machines on one net need to securely contact a fileserver on the IPsec
gateway), you'll need to create<A HREF="adv_config.html#adv_config">
extra connections</A>.</P>
<H3><A NAME="16_2_6">Finishing touches</A></H3>
<P>Now that your connection works, name it something sensible, like:</P>
<PRE>conn winstonnet-toledonet</PRE>
<P>To have the tunnel come up on-boot, replace</P>
<PRE> auto=add</PRE>
<P>with:</P>
<PRE> auto=start</PRE>
<P>Copy these changes to the other side, for example:</P>
<PRE> scp2 ipsec.conf [email protected]:/etc/ipsec.conf</PRE>
<P>Enjoy!</P>
<H2><A name="config.rw"></A>Road Warrior Configuration</H2>
<H3><A name="rw.info.ex">Gather information</A></H3>
<P>You'll need to know:</P>
<UL>
<LI>the gateway's static IP</LI>
<LI>the IP range of the subnet behind that gateway</LI>
<LI>a name by which each side can identify itself for IPsec
negotiations. Its form is a Fully Qualified Domain Name preceded by an
@ sign, ie. @road.example.com.
<BR> It does not need to be within a domain that you own. It can be a
made-up name.</LI>
</UL>
<H4>Get your leftrsasigkey...</H4>
<P>On your laptop, print your IPsec public key:</P>
<PRE> ipsec showhostkey --left</PRE>
<P>The output should look like this (with the key shortened for easy
reading):</P>
<PRE> # RSA 2192 bits road.example.com Sun Jun 9 02:45:02 2002
leftrsasigkey=0sAQPIPN9uI...</PRE>
<P>Don't have a key? See<A HREF="old_config.html#genrsakey"> these
instructions</A>.</P>
<H4>...and your rightrsasigkey</H4>
<P>Get a console on the gateway:</P>
<PRE> ssh2 xy.example.com</PRE>
<P>View the gateway's public key with:</P>
<PRE> ipsec showhostkey --right</PRE>
<P>This will yield something like</P>
<PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002
rightrsasigkey=0sAQOnwiBPt...</PRE>
<H3><A NAME="16_3_2">Customize<VAR> /etc/ipsec.conf</VAR></A></H3>
<P>On your laptop, copy this template to<VAR> /etc/ipsec.conf</VAR>. (on
Mandrake,<VAR> /etc/freeswan/ipsec.conf</VAR>). Substitute the
information you've gathered for our example data.</P>
<PRE>conn road
left=%defaultroute # Picks up our dynamic IP
leftnexthop=%defaultroute #
[email protected] # Local information
leftrsasigkey=0sAQPIPN9uI... #
right=192.0.2.10 # Remote information
rightsubnet=10.0.0.0/24 #
[email protected] #
rightrsasigkey=0sAQOnwiBPt... #
auto=add # authorizes but doesn't start this
# connection at startup</PRE>
<P>The template for the gateway is different. Notice how it reverses<VAR>
left</VAR> and<VAR> right</VAR>, in keeping with our convention that<STRONG>
L</STRONG>eft is<STRONG> L</STRONG>ocal,<STRONG> R</STRONG>ight<STRONG>
R</STRONG>emote. Be sure to switch your rsasigkeys in keeping with
this.</P>
<PRE> ssh2 xy.example.com
vi /etc/ipsec.conf</PRE>
<P>and add:</P>
<PRE>conn road
left=192.0.2.2 # Gateway's information
[email protected] #
leftsubnet=192.0.2.128/29 #
leftrsasigkey=0sAQOnwiBPt... #
rightnexthop=%defaultroute # correct in many situations
right=%any # Wildcard: we don't know the laptop's IP
[email protected] #
rightrsasigkey=0sAQPIPN9uI... #
auto=add # authorizes but doesn't start this
# connection at startup</PRE>
<H3><A NAME="16_3_3">Start your connection</A></H3>
<P>You must start the connection from the Road Warrior side. On your
laptop, type:</P>
<PRE> ipsec auto --start net-to-net</PRE>
<P>You should see:</P>
<PRE>104 &quot;net-net&quot; #223: STATE_MAIN_I1: initiate
106 &quot;road&quot; #301: STATE_MAIN_I2: sent MI2, expecting MR2
108 &quot;road&quot; #301: STATE_MAIN_I3: sent MI3, expecting MR3
004 &quot;road&quot; #301: STATE_MAIN_I4: ISAKMP SA established
112 &quot;road&quot; #302: STATE_QUICK_I1: initiate
004 &quot;road&quot; #302: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE>
<P>Look for<VAR> IPsec SA established</VAR>. If you're unsuccessful, see
our<A HREF="trouble.html#trouble"> troubleshooting tips</A>.</P>
<H3><A NAME="16_3_4">Do not MASQ or NAT packets to be tunneled</A></H3>
<P>If you are using<A HREF="glossary.html#masq"> IP masquerade</A> or<A HREF="glossary.html#NAT.gloss">
Network Address Translation (NAT)</A> on either gateway, you must now
exempt the packets you wish to tunnel from this treatment. For example,
if you have a rule like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
</PRE>
<P>change it to something like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE>
<H3><A NAME="16_3_5">Test your connection</A></H3>
<P>From your laptop, ping a subnet node behind the remote gateway. Do
not choose the gateway itself for this test.</P>
<PRE> ping ns.winston.example.com</PRE>
<P>Snoop the packets exiting the laptop, with a command like:</P>
<PRE> tcpdump -i wlan0</PRE>
<P>You have success if you see (Encapsulating Security Payload) packets
travelling<B> in both directions</B>:</P>
<PRE> 19:16:32.046220 192.0.2.2 &gt; 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
19:16:32.085630 192.0.2.9 &gt; 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE>
<P>If you do, great! Traffic between your Road Warrior and the net
behind your gateway is protected. If not, see our<A HREF="trouble.html#trouble">
troubleshooting hints</A>.</P>
<P>Your new tunnel protects only traffic addressed to the net, not to
the IPsec gateway itself. If you need the latter, you'll want to make
an<A HREF="adv_config.html#adv_config"> extra tunnel.</A>.</P>
<H3><A NAME="16_3_6">Finishing touches</A></H3>
<P>On both ends, name your connection wisely, like:</P>
<PRE>conn mike-to-office</PRE>
<P><B>On the laptop only,</B> replace</P>
<PRE> auto=add</PRE>
<P>with:</P>
<PRE> auto=start</PRE>
<P>so that you'll be connected on-boot.</P>
<P>Happy telecommuting!</P>
<H3><A NAME="16_3_7">Multiple Road Warriors</A></H3>
<P>If you're using RSA keys, as we did in this example, you can add as
many Road Warriors as you like. The left/rightid parameter lets Linux
FreeS/WAN distinguish between multiple Road Warrior peers, each with
its own public key.</P>
<P>The situation is different for shared secrets (PSK). During a PSK
negotiation, ID information is not available at the time Pluto is
trying to determine which secret to use, so, effectively, you can only
define one Roadwarrior connection. All your PSK road warriors must
therefore share one secret.</P>
<H2><A NAME="16_4">What next?</A></H2>
<P>Using the principles illustrated here, you can try variations such
as:</P>
<UL>
<LI>a telecommuter with a static IP</LI>
<LI>a road warrior with a subnet behind it</LI>
</UL>
<P>Or, look at some of our<A HREF="adv_config.html#adv_config"> more
complex configuration examples.</A>.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="install.html">Previous</A>
<A HREF="background.html">Next</A>
</BODY>
</HTML>
doc/draft-richardson-ipsec-opportunistic.txt
-2688
View File
File diff suppressed because it is too large Load Diff
doc/draft-richardson-ipsec-rr.txt
-840
View File
@@ -1,840 +0,0 @@
IPSECKEY WG M. Richardson
Internet-Draft SSW
Expires: March 4, 2004 September 4, 2003
A method for storing IPsec keying material in DNS.
draft-ietf-ipseckey-rr-07.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a new resource record for DNS. This record
may be used to store public keys for use in IPsec systems.
This record replaces the functionality of the sub-type #1 of the KEY
Resource Record, which has been obsoleted by RFC3445.
Richardson Expires March 4, 2004 [Page 1]
Internet-Draft ipsecrr September 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4
2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4
2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4
2.4 RDATA format - gateway type . . . . . . . . . . . . . . . . . 4
2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 5
2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 5
3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7
3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7
3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1 Active attacks against unsecured IPSECKEY resource records . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Normative references . . . . . . . . . . . . . . . . . . . . . 13
Non-normative references . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Richardson Expires March 4, 2004 [Page 2]
Internet-Draft ipsecrr September 2003
1. Introduction
The type number for the IPSECKEY RR is TBD.
1.1 Overview
The IPSECKEY resource record (RR) is used to publish a public key
that is to be associated with a Domain Name System (DNS) name for use
with the IPsec protocol suite. This can be the public key of a
host, network, or application (in the case of per-port keying).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [8].
1.2 Usage Criteria
An IPSECKEY resource record SHOULD be used in combination with DNSSEC
unless some other means of authenticating the IPSECKEY resource
record is available.
It is expected that there will often be multiple IPSECKEY resource
records at the same name. This will be due to the presence of
multiple gateways and the need to rollover keys.
This resource record is class independent.
Richardson Expires March 4, 2004 [Page 3]
Internet-Draft ipsecrr September 2003
2. Storage formats
2.1 IPSECKEY RDATA format
The RDATA for an IPSECKEY RR consists of a precedence value, a public
key, algorithm type, and an optional gateway address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.2 RDATA format - precedence
This is an 8-bit precedence for this record. This is interpreted in
the same way as the PREFERENCE field described in section 3.3.9 of
RFC1035 [2].
Gateways listed in IPSECKEY records with lower precedence are to be
attempted first. Where there is a tie in precedence, the order
should be non-deterministic.
2.3 RDATA format - algorithm type
The algorithm type field identifies the public key's cryptographic
algorithm and determines the format of the public key field.
A value of 0 indicates that no key is present.
The following values are defined:
1 A DSA key is present, in the format defined in RFC2536 [11]
2 A RSA key is present, in the format defined in RFC3110 [12]
2.4 RDATA format - gateway type
The gateway type field indicates the format of the information that
is stored in the gateway field.
Richardson Expires March 4, 2004 [Page 4]
Internet-Draft ipsecrr September 2003
The following values are defined:
0 No gateway is present
1 A 4-byte IPv4 address is present
2 A 16-byte IPv6 address is present
3 A wire-encoded domain name is present. The wire-encoded format is
self-describing, so the length is implicit. The domain name MUST
NOT be compressed.
2.5 RDATA format - gateway
The gateway field indicates a gateway to which an IPsec tunnel may be
created in order to reach the entity named by this resource record.
There are three formats:
A 32-bit IPv4 address is present in the gateway field. The data
portion is an IPv4 address as described in section 3.4.1 of RFC1035
[2]. This is a 32-bit number in network byte order.
A 128-bit IPv6 address is present in the gateway field. The data
portion is an IPv6 address as described in section 2.2 of RFC1886
[7]. This is a 128-bit number in network byte order.
The gateway field is a normal wire-encoded domain name, as described
in section 3.3 of RFC1035 [2]. Compression MUST NOT be used.
2.6 RDATA format - public keys
Both of the public key types defined in this document (RSA and DSA)
inherit their public key formats from the corresponding KEY RR
formats. Specifically, the public key field contains the algorithm-
specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
after the first four octets. This is the same portion of the KEY RR
that must be specified by documents that define a DNSSEC algorithm.
Those documents also specify a message digest to be used for
generation of SIG RRs; that specification is not relevant for
IPSECKEY RR.
Future algorithms, if they are to be used by both DNSSEC (in the KEY
RR) and IPSECKEY, are likely to use the same public key encodings in
both records. Unless otherwise specified, the IPSECKEY public key
field will contain the algorithm-specific portion of the KEY RR RDATA
for the corresponding algorithm. The algorithm must still be
Richardson Expires March 4, 2004 [Page 5]
Internet-Draft ipsecrr September 2003
designated for use by IPSECKEY, and an IPSECKEY algorithm type number
(which might be different than the DNSSEC algorithm number) must be
assigned to it.
The DSA key format is defined in RFC2536 [11]
The RSA key format is defined in RFC3110 [12], with the following
changes:
The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
modulus to 2552 bits in length. RFC3110 extended that limit to 4096
bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on
RSA public keys, other than the 65535 octet limit imposed by the two-
octet length encoding. This length extension is applicable only to
IPSECKEY and not to KEY RRs.
Richardson Expires March 4, 2004 [Page 6]
Internet-Draft ipsecrr September 2003
3. Presentation formats
3.1 Representation of IPSECKEY RRs
IPSECKEY RRs may appear in a zone data master file. The precedence,
gateway type and algorithm and gateway fields are REQUIRED. The
base64 encoded public key block is OPTIONAL; if not present, then the
public key field of the resource record MUST be construed as being
zero octets in length.
The algorithm field is an unsigned integer. No mnemonics are
defined.
If no gateway is to be indicated, then the gateway type field MUST be
zero, and the gateway field MUST be "."
The Public Key field is represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see RFC1521 [3] Section 5.2.
The general presentation for the record as as follows:
IN IPSECKEY ( precedence gateway-type algorithm
gateway base64-encoded-public-key )
3.2 Examples
An example of a node 192.0.2.38 that will accept IPsec tunnels on its
own behalf.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.38
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has published its key only.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2
.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has delegated authority to the
node 192.0.2.3.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.3
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
Richardson Expires March 4, 2004 [Page 7]
Internet-Draft ipsecrr September 2003
An example of a node, 192.0.1.38 that has delegated authority to the
node with the identity "mygateway.example.com".
38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2
mygateway.example.com.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
Richardson Expires March 4, 2004 [Page 8]
Internet-Draft ipsecrr September 2003
4. Security Considerations
This entire memo pertains to the provision of public keying material
for use by key management protocols such as ISAKMP/IKE (RFC2407) [9].
The IPSECKEY resource record contains information that SHOULD be
communicated to the end client in an integral fashion - i.e. free
from modification. The form of this channel is up to the consumer of
the data - there must be a trust relationship between the end
consumer of this resource record and the server. This relationship
may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
another secure source, a secure local channel on the host, or some
combination of the above.
The keying material provided by the IPSECKEY resource record is not
sensitive to passive attacks. The keying material may be freely
disclosed to any party without any impact on the security properties
of the resulting IPsec session: IPsec and IKE provide for defense
against both active and passive attacks.
Any user of this resource record MUST carefully document their trust
model, and why the trust model of DNSSEC is appropriate, if that is
the secure channel used.
4.1 Active attacks against unsecured IPSECKEY resource records
This section deals with active attacks against the DNS. These
attacks require that DNS requests and responses be intercepted and
changed. DNSSEC is designed to defend against attacks of this kind.
The first kind of active attack is when the attacker replaces the
keying material with either a key under its control or with garbage.
If the attacker is not able to mount a subsequent man-in-the-middle
attack on the IKE negotiation after replacing the public key, then
this will result in a denial of service, as the authenticator used by
IKE would fail.
If the attacker is able to both to mount active attacks against DNS
and is also in a position to perform a man-in-the-middle attack on
IKE and IPsec negotiations, then the attacker will be in a position
to compromise the resulting IPsec channel. Note that an attacker
must be able to perform active DNS attacks on both sides of the IKE
negotiation in order for this to succeed.
The second kind of active attack is one in which the attacker
replaces the the gateway address to point to a node under the
attacker's control. The attacker can then either replace the public
Richardson Expires March 4, 2004 [Page 9]
Internet-Draft ipsecrr September 2003
key or remove it, thus providing an IPSECKEY record of its own to
match the gateway address.
This later form creates a simple man-in-the-middle since the attacker
can then create a second tunnel to the real destination. Note that,
as before, this requires that the attacker also mount an active
attack against the responder.
Note that the man-in-the-middle can not just forward cleartext
packets to the original destination. While the destination may be
willing to speak in the clear, replying to the original sender, the
sender will have already created a policy expecting ciphertext.
Thus, the attacker will need to intercept traffic from both sides.
In some cases, the attacker may be able to accomplish the full
intercept by use of Network Addresss/Port Translation (NAT/NAPT)
technology.
Note that the danger here only applies to cases where the gateway
field of the IPSECKEY RR indicates a different entity than the owner
name of the IPSECKEY RR. In cases where the end-to-end integrity of
the IPSECKEY RR is suspect, the end client MUST restrict its use of
the IPSECKEY RR to cases where the RR owner name matches the content
of the gateway field.
Richardson Expires March 4, 2004 [Page 10]
Internet-Draft ipsecrr September 2003
5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types
by assigning type X to the IPSECKEY record.
This document creates an IANA registry for the algorithm type field.
Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3
through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
This document creates an IANA registry for the gateway type field.
Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm numbers 4
through 255 can be assigned by Standards Action (see RFC2434 [6]).
Richardson Expires March 4, 2004 [Page 11]
Internet-Draft ipsecrr September 2003
6. Acknowledgments
My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
Austein, and Olafur Gurmundsson who reviewed this document carefully.
Additional thanks to Olafur Gurmundsson for a reference
implementation.
Richardson Expires March 4, 2004 [Page 12]
Internet-Draft ipsecrr September 2003
Normative references
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[5] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Richardson Expires March 4, 2004 [Page 13]
Internet-Draft ipsecrr September 2003
Non-normative references
[7] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[10] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[11] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
[13] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: [email protected]
URI: http://www.sandelman.ottawa.on.ca/
Richardson Expires March 4, 2004 [Page 14]
Internet-Draft ipsecrr September 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Richardson Expires March 4, 2004 [Page 15]
doc/draft-spencer-ipsec-ike-implementation.nr
-1203
View File
File diff suppressed because it is too large Load Diff
doc/draft-spencer-ipsec-ike-implementation.txt
-1232
View File
File diff suppressed because it is too large Load Diff
doc/examples
-182
View File
@@ -1,182 +0,0 @@
# sample connections
# This file is RCSID $Id: examples,v 1.1 2004/03/15 20:35:21 as Exp $
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work.
interfaces="ipsec0=eth1 ipsec1=ppp0"
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
# Manual connections to be started at startup.
manualstart="test1 test2"
# Auto connections to be loaded into Pluto at startup.
plutoload="samplehth samplefire"
# Auto connections to be started at startup.
plutostart=samplefire
# defaults for subsequent connection descriptions
conn %default
# How persistent to be in (re)keying negotiations (0 means very).
keyingtries=0
# Parameters for manual-keying testing (DON'T USE OPERATIONALLY).
spi=0x200
esp=3des-md5-96
espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf
# key lifetime (before automatic rekeying)
keylife=8h
# sample connection
conn sample
# Left security gateway and subnet behind it.
left=10.0.0.1
leftsubnet=172.16.0.0/24
# Right security gateway and subnet behind it.
right=10.12.12.1
rightsubnet=192.168.0.0/24
# Authorize this connection, but don't actually start it, at startup.
auto=add
# sample tunnel (manually or automatically keyed)
# Here we just use ESP for both encryption and authentication, which is
# the simplest and often the best method.
conn sample
# left security gateway (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left (omit if left end of the tunnel is just the s.g.)
leftsubnet=172.16.0.0/24
# right s.g., subnet behind it, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
rightsubnet=192.168.0.0/24
# (manual) SPI number
spi=0x200
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# In the remaining examples, deviations from the sample-tunnel configuration
# are marked with ###.
# sample host-to-host tunnel (no subnets)
# Here we assume (for purposes of illustration) that the hosts talk directly
# to each other, so we don't need next-hop settings.
conn samplehth
### left host (public-network address)
left=10.0.0.1
### next hop to reach right
leftnexthop=
### right host
right=10.12.12.1
### next hop to reach left
rightnexthop=
### (manual) SPI number
spi=0x300
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# sample hybrid tunnel, with a host on one end and a subnet (behind a
# security gateway) on the other
# This case is also sometimes called "road warrior".
conn samplehyb
### left host (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left
leftsubnet=172.16.0.0/24
### right host, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
### (manual) SPI number
spi=0x400
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# sample firewall-penetrating tunnel
# Here we assume that firewalling is being done on the left side.
conn samplefire
# left security gateway (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left (omit if left end of the tunnel is just the s.g.)
leftsubnet=172.16.0.0/24
### left is firewalling for its subnet
leftfirewall=yes
# right s.g., subnet behind it, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
rightsubnet=192.168.0.0/24
### (manual) SPI number
spi=0x500
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# sample transport-mode connection (which can only be host-to-host)
# Here we use the whole nine yards, with encryption done by ESP and
# authentication by AH; this perhaps is slightly preferable for transport
# mode, where the IP headers are exposed.
conn sampletm
### transport mode rather than tunnel
type=transport
### left host (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
### right host, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
### (manual) SPI number
spi=0x600
### (manual) encryption algorithm and parameters to it
esp=3des
espenckey=[192 bits]
### (manual) authentication algorithm and parameters to it
ah=hmac-md5
ahkey=[128 bits]
### (auto) authentication control
auth=ah
# sample description with keys split out into a separate section
# Normally the key section would go in a separate file, with tighter
# permissions set on it.
conn samplesep
# left security gateway (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left (omit if left end of the tunnel is just the s.g.)
leftsubnet=172.16.0.0/24
# right s.g., subnet behind it, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
rightsubnet=192.168.0.0/24
### (manual) SPI number
spi=0x700
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
also=samplesep-keys
# keys for the previous section
# Normally this would go in a separate file, picked up using an include line,
# to allow keeping the keys confidential.
conn samplesep-keys
espenckey=[192 bits]
espauthkey=[128 bits]
doc/faq.html
-2339
View File
File diff suppressed because it is too large Load Diff
doc/firewall.html
-767
View File
@@ -1,767 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="manpages.html">Previous</A>
<A HREF="trouble.html">Next</A>
<HR>
<H1><A name="firewall">FreeS/WAN and firewalls</A></H1>
<P>FreeS/WAN, or other IPsec implementations, frequently run on gateway
machines, the same machines running firewall or packet filtering code.
This document discusses the relation between the two.</P>
<P>The firewall code in 2.4 and later kernels is called Netfilter. The
user-space utility to manage a firewall is iptables(8). See the<A href="http://netfilter.samba.org">
netfilter/iptables web site</A> for details.</P>
<H2><A name="filters">Filtering rules for IPsec packets</A></H2>
<P>The basic constraint is that<STRONG> an IPsec gateway must have
packet filters that allow IPsec packets</STRONG>, at least when talking
to other IPsec gateways:</P>
<UL>
<LI>UDP port 500 for<A href="glossary.html#IKE"> IKE</A> negotiations</LI>
<LI>protocol 50 if you use<A href="glossary.html#ESP"> ESP</A>
encryption and/or authentication (the typical case)</LI>
<LI>protocol 51 if you use<A href="glossary.html#AH"> AH</A>
packet-level authentication</LI>
</UL>
<P>Your gateway and the other IPsec gateways it communicates with must
be able to exchange these packets for IPsec to work. Firewall rules
must allow UDP 500 and at least one of<A href="glossary.html#AH"> AH</A>
or<A href="glossary.html#ESP"> ESP</A> on the interface that
communicates with the other gateway.</P>
<P>For nearly all FreeS/WAN applications, you must allow UDP port 500
and the ESP protocol.</P>
<P>There are two ways to set this up:</P>
<DL>
<DT>easier but less flexible</DT>
<DD>Just set up your firewall scripts at boot time to allow IPsec
packets to and from your gateway. Let FreeS/WAN reject any bogus
packets.</DD>
<DT>more work, giving you more precise control</DT>
<DD>Have the<A href="manpage.d/ipsec_pluto.8.html"> ipsec_pluto(8)</A>
daemon call scripts to adjust firewall rules dynamically as required.
This is done by naming the scripts in the<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf(5)</A> variables<VAR> prepluto=</VAR>,<VAR> postpluto=</VAR>
,<VAR> leftupdown=</VAR> and<VAR> rightupdown=</VAR>.</DD>
</DL>
<P>Both methods are described in more detail below.</P>
<H2><A name="examplefw">Firewall configuration at boot</A></H2>
<P>It is possible to set up both firewalling and IPsec with appropriate
scripts at boot and then not use<VAR> leftupdown=</VAR> and<VAR>
rightupdown=</VAR>, or use them only for simple up and down operations.</P>
<P>Basically, the technique is</P>
<UL>
<LI>allow IPsec packets (typically, IKE on UDP port 500 plus ESP,
protocol 50)
<UL>
<LI>incoming, if the destination address is your gateway (and
optionally, only from known senders)</LI>
<LI>outgoing, with the from address of your gateway (and optionally,
only to known receivers)</LI>
</UL>
</LI>
<LI>let<A href="glossary.html#Pluto"> Pluto</A> deal with IKE</LI>
<LI>let<A href="glossary.html#KLIPS"> KLIPS</A> deal with ESP</LI>
</UL>
<P>Since Pluto authenticates its partners during the negotiation, and
KLIPS drops packets for which no tunnel has been negotiated, this may
be all you need.</P>
<H3><A name="simple.rules">A simple set of rules</A></H3>
<P>In simple cases, you need only a few rules, as in this example:</P>
<PRE># allow IPsec
#
# IKE negotiations
iptables -I INPUT -p udp --sport 500 --dport 500 -j ACCEPT
iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# ESP encryption and authentication
iptables -I INPUT -p 50 -j ACCEPT
iptables -I OUTPUT -p 50 -j ACCEPT
</PRE>
<P>This should be all you need to allow IPsec through<VAR> lokkit</VAR>,
which ships with Red Hat 9, on its medium security setting. Once you've
tweaked to your satisfaction, save your active rule set with:</P>
<PRE>service iptables save</PRE>
<H3><A name="complex.rules">Other rules</A></H3>
You can add additional rules, or modify existing ones, to work with
IPsec and with your network and policies. We give a some examples in
this section.
<P>However, while it is certainly possible to create an elaborate set of
rules yourself (please let us know via the<A href="mail.html"> mailing
list</A> if you do), it may be both easier and more secure to use a set
which has already been published and tested.</P>
<P>The published rule sets we know of are described in the<A href="#rules.pub">
next section</A>.</P>
<H4>Adding additional rules</H4>
If necessary, you can add additional rules to:
<DL>
<DT>reject IPsec packets that are not to or from known gateways</DT>
<DD>This possibility is discussed in more detail<A href="#unknowngate">
later</A></DD>
<DT>allow systems behind your gateway to build IPsec tunnels that pass
through the gateway</DT>
<DD>This possibility is discussed in more detail<A href="#through">
later</A></DD>
<DT>filter incoming packets emerging from KLIPS.</DT>
<DD>Firewall rules can recognise packets emerging from IPsec. They are
marked as arriving on an interface such as<VAR> ipsec0</VAR>, rather
than<VAR> eth0</VAR>,<VAR> ppp0</VAR> or whatever.</DD>
</DL>
<P>It is therefore reasonably straightforward to filter these packets in
whatever way suits your situation.</P>
<H4>Modifying existing rules</H4>
<P>In some cases rules that work fine before you add IPsec may require
modification to work with IPsec.</P>
<P>This is especially likely for rules that deal with interfaces on the
Internet side of your system. IPsec adds a new interface; often the
rules must change to take account of that.</P>
<P>For example, consider the rules given in<A href="http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-5.html">
this section</A> of the Netfilter documentation:</P>
<PRE>Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:
## Insert connection-tracking modules (not needed if built into kernel).
# insmod ip_conntrack
# insmod ip_conntrack_ftp
## Create chain which blocks new connections, except if coming from inside.
# iptables -N block
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A block -j DROP
## Jump to that chain from INPUT and FORWARD chains.
# iptables -A INPUT -j block
# iptables -A FORWARD -j block</PRE>
<P>On an IPsec gateway, those rules may need to be modified. The above
allows new connections from<EM> anywhere except ppp0</EM>. That means
new connections from ipsec0 are allowed.</P>
<P>Do you want to allow anyone who can establish an IPsec connection to
your gateway to initiate TCP connections to any service on your
network? Almost certainly not if you are using opportunistic
encryption. Quite possibly not even if you have only explicitly
configured connections.</P>
<P>To disallow incoming connections from ipsec0, change the middle
section above to:</P>
<PRE> ## Create chain which blocks new connections, except if coming from inside.
# iptables -N block
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state --state NEW -i ppp+ -j DROP
# iptables -A block -m state --state NEW -i ipsec+ -j DROP
# iptables -A block -m state --state NEW -i -j ACCEPT
# iptables -A block -j DROP</PRE>
<P>The original rules accepted NEW connections from anywhere except
ppp0. This version drops NEW connections from any PPP interface (ppp+)
and from any ipsec interface (ipsec+), then accepts the survivors.</P>
<P>Of course, these are only examples. You will need to adapt them to
your own situation.</P>
<H3><A name="rules.pub">Published rule sets</A></H3>
<P>Several sets of firewall rules that work with FreeS/WAN are
available.</P>
<H4><A name="Ranch.trinity">Scripts based on Ranch's work</A></H4>
<P>One user, Rob Hutton, posted his boot time scripts to the mailing
list, and we included them in previous versions of this documentation.
They are still available from our<A href="http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/firewall.html#examplefw">
web site</A>. However, they were for an earlier FreeS/WAN version so we
no longer recommend them. Also, they had some bugs. See this<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00316.html">
message</A>.</P>
<P>Those scripts were based on David Ranch's scripts for his &quot;Trinity
OS&quot; for setting up a secure Linux. Check his<A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">
home page</A> for the latest version and for information on his<A href="biblio.html#ranch">
book</A> on securing Linux. If you are going to base your firewalling
on Ranch's scripts, we recommend using his latest version, and sending
him any IPsec modifications you make for incorporation into later
versions.</P>
<H4><A name="seawall">The Seattle firewall</A></H4>
<P>We have had several mailing lists reports of good results using
FreeS/WAN with Seawall (the Seattle Firewall). See that project's<A href="http://seawall.sourceforge.net/">
home page</A> on Sourceforge.</P>
<H4><A name="rcf">The RCF scripts</A></H4>
<P>Another set of firewall scripts with IPsec support are the RCF or
rc.firewall scripts. See their<A href="http://jsmoriss.mvlan.net/linux/rcf.html">
home page</A>.</P>
<H4><A name="asgard">Asgard scripts</A></H4>
<P><A href="http://heimdall.asgardsrealm.net/linux/firewall/">Asgard's
Realm</A> has set of firewall scripts with FreeS/WAN support, for 2.4
kernels and iptables.</P>
<H4><A name="user.scripts">User scripts from the mailing list</A></H4>
<P>One user gave considerable detail on his scripts, including
supporting<A href="glossary.html#IPX"> IPX</A> through the tunnel. His
message was too long to conveniently be quoted here, so I've put it in
a<A href="user_examples.html"> separate file</A>.</P>
<H2><A name="updown">Calling firewall scripts, named in ipsec.conf(5)</A>
</H2>
<P>The<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A>
configuration file has three pairs of parameters used to specify an
interface between FreeS/WAN and firewalling code.</P>
<P>Note that using these is not required if you have a static firewall
setup. In that case, you just set your firewall up at boot time (in a
way that permits the IPsec connections you want) and do not change it
thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN
will not attempt to adjust firewall rules at all. See<A href="#examplefw">
above</A> for some information on appropriate scripts.</P>
<P>However, if you want your firewall rules to change when IPsec
connections change, then you need to use these parameters.</P>
<H3><A name="pre_post">Scripts called at IPsec start and stop</A></H3>
<P>One pair of parmeters are set in the<VAR> config setup</VAR> section
of the<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> file and
affect all connections:</P>
<DL>
<DT>prepluto=</DT>
<DD>script to be called before<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> IKE daemon is started.</DD>
<DT>postpluto=</DT>
<DD>script to be called after<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> IKE daemon is stopped.</DD>
</DL>
These parameters allow you to change firewall parameters whenever IPsec
is started or stopped.
<P>They can also be used in other ways. For example, you might have<VAR>
prepluto</VAR> add a module to your kernel for the secure network
interface or make a dialup connection, and then have<VAR> postpluto</VAR>
remove the module or take the connection down.</P>
<H3><A name="up_down">Scripts called at connection up and down</A></H3>
<P>The other parameters are set in connection descriptions. They can be
set in individual connection descriptions, and could even call
different scripts for each connection for maximum flexibility. In most
applications, however, it makes sense to use only one script and to
call it from<VAR> conn %default</VAR> section so that it applies to all
connections.</P>
<P>You can:</P>
<DL>
<DT><STRONG>either</STRONG></DT>
<DD>set<VAR> leftfirewall=yes</VAR> or<VAR> rightfirewall=yes</VAR> to
use our supplied default script</DD>
<DT><STRONG>or</STRONG></DT>
<DD>assign a name in a<VAR> leftupdown=</VAR> or<VAR> rightupdown=</VAR>
line to use your own script</DD>
</DL>
<P>Note that<STRONG> only one of these should be used</STRONG>. You
cannot sensibly use both. Since<STRONG> our default script is obsolete</STRONG>
(designed for firewalls using<VAR> ipfwadm(8)</VAR> on 2.0 kernels),
most users who need this service will<STRONG> need to write a custom
script</STRONG>.</P>
<H4><A name="fw.default">The default script</A></H4>
<P>We supply a default script named<VAR> _updown</VAR>.</P>
<DL>
<DT>leftfirewall=</DT>
<DD></DD>
<DT>rightfirewall=</DT>
<DD>indicates that the gateway is doing firewalling and that<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> should poke holes in the firewall as required.</DD>
</DL>
<P>Set these to<VAR> yes</VAR> and Pluto will call our default script<VAR>
_updown</VAR> with appropriate arguments whenever it:</P>
<UL>
<LI>starts or stops IPsec services</LI>
<LI>brings a connection up or down</LI>
</UL>
<P>The supplied default<VAR> _updown</VAR> script is appropriate for
simple cases using the<VAR> ipfwadm(8)</VAR> firewalling package.</P>
<H4><A name="userscript">User-written scripts</A></H4>
<P>You can also write your own script and have Pluto call it. Just put
the script's name in one of these<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf(5)</A> lines:</P>
<DL>
<DT>leftupdown=</DT>
<DD></DD>
<DT>rightupdown=</DT>
<DD>specifies a script to call instead of our default script<VAR>
_updown</VAR>.</DD>
</DL>
<P>Your script should take the same arguments and use the same
environment variables as<VAR> _updown</VAR>. See the &quot;updown command&quot;
section of the<A href="manpage.d/ipsec_pluto.8.html"> ipsec_pluto(8)</A>
man page for details.</P>
<P>Note that<STRONG> you should not modify our _updown script in place</STRONG>
. If you did that, then upgraded FreeS/WAN, the upgrade would install a
new default script, overwriting your changes.</P>
<H3><A name="ipchains.script">Scripts for ipchains or iptables</A></H3>
<P>Our<VAR> _updown</VAR> is for firewalls using<VAR> ipfwadm(8)</VAR>,
the firewall code for the 2.0 series of Linux kernels. If you are using
the more recent packages<VAR> ipchains(8)</VAR> (for 2.2 kernels) or<VAR>
iptables(8)</VAR> (2.4 kernels), then you must do one of:</P>
<UL>
<LI>use static firewall rules which are set up at boot time as described<A
href="#examplefw"> above</A> and do not need to be changed by Pluto</LI>
<LI>limit yourself to ipchains(8)'s ipfwadm(8) emulation mode in order
to use our script</LI>
<LI>write your own script and call it with<VAR> leftupdown</VAR> and<VAR>
rightupdown</VAR>.</LI>
</UL>
<P>You can write a script to do whatever you need with firewalling.
Specify its name in a<VAR> [left|right]updown=</VAR> parameter in<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf(5)</A> and Pluto will automatically call it for you.</P>
<P>The arguments Pluto passes such a script are the same ones it passes
to our default _updown script, so the best way to build yours is to
copy ours and modify the copy.</P>
<P>Note, however, that<STRONG> you should not modify our _updown script
in place</STRONG>. If you did that, then upgraded FreeS/WAN, the
upgrade would install a new default script, overwriting your changes.</P>
<H2><A name="NAT">A complication: IPsec vs. NAT</A></H2>
<P><A href="glossary.html#NAT.gloss">Network Address Translation</A>,
also known as IP masquerading, is a method of allocating IP addresses
dynamically, typically in circumstances where the total number of
machines which need to access the Internet exceeds the supply of IP
addresses.</P>
<P>Any attempt to perform NAT operations on IPsec packets<EM> between
the IPsec gateways</EM> creates a basic conflict:</P>
<UL>
<LI>IPsec wants to authenticate packets and ensure they are unaltered on
a gateway-to-gateway basis</LI>
<LI>NAT rewrites packet headers as they go by</LI>
<LI>IPsec authentication fails if packets are rewritten anywhere between
the IPsec gateways</LI>
</UL>
<P>For<A href="glossary.html#AH"> AH</A>, which authenticates parts of
the packet header including source and destination IP addresses, this
is fatal. If NAT changes those fields, AH authentication fails.</P>
<P>For<A href="glossary.html#IKE"> IKE</A> and<A href="glossary.html#ESP">
ESP</A> it is not necessarily fatal, but is certainly an unwelcome
complication.</P>
<H3><A name="nat_ok">NAT on or behind the IPsec gateway works</A></H3>
<P>This problem can be avoided by having the masquerading take place<EM>
on or behind</EM> the IPsec gateway.</P>
<P>This can be done physically with two machines, one physically behind
the other. A picture, using SG to indicate IPsec<STRONG> S</STRONG>
ecurity<STRONG> G</STRONG>ateways, is:</P>
<PRE> clients --- NAT ----- SG ---------- SG
two machines</PRE>
<P>In this configuration, the actual client addresses need not be given
in the<VAR> leftsubnet=</VAR> parameter of the FreeS/WAN connection
description. The security gateway just delivers packets to the NAT box;
it needs only that machine's address. What that machine does with them
does not affect FreeS/WAN.</P>
<P>A more common setup has one machine performing both functions:</P>
<PRE> clients ----- NAT/SG ---------------SG
one machine</PRE>
<P>Here you have a choice of techniques depending on whether you want to
make your client subnet visible to clients on the other end:</P>
<UL>
<LI>If you want the single gateway to behave like the two shown above,
with your clients hidden behind the NAT, then omit the<VAR> leftsubnet=</VAR>
parameter. It then defaults to the gateway address. Clients on the
other end then talk via the tunnel only to your gateway. The gateway
takes packets emerging from the tunnel, applies normal masquerading,
and forwards them to clients.</LI>
<LI>If you want to make your client machines visible, then give the
client subnet addresses as the<VAR> leftsubnet=</VAR> parameter in the
connection description and
<DL>
<DT>either</DT>
<DD>set<VAR> leftfirewall=yes</VAR> to use the default<VAR> updown</VAR>
script</DD>
<DT>or</DT>
<DD>use your own script by giving its name in a<VAR> leftupdown=</VAR>
parameter</DD>
</DL>
These scripts are described in their own<A href="#updown"> section</A>.
<P>In this case, no masquerading is done. Packets to or from the client
subnet are encrypted or decrypted without any change to their client
subnet addresses, although of course the encapsulating packets use
gateway addresses in their headers. Clients behind the right security
gateway see a route via that gateway to the left subnet.</P>
</LI>
</UL>
<H3><A name="nat_bad">NAT between gateways is problematic</A></H3>
<P>We recommend not trying to build IPsec connections which pass through
a NAT machine. This setup poses problems:</P>
<PRE> clients --- SG --- NAT ---------- SG</PRE>
<P>If you must try it, some references are:</P>
<UL>
<LI>Jean_Francois Nadeau's document on doing<A href="http://jixen.tripod.com/#NATed gateways">
IPsec behind NAT</A></LI>
<LI><A href="web.html#VPN.masq">VPN masquerade patches</A> to make a
Linux NAT box handle IPsec packets correctly</LI>
</UL>
<H3><A name="NAT.ref">Other references on NAT and IPsec</A></H3>
<P>Other documents which may be relevant include:</P>
<UL>
<LI>an Internet Draft on<A href="http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt">
IPsec and NAT</A> which may eventually evolve into a standard solution
for this problem.</LI>
<LI>an informational<A href="http://www.cis.ohio-state.edu/rfc/rfc2709.txt">
RFC</A>,<CITE> Security Model with Tunnel-mode IPsec for NAT Domains</CITE>
.</LI>
<LI>an<A href="http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html">
article</A> in Cisco's<CITE> Internet Protocol Journal</CITE></LI>
</UL>
<H2><A name="complications">Other complications</A></H2>
<P>Of course simply allowing UDP 500 and ESP packets is not the whole
story. Various other issues arise in making IPsec and packet filters
co-exist and even co-operate. Some of them are summarised below.</P>
<H3><A name="through">IPsec<EM> through</EM></A> the gateway</H3>
<P>Basic IPsec packet filtering rules deal only with packets addressed
to or sent from your IPsec gateway.</P>
<P>It is a separate policy decision whether to permit such packets to
pass through the gateway so that client machines can build end-to-end
IPsec tunnels of their own. This may not be practical if you are using<A
href="#NAT"> NAT (IP masquerade)</A> on your gateway, and may conflict
with some corporate security policies.</P>
<P>Where possible, allowing this is almost certainly a good idea. Using
IPsec on an end-to-end basis is more secure than gateway-to-gateway.</P>
<P>Doing it is quite simple. You just need firewall rules that allow UDP
port 500 and protocols 50 and 51 to pass through your gateway. If you
wish, you can of course restrict this to certain hosts.</P>
<H3><A name="ipsec_only">Preventing non-IPsec traffic</A></H3>
You can also filter<EM> everything but</EM> UDP port 500 and ESP or AH
to restrict traffic to IPsec only, either for anyone communicating with
your host or just for specific partners.
<P>One application of this is for the telecommuter who might have:</P>
<PRE> Sunset==========West------------------East ================= firewall --- the Internet
home network untrusted net corporate network</PRE>
<P>The subnet on the right is 0.0.0.0/0, the whole Internet. The West
gateway is set up so that it allows only IPsec packets to East in or
out.</P>
<P>This configuration is used in AT&amp;T Research's network. For details,
see the<A href="intro.html#applied"> papers</A> links in our
introduction.</P>
<P>Another application would be to set up firewall rules so that an
internal machine, such as an employees-only web server, could not talk
to the outside world except via specific IPsec tunnels.</P>
<H3><A name="unknowngate">Filtering packets from unknown gateways</A></H3>
<P>It is possible to use firewall rules to restrict UDP 500, ESP and AH
packets so that these packets are accepted only from known gateways.
This is not strictly necessary since FreeS/WAN will discard packets
from unknown gateways. You might, however, want to do it for any of a
number of reasons. For example:</P>
<UL>
<LI>Arguably, &quot;belt and suspenders&quot; is the sensible approach to
security. If you can block a potential attack in two ways, use both.
The only question is whether to look for a third way after implementing
the first two.</LI>
<LI>Some admins may prefer to use the firewall code this way because
they prefer firewall logging to FreeS/WAN's logging.</LI>
<LI>You may need it to implement your security policy. Consider an
employee working at home, and a policy that says traffic from the home
system to the Internet at large must go first via IPsec to the
corporate LAN and then out to the Internet via the corporate firewall.
One way to do that is to make<VAR> ipsec0</VAR> the default route on
the home gateway and provide exceptions only for UDP 500 and ESP to the
corporate gateway. Everything else is then routed via the tunnel to the
corporate gateway.</LI>
</UL>
<P>It is not possible to use only static firewall rules for this
filtering if you do not know the other gateways' IP addresses in
advance, for example if you have &quot;road warriors&quot; who may connect from a
different address each time or if want to do<A href="glossary.html#carpediem">
opportunistic encryption</A> to arbitrary gateways. In these cases, you
can accept UDP 500 IKE packets from anywhere, then use the<A href="#updown">
updown</A> script feature of<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> to dynamically adjust firewalling for each negotiated
tunnel.</P>
<P>Firewall packet filtering does not much reduce the risk of a<A href="glossary.html#DOS">
denial of service attack</A> on FreeS/WAN. The firewall can drop
packets from unknown gateways, but KLIPS does that quite efficiently
anyway, so you gain little. The firewall cannot drop otherwise
legitmate packets that fail KLIPS authentication, so it cannot protect
against an attack designed to exhaust resources by making FreeS/WAN
perform many expensive authentication operations.</P>
<P>In summary, firewall filtering of IPsec packets from unknown gateways
is possible but not strictly necessary.</P>
<H2><A name="otherfilter">Other packet filters</A></H2>
<P>When the IPsec gateway is also acting as your firewall, other packet
filtering rules will be in play. In general, those are outside the
scope of this document. See our<A href="web.html#firewall.linux"> Linux
firewall links</A> for information. There are a few types of packet,
however, which can affect the operation of FreeS/WAN or of diagnostic
tools commonly used with it. These are discussed below.</P>
<H3><A name="ICMP">ICMP filtering</A></H3>
<P><A href="glossary.html#ICMP.gloss">ICMP</A> is the<STRONG> I</STRONG>
nternet<STRONG> C</STRONG>ontrol<STRONG> M</STRONG>essage<STRONG> P</STRONG>
rotocol. It is used for messages between IP implementations themselves,
whereas IP used is used between the clients of those implementations.
ICMP is, unsurprisingly, used for control messages. For example, it is
used to notify a sender that a desination is not reachable, or to tell
a router to reroute certain packets elsewhere.</P>
<P>ICMP handling is tricky for firewalls.</P>
<UL>
<LI>You definitely want some ICMP messages to get through; things won't
work without them. For example, your clients need to know if some
destination they ask for is unreachable.</LI>
<LI>On the other hand, you do equally definitely do not want untrusted
folk sending arbitrary control messages to your machines. Imagine what
someone moderately clever and moderately malicious could do to you,
given control of your network's routing.</LI>
</UL>
<P>ICMP does not use ports. Messages are distinguished by a &quot;message
type&quot; field and, for some types, by an additional &quot;code&quot; field. The
definitive list of types and codes is on the<A href="http://www.iana.org">
IANA</A> site.</P>
<P>One expert uses this definition for ICMP message types to be dropped
at the firewall.</P>
<PRE># ICMP types which lack socially redeeming value.
# 5 Redirect
# 9 Router Advertisement
# 10 Router Selection
# 15 Information Request
# 16 Information Reply
# 17 Address Mask Request
# 18 Address Mask Reply
badicmp='5 9 10 15 16 17 18'</PRE>
<P>A more conservative approach would be to make a list of allowed types
and drop everything else.</P>
<P>Whichever way you do it, your ICMP filtering rules on a FreeS/WAN
gateway should allow at least the following ICMP packet types:</P>
<DL>
<DT>echo (type 8)</DT>
<DD></DD>
<DT>echo reply (type 0)</DT>
<DD>These are used by ping(1). We recommend allowing both types through
the tunnel and to or from your gateway's external interface, since
ping(1) is an essential testing tool.
<P>It is fairly common for firewalls to drop ICMP echo packets addressed
to machines behind the firewall. If that is your policy, please create
an exception for such packets arriving via an IPsec tunnel, at least
during intial testing of those tunnels.</P>
</DD>
<DT>destination unreachable (type 3)</DT>
<DD>This is used, with code 4 (Fragmentation Needed and Don't Fragment
was Set) in the code field, to control<A href="glossary.html#pathMTU">
path MTU discovery</A>. Since IPsec processing adds headers, enlarges
packets and may cause fragmentation, an IPsec gateway should be able to
send and receive these ICMP messages<STRONG> on both inside and outside
interfaces</STRONG>.</DD>
</DL>
<H3><A name="traceroute">UDP packets for traceroute</A></H3>
<P>The traceroute(1) utility uses UDP port numbers from 33434 to
approximately 33633. Generally, these should be allowed through for
troubleshooting.</P>
<P>Some firewalls drop these packets to prevent outsiders exploring the
protected network with traceroute(1). If that is your policy, consider
creating an exception for such packets arriving via an IPsec tunnel, at
least during intial testing of those tunnels.</P>
<H3><A name="l2tp">UDP for L2TP</A></H3>
<P> Windows 2000 does, and products designed for compatibility with it
may, build<A href="glossary.html#L2TP"> L2TP</A> tunnels over IPsec
connections.</P>
<P>For this to work, you must allow UDP protocol 1701 packets coming out
of your tunnels to continue to their destination. You can, and probably
should, block such packets to or from your external interfaces, but
allow them from<VAR> ipsec0</VAR>.</P>
<P>See also our Windows 2000<A href="interop.html#win2k"> interoperation
discussion</A>.</P>
<H2><A name="packets">How it all works: IPsec packet details</A></H2>
<P>IPsec uses three main types of packet:</P>
<DL>
<DT><A href="glossary.html#IKE">IKE</A> uses<STRONG> the UDP protocol
and port 500</STRONG>.</DT>
<DD>Unless you are using only (less secure, not recommended) manual
keying, you need IKE to negotiate connection parameters, acceptable
algorithms, key sizes and key setup. IKE handles everything required to
set up, rekey, repair or tear down IPsec connections.</DD>
<DT><A href="glossary.html#ESP">ESP</A> is<STRONG> protocol number 50</STRONG>
</DT>
<DD>This is required for encrypted connections.</DD>
<DT><A href="glossary.html#AH">AH</A> is<STRONG> protocol number 51</STRONG>
</DT>
<DD>This can be used where only authentication, not encryption, is
required.</DD>
</DL>
<P>All of those packets should have appropriate IPsec gateway addresses
in both the to and from IP header fields. Firewall rules can check this
if you wish, though it is not strictly necessary. This is discussed in
more detail<A href="#unknowngate"> later</A>.</P>
<P>IPsec processing of incoming packets authenticates them then removes
the ESP or AH header and decrypts if necessary. Successful processing
exposes an inner packet which is then delivered back to the firewall
machinery, marked as having arrived on an<VAR> ipsec[0-3]</VAR>
interface. Firewall rules can use that interface label to distinguish
these packets from unencrypted packets which are labelled with the
physical interface they arrived on (or perhaps with a non-IPsec virtual
interface such as<VAR> ppp0</VAR>).</P>
<P>One of our users sent a mailing list message with a<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00006.html">
diagram</A> of the packet flow.</P>
<H3><A name="noport">ESP and AH do not have ports</A></H3>
<P>Some protocols, such as TCP and UDP, have the notion of ports. Others
protocols, including ESP and AH, do not. Quite a few IPsec newcomers
have become confused on this point. There are no ports<EM> in</EM> the
ESP or AH protocols, and no ports used<EM> for</EM> them. For these
protocols,<EM> the idea of ports is completely irrelevant</EM>.</P>
<H3><A name="header">Header layout</A></H3>
<P>The protocol numbers for ESP or AH are used in the 'next header'
field of the IP header. On most non-IPsec packets, that field would
have one of:</P>
<UL>
<LI>1 for ICMP</LI>
<LI>4 for IP-in-IP encapsulation</LI>
<LI>6 for TCP</LI>
<LI>17 for UDP</LI>
<LI>... or one of about 100 other possibilities listed by<A href="http://www.iana.org">
IANA</A></LI>
</UL>
<P>Each header in the sequence tells what the next header will be. IPsec
adds headers for ESP or AH near the beginning of the sequence. The
original headers are kept and the 'next header' fields adjusted so that
all headers can be correctly interpreted.</P>
<P>For example, using<STRONG> [</STRONG><STRONG> ]</STRONG> to indicate
data protected by ESP and unintelligible to an eavesdropper between the
gateways:</P>
<UL>
<LI>a simple packet might have only IP and TCP headers with:
<UL>
<LI>IP header says next header --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data</LI>
</UL>
</LI>
<LI>with ESP<A href="glossary.html#transport"> transport mode</A>
encapsulation, that packet would have:
<UL>
<LI>IP header says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data<STRONG> ]</STRONG></LI>
</UL>
Note that the IP header is outside ESP protection, visible to an
attacker, and that the final destination must be the gateway.</LI>
<LI>with ESP in<A href="glossary.html#tunnel"> tunnel mode</A>, we might
have:
<UL>
<LI>IP header says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; IP</LI>
<LI>IP header says next header --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data<STRONG> ]</STRONG></LI>
</UL>
Here the inner IP header is protected by ESP, unreadable by an
attacker. Also, the inner header can have a different IP address than
the outer IP header, so the decrypted packet can be routed from the
IPsec gateway to a final destination which may be another machine.</LI>
</UL>
<P>Part of the ESP header itself is encrypted, which is why the<STRONG>
[</STRONG> indicating protected data appears in the middle of some
lines above. The next header field of the ESP header is protected. This
makes<A href="glossary.html#traffic"> traffic analysis</A> more
difficult. The next header field would tell an eavesdropper whether
your packet was UDP to the gateway, TCP to the gateway, or encapsulated
IP. It is better not to give this information away. A clever attacker
may deduce some of it from the pattern of packet sizes and timings, but
we need not make it easy.</P>
<P>IPsec allows various combinations of these to match local policies,
including combinations that use both AH and ESP headers or that nest
multiple copies of these headers.</P>
<P>For example, suppose my employer has an IPsec VPN running between two
offices so all packets travelling between the gateways for those
offices are encrypted. If gateway policies allow it (The admins could
block UDP 500 and protocols 50 and 51 to disallow it), I can build an
IPsec tunnel from my desktop to a machine in some remote office. Those
packets will have one ESP header throughout their life, for my
end-to-end tunnel. For part of the route, however, they will also have
another ESP layer for the corporate VPN's encapsulation. The whole
header scheme for a packet on the Internet might be:</P>
<UL>
<LI>IP header (with gateway address) says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; IP</LI>
<LI>IP header (with receiving machine address) says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data<STRONG> ]]</STRONG></LI>
</UL>
<P>The first ESP (outermost) header is for the corporate VPN. The inner
ESP header is for the secure machine-to-machine link.</P>
<H3><A name="dhr">DHR on the updown script</A></H3>
<P>Here are some mailing list comments from<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> developer Hugh Redelmeier on an earlier draft of this
document:</P>
<PRE>There are many important things left out
- firewalling is important but must reflect (implement) policy. Since
policy isn't the same for all our customers, and we're not experts,
we should concentrate on FW and MASQ interactions with FreeS/WAN.
- we need a diagram to show packet flow WITHIN ONE MACHINE, assuming
IKE, IPsec, FW, and MASQ are all done on that machine. The flow is
obvious if the components are run on different machines (trace the
cables).
IKE input:
+ packet appears on public IF, as UDP port 500
+ input firewalling rules are applied (may discard)
+ Pluto sees the packet.
IKE output:
+ Pluto generates the packet &amp; writes to public IF, UDP port 500
+ output firewalling rules are applied (may discard)
+ packet sent out public IF
IPsec input, with encapsulated packet, outer destination of this host:
+ packet appears on public IF, protocol 50 or 51. If this
packet is the result of decapsulation, it will appear
instead on the paired ipsec IF.
+ input firewalling rules are applied (but packet is opaque)
+ KLIPS decapsulates it, writes result to paired ipsec IF
+ input firewalling rules are applied to resulting packet
as input on ipsec IF
+ if the destination of the packet is this machine, the
packet is passed on to the appropriate protocol handler.
If the original packet was encapsulated more than once
and the new outer destination is this machine, that
handler will be KLIPS.
+ otherwise:
* routing is done for the resulting packet. This may well
direct it into KLIPS for encoding or encrypting. What
happens then is described elsewhere.
* forwarding firewalling rules are applied
* output firewalling rules are applied
* the packet is sent where routing specified
IPsec input, with encapsulated packet, outer destination of another host:
+ packet appears on some IF, protocol 50 or 51
+ input firewalling rules are applied (but packet is opaque)
+ routing selects where to send the packet
+ forwarding firewalling rules are applied (but packet is opaque)
+ packet forwarded, still encapsulated
IPsec output, from this host or from a client:
+ if from a client, input firewalling rules are applied as the
packet arrives on the private IF
+ routing directs the packet to an ipsec IF (this is how the
system decides KLIPS processing is required)
+ if from a client, forwarding firewalling rules are applied
+ KLIPS eroute mechanism matches the source and destination
to registered eroutes, yielding a SPI group. This dictates
processing, and where the resulting packet is to be sent
(the destinations SG and the nexthop).
+ output firewalling is not applied to the resulting
encapsulated packet
- Until quite recently, KLIPS would double encapsulate packets that
didn't strictly need to be. Firewalling should be prepared for
those packets showing up as ESP and AH protocol input packets on
an ipsec IF.
- MASQ processing seems to be done as if it were part of the
forwarding firewall processing (this should be verified).
- If a firewall is being used, it is likely the case that it needs to
be adjusted whenever IPsec SAs are added or removed. Pluto invokes
a script to do this (and to adjust routing) at suitable times. The
default script is only suitable for ipfwadm-managed firewalls. Under
LINUX 2.2.x kernels, ipchains can be managed by ipfwadm (emulation),
but ipchains more powerful if manipulated using the ipchains command.
In this case, a custom updown script must be used.
We think that the flexibility of ipchains precludes us supplying an
updown script that would be widely appropriate.</PRE>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="manpages.html">Previous</A>
<A HREF="trouble.html">Next</A>
</BODY>
</HTML>
doc/glossary.html
-2132
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdf
BIN
View File
Binary file not shown.
doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf
BIN
View File
Binary file not shown.
doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdf
BIN
View File
Binary file not shown.
doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt
-3248
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[IKEv2Draft] - Internet Key Exchange (IKEv2) Protocol Draft v17.txt
-6535
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[IKEv2bis] - draft-hoffman-ikev2bis-00.txt
-6776
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[IPsecArch] - Security Architecture for the Internet Protocol.txt
-5657
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdf
BIN
View File
Binary file not shown.
doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt
-619
View File
@@ -1,619 +0,0 @@
Network Working Group H. Krawczyk
Request for Comments: 2104 IBM
Category: Informational M. Bellare
UCSD
R. Canetti
IBM
February 1997
HMAC: Keyed-Hashing for Message Authentication
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document describes HMAC, a mechanism for message authentication
using cryptographic hash functions. HMAC can be used with any
iterative cryptographic hash function, e.g., MD5, SHA-1, in
combination with a secret shared key. The cryptographic strength of
HMAC depends on the properties of the underlying hash function.
1. Introduction
Providing a way to check the integrity of information transmitted
over or stored in an unreliable medium is a prime necessity in the
world of open computing and communications. Mechanisms that provide
such integrity check based on a secret key are usually called
"message authentication codes" (MAC). Typically, message
authentication codes are used between two parties that share a secret
key in order to validate information transmitted between these
parties. In this document we present such a MAC mechanism based on
cryptographic hash functions. This mechanism, called HMAC, is based
on work by the authors [BCK1] where the construction is presented and
cryptographically analyzed. We refer to that work for the details on
the rationale and security analysis of HMAC, and its comparison to
other keyed-hash methods.
Krawczyk, et. al. Informational [Page 1]
RFC 2104 HMAC February 1997
HMAC can be used in combination with any iterated cryptographic hash
function. MD5 and SHA-1 are examples of such hash functions. HMAC
also uses a secret key for calculation and verification of the
message authentication values. The main goals behind this
construction are
* To use, without modifications, available hash functions.
In particular, hash functions that perform well in software,
and for which code is freely and widely available.
* To preserve the original performance of the hash function without
incurring a significant degradation.
* To use and handle keys in a simple way.
* To have a well understood cryptographic analysis of the strength of
the authentication mechanism based on reasonable assumptions on the
underlying hash function.
* To allow for easy replaceability of the underlying hash function in
case that faster or more secure hash functions are found or
required.
This document specifies HMAC using a generic cryptographic hash
function (denoted by H). Specific instantiations of HMAC need to
define a particular hash function. Current candidates for such hash
functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
These different realizations of HMAC will be denoted by HMAC-SHA1,
HMAC-MD5, HMAC-RIPEMD, etc.
Note: To the date of writing of this document MD5 and SHA-1 are the
most widely used cryptographic hash functions. MD5 has been recently
shown to be vulnerable to collision search attacks [Dobb]. This
attack and other currently known weaknesses of MD5 do not compromise
the use of MD5 within HMAC as specified in this document (see
[Dobb]); however, SHA-1 appears to be a cryptographically stronger
function. To this date, MD5 can be considered for use in HMAC for
applications where the superior performance of MD5 is critical. In
any case, implementers and users need to be aware of possible
cryptanalytic developments regarding any of these cryptographic hash
functions, and the eventual need to replace the underlying hash
function. (See section 6 for more information on the security of
HMAC.)
Krawczyk, et. al. Informational [Page 2]
RFC 2104 HMAC February 1997
2. Definition of HMAC
The definition of HMAC requires a cryptographic hash function, which
we denote by H, and a secret key K. We assume H to be a cryptographic
hash function where data is hashed by iterating a basic compression
function on blocks of data. We denote by B the byte-length of such
blocks (B=64 for all the above mentioned examples of hash functions),
and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
SHA-1). The authentication key K can be of any length up to B, the
block length of the hash function. Applications that use keys longer
than B bytes will first hash the key using H and then use the
resultant L byte string as the actual key to HMAC. In any case the
minimal recommended length for K is L bytes (as the hash output
length). See section 3 for more information on keys.
We define two fixed and different strings ipad and opad as follows
(the 'i' and 'o' are mnemonics for inner and outer):
ipad = the byte 0x36 repeated B times
opad = the byte 0x5C repeated B times.
To compute HMAC over the data `text' we perform
H(K XOR opad, H(K XOR ipad, text))
Namely,
(1) append zeros to the end of K to create a B byte string
(e.g., if K is of length 20 bytes and B=64, then K will be
appended with 44 zero bytes 0x00)
(2) XOR (bitwise exclusive-OR) the B byte string computed in step
(1) with ipad
(3) append the stream of data 'text' to the B byte string resulting
from step (2)
(4) apply H to the stream generated in step (3)
(5) XOR (bitwise exclusive-OR) the B byte string computed in
step (1) with opad
(6) append the H result from step (4) to the B byte string
resulting from step (5)
(7) apply H to the stream generated in step (6) and output
the result
For illustration purposes, sample code based on MD5 is provided as an
appendix.
Krawczyk, et. al. Informational [Page 3]
RFC 2104 HMAC February 1997
3. Keys
The key for HMAC can be of any length (keys longer than B bytes are
first hashed using H). However, less than L bytes is strongly
discouraged as it would decrease the security strength of the
function. Keys longer than L bytes are acceptable but the extra
length would not significantly increase the function strength. (A
longer key may be advisable if the randomness of the key is
considered weak.)
Keys need to be chosen at random (or using a cryptographically strong
pseudo-random generator seeded with a random seed), and periodically
refreshed. (Current attacks do not indicate a specific recommended
frequency for key changes as these attacks are practically
infeasible. However, periodic key refreshment is a fundamental
security practice that helps against potential weaknesses of the
function and keys, and limits the damage of an exposed key.)
4. Implementation Note
HMAC is defined in such a way that the underlying hash function H can
be used with no modification to its code. In particular, it uses the
function H with the pre-defined initial value IV (a fixed value
specified by each iterative hash function to initialize its
compression function). However, if desired, a performance
improvement can be achieved at the cost of (possibly) modifying the
code of H to support variable IVs.
The idea is that the intermediate results of the compression function
on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
only once at the time of generation of the key K, or before its first
use. These intermediate results are stored and then used to
initialize the IV of H each time that a message needs to be
authenticated. This method saves, for each authenticated message,
the application of the compression function of H on two B-byte blocks
(i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
significant when authenticating short streams of data. We stress
that the stored intermediate values need to be treated and protected
the same as secret keys.
Choosing to implement HMAC in the above way is a decision of the
local implementation and has no effect on inter-operability.
Krawczyk, et. al. Informational [Page 4]
RFC 2104 HMAC February 1997
5. Truncated output
A well-known practice with message authentication codes is to
truncate the output of the MAC and output only part of the bits
(e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some
analytical advantages of truncating the output of hash-based MAC
functions. The results in this area are not absolute as for the
overall security advantages of truncation. It has advantages (less
information on the hash result available to an attacker) and
disadvantages (less bits to predict for the attacker). Applications
of HMAC can choose to truncate the output of HMAC by outputting the t
leftmost bits of the HMAC computation for some parameter t (namely,
the computation is carried in the normal way as defined in section 2
above but the end result is truncated to t bits). We recommend that
the output length t be not less than half the length of the hash
output (to match the birthday attack bound) and not less than 80 bits
(a suitable lower bound on the number of bits that need to be
predicted by an attacker). We propose denoting a realization of HMAC
that uses a hash function H with t bits of output as HMAC-H-t. For
example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
and with the output truncated to 80 bits. (If the parameter t is not
specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
hash are output.)
6. Security
The security of the message authentication mechanism presented here
depends on cryptographic properties of the hash function H: the
resistance to collision finding (limited to the case where the
initial value is secret and random, and where the output of the
function is not explicitly available to the attacker), and the
message authentication property of the compression function of H when
applied to single blocks (in HMAC these blocks are partially unknown
to an attacker as they contain the result of the inner H computation
and, in particular, cannot be fully chosen by the attacker).
These properties, and actually stronger ones, are commonly assumed
for hash functions of the kind used with HMAC. In particular, a hash
function for which the above properties do not hold would become
unsuitable for most (probably, all) cryptographic applications,
including alternative message authentication schemes based on such
functions. (For a complete analysis and rationale of the HMAC
function the reader is referred to [BCK1].)
Krawczyk, et. al. Informational [Page 5]
RFC 2104 HMAC February 1997
Given the limited confidence gained so far as for the cryptographic
strength of candidate hash functions, it is important to observe the
following two properties of the HMAC construction and its secure use
for message authentication:
1. The construction is independent of the details of the particular
hash function H in use and then the latter can be replaced by any
other secure (iterative) cryptographic hash function.
2. Message authentication, as opposed to encryption, has a
"transient" effect. A published breaking of a message authentication
scheme would lead to the replacement of that scheme, but would have
no adversarial effect on information authenticated in the past. This
is in sharp contrast with encryption, where information encrypted
today may suffer from exposure in the future if, and when, the
encryption algorithm is broken.
The strongest attack known against HMAC is based on the frequency of
collisions for the hash function H ("birthday attack") [PV,BCK2], and
is totally impractical for minimally reasonable hash functions.
As an example, if we consider a hash function like MD5 where the
output length equals L=16 bytes (128 bits) the attacker needs to
acquire the correct message authentication tags computed (with the
_same_ secret key K!) on about 2**64 known plaintexts. This would
require the processing of at least 2**64 blocks under H, an
impossible task in any realistic scenario (for a block length of 64
bytes this would take 250,000 years in a continuous 1Gbps link, and
without changing the secret key K during all this time). This attack
could become realistic only if serious flaws in the collision
behavior of the function H are discovered (e.g. collisions found
after 2**30 messages). Such a discovery would determine the immediate
replacement of the function H (the effects of such failure would be
far more severe for the traditional uses of H in the context of
digital signatures, public key certificates, etc.).
Note: this attack needs to be strongly contrasted with regular
collision attacks on cryptographic hash functions where no secret key
is involved and where 2**64 off-line parallelizable (!) operations
suffice to find collisions. The latter attack is approaching
feasibility [VW] while the birthday attack on HMAC is totally
impractical. (In the above examples, if one uses a hash function
with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
Krawczyk, et. al. Informational [Page 6]
RFC 2104 HMAC February 1997
A correct implementation of the above construction, the choice of
random (or cryptographically pseudorandom) keys, a secure key
exchange mechanism, frequent key refreshments, and good secrecy
protection of keys are all essential ingredients for the security of
the integrity verification mechanism provided by HMAC.
Krawczyk, et. al. Informational [Page 7]
RFC 2104 HMAC February 1997
Appendix -- Sample Code
For the sake of illustration we provide the following sample code for
the implementation of HMAC-MD5 as well as some corresponding test
vectors (the code is based on MD5 code as described in [MD5]).
/*
** Function: hmac_md5
*/
void
hmac_md5(text, text_len, key, key_len, digest)
unsigned char* text; /* pointer to data stream */
int text_len; /* length of data stream */
unsigned char* key; /* pointer to authentication key */
int key_len; /* length of authentication key */
caddr_t digest; /* caller digest to be filled in */
{
MD5_CTX context;
unsigned char k_ipad[65]; /* inner padding -
* key XORd with ipad
*/
unsigned char k_opad[65]; /* outer padding -
* key XORd with opad
*/
unsigned char tk[16];
int i;
/* if key is longer than 64 bytes reset it to key=MD5(key) */
if (key_len > 64) {
MD5_CTX tctx;
MD5Init(&tctx);
MD5Update(&tctx, key, key_len);
MD5Final(tk, &tctx);
key = tk;
key_len = 16;
}
/*
* the HMAC_MD5 transform looks like:
*
* MD5(K XOR opad, MD5(K XOR ipad, text))
*
* where K is an n byte key
* ipad is the byte 0x36 repeated 64 times
Krawczyk, et. al. Informational [Page 8]
RFC 2104 HMAC February 1997
* opad is the byte 0x5c repeated 64 times
* and text is the data being protected
*/
/* start out by storing key in pads */
bzero( k_ipad, sizeof k_ipad);
bzero( k_opad, sizeof k_opad);
bcopy( key, k_ipad, key_len);
bcopy( key, k_opad, key_len);
/* XOR key with ipad and opad values */
for (i=0; i<64; i++) {
k_ipad[i] ^= 0x36;
k_opad[i] ^= 0x5c;
}
/*
* perform inner MD5
*/
MD5Init(&context); /* init context for 1st
* pass */
MD5Update(&context, k_ipad, 64) /* start with inner pad */
MD5Update(&context, text, text_len); /* then text of datagram */
MD5Final(digest, &context); /* finish up 1st pass */
/*
* perform outer MD5
*/
MD5Init(&context); /* init context for 2nd
* pass */
MD5Update(&context, k_opad, 64); /* start with outer pad */
MD5Update(&context, digest, 16); /* then results of 1st
* hash */
MD5Final(digest, &context); /* finish up 2nd pass */
}
Test Vectors (Trailing '\0' of a character string not included in test):
key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
key_len = 16 bytes
data = "Hi There"
data_len = 8 bytes
digest = 0x9294727a3638bb1c13f48ef8158bfc9d
key = "Jefe"
data = "what do ya want for nothing?"
data_len = 28 bytes
digest = 0x750c783e6ab0b503eaa86e310a5db738
key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Krawczyk, et. al. Informational [Page 9]
RFC 2104 HMAC February 1997
key_len 16 bytes
data = 0xDDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD
data_len = 50 bytes
digest = 0x56be34521d144c88dbb8c733f0e8b3f6
Acknowledgments
Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
useful comments on early drafts, and ran the first interoperability
tests of this specification. Jeff and Pau-Chen kindly provided the
sample code and test vectors that appear in the appendix. Burt
Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
Oorschot have provided useful comments and suggestions during the
investigation of the HMAC construction.
References
[ANSI] ANSI X9.9, "American National Standard for Financial
Institution Message Authentication (Wholesale)," American
Bankers Association, 1981. Revised 1986.
[Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[BCK1] M. Bellare, R. Canetti, and H. Krawczyk,
"Keyed Hash Functions and Message Authentication",
Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
(http://www.research.ibm.com/security/keyed-md5.html)
[BCK2] M. Bellare, R. Canetti, and H. Krawczyk,
"Pseudorandom Functions Revisited: The Cascade Construction",
Proceedings of FOCS'96.
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack",
RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.html
[PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash
functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
Lecture Notes in Computer Science, Springer-Verlag Vol.963,
1995, pp. 1-14.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
Krawczyk, et. al. Informational [Page 10]
RFC 2104 HMAC February 1997
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
1982.
[RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
strengthened version of RIPEMD", Fast Software Encryption,
LNCS Vol 1039, pp. 71-82.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[Tsu] G. Tsudik, "Message authentication with one-way hash
functions", In Proceedings of Infocom'92, May 1992.
(Also in "Access Control and Policy Enforcement in
Internetworks", Ph.D. Dissertation, Computer Science
Department, University of Southern California, April 1991.)
[VW] P. van Oorschot and M. Wiener, "Parallel Collision
Search with Applications to Hash Functions and Discrete
Logarithms", Proceedings of the 2nd ACM Conf. Computer and
Communications Security, Fairfax, VA, November 1994.
Authors' Addresses
Hugo Krawczyk
IBM T.J. Watson Research Center
P.O.Box 704
Yorktown Heights, NY 10598
EMail: [email protected]
Mihir Bellare
Dept of Computer Science and Engineering
Mail Code 0114
University of California at San Diego
9500 Gilman Drive
La Jolla, CA 92093
EMail: [email protected]
Ran Canetti
IBM T.J. Watson Research Center
P.O.Box 704
Yorktown Heights, NY 10598
EMail: [email protected]
Krawczyk, et. al. Informational [Page 11]
doc/ikev2/[RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt
-1795
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt
-4819
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC2409] - The Internet Key Exchange (IKE).txt
-2299
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt
-3083
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC2437] - PKCS #1 RSA Cryptography Specifications Version 2.0.txt
-2187
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC3280] - x509 Certificates.txt
-7227
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC3526] - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE).txt
-563
View File
@@ -1,563 +0,0 @@
Network Working Group T. Kivinen
Request for Comments: 3526 M. Kojo
Category: Standards Track SSH Communications Security
May 2003
More Modular Exponential (MODP) Diffie-Hellman groups
for Internet Key Exchange (IKE)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines new Modular Exponential (MODP) Groups for the
Internet Key Exchange (IKE) protocol. It documents the well known
and used 1536 bit group 5, and also defines new 2048, 3072, 4096,
6144, and 8192 bit Diffie-Hellman groups numbered starting at 14.
The selection of the primes for theses groups follows the criteria
established by Richard Schroeppel.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
2. 1536-bit MODP Group . . . . . . . . . . . . . . . . . . . 3
3. 2048-bit MODP Group . . . . . . . . . . . . . . . . . . . 3
4. 3072-bit MODP Group . . . . . . . . . . . . . . . . . . . 4
5. 4096-bit MODP Group . . . . . . . . . . . . . . . . . . . 5
6. 6144-bit MODP Group . . . . . . . . . . . . . . . . . . . 6
7. 8192-bit MODP Group . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 8
10. Normative References. . . . . . . . . . . . . . . . . . . 8
11. Non-Normative References. . . . . . . . . . . . . . . . . 8
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . 9
13. Full Copyright Statement. . . . . . . . . . . . . . . . . 10
Kivinen & Kojo Standards Track [Page 1]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
1. Introduction
One of the important protocol parameters negotiated by Internet Key
Exchange (IKE) [RFC-2409] is the Diffie-Hellman "group" that will be
used for certain cryptographic operations. IKE currently defines 4
groups. These groups are approximately as strong as a symmetric key
of 70-80 bits.
The new Advanced Encryption Standard (AES) cipher [AES], which has
more strength, needs stronger groups. For the 128-bit AES we need
about a 3200-bit group [Orman01]. The 192 and 256-bit keys would
need groups that are about 8000 and 15400 bits respectively. Another
source [RSA13] [Rousseau00] estimates that the security equivalent
key size for the 192-bit symmetric cipher is 2500 bits instead of
8000 bits, and the equivalent key size 256-bit symmetric cipher is
4200 bits instead of 15400 bits.
Because of this disagreement, we just specify different groups
without specifying which group should be used with 128, 192 or 256-
bit AES. With current hardware groups bigger than 8192-bits being
too slow for practical use, this document does not provide any groups
bigger than 8192-bits.
The exponent size used in the Diffie-Hellman must be selected so that
it matches other parts of the system. It should not be the weakest
link in the security system. It should have double the entropy of
the strength of the entire system, i.e., if you use a group whose
strength is 128 bits, you must use more than 256 bits of randomness
in the exponent used in the Diffie-Hellman calculation.
Kivinen & Kojo Standards Track [Page 2]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
2. 1536-bit MODP Group
The 1536 bit MODP group has been used for the implementations for
quite a long time, but was not defined in RFC 2409 (IKE).
Implementations have been using group 5 to designate this group, we
standardize that practice here.
The prime is: 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
The generator is: 2.
3. 2048-bit MODP Group
This group is assigned id 14.
This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
The generator is: 2.
Kivinen & Kojo Standards Track [Page 3]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
4. 3072-bit MODP Group
This group is assigned id 15.
This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
The generator is: 2.
Kivinen & Kojo Standards Track [Page 4]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
5. 4096-bit MODP Group
This group is assigned id 16.
This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFF
The generator is: 2.
Kivinen & Kojo Standards Track [Page 5]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
6. 6144-bit MODP Group
This group is assigned id 17.
This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] + 929484 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
6DCC4024 FFFFFFFF FFFFFFFF
The generator is: 2.
7. 8192-bit MODP Group
This group is assigned id 18.
This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] + 4743158 }
Kivinen & Kojo Standards Track [Page 6]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD
F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831
179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B
DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF
5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6
D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3
23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328
06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C
DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE
12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4
38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300
741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568
3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B
4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A
062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36
4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1
B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92
4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47
9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
The generator is: 2.
Kivinen & Kojo Standards Track [Page 7]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
8. Security Considerations
This document describes new stronger groups to be used in IKE. The
strengths of the groups defined here are always estimates and there
are as many methods to estimate them as there are cryptographers.
For the strength estimates below we took the both ends of the scale
so the actual strength estimate is likely between the two numbers
given here.
+--------+----------+---------------------+---------------------+
| Group | Modulus | Strength Estimate 1 | Strength Estimate 2 |
| | +----------+----------+----------+----------+
| | | | exponent | | exponent |
| | | in bits | size | in bits | size |
+--------+----------+----------+----------+----------+----------+
| 5 | 1536-bit | 90 | 180- | 120 | 240- |
| 14 | 2048-bit | 110 | 220- | 160 | 320- |
| 15 | 3072-bit | 130 | 260- | 210 | 420- |
| 16 | 4096-bit | 150 | 300- | 240 | 480- |
| 17 | 6144-bit | 170 | 340- | 270 | 540- |
| 18 | 8192-bit | 190 | 380- | 310 | 620- |
+--------+----------+---------------------+---------------------+
9. IANA Considerations
IKE [RFC-2409] defines 4 Diffie-Hellman Groups, numbered 1 through 4.
This document defines a new group 5, and new groups from 14 to 18.
Requests for additional assignment are via "IETF Consensus" as
defined in RFC 2434 [RFC-2434]. Specifically, new groups are
expected to be documented in a Standards Track RFC.
10. Normative References
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
11. Non-Normative References
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-
197.{ps,pdf}
Kivinen & Kojo Standards Track [Page 8]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
[RFC-2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[Orman01] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", Work in
progress.
[RSA13] Silverman, R. "RSA Bulleting #13: A Cost-Based Security
Analysis of Symmetric and Asymmetric Key Lengths", April
2000, http://www.rsasecurity.com/rsalabs/bulletins/
bulletin13.html
[Rousseau00] Rousseau, F. "New Time and Space Based Key Size
Equivalents for RSA and Diffie-Hellman", December 2000,
http://www.sandelman.ottawa.on.ca/ipsec/2000/12/
msg00045.html
12. Authors' Addresses
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
EMail: [email protected]
Mika Kojo
HELSINKI
Finland
EMail: [email protected]
Kivinen & Kojo Standards Track [Page 9]
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kivinen & Kojo Standards Track [Page 10]
doc/ikev2/[RFC4301] - Security Architecture for the Internet Protocol.txt
-5659
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC4306] - Internet Key Exchange (IKEv2) Protocol.txt
-5547
View File
File diff suppressed because it is too large Load Diff
doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt
-339
View File
@@ -1,339 +0,0 @@
Network Working Group J. Schiller
Request for Comments: 4307 Massachusetts Institute of Technology
Category: Standards Track December 2005
Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Internet Key
Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
which algorithms should be used in any given association. However,
to ensure interoperability between disparate implementations, it is
necessary to specify a set of mandatory-to-implement algorithms to
ensure that there is at least one algorithm that all implementations
will have available. This document defines the current set of
algorithms that are mandatory to implement as part of IKEv2, as well
as algorithms that should be implemented because they may be promoted
to mandatory at some future time.
1. Introduction
The Internet Key Exchange protocol provides for the negotiation of
cryptographic algorithms between both endpoints of a cryptographic
association. Different implementations of IPsec and IKE may provide
different algorithms. However, the IETF desires that all
implementations should have some way to interoperate. In particular,
this requires that IKE define a set of mandatory-to-implement
algorithms because IKE itself uses such algorithms as part of its own
negotiations. This requires that some set of algorithms be specified
as "mandatory-to-implement" for IKE.
Schiller Standards Track [Page 1]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
The nature of cryptography is that new algorithms surface
continuously and existing algorithms are continuously attacked. An
algorithm believed to be strong today may be demonstrated to be weak
tomorrow. Given this, the choice of mandatory-to-implement algorithm
should be conservative so as to minimize the likelihood of it being
compromised quickly. Thought should also be given to performance
considerations as many uses of IPsec will be in environments where
performance is a concern.
Finally, we need to recognize that the mandatory-to-implement
algorithm(s) may need to change over time to adapt to the changing
world. For this reason, the selection of mandatory-to-implement
algorithms was removed from the main IKEv2 specification and placed
in this document. As the choice of algorithm changes, only this
document should need to be updated.
Ideally, the mandatory-to-implement algorithm of tomorrow should
already be available in most implementations of IPsec by the time it
is made mandatory. To facilitate this, we will attempt to identify
those algorithms (that are known today) in this document. There is
no guarantee that the algorithms we believe today may be mandatory in
the future will in fact become so. All algorithms known today are
subject to cryptographic attack and may be broken in the future.
2. Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
"MAY" that appear in this document are to be interpreted as described
in [RFC2119].
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at
some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future
version of this document.
MUST- This term means the same as MUST. However, we expect at
some point that this algorithm will no longer be a MUST in
a future document. Although its status will be determined
at a later time, it is reasonable to expect that if a
future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD-.
Schiller Standards Track [Page 2]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
3. Algorithm Selection
3.1. IKEv2 Algorithm Selection
3.1.1. Encrypted Payload Algorithms
The IKEv2 Encrypted Payload requires both a confidentiality algorithm
and an integrity algorithm. For confidentiality, implementations
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For
integrity, HMAC-SHA1 MUST be implemented.
3.1.2. Diffie-Hellman Groups
There are several Modular Exponential (MODP) groups that are defined
for use in IKEv2. They are defined in both the [IKEv2] base document
and in the MODP extensions document. They are identified by group
number. Any groups not listed here are considered as "MAY be
implemented".
Group Number Bit Length Status Defined
2 1024 MODP Group MUST- [RFC2409]
14 2048 MODP Group SHOULD+ [RFC3526]
3.1.3. IKEv2 Transform Type 1 Algorithms
IKEv2 defines several possible algorithms for Transfer Type 1
(encryption). These are defined below with their implementation
status.
Name Number Defined In Status
RESERVED 0
ENCR_3DES 3 [RFC2451] MUST-
ENCR_NULL 11 [RFC2410] MAY
ENCR_AES_CBC 12 [AES-CBC] SHOULD+
ENCR_AES_CTR 13 [AES-CTR] SHOULD
3.1.4. IKEv2 Transform Type 2 Algorithms
Transfer Type 2 Algorithms are pseudo-random functions used to
generate random values when needed.
Name Number Defined In Status
RESERVED 0
PRF_HMAC_MD5 1 [RFC2104] MAY
PRF_HMAC_SHA1 2 [RFC2104] MUST
PRF_AES128_CBC 4 [AESPRF] SHOULD+
Schiller Standards Track [Page 3]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
3.1.5. IKEv2 Transform Type 3 Algorithms
Transfer Type 3 Algorithms are Integrity algorithms used to protect
data against tampering.
Name Number Defined In Status
NONE 0
AUTH_HMAC_MD5_96 1 [RFC2403] MAY
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
4. Security Considerations
The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that
there are no non-cryptographic ways to bypass the security of the
overall system.
This document concerns itself with the selection of cryptographic
algorithms for the use of IKEv2, specifically with the selection of
"mandatory-to-implement" algorithms. The algorithms identified in
this document as "MUST implement" or "SHOULD implement" are not known
to be broken at the current time, and cryptographic research so far
leads us to believe that they will likely remain secure into the
foreseeable future. However, this isn't necessarily forever. We
would therefore expect that new revisions of this document will be
issued from time to time that reflect the current best practice in
this area.
5. Normative References
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
Schiller Standards Track [Page 4]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998.
[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 3664, January
2004.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", RFC 2404, November 1998.
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", RFC 3566, September
2003.
Author's Address
Jeffrey I. Schiller
Massachusetts Institute of Technology
Room W92-190
77 Massachusetts Avenue
Cambridge, MA 02139-4307
USA
Phone: +1 (617) 253-0161
EMail: [email protected]
Schiller Standards Track [Page 5]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schiller Standards Track [Page 6]
doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdf
BIN
View File
Binary file not shown.
doc/impl.notes
-127
View File
@@ -1,127 +0,0 @@
Introduction
This document is some quick notes to sophisticated implementors, on topics
which are a bit too arcane to be mentioned in the install instructions.
Beware that it is not updated very often, and may be behind the times.
This file is RCSID $Id: impl.notes,v 1.1 2004/03/15 20:35:21 as Exp $
Where are things?
If your kernel sources are not located in /usr/src/linux, or local manual
pages are not in /usr/local/man/man[1-8], you've got a problem. You may
be able to get around it to some extent just by modifying the top-level
Makefile, but we don't promise. For a different manpage location, that
will probably suffice; for a different kernel location, probably not.
We'd welcome reports of what needs to be fixed for this.
Cross-compiling
At the moment, this distribution makes no attempt to support building
the software on one machine for use on another. That's hard, especially
since the Linux kernel sources are not set up for it at all.
One thing at a time
(CAUTION: This is somewhat outdated. It's retained because it may be a
useful guide for experts. Consult the Makefile for current details.)
If you want to do the build and install one step at a time, instead of
using the prepackaged make commands like "make menugo", do the following
instead. (We do things in a slightly different order here, to avoid
unnecessary directory changing.)
To fit the kernel part of KLIPS into the kernel sources, do:
make insert
(This makes a symbolic link /usr/src/linux/net/ipsec, pointing to the
KLIPS source directory. It patches some kernel files, where necessary, to
know about KLIPS and/or to fix bugs. It adds a default configuration to
the kernel configuration file. Finally, it makes the KLIPS communication
file, /dev/ipsec, if it's not already there.)
Build the libraries, Pluto, and various user-level utilities:
make programs
Install the Pluto daemon and user-level utilities, and set things up for
boot-time startup:
make install
Configure the kernel:
cd /usr/src/linux
make menuconfig # (or xconfig, or whatever)
See the configuration step of INSTALL for details of what to do within
the configuration program. Don't forget to save the results.
Go through the usual kernel make process (still in /usr/src/linux):
make dep clean zImage
Caution: the Linux kernel Makefiles are not always careful about checking
for errors. We recommend capturing the output of this step and searching
it for any occurrence of "error", "Error", etc. The details of how to do
so are unfortunately somewhat shell-dependent, although if you are using
the standard shell (rather than csh, tcsh, etc.), this would do:
make dep clean zImage 2>&1 | tee junk
egrep -i error junk # no output is good output
(One glitch here is that the word "error" can sometimes occur legitimately
in the make output. For example, the kernel math emulation package has a
source file "errors.c". Some judgement is required to ignore such false
alarms.) The prepackaged make commands do all this for you.
If your kernel is using loadable modules, you'll also need to do:
make modules
Now you need to install the resulting kernel. If you're not using the
kernel's "make install" -- many people aren't -- then you need to do your
usual install procedure. You might want to read doc/kernel.notes, which
recounts some of our experiences with RedHat 5.2 kernel installation in
particular.
If "make install" is good enough for you, then:
make install
(Same comments on error checking as in previous step.) If your kernel is
using loadable modules, you'll also need to do:
make modules_install
Finally, go back to INSTALL for the remaining steps.
Klips as a module
It is possible to run Klips as a kernel module, meaning that it does not
have to be loaded until needed. Formerly this was necessary, in fact,
because Klips wouldn't run any other way. Now it will, and we recommend
static linking ("y", not "m", to the configuration question) for security.
Klips is not terribly large (tens of KB, not hundreds) and should not
cause size problems unless your kernel is already pushing the limits.
However, Klips does still run as a module, if you want (although beware
that we don't test this option very often). "ipsec setup start" and
"ipsec setup stop" load and unload it as appropriate, and you should not
need to do anything about that yourself.
Old Red Hats
Our development is currently on a mix of Red Hat 6.2 and 7.1, with 6.2
fading fast. Our older Red Hats have been retired, and although FreeS/WAN
should still work on them, we no longer make any attempt to ensure that.
doc/index.html
-55
View File
@@ -1,55 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html">
<title>FreeS/WAN index</title>
<meta name="keywords"
content="Linux, IPsec, VPN, security, encryption, cryptography, FreeS/WAN, FreeSWAN">
<!--
Written by Claudia Schmeing for the Linux FreeS/WAN project
Freely distributable under the GNU General Public License
More information at www.freeswan.org
Feedback to [email protected]
CVS information:
RCS ID: $Id: index.html,v 1.1 2004/03/15 20:35:21 as Exp $
Last changed: $Date: 2004/03/15 20:35:21 $
Revision number: $Revision: 1.1 $
CVS revision numbers do not correspond to FreeS/WAN release numbers.
-->
</head>
<body>
<h1>FreeS/WAN documentation</h1>
<ul>
<li><a href="intro.html">Introduction</a></li>
<li><a href="upgrading.html">Upgrading to 2.x</a></li>
</ul>
<ul>
<li><a href="quickstart.html">Quickstart guide to Opportunistic Encryption</a></li>
<li><a href="install.html">Installing</a></li>
<li><a href="config.html">Configuring</a></li>
<li><a href="policygroups.html">Policy Groups</a>
</li>
<li><a href="interop.html">Interoperating</a>
<FONT COLOR="#FF0000">New and improved!</FONT></li>
<li><a href="faq.html">FAQ</a></li>
<li><a href="trouble.html">Troubleshooting and problem reporting</a></li>
</ul>
<ul>
<li><a href="toc.html">Full table of contents, with much more</a></li>
<li><a href="HowTo.html">All our docs as one big file</a></li>
</ul>
<p>For technical support and other questions, use our <a
href="mail.html">mailing lists</a>.</p>
<pre> This index last changed: $Date: 2004/03/15 20:35:21 $</pre>
</body>
</html>
doc/install.html
-286
View File
@@ -1,286 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="adv_config.html">Previous</A>
<A HREF="config.html">Next</A>
<HR>
<H1><A name="install">Installing FreeS/WAN</A></H1>
<P>This document will teach you how to install Linux FreeS/WAN. If your
distribution comes with Linux FreeS/WAN, we offer tips to get you
started.</P>
<H2><A NAME="15_1">Requirements</A></H2>
<P>To install FreeS/WAN you must:</P>
<UL>
<LI>be running Linux with the 2.4 or 2.2 kernel series. See this<A HREF="http://www.freeswan.ca/download.php#contact">
kernel compatibility table</A>.
<BR>We also have experimental support for 2.6 kernels. Here are two
basic approaches:
<UL>
<LI> install FreeS/WAN, including its<A HREF="ipsec.html#parts"> KLIPS</A>
kernel code. This will remove the native IPsec stack and replace it
with KLIPS.</LI>
<LI> install the FreeS/WAN<A HREF="ipsec.html#parts"> userland tools</A>
(keying daemon and supporting scripts) for use with<A HREF="http://lartc.org/howto/lartc.ipsec.html">
2.6 kernel native IPsec</A>,</LI>
</UL>
See also these<A HREF="2.6.known-issues"> known issues with 2.6</A>.</LI>
<LI>have root access to your Linux box</LI>
<LI>choose the version of FreeS/WAN you wish to install based on<A HREF="http://www.freeswan.org/mail.html">
mailing list reports</A>
<!-- or
our updates page (coming soon)-->
</LI>
</UL>
<H2><A NAME="15_2">Choose your install method</A></H2>
<P>There are three basic ways to get FreeS/WAN onto your system:</P>
<UL>
<LI>activating and testing a FreeS/WAN that<A HREF="#distroinstall">
shipped with your Linux distribution</A></LI>
<LI><A HREF="#rpminstall">RPM install</A></LI>
<LI><A HREF="#srcinstall">Install from source</A></LI>
</UL>
<A NAME="distroinstall"></A>
<H2><A NAME="15_3">FreeS/WAN ships with some Linuxes</A></H2>
<P>FreeS/WAN comes with<A HREF="intro.html#distwith"> these
distributions</A>.</P>
<P>If you're running one of these, include FreeS/WAN in the choices you
make during installation, or add it later using the distribution's
tools.</P>
<H3><A NAME="15_3_1">FreeS/WAN may be altered...</A></H3>
<P>Your distribution may have integrated extra features, such as Andreas
Steffen's X.509 patch, into FreeS/WAN. It may also use custom startup
script locations or directory names.</P>
<H3><A NAME="15_3_2">You might need to create an authentication keypair</A>
</H3>
<P>If your FreeS/WAN came with your distribution, you may wish to
generate a fresh RSA key pair. FreeS/WAN will use these keys for
authentication.</P>
<P> To do this, become root, and type:</P>
<PRE> ipsec newhostkey --output /etc/ipsec.secrets --hostname xy.example.com
chmod 600 /etc/ipsec.secrets</PRE>
<P>where you replace xy.example.com with your machine's fully-qualified
domain name. Generate some randomness, for example by wiggling your
mouse, to speed the process.</P>
<P>The resulting ipsec.secrets looks like:</P>
<PRE>: RSA {
# RSA 2192 bits xy.example.com Sun Jun 8 13:42:19 2003
# for signatures only, UNSAFE FOR ENCRYPTION
#pubkey=0sAQOFppfeE3cC7wqJi...
Modulus: 0x85a697de137702ef0...
# everything after this point is secret
PrivateExponent: 0x16466ea5033e807...
Prime1: 0xdfb5003c8947b7cc88759065...
Prime2: 0x98f199b9149fde11ec956c814...
Exponent1: 0x9523557db0da7a885af90aee...
Exponent2: 0x65f6667b63153eb69db8f300dbb...
Coefficient: 0x90ad00415d3ca17bebff123413fc518...
}
# do not change the indenting of that &quot;}&quot;</PRE>
<P>In the actual file, the strings are much longer.</P>
<H3><A NAME="15_3_3">Start and test FreeS/WAN</A></H3>
<P>You can now<A HREF="install.html#starttest"> start FreeS/WAN and test
whether it's been successfully installed.</A>.</P>
<A NAME="rpminstall"></A>
<H2><A NAME="15_4">RPM install</A></H2>
<P>These instructions are for a recent Red Hat with a stock Red Hat
kernel. We know that Mandrake and SUSE also produce FreeS/WAN RPMs. If
you're running either, install using your distribution's tools.</P>
<H3><A NAME="15_4_1">Download RPMs</A></H3>
<P>Decide which functionality you need:</P>
<UL>
<LI>standard FreeS/WAN RPMs. Use these shortcuts:
<BR>
<UL>
<LI>(for 2.6 kernels: userland only)
<BR> ncftpget
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/\*userland*
</LI>
<LI>(for 2.4 kernels)
<BR> ncftpget
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r
| tr -d 'a-wy-z'`/\*</LI>
<LI> or view all the offerings at our<A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs">
FTP site</A>.</LI>
</UL>
</LI>
<LI>unofficial<A href="http://www.freeswan.ca/download.php"> Super
FreeS/WAN</A> RPMs, which include Andreas Steffen's X.509 patch and
more. Super FreeS/WAN RPMs do not currently include<A HREF="glossary.html#NAT.gloss">
Network Address Translation</A> (NAT) traversal, but Super FreeS/WAN
source does.</LI>
</UL>
<A NAME="2.6.rpm"></A>
<P>For 2.6 kernels, get the latest FreeS/WAN userland RPM, for example:</P>
<PRE> freeswan-userland-2.04.9-0.i386.rpm</PRE>
<P>Note: FreeS/WAN's support for 2.6 kernel IPsec is preliminary. Please
see<A HREf="2.6.known-issues"> 2.6.known-issues</A>, and the latest<A HREF="http://www.freeswan.org/mail.html">
mailing list reports</A>.</P>
<P>Change to your new FreeS/WAN directory, and make and install the</P>
<P>For 2.4 kernels, get both kernel and userland RPMs. Check your kernel
version with</P>
<PRE> uname -r</PRE>
<P>Get a kernel module which matches that version. For example:</P>
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm</PRE>
<P>Note: These modules<B> will only work on the Red Hat kernel they were
built for</B>, since they are very sensitive to small changes in the
kernel.</P>
<P>Get FreeS/WAN utilities to match. For example:</P>
<PRE> freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm</PRE>
<H3><A NAME="15_4_2">For freeswan.org RPMs: check signatures</A></H3>
<P>While you're at our ftp site, grab the RPM signing key</P>
<PRE> freeswan-rpmsign.asc</PRE>
<P>If you're running RedHat 8.x or later, import this key into the RPM
database:</P>
<PRE> rpm --import freeswan-rpmsign.asc</PRE>
<P>For RedHat 7.x systems, you'll need to add it to your<A HREF="glossary.html#PGP">
PGP</A> keyring:</P>
<PRE> pgp -ka freeswan-rpmsign.asc</PRE>
<P>Check the digital signatures on both RPMs using:</P>
<PRE> rpm --checksig freeswan*.rpm </PRE>
<P>You should see that these signatures are good:</P>
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK</PRE>
<H3><A NAME="15_4_3">Install the RPMs</A></H3>
<P>Become root:</P>
<PRE> su</PRE>
<P>For a first time install, use:</P>
<PRE> rpm -ivh freeswan*.rpm</PRE>
<P>To upgrade existing RPMs (and keep all .conf files in place), use:</P>
<PRE> rpm -Uvh freeswan*.rpm</PRE>
<P>If you're upgrading from FreeS/WAN 1.x to 2.x RPMs, and encounter
problems, see<A HREF="upgrading.html#upgrading.rpms"> this note</A>.</P>
<H3><A NAME="15_4_4">Start and Test FreeS/WAN</A></H3>
<P>Now,<A HREF="install.html#starttest"> start FreeS/WAN and test your
install</A>.</P>
<A NAME="srcinstall"></A>
<H2><A NAME="15_5">Install from Source</A></H2>
<!-- Most of this section, along with "Start and Test", can replace
INSTALL. -->
<H3><A NAME="15_5_1">Decide what functionality you need</A></H3>
<P>Your choices are:</P>
<UL>
<LI><A HREF="ftp://ftp.xs4all.nl/pub/crypto/freeswan">standard FreeS/WAN</A>
,</LI>
<LI>standard FreeS/WAN plus any of these<A HREF="web.html#patch">
user-supported patches</A>, or</LI>
<LI><A HREF="http://www.freeswan.ca/download">Super FreeS/WAN</A>, an
unofficial FreeS/WAN pre-patched with many of the above. Provides
additional algorithms, X.509, SA deletion, dead peer detection, and<A HREF="glossary.html#NAT.gloss">
Network Address Translation</A> (NAT) traversal.</LI>
</UL>
<H3><A NAME="15_5_2">Download FreeS/WAN</A></H3>
<P>Download the source tarball you've chosen, along with any patches.</P>
<H3><A NAME="15_5_3">For freeswan.org source: check its signature</A></H3>
<P>While you're at our ftp site, get our source signing key</P>
<PRE> freeswan-sigkey.asc</PRE>
<P>Add it to your PGP keyring:</P>
<PRE> pgp -ka freeswan-sigkey.asc</PRE>
<P>Check the signature using:</P>
<PRE> pgp freeswan-2.04.tar.gz.sig freeswan-2.04.tar.gz</PRE>
<P>You should see something like:</P>
<PRE> Good signature from user &quot;Linux FreeS/WAN Software Team ([email protected])&quot;.
Signature made 2002/06/26 21:04 GMT using 2047-bit key, key ID 46EAFCE1</PRE>
<!-- Note to self: [email protected] has angled brackets in the original.
Changed because it conflicts with HTML tags. -->
<H3><A NAME="15_5_4">Untar, unzip</A></H3>
<P>As root, unpack your FreeS/WAN source into<VAR> /usr/src</VAR>.</P>
<PRE> su
mv freeswan-2.04.tar.gz /usr/src
cd /usr/src
tar -xzf freeswan-2.04.tar.gz
</PRE>
<H3><A NAME="15_5_5">Patch if desired</A></H3>
<P>Now's the time to add any patches. The contributor may have special
instructions, or you may simply use the patch command.</P>
<H3><A NAME="15_5_6">... and Make</A></H3>
<P>Choose one of the methods below.</P>
<H4>Userland-only Install for 2.6 kernels</H4>
<A NAME="2.6.src"></A>
<P>Note: FreeS/WAN's support for 2.6 kernel IPsec is preliminary. Please
see<A HREf="2.6.known-issues"> 2.6.known-issues</A>, and the latest<A HREF="http://www.freeswan.org/mail.html">
mailing list reports</A>.</P>
<P>Change to your new FreeS/WAN directory, and make and install the
FreeS/WAN userland tools.</P>
<PRE> cd /usr/src/freeswan-2.04
make programs
make install</PRE>
<P>Now,<A HREF="install.html#starttest"> start FreeS/WAN and test your
install</A>.</P>
<H4>KLIPS install for 2.2, 2.4, or 2.6 kernels</H4>
<A NAME="modinstall"></A>
<P>To make a modular version of KLIPS, along with other FreeS/WAN
programs you'll need, use the command sequence below. This will change
to your new FreeS/WAN directory, make the FreeS/WAN module (and other
stuff), and install it all.</P>
<PRE> cd /usr/src/freeswan-2.04
make oldmod
make minstall</PRE>
<P><A HREF="install.html#starttest">Start FreeS/WAN and test your
install</A>.</P>
<P>To link KLIPS statically into your kernel (using your old kernel
settings), and install other FreeS/WAN components, do:</P>
<PRE> cd /usr/src/freeswan-2.04
make oldmod
make minstall</PRE>
<P>Reboot your system and<A HREF="install.html#testonly"> test your
install</A>.</P>
<P>For other ways to compile KLIPS, see our Makefile.</P>
<A name="starttest"></A>
<H2><A NAME="15_6">Start FreeS/WAN and test your install</A></H2>
<P>Bring FreeS/WAN up with:</P>
<PRE> service ipsec start</PRE>
<P>This is not necessary if you've rebooted.</P>
<A name="testonly"></A>
<H2><A NAME="15_7">Test your install</A></H2>
<P>To check that you have a successful install, run:</P>
<PRE> ipsec verify</PRE>
<P>You should see at least:</P>
<PRE>
Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
</PRE>
<P>If any of these first four checks fails, see our<A href="trouble.html#install.check">
troubleshooting guide</A>.</P>
<H2><A NAME="15_8">Making FreeS/WAN play well with others</A></H2>
<P>There are at least a couple of things on your system that might
interfere with FreeS/WAN, and now's a good time to check these:</P>
<UL>
<LI>Firewalling. You need to allow UDP 500 through your firewall, plus
ESP (protocol 50) and AH (protocol 51). For more information, see our
updated firewalls document (coming soon).</LI>
<LI>Network address translation. Do not NAT the packets you will be
tunneling.</LI>
</UL>
<H2><A NAME="15_9">Configure for your needs</A></H2>
<P>You'll need to configure FreeS/WAN for your local site. Have a look
at our<A HREF="quickstart.html"> opportunism quickstart guide</A> to
see if that easy method is right for your needs. Or, see how to<A HREF="config.html">
configure a network-to-network or Road Warrior style VPN</A>.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="adv_config.html">Previous</A>
<A HREF="config.html">Next</A>
</BODY>
</HTML>
doc/interop.html
-983
View File
@@ -1,983 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="compat.html">Previous</A>
<A HREF="performance.html">Next</A>
<HR>
<A NAME="interop"></A>
<H1><A NAME="10">Interoperating with FreeS/WAN</A></H1>
<P>The FreeS/WAN project needs you! We rely on the user community to
keep up to date. Mail [email protected] with your interop
success stories.</P>
<P><STRONG>Please note</STRONG>: Most of our interop examples feature
Linux FreeS/WAN 1.x config files. You can convert them to 2.x files
fairly easily with the patch in our<A HREF="upgrading.html#ipsec.conf_v2">
Upgrading Guide</A>.</P>
<H2><A NAME="10_1">Interop at a Glance</A></H2>
<TABLE BORDER="1">
<TR><TD>&nbsp;</TD><TD colspan="5">FreeS/WAN VPN</TD><TD>Road Warrior</TD><TD>
OE</TD></TR>
<TR><TD>&nbsp;</TD><TD>PSK</TD><TD>RSA Secret</TD><TD>X.509
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
NAT-Traversal
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
Manual
<BR>Keying</TD><TD>&nbsp;</TD><TD>&nbsp;</TD></TR>
<TR><TD colspan="8">More Compatible</TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="web.html#freeswan">FreeS/WAN</A><A NAME="freeswan.top">
&nbsp;</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#isakmpd">isakmpd (OpenBSD)</A><A NAME="isakmpd.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>
<FONT color="#cc0000">No&nbsp;&nbsp;&nbsp;&nbsp;</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#kame">Kame (FreeBSD,
<BR> NetBSD, MacOSX)
<BR> <SMALL>aka racoon</SMALL></A><A NAME="kame.top"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#mcafee">McAfee VPN
<BR><SMALL>was PGPNet</SMALL></A><A NAME="mcafee.top"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#microsoft">Microsoft
<BR> Windows 2000/XP</A><A NAME="microsoft.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="glossary.html#ssh">SSH Sentinel</A><A NAME="ssh.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#safenet">Safenet SoftPK
<BR>/SoftRemote</A><A NAME="safenet.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<TR><TD colspan="8">Other</TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#6wind">6Wind</A><A NAME="6wind.top"> &nbsp;</A></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#alcatel">Alcatel Timestep</A><A NAME="alcatel.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#apple">Apple Macintosh
<BR>System 10+</A><A NAME="apple.top"> &nbsp;</A></TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#ashleylaurent">AshleyLaurent
<BR> VPCom</A><A NAME="ashleylaurent.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#borderware">Borderware</A><A NAME="borderware.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!--
http://www.cequrux.com/vpn-guides.php3
"coming soon" guide to connect with FreeS/WAN.
-->
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#checkpoint">Check Point FW-1/VPN-1</A><A NAME="checkpoint.top">
&nbsp;</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#cisco">Cisco with 3DES</A><A NAME="cisco.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT>
</TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#equinux">Equinux VPN Tracker
<BR> (for Mac OS X)</A><A NAME="equinux.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#fsecure">F-Secure</A><A NAME="fsecure.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#gauntlet">Gauntlet GVPN</A><A NAME="gauntlet.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#aix">IBM AIX</A><A NAME="aix.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#as400">IBM AS/400</A><A NAME="as400"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#intel">Intel Shiva
<BR>LANRover/Net Structure</A><A NAME="intel.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#lancom">LanCom (formerly ELSA)</A><A NAME="lancom.top">
&nbsp;</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#linksys">Linksys</A><A NAME="linksys.top"> &nbsp;</A></TD><TD>
<FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">
No</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#lucent">Lucent</A><A NAME="lucent.top"> &nbsp;</A></TD><TD><FONT
color="#cccc00">Partial</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netasq">Netasq</A><A NAME="netasq.top"> &nbsp;</A></TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netcelo">netcelo</A><A NAME="netcelo.top"> &nbsp;</A></TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netgear">Netgear fvs318</A><A NAME="netgear.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netscreen">Netscreen 100
<BR>or 5xp</A><A NAME="netscreen.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#nortel">Nortel Contivity</A><A NAME="nortel.top"> &nbsp;</A>
</TD><TD><FONT color="#cccc00">Partial</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#radguard">RadGuard</A><A NAME="radguard.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#raptor">Raptor</A><A NAME="raptor"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#redcreek">Redcreek Ravlin</A><A NAME="redcreek.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT><FONT color="#cccc00">/Partial</FONT>
</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#sonicwall">SonicWall</A><A NAME="sonicwall.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cccc00">Maybe</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#sun">Sun Solaris</A><A NAME="sun.top"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT>
</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#symantec">Symantec</A><A NAME="symantec.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#watchguard">Watchguard
<BR> Firebox</A><A NAME="watchguard.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#xedia">Xedia Access Point
<BR>/QVPN</A><A NAME="xedia.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#zyxel">Zyxel Zywall
<BR>/Prestige</A><A NAME="zyxel.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE
<TR>
<TD><A HREF="#sample">sample</A></TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD><FONT color="#cc0000">No</FONT></TD>
</TR>
-->
<TR><TD>&nbsp;</TD><TD>PSK</TD><TD>RSA Secret</TD><TD>X.509
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
NAT-Traversal
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
Manual
<BR>Keying</TD><TD>&nbsp;</TD><TD>&nbsp;</TD></TR>
<TR><TD>&nbsp;</TD><TD colspan="5">FreeS/WAN VPN</TD><TD>Road Warrior</TD><TD>
OE</TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
</TABLE>
<H3><A NAME="10_1_1">Key</A></H3>
<TABLE BORDER="1">
<TR><TD><FONT color="#00cc00">Yes</FONT></TD><TD>People report that this
works for them.</TD></TR>
<TR><TD>[Blank]</TD><TD>We don't know.</TD></TR>
<TR><TD><FONT color="#cc0000">No</FONT></TD><TD>We have reason to
believe it was, at some point, not possible to get this to work.</TD></TR>
<TR><TD><FONT color="#cccc00">Partial</FONT></TD><TD>Partial success.
For example, a connection can be created from one end only.</TD></TR>
<TR><TD><FONT color="#00cc00">Yes</FONT><FONT color="#cccc00">/Partial</FONT>
</TD><TD>Mixed reports.</TD></TR>
<TR><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>We think the answer
is &quot;yes&quot;, but need confirmation.</TD></TR>
</TABLE>
<A NAME="interoprules"></A>
<H2><A NAME="10_2">Basic Interop Rules</A></H2>
<P>Vanilla FreeS/WAN implements<A HREF="compat.html#compat"> these parts</A>
of the IPSec specifications. You can add more with<A HREF="http://www.freeswan.ca">
Super FreeS/WAN</A>, but what we offer may be enough for many users.</P>
<UL>
<LI> To use X.509 certificates with FreeS/WAN, you will need the<A HREF="http://www.strongsec.org/freeswan">
X.509 patch</A> or<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>
, which includes that patch.</LI>
<LI> To use<A HREF="glossary.html#NAT.gloss"> Network Address
Translation</A> (NAT) traversal with FreeS/WAN, you will need Arkoon
Network Security's<A HREF="http://open-source.arkoon.net"> NAT
traversal patch</A> or<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>
, which includes it.</LI>
</UL>
<P>We offer a set of proposals which is not user-adjustable, but covers
all combinations that we can offer. FreeS/WAN always proposes triple
DES encryption and Perfect Forward Secrecy (PFS). In addition, we
propose Diffie Hellman groups 5 and 2 (in that order), and MD5 and
SHA-1 hashes. We accept the same proposals, in the same order of
preference.</P>
<P>Other interop notes:</P>
<UL>
<LI> A<A HREF="http://lists.freeswan.org/archives/users/2003-September/msg00462.html">
SHA-1 bug in FreeS/WAN 2.00, 2.01 and 2.02</A> may affect some interop
scenarios. It does not affect 1.x versions, and is fixed in 2.03 and
later.</LI>
<LI> Some other implementations will close a connection with FreeS/WAN
after some time. This may be a problem with rekey lifetimes. Please see<A
HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
this tip</A> and<A HREF="http://lists.freeswan.org/pipermail/users/2001-December/005758.html">
this workaround</A>.</LI>
</UL>
<H2><A NAME="10_3">Longer Stories</A></H2>
<H3><A NAME="10_3_1">For<EM> More Compatible</EM> Implementations</A></H3>
<H4><A NAME="freeswan">FreeS/WAN</A></H4>
<P> See our documentation at<A HREF="http://www.freeswan.org">
freeswan.org</A> and the Super FreeS/WAN docs at<A HREF="http://www.freeswan.ca">
freeswan.ca</A>. Some user-written HOWTOs for FreeS/WAN-FreeS/WAN
connections are listed in<A HREF="intro.html#howto"> our Introduction</A>
.</P>
<P>See also:</P>
<UL>
<LI><A HREF="http://lugbe.ch/action/reports/ipsec_htbe.phtml"> A German
FreeS/WAN-FreeS/WAN page by Markus Wernig (X.509)</A></LI>
</UL>
<P><A HREF="#freeswan.top">Back to chart</A></P>
<H4><A NAME="isakmpd">isakmpd (OpenBSD)</A></H4>
<P><A HREF="http://www.openbsd.org/faq/faq13.html">OpenBSD FAQ: Using
IPsec</A>
<BR><A HREF="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">
Hans-Joerg Hoexer's interop Linux-OpenBSD (PSK)</A>
<BR><A HREF="http://www.segfault.net/ipsec/"> Skyper's configuration
(PSK)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A></P>
<P><A HREF="#isakmpd.top">Back to chart</A></P>
<H4><A NAME="kame">Kame</A></H4>
<UL>
<LI>For FreeBSD and NetBSD. Ships with Mac OS X; see also our<A HREF="#apple">
Mac</A> section.</LI>
<LI>Also known as<EM> racoon</EM>, its keying daemon.</LI>
</UL>
<P><A HREF="http://www.kame.net">Kame homepage, with FAQ</A>
<BR><A HREF="http://www.netbsd.org/Documentation/network/ipsec">
NetBSD's IPSec FAQ</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00560.html">
Ghislaine's post explaining some interop peculiarities</A></P>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/09/msg00511.html">
Itojun's Kame-FreeS/WAN interop tips (PSK)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2000"> Ghislaine
Labouret's French page with links to matching FreeS/WAN and Kame
configs (RSA)</A>
<BR><A HREF="http://lugbe.ch/lostfound/contrib/freebsd_router/"> Markus
Wernig's HOWTO (X.509, BSD gateway)</A>
<BR><A HREF="http://web.morgul.net/~frodo/docs/kame+freeswan_interop.html">
Frodo's Kame-FreeS/WAN interop (X.509)</A>
<BR><A HREF="http://www.wavesec.org/kame.phtml"> Kame as a WAVEsec
client.</A></P>
<P><A HREF="#kame.top">Back to chart</A></P>
<H4><A NAME="mcafee">PGPNet/McAfee</A></H4>
<P></P>
<UL>
<LI>Now called McAfee VPN Client.</LI>
<LI>PGPNet also came in a freeware version which did not support subnets</LI>
<LI>To support dhcp-over-ipsec, you need the X.509 patch, which is
included in<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>.</LI>
</UL>
<P><A HREF="http://www.freeswan.ca/docs/WindowsInterop"> Tim Carr's
Windows Interop Guide (X.509)</A>
<BR><A HREF="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html#Interop2">
Hans-Joerg Hoexer's Guide for Linux-PGPNet (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00339.html">
Kai Martius' instructions using RSA Key-Extractor Tool (RSA)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.zengl.net/freeswan/english.html">Christian
Zeng's page (RSA)</A> based on Kai's work. English or German.
<BR><A HREF="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
Oscar Delgado's PDF (X.509, no configs)</A>
<BR><A HREF="http://www-ec.njit.edu/~rxt1077/Howto.txt"> Ryan's HOWTO
for FreeS/WAN-PGPNet (X.509)</A>. Through a Linksys Router with IPsec
Passthru enabled.
<BR><A HREF="http://jixen.tripod.com/#RW-PGP-to-Fwan"> Jean-Francois
Nadeau's Practical Configuration (Road Warrior with PSK)</A>
<BR><A HREF="http://www.evolvedatacom.nl/freeswan.html#toc"> Wouter
Prins' HOWTO (Road Warrior with X.509)</A>
<BR></P>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/01/msg00271.html">
Rekeying problem with FreeS/WAN and older PGPNets</A>
<BR></P>
<P><A HREF="http://www.strongsec.com/freeswan/dhcprelay/index.htm"> DHCP
over IPSEC HOWTO for FreeS/WAN (requires X.509 and dhcprelay patches)</A>
</P>
<P><A HREF="#mcafee.top">Back to chart</A></P>
<H4><A NAME="microsoft">Microsoft Windows 2000/XP</A></H4>
<UL>
<LI>IPsec comes with Win2k, and with XP Support Tools. May require<A HREF="http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.asp">
High Encryption Pack</A>. WinXP users have also reported better results
with Service Pack 1.</LI>
<LI>The Road Warrior setup works either way round. Windows (XP or 2K)
IPsec can connect as a Road Warrior to FreeS/WAN. However, FreeS/WAN
can also successfully connect as a Road Warrior to Windows IPsec (see
Nate Carlson's configs below).</LI>
<LI>FreeS/WAN version 1.92 or later is required to avoid an
interoperation problem with Windows native IPsec. Earlier FreeS/WAN
versions did not process the Commit Bit as Windows native IPsec
expected.</LI>
</UL>
<P><A HREF="http://www.freeswan.ca/docs/WindowsInterop"> Tim Carr's
Windows Interop Guide (X.509)</A>
<BR><A HREF="http://ipsec.math.ucla.edu/services/ipsec.html"> James
Carter's instructions (X.509, NAT-T)</A>
<BR><A HREF="http://jixen.tripod.com/#Win2000-Fwan"> Jean-Francois
Nadeau's Net-net Configuration (PSK)</A>
<BR><A HREF="http://security.nta.no/freeswan-w2k.html"> Telenor's
Node-node Config (Transport-mode PSK)</A>
<BR><A HREF="http://vpn.ebootis.de"> Marcus Mueller's HOWTO using his
VPN config tool (X.509).</A> Tool also works with PSK.
<BR><A HREF="http://www.natecarlson.com/include/showpage.php?cat=linux&page=ipsec-x509">
Nate Carlson's HOWTO using same tool (Road Warrior with X.509)</A>.
Unusually, FreeS/WAN is the Road Warrior here.
<BR><A HREF="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
Oscar Delgado's PDF (X.509, no configs)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022425.html">
Tim Scannell's Windows XP Additional Checklist (X.509)</A>
<BR></P>
<!-- Note to self: Include L2TP references? -->
<P><A HREF="http://www.microsoft.com/windows2000/en/server/help/default.asp?url=/windows2000/en/server/help/sag_TCPIP_ovr_secfeatures.htm">
Microsoft's page on Win2k TCP/IP security features</A>
<BR><A HREF="http://support.microsoft.com/support/kb/articles/Q257/2/25.ASP">
Microsoft's Win2k IPsec debugging tips</A>
<BR>
<!-- Alt-URL http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257225
Perhaps newer? -->
<A HREF="http://www.wired.com/news/technology/0,1282,36336,00.html">
MS VPN may fall back to 1DES</A></P>
<P><A HREF="#microsoft.top">Back to chart</A></P>
<H4><A NAME="ssh">SSH Sentinel</A></H4>
<UL>
<LI>Popular and well tested.</LI>
<LI>Also rebranded in<A HREF="http://www.zyxel.com"> Zyxel Zywall</A>.
Our Zyxel interop notes are<A HREF="#zyxel"> here</A>.</LI>
<LI> SSH supports IPsec-over-UDP NAT traversal.</LI>
<LI>There is this<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/12/msg00370.html">
potential problem</A> if you're not using the Legacy Proposal option.</LI>
</UL>
<P><A HREF="http://www.ssh.com/support/sentinel/documents.cfm"> SSH's
Sentinel-FreeSWAN interop PDF (X.509)</A>
<BR><A HREF="http://www.nadmm.com/show.php?story=articles/vpn.inc">
Nadeem Hassan's SUSE-to-Sentinel article (Road warrior with X.509)</A>
<BR><A HREF="http://www.zerozone.it/documents/Linux/HowTo/VPN-IPsec-Freeswan-HOWTO.html">
O-Zone's Italian HOWTO (Road Warrior, X.509, DHCP)</A>
<BR></P>
<P><A HREF="#ssh.top">Back to chart</A></P>
<H4><A NAME="safenet">Safenet SoftPK/SoftRemote</A></H4>
<UL>
<LI>People recommend SafeNet as a low cost Windows client.</LI>
<LI>SoftRemote seems to be the newer name for SoftPK.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005061.html">
Whit Blauvelt's SoftRemote tips</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015591.html">
Tim Wilson's tips (X.509)</A><A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00607.html">
Workaround for a &quot;gotcha&quot;</A></P>
<P><A HREF="http://jixen.tripod.com/#Rw-IRE-to-Fwan"> Jean-Francois
Nadeau's Practical Configuration (Road Warrior with PSK)</A>
<BR><A HREF="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">
Terradon Communications' PDF (Road Warrior with PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/?????.html">
Seaan.net's PDF (Road Warrior to Subnet, with PSK)</A>
<BR><A HREF="http://www.redbaronconsulting.com/freeswan/fswansafenet.pdf">
Red Baron Consulting's PDF (Road Warrior with X.509)</A></P>
<P><A HREF="#safenet.top">Back to chart</A></P>
<H3><A NAME="10_3_2">For<EM> Other Implementations</EM></A></H3>
<H4><A NAME="6wind">6Wind</A></H4>
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A></P>
<P><A HREF="#6wind.top">Back to chart</A></P>
<H4><A NAME="alcatel">Alcatel Timestep</A></H4>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011878.html">
Alain Sabban's settings (PSK or PSK road warrior; through static NAT)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00100.html">
Derick Cassidy's configs (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/08/msg00194.html">
David Kerry's Timestep settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013711.html">
Kevin Gerbracht's ipsec.conf (X.509)</A></P>
<P><A HREF="#alcatel.top">Back to chart</A></P>
<H4><A NAME="apple">Apple Macintosh System 10+</A></H4>
<UL>
<LI>Since the system is based on FreeBSD, this should interoperate<A HREF="#kame">
just like FreeBSD</A>.</LI>
<LI> To use Appletalk over IPsec tunnels,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005116.html">
run it over TCP/IP</A>, or use Open Door Networks' Shareway IP tool,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005426.html">
described here.</A></LI>
<LI>See also the<A HREF="#equinux"> Equinux VPN Tracker</A> for Mac OS
X.</LI>
</UL>
<P><A HREF="http://ipsec.math.ucla.edu/services/ipsec.html"> James
Carter's instructions (X.509, NAT-T)</A></P>
<P><A HREF="#apple.top">Back to chart</A></P>
<H4><A NAME="ashleylaurent">AshleyLaurent VPCom</A></H4>
<P><A HREF="http://www.ashleylaurent.com/newsletter/01-28-00.htm">
Successful interop report, no details</A></P>
<P><A HREF="#ashleylaurent.top">Back to chart</A></P>
<H4><A NAME="borderware">Borderware</A></H4>
<UL>
<LI>I suspect the Borderware client is a rebranded Safenet. If that's
true, our<A HREF="#safenet"> Safenet section</A> will help.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-March/008288.html">
Philip Reetz' configs (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/09/msg00217.html">
Borderware server does not support FreeS/WAN road warriors</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007733.html">
Older Borderware may not support Diffie Hellman groups 2, 5</A>
<BR></P>
<P><A HREF="#borderware.top">Back to chart</A></P>
<H4><A NAME="checkpoint">Check Point VPN-1 or FW-1</A></H4>
<UL>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00099.html">
Caveat about IP-range inclusion on Check Point.</A></LI>
<LI> Some versions of Check Point may require an aggressive mode patch
to interoperate with FreeS/WAN.
<BR><A HREF="http://www.freeswan.ca/code/super-freeswan"> Super
FreeS/WAN</A> now features this patch.
<!--
<A HREF="http://www.freeswan.ca/patches/aggressivemode">Steve Harvey's
aggressive mode patch for FreeS/WAN 1.5</A>
-->
</LI>
<LI></LI>
<LI>A Linux FreeS/WAN-Checkpoint connection may close after some time.
Try<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
this tip</A> toward a workaround.</LI>
</UL>
<P><A HREF="http://www.fw-1.de/aerasec/ng/vpn-freeswan/CPNG+Linux-FreeSWAN.html">
AERAsec's Firewall-1 NG site (PSK, X.509, Road Warrior with X.509,
other algorithms)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.fw-1.de/aerasec/ng/vpn-freeswan/CPNG+Linux-FreeSWAN.html#support-matrix">
AERAsec's detailed Check Point-FreeS/WAN support matrix</A>
<BR><A HREF="http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/fw-linuxvpn.pdf">
Checkpoint.com PDF: Linux as a VPN Client to FW-1 (PSK)</A>
<BR><A HREF="http://www.phoneboy.com"> PhoneBoy's Check Point FAQ (on
Check Point only, not FreeS/WAN)</A>
<BR></P>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2001-August/002351.html">
Chris Harwell's tips FreeS/WAN configs (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009362.html">
Daniel Tombeil's configs (PSK)</A></P>
<P><A HREF="#checkpoint.top">Back to chart</A></P>
<H4><A NAME="cisco">Cisco</A></H4>
<UL>
<LI> Cisco supports IPsec-over-UDP NAT traversal.</LI>
<LI>Cisco VPN Client appears to use nonstandard IPsec and does not work
with FreeS/WAN.<A HREF="https://mj2.freeswan.org/archives/2003-August/maillist.html">
This message</A> concerns Cisco VPN Client 4.01.
<!-- fix link -->
</LI>
<LI>A Linux FreeS/WAN-Cisco connection may close after some time.<A HREF="http://lists.freeswan.org/pipermail/users/2001-December/005758.html">
Here</A> is a workaround, and<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
here</A> is another comment on the same subject.</LI>
<LI><A HREF="http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t2/3desips.htm">
Older Ciscos</A> purchased outside the United States may not have 3DES,
which FreeS/WAN requires.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-June/000406.html">
RSA keying may not be possible between Cisco and FreeS/WAN.</A></LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/004357.html">
In ipsec.conf, VPN3000 DN (distinguished name) must be in binary (X.509
only)</A></LI>
</UL>
<P><A HREF="http://rr.sans.org/encryption/cisco_router.php"> SANS
Institute HOWTO (PSK).</A> Detailed, with extensive references.
<BR><A HREF="http://www.worldbank.ro/IPSEC/cisco-linux.txt"> Short HOWTO
(PSK)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs for Cisco IOS, PIX and VPN 3000 (X.509)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-August/002966.html">
Dave McFerren's sample configs (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-September/003422.html">
Wolfgang Tremmel's sample configs (PSK road warrior)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00578.html">
Old doc from Pete Davis, with William Watson's updated Tips (PSK)</A>
<BR></P>
<P><STRONG>Some PIX specific information:</STRONG>
<BR><A HREF="http://www.wlug.org.nz/FreeSwanToCiscoPix"> Waikato Linux
Users' Group HOWTO. Nice detail (PSK)</A>
<BR><A HREF="http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html">
John Leach's configs (PSK)</A>
<BR><A HREF="http://www.diverdown.cc/vpn/freeswanpix.html"> Greg
Robinson's settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007901.html">
Scott's ipsec.conf for PIX (PSK, FreeS/WAN side only)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/003949.html">
Rick Trimble's PIX and FreeS/WAN settings (PSK)</A>
<BR></P>
<P><A href="http://www.cisco.com/public/support/tac"> Cisco VPN support
page</A>
<BR><A href="http://www.ieng.com/warp/public/707/index.shtml#ipsec">
Cisco IPsec information page</A></P>
<P><A HREF="#cisco.top">Back to chart</A></P>
<H4><A NAME="equinux">Equinux VPN tracker (for Mac OS X)</A></H4>
<UL>
<LI>Graphical configurator for Mac OS X IPsec. May be an interface to
the<A HREF="#apple"> native Mac OS X IPsec</A>, which is essentially<A HREF="#kame">
KAME</A>.</LI>
<LI>To use Appletalk over IPsec tunnels,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005116.html">
run it over TCP/IP</A>, or use Open Door Networks' Shareway IP tool,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005426.html">
described here.</A></LI>
</UL>
<P> Equinux provides<A HREF="http://www.equinux.com/download/HowTo_FreeSWAN.pdf">
this excellent interop PDF</A> (PSK, RSA, X.509).</P>
<P><A HREF="#equinux.top">Back to chart</A></P>
<H4><A NAME="fsecure">F-Secure</A></H4>
<UL>
<LI>
<!-- <A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007596.html"> -->
F-Secure supports IPsec-over-UDP NAT traversal.</LI>
</UL>
<P><A HREF="http://www.pingworks.de/tech/vpn/vpn.txt">pingworks.de's
&quot;Connecting F-Secure's VPN+ to Linux FreeS/WAN&quot; (PSK road warrior)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.pingworks.de/tech/vpn/vpn.pdf">Same thing
as PDF</A>
<BR><A HREF="http://www.exim.org/pipermail/linux-ipsec/Week-of-Mon-20010122/000061.html">
Success report, no detail (PSK)</A>
<BR><A HREF="http://www.exim.org/pipermail/linux-ipsec/Week-of-Mon-20010122/000041.html">
Success report, no detail (Manual)</A></P>
<!-- Other NAT traversers:
http://lists.freeswan.org/pipermail/users/2002-April/009136.html
and ssh sentinel:
http://lists.freeswan.org/pipermail/users/2001-September/003108.html
-->
<P><A HREF="#fsecure.top">Back to chart</A></P>
<H4><A NAME="gauntlet">Gauntlet GVPN</A></H4>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00535.html">
Richard Reiner's ipsec.conf (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011434.html">
Might work without that pesky firewall... (PSK)</A>
<BR>
<!-- insert archive link -->
In late July, 2003 Alexandar Antik reported success interoperating
with Gauntlet 6.0 for Solaris (X.509). Unfortunately the message is not
properly archived at this time.</P>
<P><A HREF="#gauntlet.top">Back to chart</A></P>
<H4><A NAME="aix">IBM AIX</A></H4>
<P><A HREF="http://www-1.ibm.com/servers/esdd/articles/security.html">
IBM's &quot;Built-In Network Security with AIX&quot; (PSK, X.509)</A>
<BR><A HREF="http://www-1.ibm.com/servers/aix/products/ibmsw/security/vpn/faqandtips/#ques20">
IBM's tip: importing Linux FreeS/WAN settings into AIX's<VAR> ikedb</VAR>
(PSK)</A></P>
<P><A HREF="#aix.top">Back to chart</A></P>
<H4><A NAME="as400">IBM AS/400</A></H4>
<UL>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009106.html">
Road Warriors may act flaky</A>.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-September/014264.html">
Richard Welty's tips and tricks</A>
<BR></P>
<P><A HREF="#as400.top">Back to chart</A></P>
<H4><A NAME="intel">Intel Shiva LANRover / Net Structure</A></H4>
<UL>
<LI>Intel Shiva LANRover is now known as Intel Net Structure.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00298.html">
Shiva seems to have two modes: IPsec or the proprietary &quot;Shiva Tunnel&quot;.</A>
Of course, FreeS/WAN will only create IPsec tunnels.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00293.html">
AH may not work for Shiva-FreeS/WAN.</A> That's OK, since FreeS/WAN has
phased out the use of AH.</LI>
</UL>
<P><A HREF="http://snowcrash.tdyc.com/freeswan/"> Snowcrash's configs
(PSK)</A>
<BR><A HREF="http://www.opus1.com/vpn/index.html"> Old configs from an
interop (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/003831.html">
The day Shiva tickled a Pluto bug (PSK)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://lists.freeswan.org/pipermail/users/2001-October/004270.html">
Follow up: success!</A></P>
<P><A HREF="#intel.top">Back to chart</A></P>
<H4><A NAME="lancom">LanCom (formerly ELSA)</A></H4>
<UL>
<LI>This router is popular in Germany.</LI>
</UL>
<P> Jakob Curdes successfully created a PSK connection with the LanCom
1612 in August 2003.
<!-- add ML link when it appears -->
</P>
<P><A HREF="#lancom.top">Back to chart</A></P>
<H4><A NAME="linksys">Linksys</A></H4>
<UL>
<LI>Linksys may be used as an IPsec tunnel endpoint,<STRONG> OR</STRONG>
as a router in &quot;IPsec passthrough&quot; mode, so that the IPsec tunnel
passes through the Linksys.</LI>
</UL>
<H5>As tunnel endpoint</H5>
<P><A HREF="http://www.freeswan.ca/docs/BEFVP41/"> Ken Bantoft's
instructions (Road Warrior with PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007814.html">
Nate Carlson's caveats</A></P>
<H5>In IPsec passthrough mode</H5>
<P><A HREF="http://www-ec.njit.edu/~rxt1077/Howto.txt"> Sample HOWTO
through a Linksys Router</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2002/02/msg00114.html">
Nadeem Hasan's configs</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2002/02/msg00180.html">
Brock Nanson's tips</A>
<BR></P>
<P><A HREF="#linksys.top">Back to chart</A></P>
<H4><A NAME="lucent">Lucent</A></H4>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010976.html">
Partial success report; see also the next message in thread</A></P>
<!-- section done -->
<P><A HREF="#lucent.top">Back to chart</A></P>
<H4><A NAME="netasq">Netasq</A></H4>
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A></P>
<!-- section done -->
<P><A HREF="#netasq.top">Back to chart</A></P>
<H4><A NAME="netcelo">Netcelo</A></H4>
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A>
<!-- section done -->
</P>
<P><A HREF="#netcelo.top">Back to chart</A></P>
<H4><A NAME="netgear">Netgear fvs318</A></H4>
<UL>
<LI>With a recent Linux FreeS/WAN, you will require the latest (12/2002)
Netgear firmware, which supports Diffie-Hellman (DH) group 2. For
security reasons, we phased out DH 1 after Linux FreeS/WAN 1.5.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011833.html">
This message</A> reports the incompatibility between Linux FreeS/WAN
1.6+ and Netgear fvs318 without the firmware upgrade.</LI>
<LI>We believe Linux FreeS/WAN 1.5 and earlier will interoperate with
any NetGear firmware.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2003-February/017891.html">
John Morris' setup (PSK)</A></P>
<P><A HREF="#netgear.top">Back to chart</A></P>
<H4><A NAME="netscreen">Netscreen 100 or 5xp</A></H4>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013409.html">
Errol Neal's settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015265.html">
Corey Rogers' configs (PSK, no PFS)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013051.html">
Jordan Share's configs (PSK, 2 subnets, through static NAT)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/08/msg00404.html">
Set src proxy_id to your protected subnet/mask</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with ipsec.conf, Netscreen screen shots (X.509, may need to
revert to PSK...)</A></P>
<P><A HREF="http://archives.neohapsis.com/archives/sf/linux/2001-q2/0123.html">
A report of a company using Netscreen with FreeS/WAN on a large scale
(FreeS/WAN road warriors?)</A></P>
<P><A HREF="#netscreen.top">Back to chart</A></P>
<H4><A NAME="nortel">Nortel Contivity</A></H4>
<UL>
<LI> Nortel supports IPsec-over-UDP NAT traversal.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00417.html">
Some older versions of Contivity and FreeS/WAN will not communicate.</A>
</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010924.html">
FreeS/WAN cannot be used as a &quot;client&quot; to a Nortel Contivity server,
but can be used as a branch-office tunnel.</A></LI>
<!-- Probably obsoleted by Ken's post
<LI>
(Matthias siebler from old interop)
At one point you could not configure Nortel-FreeS/WAN tunnels as
"Client Tunnels" since FreeS/WAN does not support Aggressive Mode.
Current status of this problem: unknown.
<LI>
<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/004612.html">
How do we map group and user passwords onto the data that FreeS/WAN wants?
</A>
</LI>
-->
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015455.html">
Contivity does not send Distinguished Names in the order FS wants them
(X.509).</A></LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00137.html">
Connections may time out after 30-40 minutes idle.</A></LI>
</UL>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00137.html">
JJ Streicher-Bremer's mini HOWTO for old new software. (PSK with two
subnets)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A>. This succeeds using the above
X.509 tip.</P>
<!-- I could do more searching but this is a solid start. -->
<P><A HREF="#nortel.top">Back to chart</A></P>
<H4><A NAME="radguard">Radguard</A></H4>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00009.html">
Marko Hausalo's configs (PSK).</A> Note: These do create a connection,
as you can see by &quot;IPsec SA established&quot;.
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/???.html">
Claudia Schmeing's comments</A></P>
<P><A HREF="#radguard.top">Back to chart</A></P>
<H4><A NAME="raptor">Raptor (NT or Solaris)</A></H4>
<P></P>
<UL>
<LI>Now known as Symantec Enterprise Firewall.</LI>
<LI>The Raptor does not normally come with X.509, but this may be
available as an add-on.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010256.html">
Raptor requires alphanumberic PSK values, whereas FreeS/WAN uses hex.</A>
</LI>
<LI>Raptor's tunnel endpoint may be a host, subnet or group of subnets
(see<A HREF="http://lists.freeswan.org/pipermail/design/2001-November/001295.html">
this message</A> ). FreeS/WAN cannot handle the group of subnets; you
must create separate connections for each in order to interoperate.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010113.html">
Some versions of Raptor accept only single DES.</A> According to this
German message,<A HREF="http://radawana.cg.tuwien.ac.at/mail-archives/lll/200012/msg00065.html">
the Raptor Mobile Client demo offers single DES only.</A></LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-January/006935.html">
Peter Mazinger's settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005522.html">
Peter Gerland's configs (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00597.html">
Charles Griebel's configs (PSK).</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-July/012275.html">
Lumir Srch's tips (PSK)</A></P>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00214.html">
John Hardy's configs (Manual)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/01/msg00236.html">
Older Raptors want 3DES keys in 3 parts (Manual).</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/06/msg00480.html">
Different keys for each direction? (Manual)</A>
<BR></P>
<P><A HREF="#raptor.top">Back to chart</A></P>
<H4><A NAME="redcreek">Redcreek Ravlin</A></H4>
<UL>
<LI>Known issue #1: The Ravlin expects a quick mode renegotiation right
after every Main Mode negotiation.</LI>
<LI> Known issue #2: The Ravlin tries to negotiate a zero connection
lifetime, which it takes to mean &quot;infinite&quot;.<A HREF="http://www.bear-cave.org.uk/linux/ravlin/">
Jim Hague's patch</A> addresses both issues.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/03/msg00191.html">
Interop works with Ravlin Firmware &gt; 3.33. Includes tips (PSK).</A></LI>
</UL>
<P><A HREF="#redcreek.top">Back to chart</A></P>
<H4><A NAME="sonicwall">SonicWall</A></H4>
<UL>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-June/000998.html">
Sonicwall cannot be used for Road Warrior setups</A></LI>
<LI> At one point,<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00217.html">
only Sonicwall PRO supported triple DES</A>.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-March/008600.html">
Older Sonicwalls (before Nov 2001) feature Diffie Hellman group 1 only</A>
.</LI>
</UL>
<P><A HREF="http://www.xinit.cx/docs/freeswan.html"> Paul Wouters'
config (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00073.html">
Dilan Arumainathan's configuration (PSK)</A>
<BR><A HREF="http://www.gravitas.co.uk/vpndebug"> Dariush's setup...
only opens one way (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022302.html">
Andreas Steffen's tips (X.509)</A>
<BR></P>
<P><A HREF="#sonicwall.top">Back to chart</A></P>
<H4><A NAME="sun">Sun Solaris</A></H4>
<UL>
<LI> Solaris 8+ has a native (in kernel) IPsec implementation.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010503.html">
Solaris does not seem to support tunnel mode, but you can make IP-in-IP
tunnels instead, like this.</A></LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2003-June/022216.html">
Reports of some successful interops</A> from a fellow @sun.com. See
also<A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022247.html">
these follow up posts</A>.
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00332.html">
Aleks Shenkman's configs (Manual in transport mode)</A>
<BR>
<!--sparc 64 stuff goes where?-->
</P>
<P><A HREF="#solaris.top">Back to chart</A></P>
<H4><A NAME="symantec">Symantec</A></H4>
<UL>
<LI>The Raptor, covered<A HREF="#raptor"> above</A>, is now known as
Symantec Enterprise Firewall.</LI>
<LI>Symantec's &quot;distinguished name&quot; is a KEY_ID. See Andreas Steffen's
post, below.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009037.html">
Andreas Steffen's configs for Symantec 200R (PSK)</A></P>
<P><A HREF="#symantec.top">Back to chart</A></P>
<H4><A NAME="watchguard">Watchguard Firebox</A></H4>
<UL>
<LI>Automatic keying works with WatchGuard 5.0+ only.</LI>
<LI>Seen to interoperate with WatchGuard 1000, II, III; firmware v. 5,
6..</LI>
<LI>For manual keying, Watchguard's Policy Manager expects SPI numbers
and encryption and authentication keys in decimal (not hex).</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-July/012595.html">
WatchGuard's HOWTO (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013342.html">
Ronald C. Riviera's Settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00179.html">
Walter Wickersham's Notes (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015587.html">
Max Enders' Configs (Manual)</A></P>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009404.html">
Old known issue with auto keying</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00124.html">
Tips on key generation and format (Manual)</A>
<BR></P>
<P><A HREF="#watchguard.top">Back to chart</A></P>
<H4><A NAME="xedia">Xedia Access Point/QVPN</A></H4>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/12/msg00520.html">
Hybrid IPsec/L2TP connection settings (X.509)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/ipsec/1999/08/msg00140.html">
Xedia's LAN-LAN links don't use multiple tunnels</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.sandelman.ottawa.on.ca/ipsec/1999/08/msg00140.html">
That explanation, continued</A></P>
<P><A HREF="#xedia.top">Back to chart</A></P>
<H4><A NAME="zyxel">Zyxel</A></H4>
<UL>
<LI>The Zyxel Zywall is a rebranded SSH Sentinel box. See also our
section on<A HREF="glossary.html#ssh"> SSH</A>.</LI>
<LI>There seems to be a problem with keeping this connection alive. This
is caused at the Zyxel end. See this brief<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00141.html">
discussion and solution.</A></LI>
</UL>
<P><A HREF="http://www.zyxel.com/support/supportnote/zywall/app/zw_freeswan.htm">
Zyxel's Zywall to FreeS/WAN instructions (PSK)</A>
<BR><A HREF="http://www.zyxel.com/support/supportnote/p652/app/zw_freeswan.htm">
Zyxel's Prestige to FreeS/WAN instructions (PSK)</A>. Note: not all
Prestige versions include VPN software.
<BR><A HREF="http://www.lancry.net/techdocs/freeswan-zyxel.txt"> Fabrice
Cahen's HOWTO (PSK)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;</P>
<P><A HREF="#zyxel.top">Back to chart</A></P>
<!-- SAMPLE ENTRY
<H4><A NAME="timestep">Timestep</A></H4>
<P>Text goes here.
</P>
-->
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="compat.html">Previous</A>
<A HREF="performance.html">Next</A>
</BODY>
</HTML>
doc/intro.html
-733
View File
@@ -1,733 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="upgrading.html">Next</A>
<HR>
<H1><A name="intro">Introduction</A></H1>
<P>This section gives an overview of:</P>
<UL>
<LI>what IP Security (IPsec) does</LI>
<LI>how IPsec works</LI>
<LI>why we are implementing it for Linux</LI>
<LI>how this implementation works</LI>
</UL>
<P>This section is intended to cover only the essentials,<EM> things you
should know before trying to use FreeS/WAN.</EM></P>
<P>For more detailed background information, see the<A href="politics.html#politics">
history and politics</A> and<A href="ipsec.html#ipsec.detail"> IPsec
protocols</A> sections.</P>
<H2><A name="ipsec.intro">IPsec, Security for the Internet Protocol</A></H2>
<P>FreeS/WAN is a Linux implementation of the IPsec (IP security)
protocols. IPsec provides<A href="glossary.html#encryption"> encryption</A>
and<A href="glossary.html#authentication"> authentication</A> services
at the IP (Internet Protocol) level of the network protocol stack.</P>
<P>Working at this level, IPsec can protect any traffic carried over IP,
unlike other encryption which generally protects only a particular
higher-level protocol --<A href="glossary.html#PGP"> PGP</A> for mail,<A
href="glossary.html#SSH"> SSH</A> for remote login,<A href="glossary.html#SSL">
SSL</A> for web work, and so on. This approach has both considerable
advantages and some limitations. For discussion, see our<A href="ipsec.html#others">
IPsec section</A></P>
<P>IPsec can be used on any machine which does IP networking. Dedicated
IPsec gateway machines can be installed wherever required to protect
traffic. IPsec can also run on routers, on firewall machines, on
various application servers, and on end-user desktop or laptop
machines.</P>
<P>Three protocols are used</P>
<UL>
<LI><A href="glossary.html#AH">AH</A> (Authentication Header) provides a
packet-level authentication service</LI>
<LI><A href="glossary.html#ESP">ESP</A> (Encapsulating Security Payload)
provides encryption plus authentication</LI>
<LI><A href="glossary.html#IKE">IKE</A> (Internet Key Exchange)
negotiates connection parameters, including keys, for the other two</LI>
</UL>
<P>Our implementation has three main parts:</P>
<UL>
<LI><A href="glossary.html#KLIPS">KLIPS</A> (kernel IPsec) implements
AH, ESP, and packet handling within the kernel</LI>
<LI><A href="glossary.html#Pluto">Pluto</A> (an IKE daemon) implements
IKE, negotiating connections with other systems</LI>
<LI>various scripts provide an adminstrator's interface to the machinery</LI>
</UL>
<P>IPsec is optional for the current (version 4) Internet Protocol.
FreeS/WAN adds IPsec to the Linux IPv4 network stack. Implementations
of<A href="glossary.html#ipv6.gloss"> IP version 6</A> are required to
include IPsec. Work toward integrating FreeS/WAN into the Linux IPv6
stack has<A href="compat.html#ipv6"> started</A>.</P>
<P>For more information on IPsec, see our<A href="ipsec.html#ipsec.detail">
IPsec protocols</A> section, our collection of<A href="web.html#ipsec.link">
IPsec links</A> or the<A href="rfc.html#RFC"> RFCs</A> which are the
official definitions of these protocols.</P>
<H3><A name="intro.interop">Interoperating with other IPsec
implementations</A></H3>
<P>IPsec is designed to let different implementations work together. We
provide:</P>
<UL>
<LI>a<A href="web.html#implement"> list</A> of some other
implementations</LI>
<LI>information on<A href="interop.html#interop"> using FreeS/WAN with
other implementations</A></LI>
</UL>
<P>The VPN Consortium fosters cooperation among implementers and
interoperability among implementations. Their<A href="http://www.vpnc.org/">
web site</A> has much more information.</P>
<H3><A name="advantages">Advantages of IPsec</A></H3>
<P>IPsec has a number of security advantages. Here are some
independently written articles which discuss these:</P>
<P><A HREF="http://www.sans.org/rr/"> SANS institute papers</A>. See the
section on Encryption &amp;VPNs.
<BR><A HREF="http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns128/networking_solutions_white_papers_list.html">
Cisco's white papers on &quot;Networking Solutions&quot;</A>.
<BR><A HREF="http://iscs.sourceforge.net/HowWhyBrief/HowWhyBrief.html">
Advantages of ISCS (Linux Integrated Secure Communications System;
includes FreeS/WAN and other software)</A>.</P>
<H3><A name="applications">Applications of IPsec</A></H3>
<P>Because IPsec operates at the network layer, it is remarkably
flexible and can be used to secure nearly any type of Internet traffic.
Two applications, however, are extremely widespread:</P>
<UL>
<LI>a<A href="glossary.html#VPN"> Virtual Private Network</A>, or VPN,
allows multiple sites to communicate securely over an insecure Internet
by encrypting all communication between the sites.</LI>
<LI>&quot;Road Warriors&quot; connect to the office from home, or perhaps from a
hotel somewhere</LI>
</UL>
<P>There is enough opportunity in these applications that vendors are
flocking to them. IPsec is being built into routers, into firewall
products, and into major operating systems, primarily to support these
applications. See our<A href="web.html#implement"> list</A> of
implementations for details.</P>
<P>We support both of those applications, and various less common IPsec
applications as well, but we also add one of our own:</P>
<UL>
<LI>opportunistic encryption, the ability to set up FreeS/WAN gateways
so that any two of them can encrypt to each other, and will do so
whenever packets pass between them.</LI>
</UL>
<P>This is an extension we are adding to the protocols. FreeS/WAN is the
first prototype implementation, though we hope other IPsec
implementations will adopt the technique once we demonstrate it. See<A href="#goals">
project goals</A> below for why we think this is important.</P>
<P>A somewhat more detailed description of each of these applications is
below. Our<A href="quickstart.html#quick_guide"> quickstart</A> section
will show you how to build each of them.</P>
<H4><A name="makeVPN">Using secure tunnels to create a VPN</A></H4>
<P>A VPN, or<STRONG> V</STRONG>irtual<STRONG> P</STRONG>rivate<STRONG> N</STRONG>
etwork lets two networks communicate securely when the only connection
between them is over a third network which they do not trust.</P>
<P>The method is to put a security gateway machine between each of the
communicating networks and the untrusted network. The gateway machines
encrypt packets entering the untrusted net and decrypt packets leaving
it, creating a secure tunnel through it.</P>
<P>If the cryptography is strong, the implementation is careful, and the
administration of the gateways is competent, then one can reasonably
trust the security of the tunnel. The two networks then behave like a
single large private network, some of whose links are encrypted tunnels
through untrusted nets.</P>
<P>Actual VPNs are often more complex. One organisation may have fifty
branch offices, plus some suppliers and clients, with whom it needs to
communicate securely. Another might have 5,000 stores, or 50,000
point-of-sale devices. The untrusted network need not be the Internet.
All the same issues arise on a corporate or institutional network
whenever two departments want to communicate privately with each other.</P>
<P>Administratively, the nice thing about many VPN setups is that large
parts of them are static. You know the IP addresses of most of the
machines involved. More important, you know they will not change on
you. This simplifies some of the admin work. For cases where the
addresses do change, see the next section.</P>
<H4><A name="road.intro">Road Warriors</A></H4>
<P>The prototypical &quot;Road Warrior&quot; is a traveller connecting to home
base from a laptop machine. Administratively, most of the same problems
arise for a telecommuter connecting from home to the office, especially
if the telecommuter does not have a static IP address.</P>
<P>For purposes of this document:</P>
<UL>
<LI>anyone with a dynamic IP address is a &quot;Road Warrior&quot;.</LI>
<LI>any machine doing IPsec processing is a &quot;gateway&quot;. Think of the
single-user road warrior machine as a gateway with a degenerate subnet
(one machine, itself) behind it.</LI>
</UL>
<P>These require somewhat different setup than VPN gateways with static
addresses and with client systems behind them, but are basically not
problematic.</P>
<P>There are some difficulties which appear for some road warrior
connections:</P>
<UL>
<LI>Road Wariors who get their addresses via DHCP may have a problem.
FreeS/WAN can quite happily build and use a tunnel to such an address,
but when the DHCP lease expires, FreeS/WAN does not know that. The
tunnel fails, and the only recovery method is to tear it down and
re-build it.</LI>
<LI>If<A href="glossary.html#NAT.gloss"> Network Address Translation</A>
(NAT) is applied between the two IPsec Gateways, this breaks IPsec.
IPsec authenticates packets on an end-to-end basis, to ensure they are
not altered en route. NAT rewrites packets as they go by. See our<A href="firewall.html#NAT">
firewalls</A> document for details.</LI>
</UL>
<P>In most situations, however, FreeS/WAN supports road warrior
connections just fine.</P>
<H4><A name="opp.intro">Opportunistic encryption</A></H4>
<P>One of the reasons we are working on FreeS/WAN is that it gives us
the opportunity to add what we call opportuntistic encryption. This
means that any two FreeS/WAN gateways will be able to encrypt their
traffic, even if the two gateway administrators have had no prior
contact and neither system has any preset information about the other.</P>
<P>Both systems pick up the authentication information they need from
the<A href="glossary.html#DNS"> DNS</A> (domain name service), the
service they already use to look up IP addresses. Of course the
administrators must put that information in the DNS, and must set up
their gateways with opportunistic encryption enabled. Once that is
done, everything is automatic. The gateways look for opportunities to
encrypt, and encrypt whatever they can. Whether they also accept
unencrypted communication is a policy decision the administrator can
make.</P>
<P>This technique can give two large payoffs:</P>
<UL>
<LI>It reduces the administrative overhead for IPsec enormously. You
configure your gateway and thereafter everything is automatic. The need
to configure the system on a per-tunnel basis disappears. Of course,
FreeS/WAN allows specifically configured tunnels to co-exist with
opportunistic encryption, but we hope to make them unnecessary in most
cases.</LI>
<LI>It moves us toward a more secure Internet, allowing users to create
an environment where message privacy is the default. All messages can
be encrypted, provided the other end is willing to co-operate. See our<A
href="politics.html#politics"> history and politics of cryptography</A>
section for discussion of why we think this is needed.</LI>
</UL>
<P>Opportunistic encryption is not (yet?) a standard part of the IPsec
protocols, but an extension we are proposing and demonstrating. For
details of our design, see<A href="#applied"> links</A> below.</P>
<P>Only one current product we know of implements a form of
opportunistic encryption.<A href="web.html#ssmail"> Secure sendmail</A>
will automatically encrypt server-to-server mail transfers whenever
possible.</P>
<H3><A name="types">The need to authenticate gateways</A></H3>
<P>A complication, which applies to any type of connection -- VPN, Road
Warrior or opportunistic -- is that a secure connection cannot be
created magically.<EM> There must be some mechanism which enables the
gateways to reliably identify each other.</EM> Without this, they
cannot sensibly trust each other and cannot create a genuinely secure
link.</P>
<P>Any link they do create without some form of<A href="glossary.html#authentication">
authentication</A> will be vulnerable to a<A href="glossary.html#middle">
man-in-the-middle attack</A>. If<A href="glossary.html#alicebob"> Alice
and Bob</A> are the people creating the connection, a villian who can
re-route or intercept the packets can pose as Alice while talking to
Bob and pose as Bob while talking to Alice. Alice and Bob then both
talk to the man in the middle, thinking they are talking to each other,
and the villain gets everything sent on the bogus &quot;secure&quot; connection.</P>
<P>There are two ways to build links securely, both of which exclude the
man-in-the middle:</P>
<UL>
<LI>with<STRONG> manual keying</STRONG>, Alice and Bob share a secret
key (which must be transmitted securely, perhaps in a note or via PGP
or SSH) to encrypt their messages. For FreeS/WAN, such keys are stored
in the<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> file. Of
course, if an enemy gets the key, all is lost.</LI>
<LI>with<STRONG> automatic keying</STRONG>, the two systems authenticate
each other and negotiate their own secret keys. The keys are
automatically changed periodically.</LI>
</UL>
<P>Automatic keying is much more secure, since if an enemy gets one key
only messages between the previous re-keying and the next are exposed.
It is therefore the usual mode of operation for most IPsec deployment,
and the mode we use in our setup examples. FreeS/WAN does support
manual keying for special circumstanes. See this<A href="adv_config.html#prodman">
section</A>.</P>
<P>For automatic keying, the two systems must authenticate each other
during the negotiations. There is a choice of methods for this:</P>
<UL>
<LI>a<STRONG> shared secret</STRONG> provides authentication. If Alice
and Bob are the only ones who know a secret and Alice recives a message
which could not have been created without that secret, then Alice can
safely believe the message came from Bob.</LI>
<LI>a<A href="glossary.html#public"> public key</A> can also provide
authentication. If Alice receives a message signed with Bob's private
key (which of course only he should know) and she has a trustworthy
copy of his public key (so that she can verify the signature), then she
can safely believe the message came from Bob.</LI>
</UL>
<P>Public key techniques are much preferable, for reasons discussed<A href="config.html#choose">
later</A>, and will be used in all our setup examples. FreeS/WAN does
also support auto-keying with shared secret authentication. See this<A href="adv_config.html#prodsecrets">
section</A>.</P>
<H2><A name="project">The FreeS/WAN project</A></H2>
<P>For complete information on the project, see our web site,<A href="http://liberty.freeswan.org">
freeswan.org</A>.</P>
<P>In summary, we are implementing the<A href="glossary.html#IPsec">
IPsec</A> protocols for Linux and extending them to do<A href="glossary.html#carpediem">
opportunistic encryption</A>.</P>
<H3><A name="goals">Project goals</A></H3>
<P>Our overall goal in FreeS/WAN is to make the Internet more secure and
more private.</P>
<P>Our IPsec implementation supports VPNs and Road Warriors of course.
Those are important applications. Many users will want FreeS/WAN to
build corporate VPNs or to provide secure remote access.</P>
<P>However, our goals in building it go beyond that. We are trying to
help<STRONG> build security into the fabric of the Internet</STRONG> so
that anyone who choses to communicate securely can do so, as easily as
they can do anything else on the net.</P>
<P>More detailed objectives are:</P>
<UL>
<LI>extend IPsec to do<A href="glossary.html#carpediem"> opportunistic
encryption</A> so that
<UL>
<LI>any two systems can secure their communications without a
pre-arranged connection</LI>
<LI><STRONG>secure connections can be the default</STRONG>, falling back
to unencrypted connections only if:
<UL>
<LI><EM>both</EM> the partner is not set up to co-operate on securing
the connection</LI>
<LI><EM>and</EM> your policy allows insecure connections</LI>
</UL>
</LI>
<LI>a significant fraction of all Internet traffic is encrypted</LI>
<LI>wholesale monitoring of the net (<A href="politics.html#intro.poli">
examples</A>) becomes difficult or impossible</LI>
</UL>
</LI>
<LI>help make IPsec widespread by providing an implementation with no
restrictions:
<UL>
<LI>freely available in source code under the<A href="glossary.html#GPL">
GNU General Public License</A></LI>
<LI>running on a range of readily available hardware</LI>
<LI>not subject to US or other nations'<A href="politics.html#exlaw">
export restrictions</A>.
<BR> Note that in order to avoid<EM> even the appearance</EM> of being
subject to those laws, the project cannot accept software contributions
--<EM> not even one-line bug fixes</EM> -- from US residents or
citizens.</LI>
</UL>
</LI>
<LI>provide a high-quality IPsec implementation for Linux
<UL>
<LI>portable to all CPUs Linux supports:<A href="compat.html#CPUs">
(current list)</A></LI>
<LI>interoperable with other IPsec implementations:<A href="interop.html#interop">
(current list)</A></LI>
</UL>
</LI>
</UL>
<P>If we can get opportunistic encryption implemented and widely
deployed, then it becomes impossible for even huge well-funded agencies
to monitor the net.</P>
<P>See also our section on<A href="politics.html#politics"> history and
politics</A> of cryptography, which includes our project leader's<A href="politics.html#gilmore">
rationale</A> for starting the project.</P>
<H3><A name="staff">Project team</A></H3>
<P>Two of the team are from the US and can therefore contribute no code:</P>
<UL>
<LI>John Gilmore: founder and policy-maker (<A href="http://www.toad.com/gnu/">
home page</A>)</LI>
<LI>Hugh Daniel: project manager, Most Demented Tester, and occasionally
Pointy-Haired Boss</LI>
</UL>
<P>The rest of the team are Canadians, working in Canada. (<A href="politics.html#status">
Why Canada?</A>)</P>
<UL>
<LI>Hugh Redelmeier:<A href="glossary.html#Pluto"> Pluto daemon</A>
programmer</LI>
<LI>Richard Guy Briggs:<A href="glossary.html#KLIPS"> KLIPS</A>
programmer</LI>
<LI>Michael Richardson: hacker without portfolio</LI>
<LI>Claudia Schmeing: documentation</LI>
<LI>Sam Sgro: technical support via the<A href="mail.html#lists">
mailing lists</A></LI>
</UL>
<P>The project is funded by civil libertarians who consider our goals
worthwhile. Most of the team are paid for this work.</P>
<P>People outside this core team have made substantial contributions.
See</P>
<UL>
<LI>our<A href="../CREDITS"> CREDITS</A> file</LI>
<LI>the<A href="web.html#patch"> patches and add-ons</A> section of our
web references file</LI>
<LI>lists below of user-written<A href="#howto"> HowTos</A> and<A href="#applied">
other papers</A></LI>
</UL>
<P>Additional contributions are welcome. See the<A href="faq.html#contrib.faq">
FAQ</A> for details.</P>
<H2><A name="products">Products containing FreeS/WAN</A></H2>
<P>Unfortunately the<A href="politics.html#exlaw"> export laws</A> of
some countries restrict the distribution of strong cryptography.
FreeS/WAN is therefore not in the standard Linux kernel and not in all
CD or web distributions.</P>
<P>FreeS/WAN is, however, quite widely used. Products we know of that
use it are listed below. We would appreciate hearing, via the<A href="mail.html#lists">
mailing lists</A>, of any we don't know of.</P>
<H3><A name="distwith">Full Linux distributions</A></H3>
<P>FreeS/WAN is included in various general-purpose Linux distributions,
mostly from countries (shown in brackets) with more sensible laws:</P>
<UL>
<LI><A href="http://www.suse.com/">SuSE Linux</A> (Germany)</LI>
<LI><A href="http://www.conectiva.com">Conectiva</A> (Brazil)</LI>
<LI><A href="http://www.linux-mandrake.com/en/">Mandrake</A> (France)</LI>
<LI><A href="http://www.debian.org">Debian</A></LI>
<LI>the<A href="http://www.pld.org.pl/"> Polish(ed) Linux Distribution</A>
(Poland)</LI>
<LI><A>Best Linux</A> (Finland)</LI>
</UL>
<P>For distributions which do not include FreeS/WAN and are not Redhat
(which we develop and test on), there is additional information in our<A
href="compat.html#otherdist"> compatibility</A> section.</P>
<P>The server edition of<A href="http://www.corel.com"> Corel</A> Linux
(Canada) also had FreeS/WAN, but Corel have dropped that product line.</P>
<H3><A name="kernel_dist">Linux kernel distributions</A></H3>
<UL>
<LI><A href="http://sourceforge.net/projects/wolk/">Working Overloaded
Linux Kernel (WOLK)</A></LI>
</UL>
<H3><A name="office_dist">Office server distributions</A></H3>
<P>FreeS/WAN is also included in several distributions aimed at the
market for turnkey business servers:</P>
<UL>
<LI><A href="http://www.e-smith.com/">e-Smith</A> (Canada), which has
recently been acquired and become the Network Server Solutions group of<A
href="http://www.mitel.com/"> Mitel Networks</A> (Canada)</LI>
<LI><A href="http://www.clarkconnect.org/">ClarkConnect</A> from Point
Clark Networks (Canada)</LI>
<LI><A href="http://www.trustix.net/">Trustix Secure Linux</A> (Norway)</LI>
</UL>
<H3><A name="fw_dist">Firewall distributions</A></H3>
<P>Several distributions intended for firewall and router applications
include FreeS/WAN:</P>
<UL>
<LI>The<A href="http://www.linuxrouter.org/"> Linux Router Project</A>
produces a Linux distribution that will boot from a single floppy. The<A
href="http://leaf.sourceforge.net"> LEAF</A> firewall project provides
several different LRP-based firewall packages. At least one of them,
Charles Steinkuehler's Dachstein, includes FreeS/WAN with X.509
patches.</LI>
<LI>there are several distributions bootable directly from CD-ROM,
usable on a machine without hard disk.
<UL>
<LI>Dachstein (see above) can be used this way</LI>
<LI><A href="http://www.gibraltar.at/">Gibraltar</A> is based on Debian
GNU/Linux.</LI>
<LI>at time of writing,<A href="www.xiloo.com"> Xiloo</A> is available
only in Chinese. An English version is expected.</LI>
</UL>
</LI>
<LI><A href="http://www.astaro.com/products/index.html">Astaro Security
Linux</A> includes FreeS/WAN. It has some web-based tools for managing
the firewall that include FreeS/WAN configuration management.</LI>
<LI><A href="http://www.linuxwall.de">Linuxwall</A></LI>
<LI><A href="http://www.smoothwall.org/">Smoothwall</A></LI>
<LI><A href="http://www.devil-linux.org/">Devil Linux</A></LI>
<LI>Coyote Linux has a<A href="http://embedded.coyotelinux.com/wolverine/index.php">
Wolverine</A> firewall/VPN server</LI>
</UL>
<P>There are also several sets of scripts available for managing a
firewall which is also acting as a FreeS/WAN IPsec gateway. See this<A href="firewall.html#rules.pub">
list</A>.</P>
<H3><A name="turnkey">Firewall and VPN products</A></H3>
<P>Several vendors use FreeS/WAN as the IPsec component of a turnkey
firewall or VPN product.</P>
<P>Software-only products:</P>
<UL>
<LI><A href="http://www.linuxmagic.com/vpn/index.html">Linux Magic</A>
offer a VPN/Firewall product using FreeS/WAN</LI>
<LI>The Software Group's<A href="http://www.wanware.com/sentinet/">
Sentinet</A> product uses FreeS/WAN</LI>
<LI><A href="http://www.merilus.com">Merilus</A> use FreeS/WAN in their
Gateway Guardian firewall product</LI>
</UL>
<P>Products that include the hardware:</P>
<UL>
<LI>The<A href="http://www.lasat.com"> LASAT SafePipe[tm]</A> series. is
an IPsec box based on an embedded MIPS running Linux with FreeS/WAN and
a web-config front end. This company also host our freeswan.org web
site.</LI>
<LI>Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
Firecard</A> is a Linux firewall on a PCI card.</LI>
<LI><A href="http://www.kyzo.com/">Kyzo</A> have a &quot;pizza box&quot; product
line with various types of server, all running from flash. One of them
is an IPsec/PPTP VPN server</LI>
<LI><A href="http://www.pfn.com">PFN</A> use FreeS/WAN in some of their
products</LI>
</UL>
<P><A href="www.rebel.com">Rebel.com</A>, makers of the Netwinder Linux
machines (ARM or Crusoe based), had a product that used FreeS/WAN. The
company is in receivership so the future of the Netwinder is at best
unclear.<A href="web.html#patch"> PKIX patches</A> for FreeS/WAN
developed at Rebel are listed in our web links document.</P>
<H2><A name="docs">Information sources</A></H2>
<H3><A name="docformats">This HowTo, in multiple formats</A></H3>
<P>FreeS/WAN documentation up to version 1.5 was available only in HTML.
Now we ship two formats:</P>
<UL>
<LI>as HTML, one file for each doc section plus a global<A href="toc.html">
Table of Contents</A></LI>
<LI><A href="HowTo.html">one big HTML file</A> for easy searching</LI>
</UL>
<P>and provide a Makefile to generate other formats if required:</P>
<UL>
<LI><A href="HowTo.pdf">PDF</A></LI>
<LI><A href="HowTo.ps">Postscript</A></LI>
<LI><A href="HowTo.txt">ASCII text</A></LI>
</UL>
<P>The Makefile assumes the htmldoc tool is available. You can download
it from<A href="http://www.easysw.com"> Easy Software</A>.</P>
<P>All formats should be available at the following websites:</P>
<UL>
<LI><A href="http://www.freeswan.org/doc.html">FreeS/WAN project</A></LI>
<LI><A href="http://www.linuxdoc.org">Linux Documentation Project</A></LI>
</UL>
<P>The distribution tarball has only the two HTML formats.</P>
<P><STRONG>Note:</STRONG> If you need the latest doc version, for
example to see if anyone has managed to set up interoperation between
FreeS/WAN and whatever, then you should download the current snapshot.
What is on the web is documentation as of the last release. Snapshots
have all changes I've checked in to date.</P>
<H3><A name="rtfm">RTFM (please Read The Fine Manuals)</A></H3>
<P>As with most things on any Unix-like system, most parts of Linux
FreeS/WAN are documented in online manual pages. We provide a list of<A href="/mnt/floppy/manpages.html">
FreeS/WAN man pages</A>, with links to HTML versions of them.</P>
<P>The man pages describing configuration files are:</P>
<UL>
<LI><A href="/mnt/floppy/manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec.secrets.5.html">
ipsec.secrets(5)</A></LI>
</UL>
<P>Man pages for common commands include:</P>
<UL>
<LI><A href="/mnt/floppy/manpage.d/ipsec.8.html">ipsec(8)</A></LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</A>
</LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec_newhostkey.8.html">
ipsec_newhostkey(8)</A></LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec_auto.8.html">ipsec_auto(8)</A></LI>
</UL>
<P>You can read these either in HTML using the links above or with the<VAR>
man(1)</VAR> command.</P>
<P>In the event of disagreement between this HTML documentation and the
man pages, the man pages are more likely correct since they are written
by the implementers. Please report any such inconsistency on the<A href="mail.html#lists">
mailing list</A>.</P>
<H3><A name="text">Other documents in the distribution</A></H3>
<P>Text files in the main distribution directory are README, INSTALL,
CREDITS, CHANGES, BUGS and COPYING.</P>
<P>The Libdes encryption library we use has its own documentation. You
can find it in the library directory..</P>
<H3><A name="assumptions">Background material</A></H3>
<P>Throughout this documentation, I write as if the reader had at least
a general familiarity with Linux, with Internet Protocol networking,
and with the basic ideas of system and network security. Of course that
will certainly not be true for all readers, and quite likely not even
for a majority.</P>
<P>However, I must limit amount of detail on these topics in the main
text. For one thing, I don't understand all the details of those topics
myself. Even if I did, trying to explain everything here would produce
extremely long and almost completely unreadable documentation.</P>
<P>If one or more of those areas is unknown territory for you, there are
plenty of other resources you could look at:</P>
<DL>
<DT>Linux</DT>
<DD>the<A href="http://www.linuxdoc.org"> Linux Documentation Project</A>
or a local<A href="http://www.linux.org/groups/"> Linux User Group</A>
and these<A href="web.html#linux.link"> links</A></DD>
<DT>IP networks</DT>
<DD>Rusty Russell's<A href="http://netfilter.samba.org/unreliable-guides/networking-concepts-HOWTO/index.html">
Networking Concepts HowTo</A> and these<A href="web.html#IP.background">
links</A></DD>
<DT>Security</DT>
<DD>Schneier's book<A href="biblio.html#secrets"> Secrets and Lies</A>
and these<A href="web.html#crypto.link"> links</A></DD>
</DL>
<P>Also, I do make an effort to provide some background material in
these documents. All the basic ideas behind IPsec and FreeS/WAN are
explained here. Explanations that do not fit in the main text, or that
not everyone will need, are often in the<A href="glossary.html#ourgloss">
glossary</A>, which is the largest single file in this document set.
There is also a<A href="background.html#background"> background</A>
file containing various explanations too long to fit in glossary
definitions. All files are heavily sprinkled with links to each other
and to the glossary.<STRONG> If some passage makes no sense to you, try
the links</STRONG>.</P>
<P>For other reference material, see the<A href="biblio.html#biblio">
bibliography</A> and our collection of<A href="web.html#weblinks"> web
links</A>.</P>
<P>Of course, no doubt I get this (and other things) wrong sometimes.
Feedback via the<A href="mail.html#lists"> mailing lists</A> is
welcome.</P>
<H3><A name="archives">Archives of the project mailing list</A></H3>
<P>Until quite recently, there was only one FreeS/WAN mailing list, and
archives of it were:</P>
<UL>
<LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
<LI><A href="http://www.nexial.com">Holland</A></LI>
</UL>
The two archives use completely different search engines. You might
want to try both.
<P>More recently we have expanded to five lists, each with its own
archive.</P>
<P><A href="mail.html#lists">More information</A> on mailing lists.</P>
<H3><A name="howto">User-written HowTo information</A></H3>
<P>Various user-written HowTo documents are available. The ones covering
FreeS/WAN-to-FreeS/WAN connections are:</P>
<UL>
<LI>Jean-Francois Nadeau's<A href="http://jixen.tripod.com/"> practical
configurations</A> document</LI>
<LI>Jens Zerbst's HowTo on<A href="http://dynipsec.tripod.com/"> Using
FreeS/WAN with dynamic IP addresses</A>.</LI>
<LI>an entry in Kurt Seifried's<A href="http://www.securityportal.com/lskb/kben00000013.html">
Linux Security Knowledge Base</A>.</LI>
<LI>a section of David Ranch's<A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
Trinity OS Guide</A></LI>
<LI>a section in David Bander's book<A href="biblio.html#bander"> Linux
Security Toolkit</A></LI>
</UL>
<P>User-wriiten HowTo material may be<STRONG> especially helpful if you
need to interoperate with another IPsec implementation</STRONG>. We
have neither the equipment nor the manpower to test such
configurations. Users seem to be doing an admirable job of filling the
gaps.</P>
<UL>
<LI>list of user-written<A href="interop.html#otherpub"> interoperation
HowTos</A> in our interop document</LI>
</UL>
<P>Check what version of FreeS/WAN user-written documents cover. The
software is under active development and the current version may be
significantly different from what an older document describes.</P>
<H3><A name="applied">Papers on FreeS/WAN</A></H3>
<P>Two design documents show team thinking on new developments:</P>
<UL>
<LI><A href="opportunism.spec">Opportunistic Encryption</A> by technical
lead Henry Spencer and Pluto programmer Hugh Redelemeier</LI>
<LI>discussion of<A href="http://www.sandelman.ottawa.on.ca/SSW/freeswan/klips2req/">
KLIPS redesign</A></LI>
</UL>
<P>Both documents are works in progress and are frequently revised. For
the latest version, see the<A href="mail.html#lists"> design mailing
list</A>. Comments should go to that list.</P>
<P>There is now an<A href="http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-06.txt">
Internet Draft on Opportunistic Encryption</A> by Michael Richardson,
Hugh Redelmeier and Henry Spencer. This is a first step toward getting
the protocol standardised so there can be multiple implementations of
it. Discussion of it takes place on the<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
IETF IPsec Working Group</A> mailing list.</P>
<P>A number of papers giving further background on FreeS/WAN, or
exploring its future or its applications, are also available:</P>
<UL>
<LI>Both Henry and Richard gave talks on FreeS/WAN at the 2000<A href="http://www.linuxsymposium.org">
Ottawa Linux Symposium</A>.
<UL>
<LI>Richard's<A href="http://www.conscoop.ottawa.on.ca/rgb/freeswan/ols2k/">
slides</A></LI>
<LI>Henry's paper</LI>
<LI>MP3 audio of their talks is available from the<A href="http://www.linuxsymposium.org/">
conference page</A></LI>
</UL>
</LI>
<LI><CITE>Moat: A Virtual Private Network Appliances and Services
Platform</CITE> is a paper about large-scale (a few 100 links) use of
FreeS/WAN in a production application at AT&amp;T Research. It is available
in Postscript or PDF from co-author Steve Bellovin's<A href="http://www.research.att.com/~smb/papers/index.html">
papers list page</A>.</LI>
<LI>One of the Moat co-authors, John Denker, has also written
<UL>
<LI>a<A href="http://www.av8n.com/vpn/ipsec+routing.htm"> proposal</A>
for how future versions of FreeS/WAN might interact with routing
protocols</LI>
<LI>a<A href="http://www.av8n.com/vpn/wishlist.htm"> wishlist</A> of
possible new features</LI>
</UL>
</LI>
<LI>Bart Trojanowski's web page has a draft design for<A href="http://www.jukie.net/~bart/linux-ipsec/">
hardware acceleration</A> of FreeS/WAN</LI>
</UL>
<P>Several of these provoked interesting discussions on the mailing
lists, worth searching for in the<A href="mail.html#archive"> archives</A>
.</P>
<P>There are also several papers in languages other than English, see
our<A href="web.html#otherlang"> web links</A>.</P>
<H3><A name="licensing">License and copyright information</A></H3>
<P>All code and documentation written for this project is distributed
under either the GNU General Public License (<A href="glossary.html#GPL">
GPL</A>) or the GNU Library General Public License. For details see the
COPYING file in the distribution.</P>
<P>Not all code in the distribution is ours, however. See the CREDITS
file for details. In particular, note that the<A href="glossary.html#LIBDES">
Libdes</A> library and the version of<A href="glossary.html#MD5"> MD5</A>
that we use each have their own license.</P>
<H2><A name="sites">Distribution sites</A></H2>
<P>FreeS/WAN is available from a number of sites.</P>
<H3><A NAME="1_5_1">Primary site</A></H3>
<P>Our primary site, is at xs4all (Thanks, folks!) in Holland:</P>
<UL>
<LI><A href="http://www.xs4all.nl/~freeswan">HTTP</A></LI>
<LI><A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">FTP</A></LI>
</UL>
<H3><A name="mirrors">Mirrors</A></H3>
<P>There are also mirror sites all over the world:</P>
<UL>
<LI><A href="http://www.flora.org/freeswan">Eastern Canada</A> (limited
resouces)</LI>
<LI><A href="ftp://ludwig.doculink.com/pub/freeswan/">Eastern Canada</A>
(has older versions too)</LI>
<LI><A href="ftp://ntsc.notBSD.org/pub/crypto/freeswan/">Eastern Canada</A>
(has older versions too)</LI>
<LI><A href="ftp://ftp.kame.net/pub/freeswan/">Japan</A></LI>
<LI><A href="ftp://ftp.futuredynamics.com/freecrypto/FreeSWAN/">Hong
Kong</A></LI>
<LI><A href="ftp://ipsec.dk/pub/freeswan/">Denmark</A></LI>
<LI><A href="ftp://ftp.net.lut.ac.uk/freeswan">the UK</A></LI>
<LI><A href="http://storm.alert.sk/comp/mirrors/freeswan/">Slovak
Republic</A></LI>
<LI><A href="http://the.wiretapped.net/security/vpn-tunnelling/freeswan/">
Australia</A></LI>
<LI><A href="http://freeswan.technolust.cx/">technolust</A></LI>
<LI><A href="http://freeswan.devguide.de/">Germany</A></LI>
<LI>Ivan Moore's<A href="http://snowcrash.tdyc.com/freeswan/"> site</A></LI>
<LI>the<A href="http://www.cryptoarchive.net/"> Crypto Archive</A> on
the<A href="http://www.securityportal.com/"> Security Portal</A> site</LI>
<LI><A href="http://www.wiretapped.net/">Wiretapped.net</A> in Australia</LI>
</UL>
<P>Thanks to those folks as well.</P>
<H3><A name="munitions">The &quot;munitions&quot; archive of Linux crypto software</A>
</H3>
<P>There is also an archive of Linux crypto software called &quot;munitions&quot;,
with its own mirrors in a number of countries. It includes FreeS/WAN,
though not always the latest version. Some of its sites are:</P>
<UL>
<LI><A href="http://munitions.vipul.net/">Germany</A></LI>
<LI><A href="http://munitions.iglu.cjb.net/">Italy</A></LI>
<LI><A href="http://munitions2.xs4all.nl/">Netherlands</A></LI>
</UL>
<P>Any of those will have a list of other &quot;munitions&quot; mirrors. There is
also a CD available.</P>
<H2><A NAME="1_6">Links to other sections</A></H2>
<P>For more detailed background information, see:</P>
<UL>
<LI><A href="politics.html#politics">history and politics</A> of
cryptography</LI>
<LI><A href="ipsec.html#ipsec.detail">IPsec protocols</A></LI>
</UL>
<P>To begin working with FreeS/WAN, go to our<A href="quickstart.html#quick.guide">
quickstart</A> guide.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="upgrading.html">Next</A>
</BODY>
</HTML>
doc/ipsec.conf.2_to_1
-22
View File
@@ -1,22 +0,0 @@
version 2
# If you put the preceding line in front of a 1.x ipsec.conf,
# it should work within 2.x.
# Merge the following sections with your existing config setup
# and conn %default.
# Allot these values to any you have not explictly defined.
config setup
interfaces=%none # new default is %defaultroute
plutoload=%none # new default is %search
plutostart=%none # new default is %search
conn %default
uniqueids=no # new default is yes
keyingtries=3 # new default is %forever
disablearrivalcheck=yes # new default is no
authby=secret # new default is rsasig
leftrsasigkey=%none # new default %dnsondemand
rightrsasigkey=%none # new default %dnsondemand
doc/ipsec.html
-1040
View File
File diff suppressed because it is too large Load Diff
doc/kernel.html
-353
View File
@@ -1,353 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="testing.html">Previous</A>
<A HREF="adv_config.html">Next</A>
<HR>
<H1><A name="kernelconfig">Kernel configuration for FreeS/WAN</A></H1>
<P> This section lists many of the options available when configuring a
Linux kernel, and explains how they should be set on a FreeS/WAN IPsec
gateway.</P>
<H2><A name="notall">Not everyone needs to worry about kernel
configuration</A></H2>
<P>Note that in many cases you do not need to mess with these.</P>
<P> You may have a Linux distribution which comes with FreeS/WAN
installed (see this<A href="intro.html#products"> list</A>). In that
case, you need not do a FreeS/WAN installation or a kernel
configuration. Of course, you might still want to configure and rebuild
your kernel to improve performance or security. This can be done with
standard tools described in the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
Kernel HowTo</A>.</P>
<P>If you need to install FreeS/WAN, then you do need to configure a
kernel. However, you may choose to do that using the simplest
procedure:</P>
<UL>
<LI>Configure, build and test a kernel for your system before adding
FreeS/WAN. See the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
Kernel HowTo</A> for details.<STRONG> This step cannot be skipped</STRONG>
. FreeS/WAN needs the results of your configuration.</LI>
<LI>Then use FreeS/WAN's<VAR> make oldgo</VAR> command. This sets
everything FreeS/WAN needs and retains your values everywhere else.</LI>
</UL>
<P> This document is for those who choose to configure their FreeS/WAN
kernel themselves.</P>
<H2><A name="assume">Assumptions and notation</A></H2>
<P> Help text for most kernel options is included with the kernel files,
and is accessible from within the configuration utilities. We assume
you will refer to that, and to the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
Kernel HowTo</A>, as necessary. This document covers only the
FreeS/WAN-specific aspects of the problem.</P>
<P> To avoid duplication, this document section does not cover settings
for the additional IPsec-related kernel options which become available
after you have patched your kernel with FreeS/WAN patches. There is
help text for those available from within the configuration utility.</P>
<P> We assume a common configuration in which the FreeS/WAN IPsec
gateway is also doing ipchains(8) firewalling for a local network, and
possibly masquerading as well.</P>
<P> Some suggestions below are labelled as appropriate for &quot;a true
paranoid&quot;. By this we mean they may cause inconvenience and it is not
entirely clear they are necessary, but they appear to be the safest
choice. Not using them might entail some risk. Of course one suggested
mantra for security administrators is: &quot;I know I'm paranoid. I wonder
if I'm paranoid enough.&quot;</P>
<H3><A name="labels">Labels used</A></H3>
<P> Six labels are used to indicate how options should be set. We mark
the labels with [square brackets]. For two of these labels, you have no
choice:</P>
<DL>
<DT>[required]</DT>
<DD>essential for FreeS/WAN operation.</DD>
<DT>[incompatible]</DT>
<DD>incompatible with FreeS/WAN.</DD>
</DL>
<P>those must be set correctly or FreeS/WAN will not work</P>
<P>FreeS/WAN should work with any settings of the others, though of
course not all combinations have been tested. We do label these in
various ways, but<EM> these labels are only suggestions</EM>.</P>
<DL>
<DT>[recommended]</DT>
<DD>useful on most FreeS/WAN gateways</DD>
<DT>[disable]</DT>
<DD>an unwelcome complication on a FreeS/WAN gateway.</DD>
<DT>[optional]</DT>
<DD>Your choice. We outline issues you might consider.</DD>
<DT>[anything]</DT>
<DD>This option has no direct effect on FreeS/WAN and related tools, so
you should be able to set it as you please.</DD>
</DL>
<P> Of course complexity is an enemy in any effort to build secure
systems.<STRONG> For maximum security, any feature that can reasonably
be turned off should be</STRONG>. &quot;If in doubt, leave it out.&quot;</P>
<H2><A name="kernelopt">Kernel options for FreeS/WAN</A></H2>
<P> Indentation is based on the nesting shown by 'make menuconfig' with
a 2.2.16 kernel for the i386 architecture.</P>
<DL>
<DT><A name="maturity">Code maturity and level options</A></DT>
<DD>
<DL>
<DT><A name="devel">Prompt for development ... code/drivers</A></DT>
<DD>[optional] If this is<VAR> no</VAR>, experimental drivers are not
shown in later menus.
<P>For most FreeS/WAN work,<VAR> no</VAR> is the preferred setting.
Using new or untested components is too risky for a security gateway.</P>
<P>However, for some hardware (such as the author's network cards) the
only drivers available are marked<VAR> new/experimental</VAR>. In such
cases, you must enable this option or your cards will not appear under
&quot;network device support&quot;. A true paranoid would leave this option off
and replace the cards.</P>
</DD>
<DT>Processor type and features</DT>
<DD>[anything]</DD>
<DT>Loadable module support</DT>
<DD>
<DL>
<DT>Enable loadable module support</DT>
<DD>[optional] A true paranoid would disable this. An attacker who has
root access to your machine can fairly easily install a bogus module
that does awful things, provided modules are enabled. A common tool for
attackers is a &quot;rootkit&quot;, a set of tools the attacker uses once he or
she has become root on your system. The kit introduces assorted
additional compromises so that the attacker will continue to &quot;own&quot; your
system despite most things you might do to recovery the situation. For
Linux, there is a tool called<A href="http://www.sans.org/newlook/resources/IDFAQ/knark.htm">
knark</A> which is basically a rootkit packaged as a kernel module.
<P>With modules disabled, an attacker cannot install a bogus module. The
only way he can achieve the same effects is to install a new kernel and
reboot. This is considerably more likely to be noticed.</P>
<P>Many FreeS/WAN gateways run with modules enabled. This simplifies
some administrative tasks and some ipchains features are available only
as modules. Once an enemy has root on your machine your security is
nil, so arguably defenses which come into play only in that situation
are pointless.</P>
<P></P>
</DD>
<DT>Set version information ....</DT>
<DD>[optional] This provides a check to prevent loading modules compiled
for a different kernel.</DD>
<DT>Kernel module loader</DT>
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
entails some risk.</DD>
</DL>
</DD>
<DT>General setup</DT>
<DD>We list here only the options that matter for FreeS/WAN.
<DL>
<DT>Networking support</DT>
<DD>[required]</DD>
<DT>Sysctl interface</DT>
<DD>[optional] If this option is turned on and the<VAR> /proc</VAR>
filesystem installed, then you can control various system behaviours by
writing to files under<VAR> /proc/sys</VAR>. For example:
<PRE> echo 1 &gt; /proc/sys/net/ipv4/ipforward</PRE>
turns IP forwarding on.
<P>Disabling this option breaks many firewall scripts. A true paranoid
would disable it anyway since it might conceivably be of use to an
attacker.</P>
</DD>
</DL>
</DD>
<DT>Plug and Play support</DT>
<DD>[anything]</DD>
<DT>Block devices</DT>
<DD>[anything]</DD>
<DT>Networking options</DT>
<DD>
<DL>
<DT>Packet socket</DT>
<DD>[optional] This kernel feature supports tools such as tcpdump(8)
which communicate directly with network hardware, bypassing kernel
protocols. This is very much a two-edged sword:
<UL>
<LI>such tools can be very useful to the firewall admin, especially
during initial testing</LI>
<LI>should an evildoer breach your firewall, such tools could give him
or her a great deal of information about the rest of your network</LI>
</UL>
We recommend disabling this option on production gateways.</DD>
<DT><A name="netlink">Kernel/User netlink socket</A></DT>
<DD>[optional] Required if you want to use<A href="#adv"> advanced
router</A> features.</DD>
<DT>Routing messages</DT>
<DD>[optional]</DD>
<DT>Netlink device emulation</DT>
<DD>[optional]</DD>
<DT>Network firewalls</DT>
<DD>[recommended] You need this if the IPsec gateway also functions as a
firewall.
<P>Even if the IPsec gateway is not your primary firewall, we suggest
setting this so that you can protect the gateway with at least basic
local packet filters.</P>
</DD>
<DT>Socket filtering</DT>
<DD>[disable] This enables an older filtering interface. We suggest
using ipchains(8) instead. To do that, set the &quot;Network firewalls&quot;
option just above, and not this one.</DD>
<DT>Unix domain sockets</DT>
<DD>[required] These sockets are used for communication between the<A href="manpage.d/ipsec.8.html">
ipsec(8)</A> commands and the<A href="manpage.d/ipsec_pluto.8.html">
ipsec_pluto(8)</A> daemon.</DD>
<DT>TCP/IP networking</DT>
<DD>[required]
<DL>
<DT>IP: multicasting</DT>
<DD>[anything]</DD>
<DT><A name="adv">IP: advanced router</A></DT>
<DD>[optional] This gives you policy routing, which some people have
used to good advantage in their scripts for FreeS/WAN gateway
management. It is not used in our distributed scripts, so not required
unless you want it for custom scripts. It requires the<A href="#netlink">
netlink</A> interface between kernel code and the iproute2(8) command.</DD>
<DT>IP: kernel level autoconfiguration</DT>
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
entails some risk.</DD>
<DT>IP: firewall packet netlink device</DT>
<DD>[disable]</DD>
<DT>IP: transparent proxy support</DT>
<DD>[optional] This is required in some firewall configurations, but
should be disabled unless you have a definite need for it.</DD>
<DT>IP: masquerading</DT>
<DD>[optional] Required if you want to use<A href="glossary.html#non-routable">
non-routable</A> private IP addresses for your local network.</DD>
<DT>IP: Optimize as router not host</DT>
<DD>[recommended]</DD>
<DT>IP: tunneling</DT>
<DD>[required]</DD>
<DT>IP: GRE tunnels over IP</DT>
<DD>[anything]</DD>
<DT>IP: aliasing support</DT>
<DD>[anything]</DD>
<DT>IP: ARP daemon support (EXPERIMENTAL)</DT>
<DD>Not required on most systems, but might prove useful on
heavily-loaded gateways.</DD>
<DT>IP: TCP syncookie support</DT>
<DD>[recommended] It provides a defense against a<A href="glossary.html#DOS">
denial of service attack</A> which uses bogus TCP connection requests
to waste resources on the victim machine.</DD>
<DT>IP: Reverse ARP</DT>
<DD></DD>
<DT>IP: large window support</DT>
<DD>[recommended] unless you have less than 16 meg RAM</DD>
</DL>
</DD>
<DT>IPv6</DT>
<DD>[optional] FreeS/WAN does not currently support IPv6, though work on
integrating FreeS/WAN with the Linux IPv6 stack has begun.<A href="compat.html#ipv6">
Details</A>.
<P> It should be possible to use IPv4 FreeS/WAN on a machine which also
does IPv6. This combination is not yet well tested. We would be quite
interested in hearing results from anyone expermenting with it, via the<A
href="mail.html"> mailing list</A>.</P>
<P> We do not recommend using IPv6 on production FreeS/WAN gateways
until more testing has been done.</P>
</DD>
<DT>Novell IPX</DT>
<DD>[disable]</DD>
<DT>Appletalk</DT>
<DD>[disable] Quite a few Linux installations use IP but also have some
other protocol, such as Appletalk or IPX, for communication with local
desktop machines. In theory it should be possible to configure IPsec
for the IP side of things without interfering with the second protocol.
<P>We do not recommend this. Keep the software on your gateway as simple
as possible. If you need a Linux-based Appletalk or IPX server, use a
separate machine.</P>
</DD>
</DL>
</DD>
<DT>Telephony support</DT>
<DD>[anything]</DD>
<DT>SCSI support</DT>
<DD>[anything]</DD>
<DT>I2O device support</DT>
<DD>[anything]</DD>
<DT>Network device support</DT>
<DD>[anything] should work, but there are some points to note.
<P>The development team test almost entirely on 10 or 100 megabit
Ethernet and modems. In principle, any device that can do IP should be
just fine for IPsec, but in the real world any device that has not been
well-tested is somewhat risky. By all means try it, but don't bet your
project on it until you have solid test results.</P>
<P>If you disabled experimental drivers in the<A href="#maturity"> Code
maturity</A> section above, then those drivers will not be shown here.
Check that option before going off to hunt for missing drivers.</P>
<P>If you want Linux to automatically find more than one ethernet
interface at boot time, you need to:</P>
<UL>
<LI>compile the appropriate driver(s) into your kernel. Modules will not
work for this</LI>
<LI>add a line such as
<PRE>
append=&quot;ether=0,0,eth0 ether=0,0,eth1&quot;
</PRE>
to your /etc/lilo.conf file. In some cases you may need to specify
parameters such as IRQ or base address. The example uses &quot;0,0&quot; for
these, which tells the system to search. If the search does not succeed
on your hardware, then you should retry with explicit parameters. See
the lilo.conf(5) man page for details.</LI>
<LI>run lilo(8)</LI>
</UL>
Having Linux find the cards this way is not necessary, but is usually
more convenient than loading modules in your boot scripts.</DD>
<DT>Amateur radio support</DT>
<DD>[anything]</DD>
<DT>IrDA (infrared) support</DT>
<DD>[anything]</DD>
<DT>ISDN subsystem</DT>
<DD>[anything]</DD>
<DT>Old CDROM drivers</DT>
<DD>[anything]</DD>
<DT>Character devices</DT>
<DD>The only required character device is:
<DL>
<DT>random(4)</DT>
<DD>[required] This is a source of<A href="glossary.html#random"> random</A>
numbers which are required for many cryptographic protocols, including
several used in IPsec.
<P>If you are comfortable with C source code, it is likely a good idea
to go in and adjust the<VAR> #define</VAR> lines in<VAR>
/usr/src/linux/drivers/char/random.c</VAR> to ensure that all sources
of randomness are enabled. Relying solely on keyboard and mouse
randomness is dubious procedure for a gateway machine. You could also
increase the randomness pool size from the default 512 bytes (128
32-bit words).</P>
</DD>
</DL>
</DD>
<DT>Filesystems</DT>
<DD>[anything] should work, but we suggest limiting a gateway machine to
the standard Linux ext2 filesystem in most cases.</DD>
<DT>Network filesystems</DT>
<DD>[disable] These systems are an unnecessary risk on an IPsec gateway.</DD>
<DT>Console drivers</DT>
<DD>[anything]</DD>
<DT>Sound</DT>
<DD>[anything] should work, but we suggest enabling sound only if you
plan to use audible alarms for firewall problems.</DD>
<DT>Kernel hacking</DT>
<DD>[disable] This might be enabled on test machines, but should not be
on production gateways.</DD>
</DL>
</DD>
</DL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="testing.html">Previous</A>
<A HREF="adv_config.html">Next</A>
</BODY>
</HTML>
doc/kernel.notes
-173
View File
@@ -1,173 +0,0 @@
Notes on Red Hat 5.2 kernel installation (See Addendum for RH6.1)
=================================================================
Warning: We (the FreeS/WAN Project http://www.xs4all.nl/~freeswan/)
had nothing to do with designing the kernel installation process. This
document explains some tricky points that we wish we had been told.
We don't know if these notes apply to systems other than Red Hat 5.2.
This is meant as a supplement to other kernel install guides (such as
the Red Hat 5.2 Installation Guide section 11.6).
Goal: install a new kernel on RH5.2 in such a way that it doesn't
interfere with any other kernels. This should be repeatable: each new
kernel should have this property. Each should remain bootable.
Problem: there are several components to a kernel, and each must be
segregated. How are the parts kept apart? How are they found?
All the parts live in the file system, so it all comes down to
pathnames. Well, except for the fiddly bits in /etc/lilo.conf. What
are the parts?
/lib/modules/VER/ directory for kernel modules
/boot/vmlinux-VER the kernel
/boot/System.map-VER the kernel symbol table
/boot/initrd-VER.img the initial ramdisk (for modules needed
at boot time -- usually not necessary)
/boot/boot.b the second-stage loader
/boot/map the map file, an index into system index for
all files used by boot loader (all kernels,
all initrds, perhaps /boot/boot.b, and itself)
This list does not include /boot/module-info-VER. That is supplied
by RedHat, and it isn't clear to me how to build it or why.
In each entry, I've used "VER" to signify a version number. For
RH-supplied kernels, these look like 2.0.36-0.7 (the original 5.2) or
2.0.36-3 (the kernel updates).
There are also symbolic links:
/lib/modules/preferred created by /etc/rc.d/rc.sysinit
/boot/System.map created by /etc/rc.d/rc.sysinit
/boot/module-info created by /etc/rc.d/rc.sysinit
/vmlinuz created by ???
I don't know when the /vmlinuz symlink is set up and I don't know
for what it is used.
If you follow the RH procedures, documented in 11.6 of their Installation
Guide, all your VERs will be 2.0.36. This is very bad: all your builds
will step on each other. Worse, your new module directory will be half
picked up when you boot a stock RH kernel binary!
It is important to know how the various parts of the built kernel are
found at booting.
- the kernel path is specified in the image= option in lilo.conf.
(Lilo.conf may specify several and one is selected at boot time
by default or user selection.) The kernel is loaded by the
boot loader.
- The initial ramdisk is a per-image option (initrd=) specified in
lilo.conf. (It isn't described in the RH5.2 lilo.conf(5) manpage!).
The initial ramdisk is loaded into RAM by the boot loader.
- Since the boot loader doesn't know about the file system, it needs a
map to figure out which absolute disk blocks to load, and where.
This is /boot/map. It is built by the lilo command (also known as
the map installer). It will have indices for the all the kernels
that can be booted, all their initial ram disks, perhaps
/boot/boot.b, and itself. This is why moving the blocks of these
files throws off the boot loader -- lilo must be rerun after even a
cp command to one of them.
- the modules directory is found two different ways. Unfortunately,
they don't mesh properly:
+ at boot time, /etc/rc.d/rc.sysinit tries to figure out the correct
subdirectory of /lib/modules, using the .rhkmvtag trick (see
later). It then builds a symlink /lib/modules/preferred to
record this. It also invokes depmod to build the module
dependency info. At the same time, it creates the symlinks
/boot/System.map and /boot/module-info, using the inferred
value for VER!
+ modprobe and friends stupidly look first in /lib/modules/2.0.36
(more precisely, /lib/modules/`uname -r`) and then in
/lib/modules/preferred. So if there is a /lib/modules/2.0.36 and
it is the wrong one, you are in trouble.
If there is no /lib/modules/2.0.36, then both searches above will
agree (a very Good Thing). So I recommend strongly that you not
have a /lib/boot/2.0.36 at boot time. Unfortunately, you will get
one during the kernel install process. Be sure to rename it. I
suggest using 2.0.36-x (for some unique x) as VER.
- Red Hat supplied /lib/modules/VER directories contain a hidden file
.rhkmvtag. This file contains exactly one line. This line is
exactly the same as the contents of /proc/version while the
corresponding kernel is running. For the stock kernel, the line is:
Linux version 2.0.36 ([email protected]) (gcc version 2.7.2.3) #1 Tue Dec 29 13:11:13 EST 1998
- At boot time, /etc/rc.d/rc.sysinit uses the .rhkmvtag files to
figure out which of the /lib/modules/* directories matches the
kernel. If it could figure out the directory, it uses this
information to set the symlinks mentioned above. It then runs
depmod to build the module dependency information (in
/lib/modules/preferred/modules.dep, if it created the
/lib/modules/preferred symlink). I recommend looking at the code.
- The documented kernel install procedures DO NOT fill in the
.rhkmvtag file for the new modules directory! So you should do so
by hand. You have to figure out what the contents should be. Here
is is a command that will do the job, assuming that
/usr/src/linux/vmlinux is the kernel associated with
/lib/modules/2.0.36/:
strings /usr/src/linux/vmlinux \
| grep 'x version' >/lib/modules/2.0.36/.rhkmvtag
I've recommended (above) that you use 2.0.36-x for VER when you install
a kernel. What should x be? I have found that there is a hidden file
/usr/src/linux/.version which contains a counter that gets incremented
whenever you do a "make install" in the kernel (see target
newversion). There are some other times that it gets incremented, but
I think that it all works out. It also gets incorporated into the
resulting kernel's /proc/version, prefixed with ``#''. This makes it
a natural.
Here is a script to do the recommended renaming:
# VER will eventually need to be updated
VER=2.0.36
VERX=${VER}-`cat /usr/src/linux/.version`
strings /usr/src/linux/vmlinux | grep 'x version' >/lib/modules/$VER/.rhkmvtag
mv /lib/modules/$VER /lib/modules/$VERX
mv /boot/System.map-$VER /boot/System.map-$VERX
mv /boot/vmlinuz-$VER /boot/vmlinuz-$VERX
And, if an initrd has been built (usually it is best to arrange not to
use one -- see the Red Hat Installation Guide):
/sbin/mkinitrd /boot/initrd-$VERX.img $VERX
Remember: a new lilo.conf entry is needed for the new kernel, and then
the lilo command will need to be rerun.
Now that kernel installs don't overwrite the results of previous ones,
you will need to manually delete the components and their lilo entry
to get rid of them.
Please send comments, additions, and corrections to:
Hugh Redelmeier
[email protected] voice: +1 416 482-8253
Addendum: Red Hat 6.1
=====================
The kernel supplied with RH6.1 kernel is out of date, so you might
wish to use a newer one.
Much of the description for 5.2 still applies, but the procedure is
quite different because the .version file is no longer used. Instead,
the top-level Makefile contains a definition EXTRAVERSION which adds a
qualifier to the version for most purposes. No manual renaming is
required.
Before building the kernel, change EXTRAVERSION by editing
/usr/src/linux/Makefile, and make an appropriate entry in /etc/lilo.conf.
EXTRAVERSION is a feature of the standard kernel sources, not just the
ones supplied by Red Hat.
doc/mail.html
-216
View File
@@ -1,216 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="ipsec.html">Previous</A>
<A HREF="web.html">Next</A>
<HR>
<H1><A name="lists">Mailing lists and newsgroups</A></H1>
<H2><A name="list.fs">Mailing lists about FreeS/WAN</A></H2>
<H3><A name="projlist">The project mailing lists</A></H3>
<P>The Linux FreeS/WAN project has several email lists for user support,
bug reports and software development discussions.</P>
<P>We had a single list on clinet.fi for several years (Thanks, folks!),
then one list on freeswan.org, but now we've split into several lists:</P>
<DL>
<DT><A href="mailto:[email protected]?body=subscribe">
users</A></DT>
<DD>
<UL>
<LI>The general list for discussing use of the software</LI>
<LI>The place for seeking<STRONG> help with problems</STRONG> (but
please check the<A href="faq.html"> FAQ</A> first).</LI>
<LI>Anyone can post.</LI>
</UL>
</DD>
<DT><A href="mailto:[email protected]?body=subscribe">bugs</A>
</DT>
<DD>
<UL>
<LI>For<STRONG> bug reports</STRONG>.</LI>
<LI>If you are not certain what is going on -- could be a bug, a
configuration error, a network problem, ... -- please post to the users
list instead.</LI>
<LI>Anyone can post.</LI>
</UL>
</DD>
<DT><A href="mailto:[email protected]?body=subscribe">
design</A></DT>
<DD>
<UL>
<LI><STRONG>Design discussions</STRONG>, for people working on FreeS/WAN
development or others with an interest in design and security issues.</LI>
<LI>It would be a good idea to read the existing design papers (see this<A
href="intro.html#applied"> list</A>) before posting.</LI>
<LI>Anyone can post.</LI>
</UL>
</DD>
<DT><A href="mailto:[email protected]?body=subscribe">
announce</A></DT>
<DD>
<UL>
<LI>A<STRONG> low-traffic</STRONG> list.</LI>
<LI><STRONG>Announcements</STRONG> about FreeS/WAN and related software.</LI>
<LI>All posts here are also sent to the users list. You need not
subscribe to both.</LI>
<LI>Only the FreeS/WAN team can post.</LI>
<LI>If you have something you feel should go on this list, send it to<VAR>
[email protected]</VAR>. Unless it is obvious, please
include a short note explaining why we should post it.</LI>
</UL>
</DD>
<DT><A href="mailto:[email protected]?body=subscribe">
briefs</A></DT>
<DD>
<UL>
<LI>A<STRONG> low-traffic</STRONG> list.</LI>
<LI><STRONG>Weekly summaries</STRONG> of activity on the users list.</LI>
<LI>All posts here are also sent to the users list. You need not
subscribe to both.</LI>
<LI>Only the FreeS/WAN team can post.</LI>
</UL>
</DD>
</DL>
<P>To subscribe to any of these, you can:</P>
<UL>
<LI>just follow the links above</LI>
<LI>use our<A href="http://www.freeswan.org/mail.html"> web interface</A>
</LI>
<LI>send mail to<VAR> listname</VAR>[email protected] with a
one-line message body &quot;subscribe&quot;</LI>
</UL>
<P>Archives of these lists are available via the<A href="http://www.freeswan.org/mail.html">
web interface</A>.</P>
<H4><A name="which.list">Which list should I use?</A></H4>
<P>For most questions, please check the<A href="faq.html"> FAQ</A>
first, and if that does not have an answer, ask on the users list. &quot;My
configuration doesn't work.&quot; does not belong on the bugs list, and &quot;Can
FreeS/WAN do such-and-such&quot; or &quot;How do I configure it to...&quot; do not
belong in design discussions.</P>
<P>Cross-posting the same message to two or more of these lists is
discouraged. Quite a few people read more than one list and getting
multiple copies is annoying.</P>
<H4><A name="policy.list">List policies</A></H4>
<P><STRONG>US citizens or residents are asked not to post code to the
lists, not even one-line bug fixes</STRONG>. The project cannot accept
code which might entangle it in US<A href="politics.html#exlaw"> export
restrictions</A>.</P>
<P>Non-subscribers can post to some of these lists. This is necessary;
someone working on a gateway install who encounters a problem may not
have access to a subscribed account.</P>
<P>Some spam turns up on these lists from time to time. For discussion
of why we do not attempt to filter it, see the<A href="faq.html#spam">
FAQ</A>. Please do not clutter the lists with complaints about this.</P>
<H3><A name="archive">Archives of the lists</A></H3>
<P>Searchable archives of the old single list have existed for some
time. At time of writing, it is not yet clear how they will change for
the new multi-list structure.</P>
<UL>
<LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
<LI><A href="http://www.nexial.com">Holland</A></LI>
</UL>
<P>Note that these use different search engines. Try both.</P>
<P>Archives of the new lists are available via the<A href="http://www.freeswan.org/mail.html">
web interface</A>.</P>
<H2><A name="indexes">Indexes of mailing lists</A></H2>
<P><A href="http://paml.net/">PAML</A> is the standard reference for<STRONG>
P</STRONG>ublicly<STRONG> A</STRONG>ccessible<STRONG> M</STRONG>ailing<STRONG>
L</STRONG>ists. When we last checked, it had over 7500 lists on an
amazing variety of topics. It also has FAQ information and a search
engine.</P>
<P>There is an index of<A href="http://oslab.snu.ac.kr/~djshin/linux/mail-list/index.shtml">
Linux mailing lists</A> available.</P>
<P>A list of<A href="http://xforce.iss.net/maillists/otherlists.php">
computer security mailing lists</A>, with descriptions.</P>
<H2><A name="otherlists">Lists for related software and topics</A></H2>
<P>Most links in this section point to subscription addresses for the
various lists. Send the one-line message &quot;subscribe<VAR> list_name</VAR>
&quot; to subscribe to any of them.</P>
<H3><A NAME="28_3_1">Products that include FreeS/WAN</A></H3>
<P>Our introduction document gives a<A href="intro.html#products"> list
of products that include FreeS/WAN</A>. If you have, or are
considering, one of those, check the supplier's web site for
information on mailing lists for their users.</P>
<H3><A name="linux.lists">Linux mailing lists</A></H3>
<UL>
<LI><A href="mailto:[email protected]">
[email protected]</A>, for Linux system administrators</LI>
<LI><A href="mailto:[email protected]">
[email protected]</A>, about Netfilter, which replaces IPchains
in kernels 2.3.15 and later</LI>
<LI><A href="mailto:[email protected]">
[email protected]</A>, for people working on security
audits of various Linux programs</LI>
<LI><A href="mailto:[email protected]">
[email protected]</A>, for discussion of issues common to
all the half dozen projects working on secure Linux distributions.</LI>
</UL>
<P>Each of the scure distribution projects also has its own web site and
mailing list. Some of the sites are:</P>
<UL>
<LI><A href="http://bastille-linux.org/">Bastille Linux</A> scripts to
harden Redhat, e.g. by changing permissions and modifying inialisation
scripts</LI>
<LI><A href="http://immunix.org/">Immunix</A> take a different approach,
using a modified compiler to build kernel and utilities with better
resistance to various types of overflow and exploit</LI>
<LI>the<A href="glossary.html#NSA"> NSA</A> have contractors working on
a<A href="glossary.html#SElinux"> Security Enhanced Linux</A>,
primarily adding stronger access control mechanisms. You can download
the current version (which interestingly is under GPL and not export
resrtricted) or subscribe to the mailing list from the<A href="http://www.nsa.gov/selinux">
project web page</A>.</LI>
</UL>
<H3><A name="ietf">Lists for IETF working groups</A></H3>
<P>Each<A href="glossary.html#IETF"> IETF</A> working group has an
associated mailing list where much of the work takes place.</P>
<UL>
<LI><A href="mailto:[email protected]">[email protected]</A>
, the IPsec<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
working group</A>. This is where the protocols are discussed, new
drafts announced, and so on. By now, the IPsec working group is winding
down since the work is essentially complete. A<A href="http://www.sandelman.ottawa.on.ca/ipsec/">
list archive</A> is available.</LI>
<LI><A href="mailto:[email protected]">IPsec policy</A>
list, and its<A href="http://www.vpnc.org/ipsec-policy/"> archive</A></LI>
<LI><A href="mailto:[email protected]">IP secure remote access</A>
list, and its<A href="http://www.vpnc.org/ietf-ipsra/mail-archive/">
archive</A></LI>
</UL>
<H3><A name="other">Other mailing lists</A></H3>
<UL>
<LI><A href="mailto:[email protected]">
[email protected]</A> a low-traffic list with announcements of
developments in privacy, encryption and online civil rights</LI>
<LI>a VPN mailing list's<A href="http://kubarb.phsx.ukans.edu/~tbird/vpn.html">
home page</A></LI>
</UL>
<H2><A name="newsgroups">Usenet newsgroups</A></H2>
<UL>
<LI>sci.crypt</LI>
<LI>sci.crypt.research</LI>
<LI>comp.dcom.vpn</LI>
<LI>talk.politics.crypto</LI>
</UL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="ipsec.html">Previous</A>
<A HREF="web.html">Next</A>
</BODY>
</HTML>
doc/makecheck.html
-523
View File
@@ -1,523 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="umltesting.html">Previous</A>
<A HREF="nightly.html">Next</A>
<HR>
<H1><A name="makecheck">How to configure to use &quot;make check&quot;</A></H1>
<H2><A NAME="38_1">What is &quot;make check&quot;</A></H2>
<P> &quot;make check&quot; is a target in the top level makefile. It takes care of
running a number of unit and system tests to confirm that FreeSWAN has
been compiled correctly, and that no new bugs have been introduced.</P>
<P> As FreeSWAN contains both kernel and userspace components, doing
testing of FreeSWAN requires that the kernel be simulated. This is
typically difficult to do as a kernel requires that it be run on bare
hardware. A technology has emerged that makes this simpler. This is<A HREF="http://user-mode-linux.sourceforge.net">
User Mode Linux</A>.</P>
<P> User-Mode Linux is a way to build a Linux kernel such that it can
run as a process under another Linux (or in the future other) kernel.
Presently, this can only be done for 2.4 guest kernels. The host kernel
can be 2.2 or 2.4.</P>
<P> &quot;make check&quot; expects to be able to build User-Mode Linux kernels
with FreeSWAN included. To do this it needs to have some files
downloaded and extracted prior to running &quot;make check&quot;. This is
described in the<A HREF="umltesting.html"> UML testing</A> document.</P>
<P> After having run the example in the UML testing document and
successfully brought up the four machine combination, you are ready to
use &quot;make check&quot;</P>
<H2><A NAME="38_2">Running &quot;make check&quot;</A></H2>
<P> &quot;make check&quot; works by walking the FreeSWAN source tree invoking the
&quot;check&quot; target at each node. At present there are tests defined only
for the <CODE>klips</CODE> directory. These tests will use the UML
infrastructure to test out pieces of the <CODE>klips</CODE> code.</P>
<P> The results of the tests can be recorded. If the environment
variable <CODE>$REGRESSRESULTS</CODE> is non-null, then the results of
each test will be recorded. This can be used as part of a nightly
regression testing system, see<A HREF="nightly.html"> Nightly testing</A>
for more details.</P>
<P> &quot;make check&quot; otherwise prints a minimal amount of output for each
test, and indicates pass/fail status of each test as they are run.
Failed tests do not cause failure of the target in the form of exit
codes.</P>
<H1><A NAME="39">How to write a &quot;make check&quot; test</A></H1>
<H2><A NAME="39_1">Structure of a test</A></H2>
<P> Each test consists of a set of directories under <CODE>testing/</CODE>
. There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>
packaging</CODE> and <CODE>libraries</CODE>. Each directory has a list
of tests to run is stored in a file called <CODE>TESTLIST</CODE> in
that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>.</P>
<H2 NAME="TESTLIST"><A NAME="39_2">The TESTLIST</A></H2>
<P> This isn't actually a shell script. It just looks like one. Some
tools other than /bin/sh process it. Lines that start with # are
comments.</P>
<PRE>
# test-kind directory-containing-test expectation [PR#]
</PRE>
<P>The first word provides the test type, detailed below.</P>
<P> The second word is the name of the test to run. This the directory
in which the test case is to be found..</P>
<P>The third word may be one of:</P>
<DL>
<DT> blank/good</DT>
<DD>the test is believed to function, report failure</DD>
<DT> bad</DT>
<DD> the test is known to fail, report unexpected success</DD>
<DT> suspended</DT>
<DD> the test should not be run</DD>
</DL>
<P> The fourth word may be a number, which is a PR# if the test is
failing.</P>
<H2><A NAME="39_3">Test kinds</A></H2>
The test types are:
<DL>
<DT>skiptest</DT>
<DD>means run no test.</DD>
<DT>ctltest</DT>
<DD>means run a single system without input/output.</DD>
<DT>klipstest</DT>
<DD>means run a single system with input/output networks</DD>
<DT><A HREF="#umlplutotest">umlplutotest</A></DT>
<DD>means run a pair of systems</DD>
<DT><A HREF="#umlXhost">umlXhost</A></DT>
<DD>run an arbitrary number of systems</DD>
<DT>suntest (TBD)</DT>
<DD>means run a quad of east/west/sunrise/sunset</DD>
<DT>roadtest (TBD)</DT>
<DD>means run a trio of east-sunrise + warrior</DD>
<DT>extrudedtest (TBD)</DT>
<DD>means run a quad of east-sunrise + warriorsouth + park</DD>
<DT>mkinsttest</DT>
<DD>a test of the &quot;make install&quot; machinery.</DD>
<DT>kernel_test_patch</DT>
<DD>a test of the &quot;make kernelpatch&quot; machinery.</DD>
</DL>
Tests marked (TBD) have yet to be fully defined.
<P> Each test directory has a file in it called <CODE>testparams.sh</CODE>
. This file sets a number of environment variables to define the
parameters of the test.</P>
<H2><A NAME="39_4">Common parameters</A></H2>
<DL>
<DT>TESTNAME</DT>
<DD>the name of the test (repeated for checking purposes)</DD>
<DT>TEST_TYPE</DT>
<DD>the type of the test (repeat of type type above)</DD>
<DT>TESTHOST</DT>
<DD>the name of the UML machine to run for the test, typically &quot;east&quot; or
&quot;west&quot;</DD>
<DT>TEST_PURPOSE</DT>
<DD>The purpose of the test is one of:
<DL>
<DT>goal</DT>
<DD>The goal purpose is where a test is defined for code that is not yet
finished. The test indicates when the goals have in fact been reached.</DD>
<DT>regress</DT>
<DD>This is a test to determine that a previously existing bug has been
repaired. This test will initially be created to reproduce the bug in
isolation, and then the bug will be fixed.</DD>
<DT>exploit</DT>
<DD>This is a set of packets/programs that causes a vulnerability to be
exposed. It is a specific variation of the regress option.</DD>
</DL>
</DD>
<DT>TEST_GOAL_ITEM</DT>
<DT></DT>
<DD>in the case of a goal test, this is a reference to the requirements
document</DD>
<DT>TEST_PROB_REPORT</DT>
<DD>in the case of regression test, this the problem report number from
GNATS</DD>
<DT>TEST_EXPLOIT_URL</DT>
<DD>in the case of an exploit, this is a URL referencing the paper
explaining the origin of the test and the origin of exploit software</DD>
<DT>REF_CONSOLE_OUTPUT</DT>
<DD>a file in the test directory that contains the sanitized console
output against which to compare the output of the actual test.</DD>
<DT>REF_CONSOLE_FIXUPS</DT>
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
to sanitize the console output of the machine under test. These are
typically perl, awk or sed scripts that remove things in the kernel
output that change each time the test is run and/or compiled.</DD>
<DT>INIT_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode prior to starting the tests. This file will usually
set up any eroute's and SADB entries that are required for the test.</P>
<P>Lines beginning with # are skipped. Blank lines are skipped.
Otherwise, a shell prompted is waited for each time (consisting of <CODE>
\n#</CODE>) and then the command is sent. Note that the prompt is waited
for before the command and not after, so completion of the last command
in the script is not required. This is often used to invoke a program
to monitor the system, e.g. <CODE>ipsec pf_key</CODE>.</P>
</DD>
<DT>RUN_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode, before the packets are sent. On single machine tests,
this script doesn't provide any more power than INIT_SCRIPT, but is
implemented for consistency's sake.</P>
</DD>
<DT>FINAL_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode after the final packet is sent. Similar to
INIT_SCRIPT, above. If not specified, then the single command &quot;halt&quot; is
sent. If specified, then the script should end with a halt command to
nicely shutdown the UML.</P>
</DD>
<DT>CONSOLEDIFFDEBUG</DT>
<DD>If set to &quot;true&quot; then the series of console fixups (see
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
be set to &quot;false&quot;, or unset otherwise)</DD>
<DT>NETJIGDEBUG</DT>
<DD>If set to &quot;true&quot; then the series of console fixups (see
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
be set to &quot;false&quot;, or unset otherwise)</DD>
<DT>NETJIGTESTDEBUG</DT>
<DD> If set to &quot;netjig&quot;, then the results of talking to the <CODE>
uml_netjig</CODE> will be printed to stderr during the test. In
addition, the jig will be invoked with --debug, which causes it to log
its process ID, and wait 60 seconds before continuing. This can be used
if you are trying to debug the <CODE>uml_netjig</CODE> program itself.</DD>
<DT>HOSTTESTDEBUG</DT>
<DD> If set to &quot;hosttest&quot;, then the results of taling to the consoles of
the UMLs will be printed to stderr during the test.</DD>
<DT>NETJIGWAITUSER</DT>
<DD> If set to &quot;waituser&quot;, then the scripts will wait forever for user
input before they shut the tests down. Use this is if you are debugging
through the kernel.</DD>
<DT>PACKETRATE</DT>
<DD> A number, in miliseconds (default is 500ms) at which packets will
be replayed by the netjig.</DD>
</DL>
<H2><A NAME="39_5">KLIPStest paramaters</A></H2>
<P> The klipstest function starts a program (<CODE>
testing/utils/uml_netjig/uml_netjig</CODE>) to setup a bunch of I/O
sockets (that simulate network interfaces). It then exports the
references to these sockets to the environment and invokes (using
system()) a given script. It waits for the script to finish.</P>
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
<P> The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
to start the UML and configure it appropriately for the test. The
configuration is done with the script given above for<VAR> INIT_SCRIPT</VAR>
. The TCL script then forks, leaves the UML in the background and exits.
uml_netjig continues. It then starts listening to the simulated network
answering ARPs and inserting packets as appropriate.</P>
<P> The klipstest function invokes <CODE>uml_netjig</CODE> with
arguments to capture output from network interface(s) and insert
packets as appropriate:</P>
<DL>
<DT>PUB_INPUT</DT>
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
public (encrypted) interface. (typically, eth1)</DD>
<DT>PRIV_INPUT</DT>
<DD>a pcap file to feed in on the private (plain-text) interface
(typically, eth0).</DD>
<DT>REF_PUB_OUTPUT</DT>
<DD>a text file containing tcpdump output. Packets on the public (eth1)
interface are captured to a<A HREF="http://www.tcpdump.org/"> pcap</A>
file by <CODE>uml_netjig</CODE>. The klipstest function then uses
tcpdump on the file to produce text output, which is compared to the
file given.</DD>
<DT>REF_PUB_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
<DT>REF_PRIV_OUTPUT</DT>
<DD>a text file containing tcpdump output. Packets on the private (eth0)
interface are captured and compared after conversion by tcpdump, as
with<VAR> REFPUBOUTPUT</VAR>.</DD>
<DT>REF_PRIV_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
<DT>EXITONEMPTY</DT>
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain
&quot;--exitonempty&quot; of uml_netjig should exit when all of the input (<VAR>
PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD>
<DT>ARPREPLY</DT>
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain &quot;--arpreply&quot;
if <CODE>uml_netjig</CODE> should reply to ARP requests. One will
typically set this to avoid having to fudge the ARP cache manually.</DD>
<DT>TCPDUMPFLAGS</DT>
<DD>a set of flags for the tcpdump used when converting captured output.
Typical values will include &quot;-n&quot; to turn off DNS, and often &quot;-E&quot; to set
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
&quot;-t&quot; flag (turn off timestamps) is provided automatically</DD>
<DT>NETJIG_EXTRA</DT>
<DD>additional comments to be sent to the netjig. This may arrange to
record or create additional networks, or may toggle options.</DD>
</DL>
<H2><A NAME="39_6">mkinsttest paramaters</A></H2>
<P> The basic concept of the <CODE>mkinsttest</CODE> test type is that
it performs a &quot;make install&quot; to a temporary $DESTDIR. The resulting
tree can then be examined to determine if it was done properly. The
files can be uninstalled to determine if the file list was correct, or
the contents of files can be examined more precisely.</P>
<DL>
<DT>INSTALL_FLAGS</DT>
<DD>If set, then an install will be done. This provides the set of flags
to provide for the install. The target to be used (usually &quot;install&quot;)
must be among the flags.</DD>
<DT>POSTINSTALL_SCRIPT</DT>
<DD>If set, a script to run after initial &quot;make install&quot;. Two arguments
are provided: an absolute path to the root of the FreeSWAN src tree,
and an absolute path to the temporary installation area.</DD>
<DT>INSTALL2_FLAGS</DT>
<DD>If set, a second install will be done using these flags. Similarly
to INSTALL_FLAGS, the target must be among the flags.</DD>
<DT>UNINSTALL_FLAGS</DT>
<DD>If set, an uninstall will be done using these flags. Similarly to
INSTALL_FLAGS, the target (usually &quot;uninstall&quot;) must be among the
flags.</DD>
<DT>REF_FIND_f_l_OUTPUT</DT>
<DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be
done to get a list of a real files and symlinks. The resulting file
will be compared to the file listed by this option.</DD>
<DT>REF_FILE_CONTENTS</DT>
<DD>If set, it should point to a file containing records for the form:
<PRE>
<!--VARIABLE-->
reffile</(null)>
<!--VARIABLE-->
samplefile</(null)>
</PRE>
one record per line. A diff between the provided reference file, and
the sample file (located in the temporary installation root) will be
done for each record.</DD>
</DL>
<H2><A NAME="39_7">rpm_build_install_test paramaters</A></H2>
<P> The <CODE>rpm_build_install_test</CODE> type is to verify that the
proper packing list is produced by &quot;make rpm&quot;, and that the mechanisms
for building the kernel modules produce consistent results.</P>
<DL>
<DT>RPM_KERNEL_SOURCE</DT>
<DD>Point to an extracted copy of the RedHat kernel source code.
Variables from the environment may be used.</DD>
<DT>REF_RPM_CONTENTS</DT>
<DD>This is a file containing one record per line. Each record consists
of a RPM name (may contain wildcards) and a filename to compare the
contents to. The RPM will be located and a file list will be produced
with rpm2cpio.</DD>
</DL>
<H2><A NAME="39_8">libtest paramaters</A></H2>
<P> The libtest test is for testing library routines. The library file
is expected to provided an <CODE>#ifdef</CODE> by the name of<VAR>
library</VAR>
<!--CODE_MAIN</CODE-->
. The libtest type invokes the C compiler to compile this
file, links it against <CODE>libfreeswan.a</CODE> (to resolve any other
dependancies) and runs the test with the <CODE>-r</CODE> argument to
invoke a regression test.</(null)></P>
<P>The library test case is expected to do a self-test, exiting with
status code 0 if everything is okay, and with non-zero otherwise. A
core dump (exit code greater than 128) is noted specifically.</P>
<P> Unlike other tests, there are no subdirectories required, or other
parameters to set.</P>
<H2 NAME="umlplutotest"><A NAME="39_9">umlplutotest paramaters</A></H2>
<P> The umlplutotest function starts a pair of user mode line processes.
This is a 2-host version of umlXhost. The &quot;EAST&quot; and &quot;WEST&quot; slots are
defined.</P>
<H2 NAME="umlXhost"><A NAME="39_10">umlXhost parameters</A></H2>
<P> The umlXtest function starts an arbitrary number of user mode line
processes.</P>
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
<P> The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
to start each UML and configure it appropriately for the test. It then
starts listening (using uml_netjig) to the simulated network answering
ARPs and inserting packets as appropriate.</P>
<P> umlXtest has a series of slots, each of which should be filled by a
host. The list of slots is controlled by the variable, XHOST_LIST. This
variable should be set to a space seperated list of slots. The former
umlplutotest is now implemented as a variation of the umlXhost test,
with XHOST_LIST=&quot;EAST WEST&quot;.</P>
<P> For each host slot that is defined, a series of variables should be
filled in, defining what configuration scripts to use for that host.</P>
<P> The following are used to control the console input and output to
the system. Where the string ${host} is present, the host slot should
be filled in. I.e. for the two host system with XHOST_LIST=&quot;EAST WEST&quot;,
then the variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist.</P>
<DL>
<DT>${host}HOST</DT>
<DD>The name of the UML host which will fill this slot</DD>
<DT>${host}_INIT_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode prior to starting the tests. This file will usually
set up any eroute's and SADB entries that are required for the test.
Similar to INIT_SCRIPT, above.</P>
</DD>
<DT>${host}_RUN_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode, before the packets are sent. This set of commands is
run after all of the virtual machines are initialized. I.e. after
EAST_INIT_SCRIPT<B> AND</B> WEST_INIT_SCRIPT. This script can therefore
do things that require that all machines are properly configured.</P>
</DD>
<DT>${host}_RUN2_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode, after the packets are sent. This set of commands is
run before any of the virtual machines have been shut down. (I.e.
before EAST_FINAL_SCRIPT<B> AND</B> WEST_FINAL_SCRIPT.) This script can
therefore catch post-activity status reports.</P>
</DD>
<DT>${host}_FINAL_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode after the final packet is sent. Similar to
INIT_SCRIPT, above. If not specified, then the single command &quot;halt&quot; is
sent. Note that when this script is run, the other virtual machines may
already have been killed. If specified, then the script should end with
a halt command to nicely shutdown the UML.</P>
</DD>
<DT>REF_${host}_CONSOLE_OUTPUT</DT>
<DD>Similar to REF_CONSOLE_OUTPUT, above.</DD>
</DL>
<P>Some additional flags apply to all hosts:</P>
<DL>
<DT>REF_CONSOLE_FIXUPS</DT>
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
to sanitize the console output of the machine under test. These are
typically perl, awk or sed scripts that remove things in the kernel
output that change each time the test is run and/or compiled.</DD>
</DL>
<P> In addition to input to the console, the networks may have input fed
to them:</P>
<DL>
<DT>EAST_INPUT/WEST_INPUT</DT>
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
private network side of each network. The &quot;EAST&quot; and &quot;WEST&quot; here refer
to the networks, not the hosts.</DD>
<DT>REF_PUB_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
<DT>REF_EAST_FILTER/REF_WEST_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
&lt;
<DT>TCPDUMPFLAGS</DT>
<DD>a set of flags for the tcpdump used when converting captured output.
Typical values will include &quot;-n&quot; to turn off DNS, and often &quot;-E&quot; to set
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
&quot;-t&quot; flag (turn off timestamps) is provided automatically</DD>
<DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT>
<DD>a text file containing tcpdump output. Packets on the private (eth0)
interface are captured and compared after conversion by tcpdump, as
with<VAR> REF_PUB_OUTPUT</VAR>.</DD>
<P> There are two additional environment variables that may be set on
the command line:</P>
<DL>
<DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT>
<DD> If set, then the test output will be &quot;chatty&quot;, and let you know
what commands it is running, and as packets are sent. Without it set,
the output is limited to success/failure messages.</DD>
<DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT>
<DD> This will enable debugging of the communication with uml_netjig,
and turn on debugging in this utility. This does not imply
NETJIGVERBOSE.</DD>
</DL>
<DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT>
<DD> This will show all interactions with the user-mode-linux consoles</DD>
</DL>
<H2 NAME="kernelpatch"><A NAME="39_11">kernel_patch_test paramaters</A></H2>
<P> The kernel_patch_test function takes some kernel source, copies it
with lndir, and then applies the patch as produced by &quot;make
kernelpatch&quot;.</P>
<P> The following are used to control the input and output to the
system:</P>
<DL>
<DT>KERNEL_NAME</DT>
<DD>the kernel name, typically something like &quot;linus&quot; or &quot;rh&quot;</DD>
<DT>KERNEL_VERSION</DT>
<DD>the kernel version number, as in &quot;2.2&quot; or &quot;2.4&quot;.</DD>
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
<DD>This variable should set in the environment, probably in
~/freeswan-regress-env.sh. Examples of this variables would be
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
an extracted copy of the kernel source in question.</DD>
<DT>REF_PATCH_OUTPUT</DT>
<DD>a copy of the patch output to compare against</DD>
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
<DD>If set to a non-empty string, then the patched kernel source is not
removed at the end of the test. This will typically be set in the
environment while debugging.</DD>
</DL>
<H2 NAME="modtest"><A NAME="39_12">module_compile paramaters</A></H2>
<P> The module_compile test attempts to build the KLIPS module against a
given set of kernel source. This is also done by the RPM tests, but in
a very specific manner.</P>
<P> There are two variations of this test - one where the kernel either
doesn't need to be configured, or is already done, and tests were there
is a local configuration file.</P>
<P> Where the kernel doesn't need to be configured, the kernel source
that is found is simply used. It may be a RedHat-style kernel, where
one can cause it to configure itself via rhconfig.h-style definitions.
Or, it may just be a kernel tree that has been configured.</P>
<P> If the variable KERNEL_CONFIG_FILE is set, then a new directory is
created for the kernel source. It is populated with lndir(1). The
referenced file is then copied in as .config, and &quot;make oldconfig&quot; is
used to configure the kernel. This resulting kernel is then used as the
reference source.</P>
<P> In all cases, the kernel source is found the same was for the
kernelpatch test, i.e. via KERNEL_VERSION/KERNEL_NAME and
KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P>
<P> Once there is kernel source, the module is compiled using the
top-level &quot;make module&quot; target.</P>
<P> The test is considered successful if an executable is found in
OUTPUT/module/ipsec.o at the end of the test.</P>
<DL>
<DT>KERNEL_NAME</DT>
<DD>the kernel name, typically something like &quot;linus&quot; or &quot;rh&quot;</DD>
<DT>KERNEL_VERSION</DT>
<DD>the kernel version number, as in &quot;2.2&quot; or &quot;2.4&quot;.</DD>
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
<DD>This variable should set in the environment, probably in
~/freeswan-regress-env.sh. Examples of this variables would be
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
an extracted copy of the kernel source in question.</DD>
<DT>KERNEL_CONFIG_FILE</DT>
<DD>The configuration file for the kernel.</DD>
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
<DD>If set to a non-empty string, then the configured kernel source is
not removed at the end of the test. This will typically be set in the
environment while debugging.</DD>
<DT>MODULE_DEF_INCLUDE</DT>
<DD>The include file that will be used to configure the KLIPS module,
and possibly the kernel source.</DD>
</DL>
<H1><A NAME="40">Current pitfalls</A></H1>
<DL>
<DT> &quot;tcpdump dissector&quot; not available.</DT>
<DD> This is a non-fatal warning. If uml_netjig is invoked with the -t
option, then it will attempt to use tcpdump's dissector to decode each
packet that it processes. The dissector is presently not available, so
this option it normally turned off at compile time. The dissector
library will be released with tcpdump version 4.0.</DD>
</DL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="umltesting.html">Previous</A>
<A HREF="nightly.html">Next</A>
</BODY>
</HTML>
doc/manpage.d/ipsec.8.html
-215
View File
@@ -1,215 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC</TITLE>
</HEAD><BODY>
<H1>IPSEC</H1>
Section: Maintenance Commands (8)<BR>Updated: 26 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec - invoke IPsec utilities
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
command [ argument ...]
<P>
<B>ipsec</B>
<B>--help</B>
<BR>
<B>ipsec</B>
<B>--version</B>
<BR>
<B>ipsec</B>
<B>--versioncode</B>
<BR>
<B>ipsec</B>
<B>--copyright</B>
<BR>
<B>ipsec</B>
<B>--directory</B>
<BR>
<B>ipsec</B>
<B>--confdir</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ipsec</I>
invokes any of several utilities involved in controlling the IPsec
encryption/authentication system,
running the specified
<I>command</I>
with the specified
<I>argument</I>s
as if it had been invoked directly.
This largely eliminates possible name collisions with other software,
and also permits some centralized services.
<P>
In particular,
<I>ipsec</I>
supplies the invoked
<I>command</I>
with a suitable PATH environment variable,
and also provides IPSEC_DIR,
IPSEC_CONFS, and IPSEC_VERSION environment variables,
containing respectively
the full pathname of the directory where the IPsec utilities are stored,
the full pathname of the directory where the configuration files live,
and the IPsec version number.
<P>
<B>ipsec --help</B>
lists the available commands.
Most have their own manual pages, e.g.
<I><A HREF="ipsec_auto.8.html">ipsec_auto</A></I>(8)
for
<I>auto</I>.
<P>
<B>ipsec --version</B>
outputs version information about Linux FreeS/WAN.
A version code of the form ``U<I>xxx</I>/K<I>yyy</I>''
indicates that the user-level utilities are version <I>xxx</I>
but the kernel portion appears to be version <I>yyy</I>
(this form is used only if the two disagree).
<P>
<B>ipsec --versioncode</B>
outputs <I>just</I> the version code,
with none of
<B>--version</B>'s
supporting information,
for use by scripts.
<P>
<B>ipsec --copyright</B>
supplies boring copyright details.
<P>
<B>ipsec --directory</B>
reports where
<I>ipsec</I>
thinks the IPsec utilities are stored.
<P>
<B>ipsec --confdir</B>
reports where
<I>ipsec</I>
thinks the IPsec configuration files are stored.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
/usr/local/lib/ipsec<TT>&nbsp;&nbsp;&nbsp;</TT>usual utilities directory<BR>
<A NAME="lbAF">&nbsp;</A>
<H2>ENVIRONMENT</H2>
<P>
The following environment variables control where FreeS/WAN finds its
components.
The
<B>ipsec</B>
command sets them if they are not already set.
<PRE>
IPSEC_EXECDIR directory containing published commands
IPSEC_LIBDIR directory containing internal executables
IPSEC_SBINDIR directory containing <B>ipsec</B> command
IPSEC_CONFS directory containing configuration files
</PRE>
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.conf.5.html">ipsec.conf</A>(5), <A HREF="ipsec.secrets.5.html">ipsec.secrets</A>(5),
<A HREF="ipsec_auto.8.html">ipsec_auto</A>(8),
<A HREF="ipsec_barf.8.html">ipsec_barf</A>(8),
<A HREF="ipsec_setup.8.html">ipsec_setup</A>(8),
<A HREF="ipsec_showdefaults.8.html">ipsec_showdefaults</A>(8),
<A HREF="ipsec_showhostkey.8.html">ipsec_showhostkey</A>(8)
<P>
HTML documentation shipped with the release, starting with
<I>doc/index.html</I>.
<I>&lt;<A HREF="http://www.freeswan.org/doc.html">http://www.freeswan.org/doc.html</A>&gt;</I>
may also be of use.
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for Linux FreeS/WAN
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAI">&nbsp;</A>
<H2>BUGS</H2>
The provision of centralized services,
while convenient,
does compromise the original concept of making the utilities
invocable directly as well as via
<I>ipsec</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">ENVIRONMENT</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
<DT><A HREF="#lbAI">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec.conf.5.html
-1830
View File
File diff suppressed because it is too large Load Diff
doc/manpage.d/ipsec.secrets.5.html
-227
View File
@@ -1,227 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC.SECRETS</TITLE>
</HEAD><BODY>
<H1>IPSEC.SECRETS</H1>
Section: File Formats (5)<BR>Updated: 28 March 1999<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec.secrets - secrets for IKE/IPsec authentication
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
The file <I>ipsec.secrets</I> holds a table of secrets.
These secrets are used by <I><A HREF="ipsec_pluto.8.html">ipsec_pluto</A></I>(8), the FreeS/WAN Internet Key
Exchange daemon, to authenticate other hosts.
Currently there are two kinds of secrets: preshared secrets and
RSA private keys.
<P>
It is vital that these secrets be protected. The file should be owned
by the super-user,
and its permissions should be set to block all access by others.
<P>
The file is a sequence of entries and include directives.
Here is an example. Each entry or directive must start at the
left margin, but if it continues beyond a single line, each continuation
line must be indented.
<P>
<DL COMPACT><DT><DD>
<PRE>
# sample /etc/ipsec.secrets file for 10.1.0.1
10.1.0.1 10.2.0.1: PSK &quot;secret shared by two hosts&quot;
# an entry may be split across lines,
# but indentation matters
<A HREF="http://www.xs4all.nl">www.xs4all.nl</A> @<A HREF="http://www.kremvax.ru">www.kremvax.ru</A>
&nbsp;&nbsp;&nbsp;&nbsp;10.6.0.1 10.7.0.1 1.8.0.1: PSK &quot;secret shared by 5&quot;
# an RSA private key.
# note that the lines are too wide for a
# man page, so ... has been substituted for
# the truncated part
@my.com: rsa {
&nbsp;&nbsp;&nbsp;&nbsp;Modulus:&nbsp;0syXpo/6waam+ZhSs8Lt6jnBzu3C4grtt...
&nbsp;&nbsp;&nbsp;&nbsp;PublicExponent:&nbsp;0sAw==
&nbsp;&nbsp;&nbsp;&nbsp;PrivateExponent:&nbsp;0shlGbVR1m8Z+7rhzSyenCaBN...
&nbsp;&nbsp;&nbsp;&nbsp;Prime1:&nbsp;0s8njV7WTxzVzRz7AP+0OraDxmEAt1BL5l...
&nbsp;&nbsp;&nbsp;&nbsp;Prime2:&nbsp;0s1LgR7/oUMo9BvfU8yRFNos1s211KX5K0...
&nbsp;&nbsp;&nbsp;&nbsp;Exponent1:&nbsp;0soaXj85ihM5M2inVf/NfHmtLutVz4r...
&nbsp;&nbsp;&nbsp;&nbsp;Exponent2:&nbsp;0sjdAL9VFizF+BKU4ohguJFzOd55OG6...
&nbsp;&nbsp;&nbsp;&nbsp;Coefficient:&nbsp;0sK1LWwgnNrNFGZsS/2GuMBg9nYVZ...
&nbsp;&nbsp;&nbsp;&nbsp;}
include ipsec.*.secrets # get secrets from other files
</PRE>
</DL>
<P>
Each entry in the file is a list of indices, followed by a secret.
The two parts are separated by a colon (<B>:</B>) that is
followed by whitespace or a newline. For compatability
with the previous form of this file, if the key part is just a
double-quoted string the colon may be left out.
<P>
An index is an IP address, or a Fully Qualified Domain Name, <A HREF="mailto:user@FQDN">user@FQDN</A>,
<B>%any</B> or <B>%any6</B> (other kinds may come). An IP address may be written
in the familiar dotted quad form or as a domain name to be looked up
when the file is loaded
(or in any of the forms supported by the FreeS/WAN <I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
routine). In many cases it is a bad idea to use domain names because
the name server may not be running or may be insecure. To denote a
Fully Qualified Domain Name (as opposed to an IP address denoted by
its domain name), precede the name with an at sign (<B>@</B>).
<P>
Matching IDs with indices is fairly straightforward: they have to be
equal. In the case of a ``Road Warrior'' connection, if an equal
match is not found for the Peer's ID, and it is in the form of an IP
address, an index of <B>%any</B> will match the peer's IP address if IPV4
and <B>%any6</B> will match a the peer's IP address if IPV6.
Currently, the obsolete notation <B>0.0.0.0</B> may be used in place of
<B>%any</B>.
<P>
An additional complexity
arises in the case of authentication by preshared secret: the
responder will need to look up the secret before the Peer's ID payload has
been decoded, so the ID used will be the IP address.
<P>
To authenticate a connection between two hosts, the entry that most
specifically matches the host and peer IDs is used. An entry with no
index will match any host and peer. More specifically, an entry with one index will
match a host and peer if the index matches the host's ID (the peer isn't
considered). Still more specifically, an entry with multiple indices will match a host and
peer if the host ID and peer ID each match one of the indices. If the key
is for an asymmetric authentication technique (i.e. a public key
system such as RSA), an entry with multiple indices will match a host
and peer even if only the host ID matches an index (it is presumed that the
multiple indices are all identities of the host).
It is acceptable for two entries to be the best match as
long as they agree about the secret or private key.
<P>
Authentication by preshared secret requires that both systems find the
identical secret (the secret is not actually transmitted by the IKE
protocol). If both the host and peer appear in the index list, the
same entry will be suitable for both systems so verbatim copying
between systems can be used. This naturally extends to larger groups
sharing the same secret. Thus multiple-index entries are best for PSK
authentication.
<P>
Authentication by RSA Signatures requires that each host have its own private
key. A host could reasonably use a different private keys
for different interfaces and for different peers. But it would not
be normal to share entries between systems. Thus thus no-index and
one-index forms of entry often make sense for RSA Signature authentication.
<P>
The key part of an entry may start with a token indicating the kind of
key. ``RSA'' signifies RSA private key and ``PSK'' signifies
PreShared Key (case is ignored). For compatability with previous
forms of this file, PSK is the default.
<P>
A preshared secret is most conveniently represented as a sequence of
characters, delimited by the double-quote
character (<B>&quot;</B>). The sequence cannot contain a newline or
double-quote. Strictly speaking, the secret is actually the sequence
of bytes that is used in the file to represent the sequence of
characters (excluding the delimiters).
A preshared secret may also be represented, without quotes, in any form supported by
<I><A HREF="ipsec_ttodata.3.html">ipsec_ttodata</A></I>(3).
<P>
An RSA private key is a composite of eight generally large numbers. The notation
used is a brace-enclosed list of field name and value pairs (see the example above).
A suitable key, in a suitable format, may be generated by <I><A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A></I>(8).
The structure is very similar to that used by BIND 8.2.2 or later, but note that
the numbers must have a ``0s'' prefix if they are in base 64. The order of
the fields is fixed.
<P>
The first token an entry must start in
the first column of its line. Subsequent tokens must be
separated by whitespace,
except for a colon token, which only needs to be followed by whitespace.
A newline is taken as whitespace, but every
line of an entry after the first must be indented.
<P>
Whitespace at the end of a line is ignored (except in the 0t
notation for a key). At the start of line or
after whitespace, <B>#</B> and the following text up to the end of the
line is treated as a comment. Within entries, all lines must be
indented (except for lines with no tokens).
Outside entries, no line may be indented (this is to make sure that
the file layout reflects its structure).
<P>
An include directive causes the contents of the named file to be processed
before continuing with the current file. The filename is subject to
``globbing'' as in <I><A HREF="sh.1.html">sh</A></I>(1), so every file with a matching name
is processed. Includes may be nested to a modest
depth (10, currently). If the filename doesn't start with a <B>/</B>, the
directory containing the current file is prepended to the name. The
include directive is a line that starts with the word <B>include</B>,
followed by whitespace, followed by the filename (which must not contain
whitespace).
<A NAME="lbAD">&nbsp;</A>
<H2>FILES</H2>
/etc/ipsec.secrets
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
The rest of the FreeS/WAN distribution, in particular
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5),
<I><A HREF="ipsec.8.html">ipsec</A></I>(8),
<I><A HREF="ipsec_newhostkey.8.html">ipsec_newhostkey</A></I>(8),
<I><A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A></I>(8),
<I><A HREF="ipsec_showhostkey.8.html">ipsec_showhostkey</A></I>(8),
<I><A HREF="ipsec_auto.8.html">ipsec_auto</A></I>(8) <B>--rereadsecrets</B>,
and <I><A HREF="ipsec_pluto.8.html">ipsec_pluto</A></I>(8) <B>--listen</B>,.
<BR>
BIND 8.2.2 or later, <A HREF="ftp://ftp.isc.org/isc/bind/src/">ftp://ftp.isc.org/isc/bind/src/</A>
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Designed for the FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by D. Hugh Redelmeier.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
If an ID is <B>0.0.0.0</B>, it will match <B>%any</B>;
if it is <B>0::0</B>, it will match <B>%any6</B>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">FILES</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__confread.8.html
-58
View File
@@ -1,58 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _CONFREAD</TITLE>
</HEAD><BODY>
<H1>_CONFREAD</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _confread - internal routing to parse config file
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_confread </I>
is an internal script used for parsing /etc/ipsec.conf into a canonical format.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_conf.8.html">ipsec_conf</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__copyright.8.html
-62
View File
@@ -1,62 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _COPYRIGHT</TITLE>
</HEAD><BODY>
<H1>_COPYRIGHT</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _copyright - prints FreeSWAN copyright
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_copyright</I>
outputs the FreeSWAN copyright, and version numbers for &quot;ipsec --copyright&quot;
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__include.8.html
-67
View File
@@ -1,67 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _INCLUDE</TITLE>
</HEAD><BODY>
<H1>_INCLUDE</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _include - internal script to process config files
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_include</I>
is used by
<I>_confread </I>
to process
<B>include </B>
directives in /etc/ipsec.conf.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec__confread.8.html">ipsec__confread</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__keycensor.8.html
-64
View File
@@ -1,64 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _KEYCENSOR</TITLE>
</HEAD><BODY>
<H1>_KEYCENSOR</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _keycensor - internal routine to remove sensitive information
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_keycensor</I>
is used by
<B>ipsec barf</B>
to process the /etc/ipsec.secrets file, removing private key info.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_barf.8.html">ipsec_barf</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__plutoload.8.html
-64
View File
@@ -1,64 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _PLUTOLOAD</TITLE>
</HEAD><BODY>
<H1>_PLUTOLOAD</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _plutoload - internal script to start pluto
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_plutoload</I>
is called by
<B>_plutorun</B>
to actually start the pluto executable.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_setup.8.html">ipsec_setup</A>(8), <A HREF="ipsec__realsetup.8.html">ipsec__realsetup</A>(8), <A HREF="ipsec__plutorun.8.html">ipsec__plutorun</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__plutorun.8.html
-70
View File
@@ -1,70 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _PLUTORUN</TITLE>
</HEAD><BODY>
<H1>_PLUTORUN</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _plutorun - internal script to start pluto
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_plutorun</I>
is called by
<B>_realsetup</B>
to configure and bring up
<B><A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8).</B>
It calls
<B>_plutoload</B>
to invoke pluto, and watches to makes sure that pluto is restarted if it fails.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_setup.8.html">ipsec_setup</A>(8), <A HREF="ipsec__realsetup.8.html">ipsec__realsetup</A>(8), <A HREF="ipsec__plutoload.8.html">ipsec__plutoload</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__realsetup.8.html
-68
View File
@@ -1,68 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _REALSETUP</TITLE>
</HEAD><BODY>
<H1>_REALSETUP</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _realsetup - internal routine to start FreeS/WAN.
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_realsetup</I>
is called by the system init scripts to start the FreeS/WAN
system. It starts
<B>KLIPS </B>
(the kernel component) and
<B>pluto </B>
(the userspace keying component).
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec__klipsstart.8.html">ipsec__klipsstart</A>(8), <A HREF="ipsec__plutorun.8.html">ipsec__plutorun</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__secretcensor.8.html
-65
View File
@@ -1,65 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _SECRETCENSOR</TITLE>
</HEAD><BODY>
<H1>_SECRETCENSOR</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _secretcensor - internal routing to sanitize files
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_secretcensor</I>
is called by
<B>ipsec barf</B>
to process the /etc/ipsec.secrets file to remove the private key components
from the file prior to revealing the contents.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_barf.8.html">ipsec_barf</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__startklips.8.html
-63
View File
@@ -1,63 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _STARTKLIPS</TITLE>
</HEAD><BODY>
<H1>_STARTKLIPS</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _startklips - internal script to bring up kernel components
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_startklips</I>
brings up the FreeS/WAN kernel component. This involves loading any
required modules, attaching and configuring the ipsecX pseudo-devices and
attaching the pseudo-devices to the physical devices.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec__updown.8.html
-63
View File
@@ -1,63 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _UPDOWN</TITLE>
</HEAD><BODY>
<H1>_UPDOWN</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _updown - klips manipulation script
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<I>_updown</I>
is invoked by pluto when it has brought up a new connection. This script
is used to insert the appropriate routing entries for IPsec operation.
The interface to the script is documented in the pluto man page.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrbytesof.3.html
-232
View File
@@ -1,232 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrbytesptr.3.html
-232
View File
@@ -1,232 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrcmp.3.html
-274
View File
@@ -1,274 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 28 Nov 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec sameaddr - are two addresses the same?
<BR>
ipsec addrcmp - ordered comparison of addresses
<BR>
ipsec samesubnet - are two subnets the same?
<BR>
ipsec addrinsubnet - is an address within a subnet?
<BR>
ipsec subnetinsubnet - is a subnet within another subnet?
<BR>
ipsec subnetishost - is a subnet a single host?
<BR>
ipsec samesaid - are two SA IDs the same?
<BR>
ipsec sameaddrtype - are two addresses of the same address family?
<BR>
ipsec samesubnettype - are two subnets of the same address family?
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int sameaddr(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int addrcmp(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int addrinsubnet(const ip_address *a, const ip_subnet *s);</B>
<BR>
<B>int subnetinsubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int subnetishost(const ip_subnet *s);</B>
<BR>
<B>int samesaid(const ip_said *a, const ip_said *b);</B>
<BR>
<B>int sameaddrtype(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnettype(const ip_subnet *a, const ip_subnet *b);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions do various comparisons and tests on the
<I>ip_address</I>
type and
<I>ip_subnet</I>
types.
<P>
<I>Sameaddr</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Addresses of different families are never identical.
<P>
<I>Addrcmp</I>
returns
<B>-1</B>,
<B>0</B>,
or
<B>1</B>
respectively
if address
<I>a</I>
is less than, equal to, or greater than
<I>b</I>.
If they are not of the same address family,
they are never equal;
the ordering reported in this case is arbitrary
(and probably not useful) but consistent.
<P>
<I>Samesubnet</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Subnets of different address families are never identical.
<P>
<I>Addrinsubnet</I>
returns
non-zero
if address
<I>a</I>
is within subnet
<I>s</I>
and
<B>0</B>
otherwise.
An address is never within a
subnet of a different address family.
<P>
<I>Subnetinsubnet</I>
returns
non-zero
if subnet
<I>a</I>
is a subset of subnet
<I>b</I>
and
<B>0</B>
otherwise.
A subnet is deemed to be a subset of itself.
A subnet is never a subset of another
subnet if their address families differ.
<P>
<I>Subnetishost</I>
returns
non-zero
if subnet
<I>s</I>
is in fact only a single host,
and
<B>0</B>
otherwise.
<P>
<I>Samesaid</I>
returns
non-zero
if SA IDs
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
<P>
<I>Sameaddrtype</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<P>
<I>Samesubnettype</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_initaddr.3.html">ipsec_initaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrinsubnet.3.html
-274
View File
@@ -1,274 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 28 Nov 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec sameaddr - are two addresses the same?
<BR>
ipsec addrcmp - ordered comparison of addresses
<BR>
ipsec samesubnet - are two subnets the same?
<BR>
ipsec addrinsubnet - is an address within a subnet?
<BR>
ipsec subnetinsubnet - is a subnet within another subnet?
<BR>
ipsec subnetishost - is a subnet a single host?
<BR>
ipsec samesaid - are two SA IDs the same?
<BR>
ipsec sameaddrtype - are two addresses of the same address family?
<BR>
ipsec samesubnettype - are two subnets of the same address family?
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int sameaddr(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int addrcmp(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int addrinsubnet(const ip_address *a, const ip_subnet *s);</B>
<BR>
<B>int subnetinsubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int subnetishost(const ip_subnet *s);</B>
<BR>
<B>int samesaid(const ip_said *a, const ip_said *b);</B>
<BR>
<B>int sameaddrtype(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnettype(const ip_subnet *a, const ip_subnet *b);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions do various comparisons and tests on the
<I>ip_address</I>
type and
<I>ip_subnet</I>
types.
<P>
<I>Sameaddr</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Addresses of different families are never identical.
<P>
<I>Addrcmp</I>
returns
<B>-1</B>,
<B>0</B>,
or
<B>1</B>
respectively
if address
<I>a</I>
is less than, equal to, or greater than
<I>b</I>.
If they are not of the same address family,
they are never equal;
the ordering reported in this case is arbitrary
(and probably not useful) but consistent.
<P>
<I>Samesubnet</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Subnets of different address families are never identical.
<P>
<I>Addrinsubnet</I>
returns
non-zero
if address
<I>a</I>
is within subnet
<I>s</I>
and
<B>0</B>
otherwise.
An address is never within a
subnet of a different address family.
<P>
<I>Subnetinsubnet</I>
returns
non-zero
if subnet
<I>a</I>
is a subset of subnet
<I>b</I>
and
<B>0</B>
otherwise.
A subnet is deemed to be a subset of itself.
A subnet is never a subset of another
subnet if their address families differ.
<P>
<I>Subnetishost</I>
returns
non-zero
if subnet
<I>s</I>
is in fact only a single host,
and
<B>0</B>
otherwise.
<P>
<I>Samesaid</I>
returns
non-zero
if SA IDs
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
<P>
<I>Sameaddrtype</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<P>
<I>Samesubnettype</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_initaddr.3.html">ipsec_initaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrlenof.3.html
-232
View File
@@ -1,232 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrtoa.3.html
-448
View File
@@ -1,448 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoaddr, addrtoa - convert Internet addresses to and from ASCII
<BR>
ipsec atosubnet, subnettoa - convert subnet/mask ASCII form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr);</B>
<BR>
<B>size_t addrtoa(struct in_addr addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *atosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr, struct in_addr *mask);</B>
<BR>
<B>size_t subnettoa(struct in_addr addr, struct in_addr mask,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
for their replacements.
<P>
<I>Atoaddr</I>
converts an ASCII name or dotted-decimal address into a binary address
(in network byte order).
<I>Addrtoa</I>
does the reverse conversion, back to an ASCII dotted-decimal address.
<I>Atosubnet</I>
and
<I>subnettoa</I>
do likewise for the ``address/mask'' ASCII form used to write a
specification of a subnet.
<P>
An address is specified in ASCII as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
ASCII-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of
<I>addrtoa</I>
is always complete and does not contain leading zeros.
<P>
The letters in
a hexadecimal address may be uppercase or lowercase or any mixture thereof.
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
Name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>atoaddr</I>.
In addition, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>.
<P>
<I>Atosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettoa</I>
generates the decimal-integer-bit-count
form of the mask,
with no leading zeros,
unless the mask is non-contiguous.
<P>
The
<I>srclen</I>
parameter of
<I>atoaddr</I>
and
<I>atosubnet</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOA_BUF</B>
and
<B>SUBNETTOA_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
The ASCII-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-ASCII functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoaddr</I>
are:
empty input;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal form;
dotted-decimal component too large to fit in 8 bits.
<P>
Fatal errors in
<I>atosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>atoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtoa</I>
and
<I>subnettoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrtosubnet.3.html
-238
View File
@@ -1,238 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrtot.3.html
-569
View File
@@ -1,569 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_TTOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_TTOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 28 Sept 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ttoaddr, tnatoaddr, addrtot - convert Internet addresses to and from text
<BR>
ipsec ttosubnet, subnettot - convert subnet/mask text form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *ttoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *addr);</B>
<BR>
<B>const char *tnatoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *addr);</B>
<BR>
<B>size_t addrtot(const ip_address *addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *ttosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_subnet *dst);</B>
<BR>
<B>size_t subnettot(const ip_subnet *sub, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ttoaddr</I>
converts a text-string name or numeric address into a binary address
(in network byte order).
<I>Tnatoaddr</I>
does the same conversion,
but the only text forms it accepts are
the ``official'' forms of
numeric address (dotted-decimal for IPv4, colon-hex for IPv6).
<I>Addrtot</I>
does the reverse conversion, from binary address back to a text form.
<I>Ttosubnet</I>
and
<I>subnettot</I>
do likewise for the ``address/mask'' form used to write a
specification of a subnet.
<P>
An IPv4 address is specified in text as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
text-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of applying
<I>addrtot</I>
to an IPv4 address is always complete and does not contain leading zeros.
<P>
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
An IPv6 address is specified in text with
colon-hex notation (e.g.
<B>0:56:78ab:22:33:44:55:66</B>),
colon-hex with
<B>::</B>
abbreviating at most one subsequence of multiple zeros (e.g.
<B>99:ab::54:068</B>,
which is synonymous with
<B>99:ab:0:0:0:0:54:68</B>),
or a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3).
The result of applying
<I>addrtot</I>
to an IPv6 address will use
<B>::</B>
abbreviation if possible,
and will not contain leading zeros.
<P>
The letters in hexadecimal
may be uppercase or lowercase or any mixture thereof.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname2.3.html">gethostbyname2</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
IPv4 name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname2.3.html">gethostbyname2</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>ttoaddr</I>.
In addition, and preferably, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
in IPv4 means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>
or
<B>::/0</B>
in IPv4 or IPv6 respectively.
<P>
<I>Ttosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettot</I>
always generates the decimal-integer-bit-count
form of the mask,
with no leading zeros.
<P>
The
<I>srclen</I>
parameter of
<I>ttoaddr</I>
and
<I>ttosubnet</I>
specifies the length of the text string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>af</I>
parameter of
<I>ttoaddr</I>
and
<I>ttosubnet</I>
specifies the address family of interest.
It should be either
<B>AF_INET</B>
or
<B>AF_INET6</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtot</I>
and
<I>subnettot</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOT_BUF</B>
and
<B>SUBNETTOT_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtot</I>
and
<I>subnettot</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available in
<I>subnettot</I>.
<I>Addrtot</I>
also accepts format values
<B>'r'</B>
(signifying a text form suitable for DNS reverse lookups,
e.g.
<B>4.3.2.1.IN-ADDR.ARPA.</B>
for IPv4 and
RFC 2874 format for IPv6),
and
<B>'R'</B>
(signifying an alternate reverse-lookup form,
an error for IPv4 and RFC 1886 format for IPv6).
Reverse-lookup names always end with a ``.''.
<P>
The text-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-text functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>ttoaddr</I>
are:
empty input;
unknown address family;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal or colon-hex form;
dotted-decimal or colon-hex component too large.
<P>
Fatal errors in
<I>ttosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>ttoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtot</I>
and
<I>subnettot</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
<I>Ttoaddr</I>
does not support the mixed colon-hex-dotted-decimal
convention used to embed an IPv4 address in an IPv6 address.
<P>
<I>Addrtot</I>
always uses the
<B>::</B>
abbreviation (which can appear only once in an address) for the
<I>first</I>
sequence of multiple zeros in an IPv6 address.
One can construct addresses (unlikely ones) in which this is suboptimal.
<P>
<I>Addrtot</I>
<B>'r'</B>
conversion of an IPv6 address uses lowercase hexadecimal,
not the uppercase used in RFC 2874's examples.
It takes careful reading of RFCs 2874, 2673, and 2234 to realize
that lowercase is technically legitimate here,
and there may be software which botches this
and hence would have trouble with lowercase hex.
<P>
Possibly
<I>subnettot</I>
ought to recognize the
<B>%default</B>
case and generate that string as its output.
Currently it doesn't.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
<I>Tnatoaddr</I>
probably should enforce completeness of dotted-decimal addresses.
<P>
The restriction of text-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The text-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = ttoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_addrtypeof.3.html
-232
View File
@@ -1,232 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_anyaddr.3.html
-166
View File
@@ -1,166 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_atoaddr.3.html
-448
View File
@@ -1,448 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoaddr, addrtoa - convert Internet addresses to and from ASCII
<BR>
ipsec atosubnet, subnettoa - convert subnet/mask ASCII form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr);</B>
<BR>
<B>size_t addrtoa(struct in_addr addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *atosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr, struct in_addr *mask);</B>
<BR>
<B>size_t subnettoa(struct in_addr addr, struct in_addr mask,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
for their replacements.
<P>
<I>Atoaddr</I>
converts an ASCII name or dotted-decimal address into a binary address
(in network byte order).
<I>Addrtoa</I>
does the reverse conversion, back to an ASCII dotted-decimal address.
<I>Atosubnet</I>
and
<I>subnettoa</I>
do likewise for the ``address/mask'' ASCII form used to write a
specification of a subnet.
<P>
An address is specified in ASCII as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
ASCII-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of
<I>addrtoa</I>
is always complete and does not contain leading zeros.
<P>
The letters in
a hexadecimal address may be uppercase or lowercase or any mixture thereof.
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
Name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>atoaddr</I>.
In addition, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>.
<P>
<I>Atosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettoa</I>
generates the decimal-integer-bit-count
form of the mask,
with no leading zeros,
unless the mask is non-contiguous.
<P>
The
<I>srclen</I>
parameter of
<I>atoaddr</I>
and
<I>atosubnet</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOA_BUF</B>
and
<B>SUBNETTOA_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
The ASCII-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-ASCII functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoaddr</I>
are:
empty input;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal form;
dotted-decimal component too large to fit in 8 bits.
<P>
Fatal errors in
<I>atosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>atoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtoa</I>
and
<I>subnettoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_atoasr.3.html
-294
View File
@@ -1,294 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOASR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOASR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoasr - convert ASCII to Internet address, subnet, or range
<BR>
ipsec rangetoa - convert Internet address range to ASCII
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoasr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>char *type, struct in_addr *addrs);</B>
<BR>
<B>size_t rangetoa(struct in_addr *addrs, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
there is no current equivalent,
because so far they have not proved useful.
<P>
<I>Atoasr</I>
converts an ASCII address, subnet, or address range
into a suitable combination of binary addresses
(in network byte order).
<I>Rangetoa</I>
converts an address range back into ASCII,
using dotted-decimal form for the addresses
(the other reverse conversions are handled by
<I><A HREF="ipsec_addrtoa.3.html">ipsec_addrtoa</A></I>(3)
and
<I><A HREF="ipsec_subnettoa.3.html">ipsec_subnettoa</A></I>(3)).
<P>
A single address can be any form acceptable to
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3):
dotted decimal, DNS name, or hexadecimal number.
A subnet
specification uses the form <I>network</I><B>/</B><I>mask</I>
interpreted by
<I><A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A></I>(3).
<P>
An address range is two
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3)
addresses separated by a
<B>...</B>
delimiter.
If there are four dots rather than three, the first is taken as
part of the begin address,
e.g. for a complete DNS name which ends with
<B>.</B>
to suppress completion attempts.
The begin address of a range must be
less than or equal to the end address.
<P>
The
<I>srclen</I>
parameter of
<I>atoasr</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>type</I>
parameter of
<I>atoasr</I>
must point to a
<B>char</B>
variable used to record which form was found.
The
<I>addrs</I>
parameter must point to a two-element array of
<B>struct in_addr</B>
which receives the results.
The values stored into
<B>*type</B>,
and the corresponding values in the array, are:
<P>
<TT>&nbsp;&nbsp;&nbsp;</TT>*typeaddrs[0]addrs[1]<BR>
<P>
address<B>'a'</B>address-<BR>
<BR>
subnet<TT>&nbsp;</TT><B>'s'</B>networkmask<BR>
<BR>
range<TT>&nbsp;&nbsp;</TT><B>'r'</B>beginend<BR>
<P>
The
<I>dstlen</I>
parameter of
<I>rangetoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines a constant,
<B>RANGETOA_BUF</B>,
which is the size of a buffer just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>rangetoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
<I>Atoasr</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Rangetoa</I>
returns
<B>0</B>
for a failure, and otherwise
always returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoasr</I>
are:
empty input;
error in
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3)
or
<I><A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A></I>(3)
during conversion;
begin address of range exceeds end address.
<P>
Fatal errors in
<I>rangetoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The restriction of error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoasr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_atosa.3.html
-347
View File
@@ -1,347 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOSA</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOSA</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atosa, satoa - convert IPsec Security Association IDs to and from ASCII
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atosa(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct sa_id *sa);</B>
<BR>
<B>size_t satoa(struct sa_id sa, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>struct sa_id {</B>
<BR>
&nbsp;
<B>struct in_addr dst;</B>
<BR>
&nbsp;
<B>ipsec_spi_t spi;</B>
<BR>
&nbsp;
<B>int proto;</B>
<BR>
<B>};</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttosa.3.html">ipsec_ttosa</A></I>(3)
for their replacements.
<P>
<I>Atosa</I>
converts an ASCII Security Association (SA) specifier into an
<B>sa_id</B>
structure (containing
a destination-host address
in network byte order,
an SPI number in network byte order, and
a protocol code).
<I>Satoa</I>
does the reverse conversion, back to an ASCII SA specifier.
<P>
An SA is specified in ASCII with a mail-like syntax, e.g.
<B><A HREF="mailto:[email protected]">[email protected]</A></B>.
An SA specifier contains
a protocol prefix (currently
<B>ah</B>,
<B>esp</B>,
or
<B>tun</B>),
an unsigned integer SPI number,
and an IP address.
The SPI number can be decimal or hexadecimal
(with
<B>0x</B>
prefix), as accepted by
<I><A HREF="ipsec_atoul.3.html">ipsec_atoul</A></I>(3).
The IP address can be any form accepted by
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3),
e.g. dotted-decimal address or DNS name.
<P>
As a special case, the SA specifier
<B>%passthrough</B>
signifies the special SA used to indicate that packets should be
passed through unaltered.
(At present, this is a synonym for
<B><A HREF="mailto:[email protected]">[email protected]</A></B>,
but that is subject to change without notice.)
This form is known to both
<I>atosa</I>
and
<I>satoa</I>,
so the internal form of
<B>%passthrough</B>
is never visible.
<P>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file supplies the
<B>sa_id</B>
structure, as well as a data type
<B>ipsec_spi_t</B>
which is an unsigned 32-bit integer.
(There is no consistency between kernel and user on what such a type
is called, hence the header hides the differences.)
<P>
The protocol code uses the same numbers that IP does.
For user convenience, given the difficulty in acquiring the exact set of
protocol names used by the kernel,
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
defines the names
<B>SA_ESP</B>,
<B>SA_AH</B>,
and
<B>SA_IPIP</B>
to have the same values as the kernel names
<B>IPPROTO_ESP</B>,
<B>IPPROTO_AH</B>,
and
<B>IPPROTO_IPIP</B>.
<P>
The
<I>srclen</I>
parameter of
<I>atosa</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>satoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines a constant,
<B>SATOA_BUF</B>,
which is the size of a buffer just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>satoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default
(currently
lowercase protocol prefix, lowercase hexadecimal SPI, dotted-decimal address).
The value
<B>d</B>
causes the SPI to be generated in decimal instead.
<P>
<I>Atosa</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Satoa</I>
returns
<B>0</B>
for a failure, and otherwise
always returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_atoul.3.html">ipsec_atoul</A>(3), <A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A>(3), <A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atosa</I>
are:
empty input;
input too small to be a legal SA specifier;
no
<B>@</B>
in input;
unknown protocol prefix;
conversion error in
<I>atoul</I>
or
<I>atoaddr</I>.
<P>
Fatal errors in
<I>satoa</I>
are:
unknown format; unknown protocol code.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The
<B>tun</B>
protocol code is a FreeS/WANism which may eventually disappear.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_atosubnet.3.html
-448
View File
@@ -1,448 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoaddr, addrtoa - convert Internet addresses to and from ASCII
<BR>
ipsec atosubnet, subnettoa - convert subnet/mask ASCII form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr);</B>
<BR>
<B>size_t addrtoa(struct in_addr addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *atosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr, struct in_addr *mask);</B>
<BR>
<B>size_t subnettoa(struct in_addr addr, struct in_addr mask,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
for their replacements.
<P>
<I>Atoaddr</I>
converts an ASCII name or dotted-decimal address into a binary address
(in network byte order).
<I>Addrtoa</I>
does the reverse conversion, back to an ASCII dotted-decimal address.
<I>Atosubnet</I>
and
<I>subnettoa</I>
do likewise for the ``address/mask'' ASCII form used to write a
specification of a subnet.
<P>
An address is specified in ASCII as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
ASCII-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of
<I>addrtoa</I>
is always complete and does not contain leading zeros.
<P>
The letters in
a hexadecimal address may be uppercase or lowercase or any mixture thereof.
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
Name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>atoaddr</I>.
In addition, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>.
<P>
<I>Atosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettoa</I>
generates the decimal-integer-bit-count
form of the mask,
with no leading zeros,
unless the mask is non-contiguous.
<P>
The
<I>srclen</I>
parameter of
<I>atoaddr</I>
and
<I>atosubnet</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOA_BUF</B>
and
<B>SUBNETTOA_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
The ASCII-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-ASCII functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoaddr</I>
are:
empty input;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal form;
dotted-decimal component too large to fit in 8 bits.
<P>
Fatal errors in
<I>atosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>atoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtoa</I>
and
<I>subnettoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_atoul.3.html
-266
View File
@@ -1,266 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOUL</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOUL</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoul, ultoa - convert unsigned-long numbers to and from ASCII
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoul(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int base, unsigned long *n);</B>
<BR>
<B>size_t ultoa(unsigned long n, int base, char *dst,</B>
<BR>
&nbsp;
<B>size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoul.3.html">ipsec_ttoul</A></I>(3)
for their replacements.
<P>
<I>Atoul</I>
converts an ASCII number into a binary
<B>unsigned long</B>
value.
<I>Ultoa</I>
does the reverse conversion, back to an ASCII version.
<P>
Numbers are specified in ASCII as
decimal (e.g.
<B>123</B>),
octal with a leading zero (e.g.
<B>012</B>,
which has value 10),
or hexadecimal with a leading
<B>0x</B>
(e.g.
<B>0x1f</B>,
which has value 31)
in either upper or lower case.
<P>
The
<I>srclen</I>
parameter of
<I>atoul</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>base</I>
parameter of
<I>atoul</I>
can be
<B>8</B>,
<B>10</B>,
or
<B>16</B>,
in which case the number supplied is assumed to be of that form
(and in the case of
<B>16</B>,
to lack any
<B>0x</B>
prefix).
It can also be
<B>0</B>,
in which case the number is examined for a leading zero
or a leading
<B>0x</B>
to determine its base,
or
<B>13</B>
(halfway between 10 and 16),
which has the same effect as
<B>0</B>
except that a non-hexadecimal
number is considered decimal regardless of any leading zero.
<P>
The
<I>dstlen</I>
parameter of
<I>ultoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
<P>
The
<I>base</I>
parameter of
<I>ultoa</I>
must be
<B>8</B>,
<B>10</B>,
or
<B>16</B>.
<P>
<I>Atoul</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Ultoa</I>
returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="atol.3.html">atol</A>(3), <A HREF="strtoul.3.html">strtoul</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoul</I>
are:
empty input;
unknown
<I>base</I>;
non-digit character found;
number too large for an
<B>unsigned long</B>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
There is no provision for reporting an invalid
<I>base</I>
parameter given to
<I>ultoa</I>.
<P>
The restriction of error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The error-reporting convention lends itself to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoul( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_auto.8.html
-416
View File
@@ -1,416 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_AUTO</TITLE>
</HEAD><BODY>
<H1>IPSEC_AUTO</H1>
Section: Maintenance Commands (8)<BR>Updated: 31 Jan 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec auto - control automatically-keyed IPsec connections
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>auto</B>
[
<B>--show</B>
] [
<B>--showonly</B>
] [
<B>--asynchronous</B>
]
<BR>
&nbsp;&nbsp;&nbsp;[
<B>--config</B>
configfile
] [
<B>--verbose</B>
]
<BR>
&nbsp;&nbsp;&nbsp;operation
connection
<P>
<B>ipsec</B>
<B>auto</B>
[
<B>--show</B>
] [
<B>--showonly</B>
] operation
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Auto</I>
manipulates automatically-keyed FreeS/WAN IPsec connections,
setting them up and shutting them down
based on the information in the IPsec configuration file.
In the normal usage,
<I>connection</I>
is the name of a connection specification in the configuration file;
<I>operation</I>
is
<B>--add</B>,
<B>--delete</B>,
<B>--replace</B>,
<B>--up</B>,
<B>--down</B>,
<B>--route</B>,
or
<B>--unroute</B>.
The
<B>--ready</B>,
<B>--rereadsecrets</B>,
<B>--rereadgroups</B>,
and
<B>--status</B>
<I>operations</I>
do not take a connection name.
<I>Auto</I>
generates suitable
commands and feeds them to a shell for execution.
<P>
The
<B>--add</B>
operation adds a connection specification to the internal database
within
<I>pluto</I>;
it will fail if
<I>pluto</I>
already has a specification by that name.
The
<B>--delete</B>
operation deletes a connection specification from
<I>pluto</I>'s
internal database (also tearing down any connections based on it);
it will fail if the specification does not exist.
The
<B>--replace</B>
operation is equivalent to
<B>--delete</B>
(if there is already a specification by the given name)
followed by
<B>--add</B>,
and is a convenience for updating
<I>pluto</I>'s
internal specification to match an external one.
(Note that a
<B>--rereadsecrets</B>
may also be needed.)
The
<B>--rereadgroups</B>
operation causes any changes to the policy group files to take effect
(this is currently a synonym for
<B>--ready</B>,
but that may change).
None of the other operations alters the internal database.
<P>
The
<B>--up</B>
operation asks
<I>pluto</I>
to establish a connection based on an entry in its internal database.
The
<B>--down</B>
operation tells
<I>pluto</I>
to tear down such a connection.
<P>
Normally,
<I>pluto</I>
establishes a route to the destination specified for a connection as
part of the
<B>--up</B>
operation.
However, the route and only the route can be established with the
<B>--route</B>
operation.
Until and unless an actual connection is established,
this discards any packets sent there,
which may be preferable to having them sent elsewhere based on a more
general route (e.g., a default route).
<P>
Normally,
<I>pluto</I>'s
route to a destination remains in place when a
<B>--down</B>
operation is used to take the connection down
(or if connection setup, or later automatic rekeying, fails).
This permits establishing a new connection (perhaps using a
different specification; the route is altered as necessary)
without having a ``window'' in which packets might go elsewhere
based on a more general route.
Such a route can be removed using the
<B>--unroute</B>
operation
(and is implicitly removed by
<B>--delete</B>).
<P>
The
<B>--ready</B>
operation tells
<I>pluto</I>
to listen for connection-setup requests from other hosts.
Doing an
<B>--up</B>
operation before doing
<B>--ready</B>
on both ends is futile and will not work,
although this is now automated as part of IPsec startup and
should not normally be an issue.
<P>
The
<B>--status</B>
operation asks
<I>pluto</I>
for current connection status.
The output format is ad-hoc and likely to change.
<P>
The
<B>--rereadsecrets</B>
operation tells
<I>pluto</I>
to re-read the
<I>/etc/ipsec.secrets</I>
secret-keys file,
which it normally reads only at startup time.
(This is currently a synonym for
<B>--ready</B>,
but that may change.)
<P>
The
<B>--show</B>
option turns on the
<B>-x</B>
option of the shell used to execute the commands,
so each command is shown as it is executed.
<P>
The
<B>--showonly</B>
option causes
<I>auto</I>
to show the commands it would run, on standard output,
and not run them.
<P>
The
<B>--asynchronous</B>
option, applicable only to the
<B>up</B>
operation,
tells
<I>pluto</I>
to attempt to establish the connection,
but does not delay to report results.
This is especially useful to start multiple connections in parallel
when network links are slow.
<P>
The
<B>--verbose</B>
option instructs
<I>auto</I>
to pass through all output from
<I><A HREF="ipsec_whack.8.html">ipsec_whack</A></I>(8),
including log output that is normally filtered out as uninteresting.
<P>
The
<B>--config</B>
option specifies a non-standard location for the IPsec
configuration file (default
<I>/etc/ipsec.conf</I>).
<P>
See
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5)
for details of the configuration file.
Apart from the basic parameters which specify the endpoints and routing
of a connection (<B>left</B>
and
<B>right</B>,
plus possibly
<B>leftsubnet</B>,
<B>leftnexthop</B>,
<B>leftfirewall</B>,
their
<B>right</B>
equivalents,
and perhaps
<B>type</B>),
an
<I>auto</I>
connection almost certainly needs a
<B>keyingtries</B>
parameter (since the
<B>keyingtries</B>
default is poorly chosen).
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
/etc/ipsec.conf<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>default IPSEC configuration file<BR>
<BR>
/var/run/ipsec.info<TT>&nbsp;&nbsp;&nbsp;</TT><B>%defaultroute</B> information<BR>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.conf.5.html">ipsec.conf</A>(5), <A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8), <A HREF="ipsec_whack.8.html">ipsec_whack</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
Although an
<B>--up</B>
operation does connection setup on both ends,
<B>--down</B>
tears only one end of the connection down
(although the orphaned end will eventually time out).
<P>
There is no support for
<B>passthrough</B>
connections.
<P>
A connection description which uses
<B>%defaultroute</B>
for one of its
<B>nexthop</B>
parameters but not the other may be falsely
rejected as erroneous in some circumstances.
<P>
The exit status of
<B>--showonly</B>
does not always reflect errors discovered during processing of the request.
(This is fine for human inspection, but not so good for use in scripts.)
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_barf.8.html
-150
View File
@@ -1,150 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_BARF</TITLE>
</HEAD><BODY>
<H1>IPSEC_BARF</H1>
Section: Maintenance Commands (8)<BR>Updated: 17 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec barf - spew out collected IPsec debugging information
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>barf</B>
[
<B>--short</B>
]
<P>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Barf</I>
outputs (on standard output) a collection of debugging information
(contents of files, selections from logs, etc.)
related to the IPsec encryption/authentication system.
It is primarily a convenience for remote debugging,
a single command which packages up (and labels) all information
that might be relevant to diagnosing a problem in IPsec.
<P>
<P>
The
<B>--short</B>
option limits the length of
the log portion of
<I>barf</I>'s
output, which can otherwise be extremely voluminous
if debug logging is turned on.
<P>
<I>Barf</I>
censors its output,
replacing keys
and secrets with brief checksums to avoid revealing sensitive information.
<P>
Beware that the output of both commands is aimed at humans,
not programs,
and the output format is subject to change without warning.
<P>
<I>Barf</I>
has to figure out which files in
<I>/var/log</I>
contain the IPsec log messages.
It looks for KLIPS and general log messages first in
<I>messages</I>
and
<I>syslog</I>,
and for Pluto messages first in
<I>secure</I>,
<I>auth.log</I>,
and
<I>debug</I>.
In both cases,
if it does not find what it is looking for in one of those ``likely'' places,
it will resort to a brute-force search of most (non-compressed) files in
<I>/var/log</I>.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
<PRE>
/proc/net/*
/var/log/*
/etc/ipsec.conf
/etc/ipsec.secrets
</PRE>
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
<I>Barf</I>
uses heuristics to try to pick relevant material out of the logs,
and relevant messages
which are not labelled with any of the tags that
<I>barf</I>
looks for will be lost.
We think we've eliminated the last such case, but one never knows...
<P>
Finding
<I>updown</I>
scripts (so they can be included in output) is, in general, difficult.
<I>Barf</I>
uses a very simple heuristic that is easily fooled.
<P>
The brute-force search for the right log files can get expensive on
systems with a lot of clutter in
<I>/var/log</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_bitstomask.3.html
-122
View File
@@ -1,122 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_GOODMASK</TITLE>
</HEAD><BODY>
<H1>IPSEC_GOODMASK</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec goodmask - is this Internet subnet mask a valid one?
<BR>
ipsec masktobits - convert Internet subnet mask to bit count
<BR>
ipsec bitstomask - convert bit count to Internet subnet mask
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int goodmask(struct in_addr mask);</B>
<BR>
<B>int masktobits(struct in_addr mask);</B>
<BR>
<B>struct in_addr bitstomask(int n);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
see
<I><A HREF="ipsec_masktocount.3.html">ipsec_masktocount</A></I>(3)
for a partial replacement.
<P>
<I>Goodmask</I>
reports whether the subnet
<I>mask</I>
is a valid one,
i.e. consists of a (possibly empty) sequence of
<B>1</B>s
followed by a (possibly empty) sequence of
<B>0</B>s.
<I>Masktobits</I>
takes a (valid) subnet mask and returns the number of
<B>1</B>
bits in it.
<I>Bitstomask</I>
reverses this,
returning the subnet mask corresponding to bit count
<I>n</I>.
<P>
All masks are in network byte order.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
<I>Masktobits</I>
returns
<B>-1</B>
for an invalid mask.
<I>Bitstomask</I>
returns an all-zeros mask for a negative or out-of-range
<I>n</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The error-reporting convention of
<I>bitstomask</I>
is less than ideal;
zero is sometimes a legitimate mask.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_broadcastof.3.html
-107
View File
@@ -1,107 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_SUBNETOF</TITLE>
</HEAD><BODY>
<H1>IPSEC_SUBNETOF</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec subnetof - given Internet address and subnet mask, return subnet number
<BR>
ipsec hostof - given Internet address and subnet mask, return host part
<BR>
ipsec broadcastof - given Internet address and subnet mask, return broadcast address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>struct in_addr subnetof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr hostof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr broadcastof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_networkof.3.html">ipsec_networkof</A></I>(3)
for their replacements.
<P>
<I>Subnetof</I>
takes an Internet
<I>address</I>
and a subnet
<I>mask</I>
and returns the network part of the address
(all in network byte order).
<I>Hostof</I>
similarly returns the host part, and
<I>broadcastof</I>
returns the broadcast address (all-1s convention) for the network.
<P>
These functions are provided to hide the Internet bit-munging inside
an API, in hopes of easing the eventual transition to IPv6.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
Calling functions for this is more costly than doing it yourself.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_calcgoo.8.html
-78
View File
@@ -1,78 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_CALCGOO</TITLE>
</HEAD><BODY>
<H1>IPSEC_CALCGOO</H1>
Section: Maintenance Commands (8)<BR>Updated: 8 June 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec calcgoo - calculate hex value for matching modules and kernels
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>calcgoo</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>calcgoo</I>
accepts the output of
<B>nm -ao</B>
or
<B>/proc/ksyms</B>
and extracts a release dependant list of symbols from it. The symbols
are processed to extract the values assigned during the MODVERSIONS
process. This process makes sure that Linux modules are only loaded
on matching kernels.
This routine is used to find an appropriate module to match the currently
running kernel by _startklips.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
<PRE>
/proc/ksyms
</PRE>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec__startklips.8.html">ipsec__startklips</A>(8), <A HREF="genksyms.8.html">genksyms</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Michael Richardson.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_copyright_notice.3.html
-94
View File
@@ -1,94 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_VERSION</TITLE>
</HEAD><BODY>
<H1>IPSEC_VERSION</H1>
Section: C Library Functions (3)<BR>Updated: 21 Nov 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ipsec_version_code - get IPsec version code
<BR>
ipsec ipsec_version_string - get full IPsec version string
<BR>
ipsec ipsec_copyright_notice - get IPsec copyright notice
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *ipsec_version_code(void);</B>
<BR>
<B>const char *ipsec_version_string(void);</B>
<BR>
<B>const char **ipsec_copyright_notice(void);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions provide information on version numbering and copyright
of the Linux FreeS/WAN IPsec implementation.
<P>
<I>Ipsec_version_code</I>
returns a pointer to a string constant
containing the current IPsec version code,
such as ``1.92'' or ``snap2001Nov19b''.
<P>
<I>Ipsec_version_string</I>
returns a pointer to a string constant giving a full version identification,
consisting of the version code preceded by a prefix identifying the software,
e.g. ``Linux FreeS/WAN 1.92''.
<P>
<I>Ipsec_copyright_notice</I>
returns a pointer to a vector of pointers,
terminated by a
<B>NULL</B>,
which is the text of a suitable copyright notice.
Each pointer points to a string constant (possibly empty) which is one line
of the somewhat-verbose copyright notice.
The strings are NUL-terminated and do not contain a newline;
supplying suitable line termination for the output device is
the caller's responsibility.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_datatot.3.html
-439
View File
@@ -1,439 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_TTODATA</TITLE>
</HEAD><BODY>
<H1>IPSEC_TTODATA</H1>
Section: C Library Functions (3)<BR>Updated: 16 August 2003<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ttodata, datatot - convert binary data bytes from and to text formats
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *ttodata(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int base, char *dst, size_t dstlen, size_t *lenp);</B>
<BR>
<B>const char *ttodatav(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int base, char *dst, size_t dstlen, size_t *lenp,</B>
<BR>
&nbsp;
<B>char *errp, size_t errlen, int flags);</B>
<BR>
<B>size_t datatot(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ttodata</I>,
<I>ttodatav</I>,
and
<I>datatot</I>
convert arbitrary binary data (e.g. encryption or authentication keys)
from and to more-or-less human-readable text formats.
<P>
Currently supported formats are hexadecimal, base64, and characters.
<P>
A hexadecimal text value begins with a
<B>0x</B>
(or
<B>0X</B>)
prefix and continues with two-digit groups
of hexadecimal digits (0-9, and a-f or A-F),
each group encoding the value of one binary byte, high-order digit first.
A single
<B>_</B>
(underscore)
between consecutive groups is ignored, permitting punctuation to improve
readability; doing this every eight digits seems about right.
<P>
A base64 text value begins with a
<B>0s</B>
(or
<B>0S</B>)
prefix
and continues with four-digit groups of base64 digits (A-Z, a-z, 0-9, +, and /),
each group encoding the value of three binary bytes as described in
section 6.8 of RFC 2045.
If
<B>flags</B>
has the
<B>TTODATAV_IGNORESPACE</B>
bit on, blanks are ignore (after the prefix).
Note that the last one or two digits of a base64 group can be
<B>=</B>
to indicate that fewer than three binary bytes are encoded.
<P>
A character text value begins with a
<B>0t</B>
(or
<B>0T</B>)
prefix
and continues with text characters, each being the value of one binary byte.
<P>
All these functions basically copy data from
<I>src</I>
(whose size is specified by
<I>srclen</I>)
to
<I>dst</I>
(whose size is specified by
<I>dstlen</I>),
doing the conversion en route.
If the result will not fit in
<I>dst</I>,
it is truncated;
under no circumstances are more than
<I>dstlen</I>
bytes of result written to
<I>dst</I>.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result bytes are written at all.
<P>
The
<I>base</I>
parameter of
<I>ttodata</I>
and
<I>ttodatav</I>
specifies what format the input is in;
normally it should be
<B>0</B>
to signify that this gets figured out from the prefix.
Values of
<B>16</B>,
<B>64</B>,
and
<B>256</B>
respectively signify hexadecimal, base64, and character-text formats
without prefixes.
<P>
The
<I>format</I>
parameter of
<I>datatot</I>,
a single character used as a type code,
specifies which text format is wanted.
The value
<B>0</B>
(not ASCII
<B>'0'</B>,
but a zero value) specifies a reasonable default.
Other currently-supported values are:
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT><B>'x'</B>
<DD>
continuous lower-case hexadecimal with a
<B>0x</B>
prefix
<DT><B>'h'</B>
<DD>
lower-case hexadecimal with a
<B>0x</B>
prefix and a
<B>_</B>
every eight digits
<DT><B>':'</B>
<DD>
lower-case hexadecimal with no prefix and a
<B>:</B>
(colon) every two digits
<DT><B>16</B>
<DD>
lower-case hexadecimal with no prefix or
<B>_</B>
<DT><B>'s'</B>
<DD>
continuous base64 with a
<B>0s</B>
prefix
<DT><B>64</B>
<DD>
continuous base64 with no prefix
</DL>
</DL>
<P>
The default format is currently
<B>'h'</B>.
<P>
<I>Ttodata</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
On success,
if and only if
<I>lenp</I>
is non-NULL,
<B>*lenp</B>
is set to the number of bytes required to contain the full untruncated result.
It is the caller's responsibility to check this against
<I>dstlen</I>
to determine whether he has obtained a complete result.
The
<B>*lenp</B>
value is correct even if
<I>dstlen</I>
is zero, which offers a way to determine how much space would be needed
before having to allocate any.
<P>
<I>Ttodatav</I>
is just like
<I>ttodata</I>
except that in certain cases,
if
<I>errp</I>
is non-NULL,
the buffer pointed to by
<I>errp</I>
(whose length is given by
<I>errlen</I>)
is used to hold a more detailed error message.
The return value is NULL for success,
and is either
<I>errp</I>
or a pointer to a string literal for failure.
If the size of the error-message buffer is
inadequate for the desired message,
<I>ttodatav</I>
will fall back on returning a pointer to a literal string instead.
The
<I>freeswan.h</I>
header file defines a constant
<B>TTODATAV_BUF</B>
which is the size of a buffer large enough for worst-case results.
<P>
The normal return value of
<I>datatot</I>
is the number of bytes required
to contain the full untruncated result.
It is the caller's responsibility to check this against
<I>dstlen</I>
to determine whether he has obtained a complete result.
The return value is correct even if
<I>dstlen</I>
is zero, which offers a way to determine how much space would be needed
before having to allocate any.
A return value of
<B>0</B>
signals a fatal error of some kind
(see DIAGNOSTICS).
<P>
A zero value for
<I>srclen</I>
in
<I>ttodata</I>
(but not
<I>datatot</I>!)
is synonymous with
<B>strlen(src)</B>.
A non-zero
<I>srclen</I>
in
<I>ttodata</I>
must not include the terminating NUL.
<P>
Unless
<I>dstlen</I>
is zero,
the result supplied by
<I>datatot</I>
is always NUL-terminated,
and its needed-size return value includes space for the terminating NUL.
<P>
Several obsolete variants of these functions
(<I>atodata</I>,
<I>datatoa</I>,
<I>atobytes</I>,
and
<I>bytestoa</I>)
are temporarily also supported.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="sprintf.3.html">sprintf</A>(3), <A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>ttodata</I>
and
<I>ttodatav</I>
are:
unknown characters in the input;
unknown or missing prefix;
unknown base;
incomplete digit group;
non-zero padding in a base64 less-than-three-bytes digit group;
zero-length input.
<P>
Fatal errors in
<I>datatot</I>
are:
unknown format code;
zero-length input.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Datatot</I>
should have a format code to produce character-text output.
<P>
The
<B>0s</B>
and
<B>0t</B>
prefixes are the author's inventions and are not a standard
of any kind.
They have been chosen to avoid collisions with existing practice
(some C implementations use
<B>0b</B>
for binary)
and possible confusion with unprefixed hexadecimal.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_eroute.5.html
-370
View File
@@ -1,370 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_EROUTE</TITLE>
</HEAD><BODY>
<H1>IPSEC_EROUTE</H1>
Section: File Formats (5)<BR>Updated: 20 Sep 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec_eroute - list of existing eroutes
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>eroute</B>
<P>
<B>cat</B>
<B>/proc/net/ipsec_eroute</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>/proc/net/ipsec_eroute</I>
lists the IPSEC extended routing tables,
which control what (if any) processing is applied
to non-encrypted packets arriving for IPSEC processing and forwarding.
At this point it is a read-only file.
<P>
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
packet count,
<DT>+<DD>
source address with mask,
<DT>+<DD>
a '-&gt;' separator for visual and automated parsing between src and dst
<DT>+<DD>
destination address with mask
<DT>+<DD>
a '=&gt;' separator for visual and automated parsing between selection
criteria and SAID to use
<DT>+<DD>
SAID (Security Association IDentifier), comprised of:
<DT>+<DD>
protocol
(<I>proto</I>),
<DT>+<DD>
address family
(<I>af</I>),
where '.' stands for IPv4 and ':' for IPv6
<DT>+<DD>
Security Parameters Index
(<I>SPI</I>),
<DT>+<DD>
effective destination
(<I>edst</I>),
where the packet should be forwarded after processing
(normally the other security gateway)
together indicate which Security Association should be used to process
the packet,
<DT>+<DD>
source identity text string with no whitespace, in parens,
<DT>+<DD>
destination identity text string with no whitespace, in parens
</DL>
<P>
Addresses are written as IPv4 dotted quads or IPv6 coloned hex,
protocol is one of &quot;ah&quot;, &quot;esp&quot;, &quot;comp&quot; or &quot;tun&quot;
and
SPIs are prefixed hexadecimal numbers where the prefix '.' is for IPv4 and the prefix ':' is for IPv6
<P>
SAIDs are written as &quot;<A HREF="mailto:protoafSPI@edst">protoafSPI@edst</A>&quot;. There are also 5
&quot;magic&quot; SAIDs which have special meaning:
<DL COMPACT>
<DT>+<DD>
<B>%drop</B>
means that matches are to be dropped
<DT>+<DD>
<B>%reject</B>
means that matches are to be dropped and an ICMP returned, if
possible to inform
<DT>+<DD>
<B>%trap</B>
means that matches are to trigger an ACQUIRE message to the Key
Management daemon(s) and a hold eroute will be put in place to
prevent subsequent packets also triggering ACQUIRE messages.
<DT>+<DD>
<B>%hold</B>
means that matches are to stored until the eroute is replaced or
until that eroute gets reaped
<DT>+<DD>
<B>%pass</B>
means that matches are to allowed to pass without IPSEC processing
<BR>
</DL>
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<P>
<B>1867 172.31.252.0/24 -&gt; 0.0.0.0/0 =&gt; <A HREF="mailto:[email protected]">[email protected]</A> </B>
<BR>
<B> ()<TT>&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 1,867 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to protect traffic between the subnet
<B>172.31.252.0</B>
with a subnet mask of
<B>24</B>
bits and the default address/mask represented by an address of
<B>0.0.0.0</B>
with a subnet mask of
<B>0</B>
bits using the local machine as a security gateway on this end of the
tunnel and the machine
<B>192.168.43.1</B>
on the other end of the tunnel with a Security Association IDentifier of
<B><A HREF="mailto:[email protected]">[email protected]</A></B>
which means that it is a tunnel mode connection (4, IPPROTO_IPIP) with a
Security Parameters Index of
<B>130</B>
in hexadecimal with no identies defined for either end.
<P>
<B>125 3049:1::/64 -&gt; 0:0/0 =&gt; tun:<A HREF="mailto:130@3058">130@3058</A>:4::5<TT>&nbsp;</TT>()<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 125 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to protect traffic between the subnet
<B>3049:1::</B>
with a subnet mask of
<B>64</B>
bits and the default address/mask represented by an address of
<B>0:0</B>
with a subnet mask of
<B>0</B>
bits using the local machine as a security gateway on this end of the
tunnel and the machine
<B>3058:4::5</B>
on the other end of the tunnel with a Security Association IDentifier of
<B>tun:<A HREF="mailto:130@3058">130@3058</A>:4::5</B>
which means that it is a tunnel mode connection with a
Security Parameters Index of
<B>130</B>
in hexadecimal with no identies defined for either end.
<P>
<B>42 192.168.6.0/24 -&gt; 192.168.7.0/24 =&gt; %passthrough</B>
<P>
means that 42 packets have been sent to an
<B>eroute</B>
that has been set up to pass the traffic from the subnet
<B>192.168.6.0</B>
with a subnet mask of
<B>24</B>
bits and to subnet
<B>192.168.7.0</B>
with a subnet mask of
<B>24</B>
bits without any IPSEC processing with no identies defined for either end.
<P>
<B>2112 192.168.8.55/32 -&gt; 192.168.9.47/24 =&gt; %hold<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>(east)<TT>&nbsp;&nbsp;</TT>()</B>
<P>
means that 2112 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to hold the traffic from the host
<B>192.168.8.55</B>
and to host
<B>192.168.9.47</B>
until a key exchange from a Key Management daemon
succeeds and puts in an SA or fails and puts in a pass
or drop eroute depending on the default configuration with the local client
defined as &quot;east&quot; and no identy defined for the remote end.
<P>
<B>2001 192.168.2.110/32 -&gt; 192.168.2.120/32 =&gt; </B>
<BR>
<B> <A HREF="mailto:[email protected]">[email protected]</A><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 2001 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to protect traffic between the host
<B>192.168.2.110</B>
and the host
<B>192.168.2.120</B>
using
<B>192.168.2.110</B>
as a security gateway on this end of the
connection and the machine
<B>192.168.2.120</B>
on the other end of the connection with a Security Association IDentifier of
<B><A HREF="mailto:[email protected]">[email protected]</A></B>
which means that it is a transport mode connection with a Security
Parameters Index of
<B>e6de</B>
in hexadecimal using Encapsuation Security Payload protocol (50,
IPPROTO_ESP) with no identies defined for either end.
<P>
<B>1984 3049:1::110/128 -&gt; 3049:1::120/128 =&gt; </B>
<BR>
<B> ah:<A HREF="mailto:f5ed@3049">f5ed@3049</A>:1::120<TT>&nbsp;&nbsp;&nbsp;</TT>()<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 1984 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to authenticate traffic between the host
<B>3049:1::110</B>
and the host
<B>3049:1::120</B>
using
<B>3049:1::110</B>
as a security gateway on this end of the
connection and the machine
<B>3049:1::120</B>
on the other end of the connection with a Security Association IDentifier of
<B>ah:<A HREF="mailto:f5ed@3049">f5ed@3049</A>:1::120</B>
which means that it is a transport mode connection with a Security
Parameters Index of
<B>f5ed</B>
in hexadecimal using Authentication Header protocol (51,
IPPROTO_AH) with no identies defined for either end.
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_eroute, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.5.html">ipsec_tncfg</A>(5), <A HREF="ipsec_spi.5.html">ipsec_spi</A>(5),
<A HREF="ipsec_spigrp.5.html">ipsec_spigrp</A>(5), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5), <A HREF="ipsec_eroute.8.html">ipsec_eroute</A>(8), <A HREF="ipsec_version.5.html">ipsec_version</A>(5),
<A HREF="ipsec_pf_key.5.html">ipsec_pf_key</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_eroute.8.html
-421
View File
@@ -1,421 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_EROUTE</TITLE>
</HEAD><BODY>
<H1>IPSEC_EROUTE</H1>
Section: Maintenance Commands (8)<BR>Updated: 21 Jun 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec eroute - manipulate IPSEC extended routing tables
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>eroute</B>
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--add</B>
<B>--eraf (inet | inet6)</B>
<B>--src</B>
src/srcmaskbits|srcmask
<B>--dst</B>
dst/dstmaskbits|dstmask
&lt;SAID&gt;
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--replace</B>
<B>--eraf (inet | inet6)</B>
<B>--src</B>
src/srcmaskbits|srcmask
<B>--dst</B>
dst/dstmaskbits|dstmask
&lt;SAID&gt;
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--del</B>
<B>--eraf (inet | inet6)</B>
<B>--src</B>
src/srcmaskbits|srcmask
<B>--dst</B>
dst/dstmaskbits|dstmask
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--clear</B>
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--help</B>
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--version</B>
<P>
Where &lt;SAID&gt; is
<B>--af</B>
(inet | inet6)
<B>--edst</B>
edst
<B>--spi</B>
spi
<B>--proto</B>
proto
OR
<B>--said</B>
said
OR
<B>--said</B>
<B>(%passthrough | %passthrough4 | %passthrough6)</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Eroute</I>
manages the IPSEC extended routing tables,
which control what (if any) processing is applied
to non-encrypted packets arriving for IPSEC processing and forwarding.
The form with no additional arguments lists the contents of
/proc/net/ipsec_eroute.
The
<B>--add</B>
form adds a table entry, the
<B>--replace</B>
form replaces a table entry, while the
<B>--del</B>
form deletes one. The
<B>--clear</B>
form deletes the entire table.
<P>
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
source and destination addresses,
with masks,
for selection of packets
<DT>+<DD>
Security Association IDentifier, comprised of:
<DT>+<DD>
protocol
(<I>proto</I>), indicating (together with the
effective destination and the security parameters index)
which Security Association should be used to process the packet
<DT>+<DD>
address family
(<I>af</I>),
<DT>+<DD>
Security Parameters Index
(<I>spi</I>), indicating (together with the
effective destination and protocol)
which Security Association should be used to process the packet
(must be larger than or equal to 0x100)
<DT>+<DD>
effective destination
(<I>edst</I>),
where the packet should be forwarded after processing
(normally the other security gateway)
<DT>+<DD>
OR
<DT>+<DD>
SAID
(<I>said</I>), indicating
which Security Association should be used to process the packet
</DL>
<P>
Addresses are written as IPv4 dotted quads or IPv6 coloned hex,
protocol is one of &quot;ah&quot;, &quot;esp&quot;, &quot;comp&quot; or &quot;tun&quot; and SPIs are
prefixed hexadecimal numbers where '.' represents IPv4 and ':'
stands for IPv6.
<P>
SAIDs are written as &quot;<A HREF="mailto:protoafSPI@address">protoafSPI@address</A>&quot;. There are also 5
&quot;magic&quot; SAIDs which have special meaning:
<DL COMPACT>
<DT>+<DD>
<B>%drop</B>
means that matches are to be dropped
<DT>+<DD>
<B>%reject</B>
means that matches are to be dropped and an ICMP returned, if
possible to inform
<DT>+<DD>
<B>%trap</B>
means that matches are to trigger an ACQUIRE message to the Key
Management daemon(s) and a hold eroute will be put in place to
prevent subsequent packets also triggering ACQUIRE messages.
<DT>+<DD>
<B>%hold</B>
means that matches are to stored until the eroute is replaced or
until that eroute gets reaped
<DT>+<DD>
<B>%pass</B>
means that matches are to allowed to pass without IPSEC processing
</DL>
<P>
The format of /proc/net/ipsec_eroute is listed in <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5).
<BR>
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<P>
<B>ipsec eroute --add --eraf inet --src 192.168.0.1/32 \</B>
<BR>
<B> --dst 192.168.2.0/24 --af inet --edst 192.168.0.2 \</B>
<BR>
<B> --spi 0x135 --proto tun</B>
<P>
sets up an
<B>eroute</B>
on a Security Gateway to protect traffic between the host
<B>192.168.0.1</B>
and the subnet
<B>192.168.2.0</B>
with
<B>24</B>
bits of subnet mask via Security Gateway
<B>192.168.0.2</B>
using the Security Association with address
<B>192.168.0.2</B>,
Security Parameters Index
<B>0x135</B>
and protocol
<B>tun</B>
(50, IPPROTO_ESP).
<P>
<B>ipsec eroute --add --eraf inet6 --src 3049:1::1/128 \</B>
<BR>
<B> --dst 3049:2::/64 --af inet6 --edst 3049:1::2 \</B>
<BR>
<B> --spi 0x145 --proto tun</B>
<P>
sets up an
<B>eroute</B>
on a Security Gateway to protect traffic between the host
<B>3049:1::1</B>
and the subnet
<B>3049:2::</B>
with
<B>64</B>
bits of subnet mask via Security Gateway
<B>3049:1::2</B>
using the Security Association with address
<B>3049:1::2</B>,
Security Parameters Index
<B>0x145</B>
and protocol
<B>tun</B>
(50, IPPROTO_ESP).
<P>
<B>ipsec eroute --replace --eraf inet --src company.com/24 \</B>
<BR>
<B> --dst <A HREF="ftp://ftp.ngo.org">ftp.ngo.org</A>/32 --said <A HREF="mailto:[email protected]">[email protected]</A></B>
<P>
replaces an
<B>eroute</B>
on a Security Gateway to protect traffic between the subnet
<B>company.com</B>
with
<B>24</B>
bits of subnet mask and the host
<B><A HREF="ftp://ftp.ngo.org">ftp.ngo.org</A></B>
via Security Gateway
<B>gw.ngo.org</B>
using the Security Association with Security Association ID
<B><A HREF="mailto:[email protected]">[email protected]</A></B>
<P>
<B>ipsec eroute --del --eraf inet --src company.com/24 \</B>
<BR>
<B> --dst <A HREF="http://www.ietf.org">www.ietf.org</A>/32 --said %passthrough4</B>
<P>
deletes an
<B>eroute</B>
on a Security Gateway that allowed traffic between the subnet
<B>company.com</B>
with
<B>24</B>
bits of subnet mask and the host
<B><A HREF="http://www.ietf.org">www.ietf.org</A></B>
to pass in the clear, unprocessed.
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_eroute, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_spi.8.html">ipsec_spi</A>(8),
<A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8), <A HREF="ipsec_klipsdebug.8.html">ipsec_klipsdebug</A>(8), <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_goodmask.3.html
-122
View File
@@ -1,122 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_GOODMASK</TITLE>
</HEAD><BODY>
<H1>IPSEC_GOODMASK</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec goodmask - is this Internet subnet mask a valid one?
<BR>
ipsec masktobits - convert Internet subnet mask to bit count
<BR>
ipsec bitstomask - convert bit count to Internet subnet mask
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int goodmask(struct in_addr mask);</B>
<BR>
<B>int masktobits(struct in_addr mask);</B>
<BR>
<B>struct in_addr bitstomask(int n);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
see
<I><A HREF="ipsec_masktocount.3.html">ipsec_masktocount</A></I>(3)
for a partial replacement.
<P>
<I>Goodmask</I>
reports whether the subnet
<I>mask</I>
is a valid one,
i.e. consists of a (possibly empty) sequence of
<B>1</B>s
followed by a (possibly empty) sequence of
<B>0</B>s.
<I>Masktobits</I>
takes a (valid) subnet mask and returns the number of
<B>1</B>
bits in it.
<I>Bitstomask</I>
reverses this,
returning the subnet mask corresponding to bit count
<I>n</I>.
<P>
All masks are in network byte order.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
<I>Masktobits</I>
returns
<B>-1</B>
for an invalid mask.
<I>Bitstomask</I>
returns an all-zeros mask for a negative or out-of-range
<I>n</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The error-reporting convention of
<I>bitstomask</I>
is less than ideal;
zero is sometimes a legitimate mask.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_hostof.3.html
-107
View File
@@ -1,107 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_SUBNETOF</TITLE>
</HEAD><BODY>
<H1>IPSEC_SUBNETOF</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec subnetof - given Internet address and subnet mask, return subnet number
<BR>
ipsec hostof - given Internet address and subnet mask, return host part
<BR>
ipsec broadcastof - given Internet address and subnet mask, return broadcast address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>struct in_addr subnetof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr hostof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr broadcastof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_networkof.3.html">ipsec_networkof</A></I>(3)
for their replacements.
<P>
<I>Subnetof</I>
takes an Internet
<I>address</I>
and a subnet
<I>mask</I>
and returns the network part of the address
(all in network byte order).
<I>Hostof</I>
similarly returns the host part, and
<I>broadcastof</I>
returns the broadcast address (all-1s convention) for the network.
<P>
These functions are provided to hide the Internet bit-munging inside
an API, in hopes of easing the eventual transition to IPv6.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
Calling functions for this is more costly than doing it yourself.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_ikeping.8.html
-137
View File
@@ -1,137 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_IKEPING</TITLE>
</HEAD><BODY>
<H1>IPSEC_IKEPING</H1>
Section: Maintenance Commands (8)<BR>Updated: 23 Feb 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ikeping - send/receive ISAKMP/IKE echo requests/replies
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>ikeping</B>
[
<B>--listen</B>
] [
<B>--verbose</B>
] [
<B>--wait </B>
time ] [
<B>--exchangenum </B>
num ] [
<B>--ikeport </B>
localport ] [
<B>--ikeaddress </B>
address ] [
<B>--inet</B>
] [
<B>--inet6</B>
] destaddr[/dstport] ...
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ikeping</I>
sends and receives ISAKMP/IKE echo request and echo reply packets. These
packets are intended for diagnostics purposes, in a manner similar to
<I><A HREF="ping.8.html">ping</A></I>(8)
does for ICMP echo request/reply packets.
<P>
At the time of this writing, the ISAKMP echo request/reply exchange is still
an internet-draft, and is therefore completely non-standard.
<P>
<I>Ikeping</I>
will bind to the local address given by
<B>--ikeaddress</B>
and the port number given by
<B>--ikeport</B>
defaulting to the wildcard address and the ISAKMP port 500. An ISAKMP
exchange of type 244 (a private use number) is sent to each of the
address/ports listed on the command line. The exchange number may be
overridden by the
<B>--exchangenum </B>
option.
<P>
<I>Ikeping</I>
then listens for replies, printing them as they are received. Replies
are of exchange type 245 or the specified exchange number plus 1.
<I>Ikeping </I>
will keep listening until it either receives as many echo responses as it sent,
or until the timeout period (10 seconds) has been reached. Receipt of a
packet will reset the timer. The
<B>--wait</B>
option can be used to specify a different timeout period.
<P>
If the
<B>--listen</B>
option is given, then
<I>ikeping</I>
will not send any packets. Instead, it will listen for them and reply to
each request received.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
no external files
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ping.8.html">ping</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Michael Richardson.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_initaddr.3.html
-232
View File
@@ -1,232 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_initsaid.3.html
-453
View File
@@ -1,453 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_TTOSA</TITLE>
</HEAD><BODY>
<H1>IPSEC_TTOSA</H1>
Section: C Library Functions (3)<BR>Updated: 26 Nov 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ttosa, satot - convert IPsec Security Association IDs to and from text
<BR>
ipsec initsaid - initialize an SA ID
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>typedef struct {</B>
<BR>
&nbsp;
<B>ip_address dst;</B>
<BR>
&nbsp;
<B>ipsec_spi_t spi;</B>
<BR>
&nbsp;
<B>int proto;</B>
<BR>
<B>} ip_said;</B>
<P>
<B>const char *ttosa(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>ip_said *sa);</B>
<BR>
<B>size_t satot(const ip_said *sa, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<BR>
<B>void initsaid(const ip_address *addr, ipsec_spi_t spi,</B>
<BR>
&nbsp;
<B>int proto, ip_said *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ttosa</I>
converts an ASCII Security Association (SA) specifier into an
<B>ip_said</B>
structure (containing
a destination-host address
in network byte order,
an SPI number in network byte order, and
a protocol code).
<I>Satot</I>
does the reverse conversion, back to a text SA specifier.
<I>Initsaid</I>
initializes an
<B>ip_said</B>
from separate items of information.
<P>
An SA is specified in text with a mail-like syntax, e.g.
<B><A HREF="mailto:[email protected]">[email protected]</A></B>.
An SA specifier contains
a protocol prefix (currently
<B>ah</B>,
<B>esp</B>,
<B>tun</B>,
<B>comp</B>,
or
<B>int</B>),
a single character indicating the address family
(<B>.</B>
for IPv4,
<B>:</B>
for IPv6),
an unsigned integer SPI number in hexadecimal (with no
<B>0x</B>
prefix),
and an IP address.
The IP address can be any form accepted by
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3),
e.g. dotted-decimal IPv4 address,
colon-hex IPv6 address,
or DNS name.
<P>
As a special case, the SA specifier
<B>%passthrough4</B>
or
<B>%passthrough6</B>
signifies the special SA used to indicate that packets should be
passed through unaltered.
(At present, these are synonyms for
<B><A HREF="mailto:[email protected]">[email protected]</A></B>
and
<B>tun:0@::</B>
respectively,
but that is subject to change without notice.)
<B>%passthrough</B>
is a historical synonym for
<B>%passthrough4</B>.
These forms are known to both
<I>ttosa</I>
and
<I>satot</I>,
so the internal representation is never visible.
<P>
Similarly, the SA specifiers
<B>%pass</B>,
<B>%drop</B>,
<B>%reject</B>,
<B>%hold</B>,
<B>%trap</B>,
and
<B>%trapsubnet</B>
signify special ``magic'' SAs used to indicate that packets should be
passed, dropped, rejected (dropped with ICMP notification),
held,
and trapped (sent up to
<I><A HREF="ipsec_pluto.8.html">ipsec_pluto</A></I>(8),
with either of two forms of
<B>%hold</B>
automatically installed)
respectively.
These forms too are known to both routines,
so the internal representation of the magic SAs should never be visible.
<P>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file supplies the
<B>ip_said</B>
structure, as well as a data type
<B>ipsec_spi_t</B>
which is an unsigned 32-bit integer.
(There is no consistency between kernel and user on what such a type
is called, hence the header hides the differences.)
<P>
The protocol code uses the same numbers that IP does.
For user convenience, given the difficulty in acquiring the exact set of
protocol names used by the kernel,
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
defines the names
<B>SA_ESP</B>,
<B>SA_AH</B>,
<B>SA_IPIP</B>,
and
<B>SA_COMP</B>
to have the same values as the kernel names
<B>IPPROTO_ESP</B>,
<B>IPPROTO_AH</B>,
<B>IPPROTO_IPIP</B>,
and
<B>IPPROTO_COMP</B>.
<P>
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
also defines
<B>SA_INT</B>
to have the value
<B>61</B>
(reserved by IANA for ``any host internal protocol'')
and
<B>SPI_PASS</B>,
<B>SPI_DROP</B>,
<B>SPI_REJECT</B>,
<B>SPI_HOLD</B>,
and
<B>SPI_TRAP</B>
to have the values 256-260 (in <I>host</I> byte order) respectively.
These are used in constructing the magic SAs
(which always have address
<B>0.0.0.0</B>).
<P>
If
<I>satot</I>
encounters an unknown protocol code, e.g. 77,
it yields output using a prefix
showing the code numerically, e.g. ``unk77''.
This form is
<I>not</I>
recognized by
<I>ttosa</I>.
<P>
The
<I>srclen</I>
parameter of
<I>ttosa</I>
specifies the length of the string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>satot</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file defines a constant,
<B>SATOT_BUF</B>,
which is the size of a buffer just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>satot</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default
(currently
lowercase protocol prefix, lowercase hexadecimal SPI,
dotted-decimal or colon-hex address).
The value
<B>'f'</B>
is similar except that the SPI is padded with
<B>0</B>s
to a fixed 32-bit width, to ease aligning displayed tables.
<P>
<I>Ttosa</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Satot</I>
returns
<B>0</B>
for a failure, and otherwise
always returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<P>
There is also, temporarily, support for some obsolete
forms of SA specifier which lack the address-family indicator.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_ttoul.3.html">ipsec_ttoul</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3), <A HREF="ipsec_samesaid.3.html">ipsec_samesaid</A>(3), <A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>ttosa</I>
are:
empty input;
input too small to be a legal SA specifier;
no
<B>@</B>
in input;
unknown protocol prefix;
conversion error in
<I>ttoul</I>
or
<I>ttoaddr</I>.
<P>
Fatal errors in
<I>satot</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The restriction of text-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The text-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = ttosa( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_initsubnet.3.html
-238
View File
@@ -1,238 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_isanyaddr.3.html
-166
View File
@@ -1,166 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_isloopbackaddr.3.html
-166
View File
@@ -1,166 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_isunspecaddr.3.html
-166
View File
@@ -1,166 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_keyblobtoid.3.html
-174
View File
@@ -1,174 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_KEYBLOBTOID</TITLE>
</HEAD><BODY>
<H1>IPSEC_KEYBLOBTOID</H1>
Section: C Library Functions (3)<BR>Updated: 25 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec keyblobtoid, splitkeytoid - generate key IDs from RSA keys
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>size_t keyblobtoid(const unsigned char *blob,</B>
<BR>
&nbsp;
<B>size_t bloblen, char *dst, size_t dstlen);</B>
<BR>
<B>size_t splitkeytoid(const unsigned char *e, size_t elen,</B>
<BR>
&nbsp;
<B>const unsigned char *m, size_t mlen, char *dst,</B>
<BR>
&nbsp;
<B>size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Keyblobtoid</I>
and
<I>splitkeytoid</I>
generate
key IDs
from RSA keys,
for use in messages and reporting,
writing the result to
<I>dst</I>.
A
<I>key ID</I>
is a short ASCII string identifying a key;
currently it is just the first nine characters of the base64
encoding of the RFC 2537/3110 ``byte blob'' representation of the key.
(Beware that no finite key ID can be collision-proof:
there is always some small chance of two random keys having the
same ID.)
<P>
<I>Keyblobtoid</I>
generates a key ID from a key which is already in the form of an
RFC 2537/3110 binary key
<I>blob</I>
(encoded exponent length, exponent, modulus).
<P>
<I>Splitkeytoid</I>
generates a key ID from a key given in the form of a separate
(binary) exponent
<I>e</I>
and modulus
<I>m</I>.
<P>
The
<I>dstlen</I>
parameter of either
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines a constant
<B>KEYID_BUF</B>
which is the size of a buffer large enough for worst-case results.
<P>
Both functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
With keys generated by
<I><A HREF="ipsec_rsasigkey.3.html">ipsec_rsasigkey</A></I>(3),
the first two base64 digits are always the same,
and the third carries only about one bit of information.
It's worse with keys using longer fixed exponents,
e.g. the 24-bit exponent that's common in X.509 certificates.
However, being able to relate key IDs to the full
base64 text form of keys by eye is sufficiently useful that this
waste of space seems justifiable.
The choice of nine digits is a compromise between bulk and
probability of collision.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
RFC 3110,
<I>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</I>,
Eastlake, 2001
(superseding the older but better-known RFC 2537).
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors are:
key too short to supply enough bits to construct a complete key ID
(almost certainly indicating a garbage key);
exponent too long for its length to be representable.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>
doc/manpage.d/ipsec_klipsdebug.5.html
-229
View File
@@ -1,229 +0,0 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_KLIPSDEBUG</TITLE>
</HEAD><BODY>
<H1>IPSEC_KLIPSDEBUG</H1>
Section: File Formats (5)<BR>Updated: 26 Jun 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec_klipsdebug - list KLIPS (kernel IPSEC support) debug features and level
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>klipsdebug</B>
<P>
<B>cat</B>
<B>/proc/net/ipsec_klipsdebug</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>/proc/net/ipsec_klipsdebug</I>
lists flags that control various parts of the debugging output of Klips
(the kernel portion of FreeS/WAN IPSEC).
At this point it is a read-only file.
<P>
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
a KLIPS debug variable
<DT>+<DD>
a '=' separator for visual and automated parsing between the variable
name and its current value
<DT>+<DD>
hexadecimal bitmap of variable's flags.
</DL>
<P>
The variable names roughly describe the scope of the debugging variable.
Currently, no flags are documented or individually accessible yet except
tunnel-xmit.
<P>
The variable names are:
<DL COMPACT>
<DT><B>tunnel</B>
<DD>
tunnelling code
<DT><B>netlink</B>
<DD>
userspace communication code (obsolete)
<DT><B>xform</B>
<DD>
transform selection and manipulation code
<DT><B>eroute</B>
<DD>
eroute table manipulation code
<DT><B>spi</B>
<DD>
SA table manipulation code
<DT><B>radij</B>
<DD>
radij tree manipulation code
<DT><B>esp</B>
<DD>
encryptions transforms code
<DT><B>ah</B>
<DD>
authentication transforms code
<DT><B>rcv</B>
<DD>
receive code
<DT><B>ipcomp</B>
<DD>
ip compression transforms code
<DT><B>verbose</B>
<DD>
give even more information, beware this will probably trample the 4k kernel printk buffer giving inaccurate output
</DL>
<P>
All KLIPS debug output appears as
<B>kernel.info</B>
messages to
<I><A HREF="syslogd.8.html">syslogd</A></I>(8).
Most systems are set up
to log these messages to
<I>/var/log/messages</I>.
<P>
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<P>
<B>debug_tunnel=00000010.</B>
<BR>
<B>debug_netlink=00000000.</B>
<BR>
<B>debug_xform=00000000.</B>
<BR>
<B>debug_eroute=00000000.</B>
<BR>
<B>debug_spi=00000000.</B>
<BR>
<B>debug_radij=00000000.</B>
<BR>
<B>debug_esp=00000000.</B>
<BR>
<B>debug_ah=00000000.</B>
<BR>
<B>debug_rcv=00000000.</B>
<BR>
<B>debug_pfkey=ffffffff.</B>
<P>
means that one
<B>tunnel</B>
flag has been set (tunnel-xmit),
full
<B>pfkey</B>
sockets debugging has been set and everything else is not set.
<P>
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_klipsdebug, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_eroute.8.html">ipsec_eroute</A>(8),
<A HREF="ipsec_spi.8.html">ipsec_spi</A>(8), <A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5), <A HREF="ipsec_version.5.html">ipsec_version</A>(5),
<A HREF="ipsec_pf_key.5.html">ipsec_pf_key</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

Some files were not shown because too many files have changed in this diff Show More