Code design and explanations

Code design and explanations

This is currently an ad-hoc scribble place to jot down notes while encountering things, being confused, and getting it explained by a programmer. It will get updated slowly and strangely, but feel free to add to it

pluto daemon basic design

- event driven
- state machine based
- not really threaded
- helpers and continuations
- userland state vs kernel state

pluto core and internal state

Pluto has a concept of connections and states. A connection is what you define in a configuration file. There are a few types of connections, differentiated by c→kind
- CK_PERMANENT: static single connection which can be up or down
- CK_TEMPLATE: a connection that can have multiple instantiations. The template itself is never “up”
- CK_INSTANCE: An instance of a template

The reason for instantiating a template is that some part of the connection is variable, and you do not want to change the template itself. Examples include
- right=%any Roadwarriors who have different right= IP addresses
- rightprotoport=17/%any These connections can ask for any 1 port (usually depends on the NAT)
- rightsubnet=vnet:%priv These connections can happen when Openswan is a “cloud gateway” where connecting clients differ their RFC1918 space
- narrowing=yes (IKEv2) These connections can be dynamically narrowed on demand.

the core structs

- struct state
- struct connection
- struct end
- stf_status

debug

force pluto to handle crypto “inline” rather than in forked processes

- pluto --nhelpers 0
- do this by adding in [setup] section of /etc/ipsec.conf:

nhelpers=0

add a delay in crypto processing to help with debugging

- compile stage define: PLUTO_CRYPTO_HELPER_DEBUG

make pluto run in foreground (no daemon fork):

- pluto --nofork

pluto startup

- The init script is created from setup (programs/setup/setup.in)
- Some other scripts involved:
– _realsetup (called by setup; calls _plutorun)
– _plutorun (launches pluto and calls _plutoload)
– _plutoload (loads the init file by calling ipsec addconn which calls whack on each connection)

init file

- the init file is /etc/ipsec.conf
- it is NOT read on startup by pluto
- some of the above startup scripts run a program that reads it, and then send the config, piece by piece, to pluto via a command called whack.

IETF specifications and pluto defines

- include/ietf_constants.h and lib/libopenswan/constants.c
- include/pluto_constants.h
- programs/pluto/state.h

network packets

- marshalling code in in_struct/out_struct – should be the only place for host/network ordering
- include/packet.h

parsing and config file

- lib/libipsecconf/
- lib/libipsecsecrets/