Moby Dick Consolidated System Integration Plan

Moby Dick Consolidated System Integration Plan Moby Dick Consolidated System Integration Plan

kt.agh.edu.pl
from kt.agh.edu.pl More from this publisher
27.03.2014 Views

D0103v1.doc Version 1 6.7.2003 • IP_PA -> IPv6: SEND_DORMANT_MODE_REQUEST, parameters: _PAaddr (IP address of the paging agent), _HoA, _MAC address list (n * 3byte) or _L3-ID, _Paging area ID, _Sequence #, _reg. Lifetime, _NAI, _credentials • IPv6 -> IP_PA: PAGING_REQUEST, parameters: _RAN (random number), _SessKey (session key), _MAC address list , L3-ID (MTSolicitedNodeAddr????) • IP_PA -> IPv6: ON-LINK_PAGING_REQUEST, parameters: _MTSolicitedNodeAddrInterface between AAAC Attendant and IpSec 4.2.3.6 Interface between AAAC Attendant and IPSec 4.2.3.6.1 IPSec Functions SWAMP gets its IPSec functionality from two projects: the FreeS/WAN project (http://www.freeswan.org) implements IPSec for Ipv4 on the Linux platform. IABG has patched FreeS/WAN to provide Ipv6 support. Since the IPSec protocol , and its API, PFKEY has been extensively described in the relevant standards, this document focuses on the interface provided by liburp for the purposes of liburp. This interface is used by the AAA Attendant on the AR. The liburp library provides a simplified interface to the kernel IPSec interface. It allows programs to set up 'connections', described by a 'struct ipsec_conn'. A connection is an IPSec tunnel between a mobile node and an access router. It is assumed that all the traffic of a mobile node will be routed to a single access router, through a single connection. Each router, of course, may have multiple connections, one for each attached mobile node. Each connection contains a bundle of Security Associations (SA's). A program may set up a connection with only AH tunnel, only ESP tunnel, or both AH and ESP tunnel protection. Before one can use the IPSec functionality, one must call IPSecMgr::init(). Likewise, when done, the program should call IPSecMgr::exit(). This will destroy any IPSec connections that are still around. To set up a connection, a program creates and fills up a 'struct ipsec_conn' variable: truct ipsec_conn { bool is_mn; /* Is the node an MN? AR? */ in6_addr *local_addr6; uint32_t local_maskbits; in6_addr *remote_addr6; uint32_t remote_maskbits; uint8_t *ah_key; uint32_t ah_spi_in; uint32_t ah_spi_out; uint8_t *esp_key; uint32_t esp_spi_in; uint32_t esp_spi_out; /* tunnel SA SPI's */ uint32_t ipip_in_spi; uint32_t ipip_out_spi; }; On the mobile node, 'is_mn' is set to true, and on the access router, it is set to false. The 'local_addr6' and 'remote_addr6' members are self_explanatory. The '*_maskbits' is set to 128 for now. In future they may be used to protect network segments instead all traffic. 'ah_key' and 'esp_key' are the keys for AH and ESP protection, respectively. The liburp uses HMAC- MD5-96 algorithm for AH, and 3DES-CBC for ESP. Thus, they ah_key must always be 16 bytes in length, and the esp_key must always be 24 bytes in length (the canonical key lengths for these algorithms). The liburp does not attempt to pad or truncate the keys you supply, and improper lengths may be fatal. If neither AH nor ESP is used, then the corresponding key is set to 0 (NULL pointer). This is the only exception to the restriction on key length described above. The '*_spi_in' and '*_spi_out' members are the SPI's of incoming and outgoing SA's, respectively. They must be anti-symmetric on the mobile node and access router. That is, if the ah_spi_in on the mobile node is 101, then (for the same ipsec connection) the ah_spi_out on the access router must also be 101, and vice-versa. If you are not using AH, then you can leave the ah_spi_* members unset: they will not be used. However, you must always set the esp_spi_* members correctly. This restriction is imposed by the design of the FreeS/WAN IPSec implementation. The ipip_*_spi members must also be set, but they need not be anti-symmetric or even same on the mobile node and access router: they should just be unique within and between ipsec connections. D0103v1.doc 68 / 168

