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

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/