D0103v1.doc Version 1 6.7.2003 The above means that you will use up four SPI's for an ESP only connection (two for incoming and outgoing ESP SA's, two for incoming and outgoing IPIP SA's) and six SPI's for an AH or Ah+ESP connection (additionally two SPI's for incoming and outgoing AH SA's). Once you have set up the ipsec_conn structure properly, you can create a connection by calling IPSecMgr::add_conn(). Since liburp will make copies of any data it needs, you can reuse the same structure variable again and again (after changing the required members, of course). This also implies that you are responsible for managing the memory (keys, etc.) used by your variable. The IPsecMgr::add_conn() method returns a 'connection-id': a non-negative integer identifying the connection. This id can be used to call IPSecMgr::del_conn(), to destroy the connection. Note: calling IPSecMgr::exit() also destroys all connections which have not been released by calling IPSecMgr::del_conn(). 4.2.3.6.2 SPI Management Since one needs to have unique SPI's for each connection, and should then return them to the unused SPI 'pool' for later re -use after destroying a connection (lest you run out of SPI's), liburp provides a SPI management interface. You can ask for unique SPI's by calling PFKey::get_spi() as many times as required: it will ensure that you only get unique PI's, and will return 0 if no SPI is available. Once you have done with an SPI, free it by calling PFKey::free_spi(). PFKey will then re-use it if necessary. Note: IPSecMgr::del_conn() does not automatically free the SPI's used by a connection: you must still call PFKey::free_spi(). Note that the SPI management routines can only ensure that SPI's are unique within a single process. There is no mechanism to ensure SPI uniqueness system-wide. Thus, if there is another program using the PF_KEY (RFC 2367) interface to use SPI's, then conflict is likely. To be safe, liburp uses the SPI range 0x100 to 0xfff, which is reserved for manual keying. This will ensure that at least liburpallocated SPI's do not conflict with those used by some key-management daemon like FreeS/WAN's pluto. 4.2.3.6.3 Firewall control The Access Router has to implement a packet filter that would drop packets sent from unauthenticated mobile hosts. This is achieved via the pep6_kmod kernel filter. This is a kernel module provided with the library. You must compile and insert this mo dule into the kernel to use the packet filter functions of librup. This library provides a simple interface to the kernel filter rules through the class URPFWMgr. The philosophy of the kernel filter is to not allow Any packets to be forwarded, except those from or to addresses Specified in a “rule". Each rule is associated with an interface. The wildcard "any" interface is also allowed, to create global rules. Call URPFWMgr::init() to initialize the firewall manager. The kernel module must be loaded for this to success. Call URPFWMgr::allow6() to allow forwarding for a particular mobile node. 'in_dev' is the name of the network interface the rule should be associated with ("eth0", "wlan0", etc. for example). Using "any" as the interface name causes the rule to be associated with all interfaces. 'v6addr' is the source or destination address of the packets for which forwarding is enabled, and should be the care-of-address of the mobile node. URPFWMgr::forbid6() serves to disable the forwarding enabled by calling allow6(). It takes only a single argument, which is the address the rules should be revoked. All rules containing this address will be removed. All these functions return 0 if the operation was successful; otherwise they return an integer less than 0. 4.2.3.6.4 2.2.2.4 API Synopsis The API is summarized here. #include static void Logger::setDefaults(const char *ident, const bool tid = false, const int facility = DAEMON) static void Logger::setDebugState(bool state) static int IPSecMgr::init() static int IPSecMgr::add_conn(struct ipsec_conn *conn) static int IPSecMgr::del_conn(int connid) static int IPSecMgr::exit() D0103v1.doc 69 / 168

D0103v1.doc Version 1 6.7.2003<br />

The above means that you will use up four SPI's for an ESP only connection (two for incoming and<br />

outgoing ESP SA's, two for incoming and outgoing IPIP SA's) and six SPI's for an AH or Ah+ESP<br />

connection (additionally two SPI's for incoming and outgoing AH SA's).<br />

Once you have set up the ipsec_conn structure properly, you can create a connection by calling<br />

IPSecMgr::add_conn(). Since liburp will make copies of any data it needs, you can reuse the same<br />

structure variable again and again (after changing the required members, of course). This also implies that<br />

you are responsible for managing the memory (keys, etc.) used by your variable.<br />

The IPsecMgr::add_conn() method returns a 'connection-id': a non-negative integer identifying the<br />

connection. This id can be used to call IPSecMgr::del_conn(), to destroy the connection. Note: calling<br />

IPSecMgr::exit() also destroys all connections which have not been released by calling<br />

IPSecMgr::del_conn().<br />

4.2.3.6.2 SPI Management<br />

Since one needs to have unique SPI's for each connection, and should then return them to the unused SPI<br />

'pool' for later re -use after destroying a connection (lest you run out of SPI's), liburp provides a SPI<br />

management interface.<br />

You can ask for unique SPI's by calling PFKey::get_spi() as many times as required: it will ensure that<br />

you only get unique PI's, and will return 0 if no SPI is available.<br />

Once you have done with an SPI, free it by calling PFKey::free_spi(). PFKey will then re-use it if<br />

necessary.<br />

Note: IPSecMgr::del_conn() does not automatically free the SPI's used by a connection: you must still<br />

call PFKey::free_spi().<br />

Note that the SPI management routines can only ensure that SPI's are unique within a single process.<br />

There is no mechanism to ensure SPI uniqueness system-wide. Thus, if there is another program using the<br />

PF_KEY (RFC 2367) interface to use SPI's, then conflict is likely. To be safe, liburp uses the SPI range<br />

0x100 to 0xfff, which is reserved for manual keying. This will ensure that at least liburpallocated SPI's<br />

do not conflict with those used by some key-management daemon like FreeS/WAN's pluto.<br />

4.2.3.6.3 Firewall control<br />

The Access Router has to implement a packet filter that would drop packets sent from unauthenticated<br />

mobile hosts. This is achieved via the pep6_kmod kernel filter. This is a kernel module provided with the<br />

library. You must compile and insert this mo dule into the kernel to use the packet filter functions of<br />

librup. This library provides a simple interface to the kernel filter rules through the class<br />

URPFWMgr. The philosophy of the kernel filter is to not allow Any packets to be forwarded, except<br />

those from or to addresses Specified in a “rule". Each rule is associated with an interface. The wildcard<br />

"any" interface is also allowed, to create global rules.<br />

Call URPFWMgr::init() to initialize the firewall manager. The kernel module must be loaded for this to<br />

success.<br />

Call URPFWMgr::allow6() to allow forwarding for a particular mobile node. 'in_dev' is the name of the<br />

network interface the rule should be associated with ("eth0", "wlan0", etc. for example). Using "any" as<br />

the interface name causes the rule to be associated with all interfaces. 'v6addr' is the source or destination<br />

address of the packets for which forwarding is enabled, and should be the care-of-address of the mobile<br />

node.<br />

URPFWMgr::forbid6() serves to disable the forwarding enabled by calling allow6(). It takes only a single<br />

argument, which is the address the rules should be revoked. All rules containing this address will be<br />

removed.<br />

All these functions return 0 if the operation was successful; otherwise they return an integer less than 0.<br />

4.2.3.6.4 2.2.2.4 API Synopsis<br />

The API is summarized here.<br />

#include <br />

static void Logger::setDefaults(const char *ident,<br />

const bool tid = false, const int facility = DAEMON)<br />

static void Logger::setDebugState(bool state)<br />

static int IPSecMgr::init()<br />

static int IPSecMgr::add_conn(struct ipsec_conn *conn)<br />

static int IPSecMgr::del_conn(int connid)<br />

static int IPSecMgr::exit()<br />

D0103v1.doc 69 / 168

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!