IPSec

IPSec

dn03551794Issue 3-0 en draft

# Nokia Corporation 1 (67)

201005Nokia FlexiServer, Release 4, ProductDocumentation

The product described in this document is still under development by Nokia Networks. However,in the interest of offering early possibility to our customers to evaluate the documentation, thisdocumentation is provided in draft form. Therefore the customer understands that theinformation in this document is subject to change without notice and describes only the prototypeproduct defined in the introduction of this documentation in its current state of development.Nokia Networks welcomes customer comments as part of the process of continuousdevelopment and improvement of its products and the documentation.

This document is not a final customer document and Nokia Networks does not takeresponsibility for any errors or omissions in this document. No part of it may be reproduced ortransmitted in any form or means without the prior written permission of Nokia Networks. Thedocument has been prepared to be used by professional and properly trained personnel, and thecustomer assumes full responsibility when using it.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia Networks and the customer.

Nokia Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDINGMONETARY LOSSES), that might arise from the use of this document or the information in it.UNDER NO CIRCUMSTANCES SHALL NOKIA BE RESPONSIBLE FOR ANY LOSS OF USE,DATA, OR INCOME, COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES,PROPERTY DAMAGE, PERSONAL INJURY OR ANY SPECIAL, INDIRECT, INCIDENTAL,PUNITIVE OR CONSEQUENTIAL DAMAGES HOWSOEVER CAUSED.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIREDBY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT,ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY OR CONTENTS OF THISDOCUMENT. NOKIA RESERVES THE RIGHT TO REVISE THIS DOCUMENT ORWITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.

This document and the product it describes are protected by copyright according to theapplicable laws.

NOKIA and Nokia Connecting People are registered trademarks of Nokia Corporation. Otherproduct names mentioned in this document may be trademarks of their respective companies,and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2005. All rights reserved. Reproduction, transfer, distribution orstorage of part or all of the contents in this document in any form without the prior writtenpermission of Nokia is prohibited.

© 1995 - 2004 SAFENET, Inc. This software is protected by international copyright laws. Allrights reserved. SafeNet® is a registered trademark of SAFENET, Inc., in the United States andin certain other jurisdictions. SAFENET and the SAFENET logo are trademarks of SAFENET,Inc., and may be registered in certain jurisdictions. All other names and marks are property oftheir respective owners.

2 (67) # Nokia Corporation dn03551794Issue 3-0 en draft

IPSec

Contents

Contents 3

1 Changes in IPSec 51.1 Changes between the Nokia FlexiServer Platform releases 3.0 and 4.1 51.1.1 Changes in IPSec 51.1.2 Changes in the IPSec documentation 51.2 Changes between the Nokia FlexiServer Platform increment 2.1 and

release 3.0 61.2.1 Changes in IPSec 61.2.2 Changes in the IPSec documentation 61.3 Changes between increments 2.0 and 2.1 71.3.1 Changes in IPSec 71.3.2 Changes in documentation 7

2 IPSec 9

3 IP addresses and interfaces for IPSec 13

4 IPSec policy 174.1 IPSec policy 174.2 Basic IPSec configuration 204.3 IP traffic filtering rules 224.4 IKE keyed tunnels 274.5 Manually keyed tunnels 314.6 Global configuration parameters for IPSec 344.7 Advanced configuration options for IPSec 364.7.1 External entities 384.7.2 Built-in entities 384.7.3 Input encodings 404.7.4 Changing DTD default values 404.8 Intrusion events 41

5 Reserving memory for IPSec 49

6 Enabling IPSec service 51

7 Checking IPSec service 57

8 Configuring intrusion event monitoring 61

9 Monitoring intrusion events 63

10 IPSec is not working properly 65



Contents


IPSec

1 Changes in IPSec

The information contained in this section is for internal use only. Do not reusethis module in application-specific library configurations. Use only relevantinformation to your own change module(s)

1.1 Changes between the Nokia FlexiServer Platformreleases 3.0 and 4.1

The new version of IPSec QuickSec Toolkit, 3.0, is provided by SafeNet Inc.

1.1.1 Changes in IPSec

The basic architecture of the QuickSec Toolkit 3.0 is similar to the QuickSecToolkit 2.1 used in FS3. The improvements are:

. DNS name selectors.

QuickSec Toolkit now includes a DNS resolver library and the capabilityto use DNS names in the policy file. This allows easy connecting togateways that have a dynamic IP address but a static DNS name.

. Support for AES-XCBC MAC.

QuickSec Toolkit now supports the AES-XCBC MAC (RFC 3566) that isrecommended as a more secure MAC and recommended in Storage AreaNetworking protocols. SafeNet QuickSec Toolkit includes a softwareimplementation of the algorithm, as well as IKE negotiation for it.

© Safenet Inc. SafeNet QuickSec Toolkit version 3.0, Handbook

1.1.2 Changes in the IPSec documentation



Changes in IPSec

Changes between issues 3 and 2

IP traffic filtering rules

New elements flags, dns-src, dns-dst, and routed-ifname have been added.

IKE keyed tunnels

New attribute xcbc-aes has been added for the element transform.

The group IDs have been added to the description of the element ike-groups.

The attribute none has been removed from the description of the element pfs-groups.

Global configuration parameters for IPSec

New elements drop-if-cannot-audit and routing have been added.

1.2 Changes between the Nokia FlexiServer Platformincrement 2.1 and release 3.0


The IPSec toolkit supports intrusion events. Intrusion events are a subset of auditevents that are written to the system log. By analysing them the user can detectattempts of breaking into the system as well as improper, unauthorised, andabnormal system and network activities.

The SA capacity allocation mechanism has been improved. The system nowsupports millions of SAs.

1.2.2 Changes in the IPSec documentation

Issue 2 of the PDF is used in FS3.

Information on the active/standby model has been added to IPSec.

The documentation has been improved by adding new tunnel attributes to IKEkeyed tunnels.

Information on intrusion events has been added to Intrusion events, Configuringintrusion event monitoring, and Viewing intrusion events.


IPSec

1.3 Changes between increments 2.0 and 2.1

The main change in this area is that IPSec Toolkit version has changed.


The new version of IPSec Toolkit, 2.1, is provided by SafeNet Inc.

1.3.2 Changes in documentation

This is the first edition of this document. The contents of this document havebeen moved here from the Basic IP Services document.

Troubleshooting instructions have been added, see IPSec is not working properly.A new figure has been added to clarify the IPSec usage, see IP addresses andinterfaces for IPSec.



Changes in IPSec


IPSec

2 IPSec

IPSec provides a transparent, secure communication mechanism to use overshared or public networks. IPSec was defined within the Internet EngineeringTask Force (IETF) to provide a set of open standards security services for theInternet Protocol (IP). IPSec provides integrity and authenticity checking, whichdetects changes that might have occurred to packets during transmission. It alsoprovides privacy to ensure that secure communication can occur even onunsecured networks. In addition, IPSec provides replay protection, which ensuresthat a valid data packet is not captured and resent to an unauthorised device.

IPSec is interoperable and adaptable. Various devices running different operatingsystems and residing on different types of networks can communicate securelyusing IPSec. Any IPSec-compliant network device can communicate securelywith any other IPSec device. Also, as new techniques for encryption andauthentication emerge, the IPSec standard can be expanded to include newdevelopments with no impact to existing implementations.

The main IPSec protocol used is encapsulated security protocol (ESP). ESPprovides authentication mechanisms and includes strong encryption features toensure message integrity and confidentiality.

Although IPSec ESP can be implemented in a number of ways, it is commonlyused for establishing an encrypted tunnel between IPSec gateways.

IPSec combines a number of pre-existing protocols into a coherent framework forestablishing secure communication over TCP/IP networks. The main aspects ofIPSec are:

. Security Associations

IPSec authentication and access control is based on security associations(SA), which are negotiated between the two endpoints on an IPSec tunnel.An SA describes the various encryption and authentication parameters thatboth endpoints agree to use. SAs are stored in an SA database maintainedby each gateway and are referenced by a unique security parameter index(SPI). You can assign an SA a lifetime so that it expires after a given periodof time. This lifetime limits the time a potential attacker has to eavesdropor otherwise compromise the security of the connection.



IPSec

. Selectors

To create an SA, the proper selector must be defined on both endpoints.Selectors are essentially access list entries, which map IP packets to IPSecpolicy. Selectors identify source and destination IP addresses as well as IPprotocols. They can also include port numbers when this degree ofgranularity is necessary. When a selector matches a packet, it can apply oneof three processing mechanisms to a packet flow:

- drop

- bypass (pass without protection)

- apply security (protect using IPSec).

. Security Association Database

The SA database contains all the SAs that a device has negotiated. AnIPSec device examines the SA database every time there is an inbound oroutbound IP packet. This database contains authentication and encryptionparameters for each SA, including the SA lifetime, sequence numbers foranti-replay protection, the IPSec protocol mode (tunnel or transport), andthe path maximum transmission unit (MTU).

. Security Policy Database

The Security Policy Database stores the selectors and the action to be taken(drop, bypass, or apply security) if the packet matches. If the action takenis to apply security, the details will be retrieved from the SA database.

. Internet Key Exchange

The Internet Key Exchange (IKE) is a standardised protocol for negotiatingsecure communications between IPSec peers and automatically creatingSAs. IKE negotiation is performed in two phases, or modes:

- Phase 1 or main mode establishes an IKE SA.

- Phase 2 or quick mode uses an existing IKE SA to establish anIPSec SA for the actual exchange of encrypted data.

IPSec operates in one of two modes:

. Transport mode, which places the IPSec header after the original outer IPheader and before the upper layer protocol.

Only the sender of the original datagram can perform transport mode, andthe destination address must handle detunnelling itself. This means thatIPSec protection needs to occur on the device building the IP packets.

. Tunnel mode, which encapsulates the entire IP header and datagram,prepends an IPSec header, and then creates an outer IP header to tunnel thepacket.


IPSec

Either the sender of the original datagram or another device within thenetwork can implement tunnel mode. Thus, tunnel mode is required whena gateway protects traffic between a node (positioned behind the gateway)and hosts over the Internet or other shared network.

Functional blocks of IPSec

IPSec functionality contains the following functional blocks:

. IPSec Policy Manager

. IPSec Engine

IPSec Policy Manager is the user space application responsible for keymanagement, policy management, and general management duties. IPSec Engineis a kernel loadable module (KLM) responsible for the actual IPsec protection.

IPSec supports the active/standby model, which means that IPSec runs in an IPDpair. If the active IPD node fails, the standby node takes over its duties, that is,SAs are transferred to the standby node.

Supported IPSec features

This network element (NE) supports the following features in IPSec:

. AES, 3DES, and DES encryption algorithms

. SHA-1 and MD5 hashes (for IKE and hashed message authentication code,HMAC)

. RSA public key algorithms

. Diffie-Hellman key exchange algorithm

. ESP transform

. transport mode and tunnel mode

. manual keying support.

IPSec also supports the following features for IKE:

. full IKE support

. RSA public key algorithms (IKE signature modes only)

. perfect forward secrecy (PFS) option

. main mode

. shared secret authentication.



IPSec


IPSec

3 IP addresses and interfaces for IPSecIP addresses

Three IP address types are used in the IPSec context: virtual, redundant, andperimeter IP address (formerly known as the IPD IP address). For moreinformation on IP addressing, see IP addresses.

Tunnel mode

The IPSec tunnel mode is always negotiated via the Internet key exchange (IKE).IKE uses the perimeter IP address for the negotiation.

The resulting IPSec security association (SA) contains two pairs of addresses:

. tunnel source and tunnel destination addresses (outer header)

. source and destination addresses (inner header)

The inner header is a dedicated or virtual IP address. The outer header is alwaysthe perimeter IP address. The following table lists the supported IP addresscombinations and their use with IPSec tunnel mode:



IP addresses and interfaces for IPSec

Table 1. IP address combinations (IPSec tunnel mode)

Tunnel mode header Usage

Outer header Inner header

Perimeter IP Address Virtual IP address Connections between net-work elements when SessionInitiation Protocol (SIP) isused.

Perimeter IP Address Dedicated IP address Connections between net-work elements when SIP isnot used.

Transport mode

The IP multimedia subsystem – authentication and key agreement (IMS-AKA) isused for negotiating IPSec connections between the user equipment (UE) and theSIP proxy. The IMS-AKA negotiates the IPSec transport mode securityassociation to protect the first hop SIP traffic. The IMS-AKA negotiates SAparameters and generates session keys.

The resulting IPSec SA has one pair of addresses: the source and destinationaddress. The address of the system is the virtual IP address. The address of theother end of the SA is the network element’s (NE) IP address. The following tablelists the supported IP address combinations and their use with IPSec transportmode:

Table 2. IP address combinations (IPSec transport mode)

Transport mode header Usage

Virtual IP address IMS access

Dedicated IP address Not in use

Optionally, IKE can be used for IPSec transport SA negotiations. IKE uses thevirtual or dedicated IP address for the negotiation. The resulting IPSec SA hasone pair of addresses: the source and destination addresses. The address of thesystem is the virtual or dedicated IP address. The address of the other end of theSA is the NE’s IP address.


IPSec

Interfaces

IPSec is only applied on the IP Director's (IPD) external interface.

IPSec transport mode is used between the NE and UE. IPSec tunnel mode is usedbetween the NE and another element. The following figure shows the differencein the IPSec usage:

Figure 1. IPSec usage between the NE and UE, and between two NEs

Cluster

Servernode

Servernode

Servernode

UE NE

IPD node

IKE

IPSec transport mode

IMS-AKA

IPSec tunnel mode



IP addresses and interfaces for IPSec


IPSec

4 IPSec policy

4.1 IPSec policy

IPSec policy basically dictates which packets should be IPSec-protected, whichpackets should be dropped, and which packets should be allowed to pass in-the-clear.

The system has a set of rules. Each rule matches certain packets and specifieswhat to do with them. The rules are prioritised by their precedence values. This isapproximately equivalent to sorting all rules by precedence, then going throughthe list in descending order by precedence value, and selecting the first rule thatmatches the packet. Only one rule (the first one that matches) is applied to apacket. If two matching rules have the same precedence, one of them is chosen atrandom. The system never applies two rules to the same packet.

Policy rules are stateful, which means that if the rule allows access to a service,then it also allows return packets from that service.

A policy rule is basically a quintuplet <from-domain, from-tunnel, service, to-tunnel, to-domain>, where

from-domain determines where the packets must be coming from (bynetwork interface, IP address, and so on)

from-tunnel specifies whether packets must arrive directly at the interfaceor from a VPN tunnel (and what kind of tunnel)

service determines the IP protocol and port numbers (or, for example,the ICMP type and code) that the rule applies to, and mayspecify special processing (such as passing it through anapplication proxy).

to-tunnel specifies what needs to be done for the packets to make themreach the to-domain (for example, if they need to be tunnelledusing IPSec, where they should be tunnelled to, and whatkind of parameters are to be used to establish the tunnel)

to-domain specifies where the packets must be going to (by networkinterface, IP address, and so on).



IPSec policy

Tunnels

The tunnel specifies how packets targeted to the remote domain should beencapsulated and what kind of IPSec protection should be provided for the traffic.The tunnel also specifies how access is to be authenticated.

IPSec tunnels are configured using tunnel objects, that is, XML elements. Tunnelobjects are used in rules to

. limit the application of the rule to those packets arriving from a specifictunnel.

. specify that packets matching the rule must be tunnelled to the givenremote sight.

A tunnel object contains the following information:

. IKE authentication parameters, such as trusted root certificates or sharedsecrets, and other optional IKE-specific parameters

. manual keying information (if manual keying is used)

. security parameters (encryption algorithms, MAC algorithms, andcompression algorithms) that are acceptable

. remote tunnel destination (if tunnel mode is used)

. whether IPSec security associations (SA) are created on demand (when thefirst packet arrives) or when the system is started

. granularity of security associations that will be used.

Tunnels are designed to require minimal configuration, and in particular tominimise the amount of knowledge that the management system user needs tohave in order to configure tunnels. As many things as possible are made fullyautomatic.

Some tunnels can be used both for initiating IPSec SAs and for responding tonegotiations initiated by another person. Other tunnels are only used forresponding to negotiations initiated elsewhere (such tunnels are typically used inremote access scenarios). When initiating, tunnels specify what securityparameters will be proposed to the remote site and which authenticationmechanisms are to be tried. When responding, tunnels determine which securityparameters and authentication methods are acceptable.


IPSec

Shared secret authentication

The simplest way to authenticate tunnels is to use shared secrets. A shared secretmeans that the same secret value (similar to a password) is configured at bothends of the tunnel, and encrypted communication is allowed if the secrets are thesame. The system does not, of course, send the secrets over the network. Instead,sophisticated cryptographic techniques are used to verify whether the other sideknows the secret without actually revealing the secret to the other side or to anyoutside observer.


Default IPSec policy

The following listing is an example IPSec firewall policy. The example policyrules accept all outgoing traffic and incoming SSH connections as well as allICMP(6) messages. All other traffic is quietly dropped.

Example Example IPSec policy

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE quicksec PUBLIC "quicksec:dtd" "quicksec.dtd">

<quicksec>

<policy>



<service name="icmp" protocol="icmp"/>

<rule service="icmp"/>



<service name="icmp6" protocol="ipv6icmp"/>

<rule service="icmp6">

<src>::</src>

</rule>



<service name="ssh" protocol="tcp" dstport="22"/>

<rule service="ssh"/>



<rule service="ssh">

<src>::</src>

</rule>



<rule>

<local-stack direction="from"/>

</rule>

<rule>

<src>::</src>


</rule>



IPSec policy



<rule type="drop" flags="no-flow"/>

<rule type="drop" flags="no-flow">

<src>::</src>

</rule>

</policy>

</quicksec>

The actual default policy that is used is much longer than the example policy. Thecomplete default policy accepts all outgoing traffic, and all incoming (IPv4 andIPv6) ICMP, SSH, DNS, NTP, HTTP, HTTPS, LDAP, LDAPS and FTP traffic, aswell as traffic from numerous FlexiServer specific services.

The default policy is stored in the /opt/Nokia/etc/IPSec/ipsec-policy.xml file inthe IPD nodes. Please refer to the file for a complete listing of the policy. Formodification instructions, see Enabling IPSec service.

4.2 Basic IPSec configuration

The configuration files for the IPSec policy manager are in the XML format. Youdo not have to know the XML format to configure IPSec policies. See thefollowing sections for descriptions of all the aspects of the policy configurationand example policies that can be used with the ipm program:

. Global configuration parameters for IPSec

. IP traffic filtering rules

. IKE keyed tunnels

. Manually keyed tunnels

. Advanced configuration options for IPSec

The following configuration file shows a fully functional IPSec policy for host-to-host setup. It also shows some parts of the XML policy that are mandatory inall configuration files.

Example IPSec policy for host-to-host setup



<quicksec>

<policy>



<tunnel name="hostb">

<psk>Hello, world!</psk>

</tunnel>


IPSec

<rule to-tunnel="hostb">

<src>10.1.48.7</src>

<dst>10.1.48.8</dst>

</rule>

<rule from-tunnel="hostb">

<src>10.1.48.8</src>

<dst>10.1.48.7</dst>

</rule>


<src>fec0:0:0:20::1</src>

<dst>fec0:0:0:20::2</dst>

</rule>


<src>fec0:0:0:20::2</src>

<dst>fec0:0:0:20::1</dst>

</rule>



<rule/>



<rule>

<src>::</src>

</rule>

</policy>

</quicksec>

The first line declares that the file is actually an XML file conforming to theversion 1.0 of the XML standard. The encoding attribute declares the encodingused in the file. The default encoding for XML is UTF-8. With theencoding="ISO-8859-1" attribute you notify the XML parser that this fileuses the ISO-8859-1 encoding and you do not have to encode characters biggerthan the decimal code 127 in any special way. To select different encoding values,see Input encodings.

The second line describes the document type used in the policy configuration.IPSec policies are described in the quicksec.dtd file. Do not change this linein any way.

The actual policy comes after the two line prologue. It is enclosed in thequicksec element. It starts from the <quicksec> element start tag and endsat the </quicksec> end tag. The policy is constructed from elements(policy, tunnel, rule, and so on) and character data (Hello, world!).

The XML files can also have comments. The comments start from the  tag. Everything in between these tags is comment text and isignored.



IPSec policy

Note

The only exception to this is the two character sequence -- which must notappear in the comment.

The DTD file is located in /etc/opt/Nokia/IPSec.

Root element

IPSec policy elements are enclosed within the quicksec root element. It is themandatory top-level element in the policy files. The quicksec element cancontain an optional params element and one or more policy elements. Theparams element describes global parameters for the system. See Globalconfiguration parameters for a description of the configurable parameters.Normally your policy contains only one policy element that contains yourIPSec rules.


4.3 IP traffic filtering rules

The rule elements are the basic building blocks in defining packet filtering andIPSec rules. The following attributes are accepted:

. precedence

The precedence of the rule. This is an optional attribute for specifying therule precedence. Normally, the rule precedence is computed automaticallyto be one unit smaller than the precedence of the previous rule in theconfiguration. The precedence value must be in the range from 99999999to 0 inclusively.

. type

The type of the rule. Possible values are:

- pass: Pass packets through. This is the default value for the ruletype. See Advanced configuration options for IPSec for details onhow to change the default value.

- reject: Drop packets and send an ICMP Admin Prohibit or TCPRST back to the sender of the packet.

- drop: Drop packet silently.

. from-tunnel


IPSec

The rule applies to those packets that are decapsulated from this tunnel.

. to-tunnel

The name of the tunnel where the packets are passed.

. service

The name of the service object that is applied for the rule.

. log

How to audit actions occurring on the rule. One possible value for theattribute is:

- connections: Create an audit event of all connectionestablishments and terminations.

. flags

Specifies additional flags for the rule. Possible flags are the following:

- no-flow: Process packets without creating flows for individualsessions. When SSH_IPSEC_EXECUTE_PROTOCOL_MONITORSis defined, if the no-flow flag is set for the forward direction of arule, then it must also be set for a corresponding rule in the reversedirection. Otherwise the protocol monitor will terminate any TCPsessions which originate in the forward direction of the rule forwhich the no-flow flag is set, but is not set for the correspondingreverse rule.

- authentication-only: The rule can only be used for IKE SAnegotiations.

The rule element can be further constrained with a service object. Serviceobjects can be used to select different IP protocols and port numbers. Theservice element takes the following attributes:

. name

The name of the service object. This must be set and it must be unique inthe configuration.

. protocol

An optional IP protocol identifier. This can be specified as a symbolicname or as an integer number. If the IP protocol selector is not set, theservice will match all IP protocols.

. dstport

A destination port number or port number range. The value of the attributecan be specified in the following formats:

- highports: matches the high (higher than 1023) port numbers.

- allports: matches all port numbers.



IPSec policy

- port: a port number.

- start-end: port number range from start to end.

. srcport

A source port number or port number range. The value of the attribute canbe specified in the same formats as the value of the dstport attribute.

The service element accepts the following optional child element:

. icmp

Specifies a selector for Internet control message protocol (ICMP) traffic.The icmp element accepts the following attributes:

- type: the ICMP type.

- code: the ICMP type dependent code.

The following example shows how to pass secure shell (SSH) traffic in plain-textand how to reject Telnet traffic.

Example IPSec policy for passing SSH and rejecting Telnet traffic



<quicksec>

<policy>



<service name="secsh" protocol="tcp" dstport="22"/>



<service name="telnet" protocol="tcp" dstport="23"/>



<rule service="secsh"/>



<rule service="telnet" type="reject"/>

</policy>

</quicksec>

In the previous example, the rule elements did not have any child elements.They only referred to the service objects with the service attribute. If an XMLelement is empty, you can omit its end tag by terminating the start tag with the / >markup. So these two rules are identical:

<rule/>

<rule></rule>


IPSec

The rule objects do not have to be empty. You can specify child elements forsetting additional selectors for the rules. The following child elements are allowedfor rules:

. src

Specifies the source IP selector. The value of the element is an IP address,IP address range, or an IP subnet specification given in one of thefollowing formats:

- ipaddr: a single IPv4 or IPv6 address.

- start-end: an IPv4 or IPv6 address range containing IPaddresses from start to end.

- network/maskbits: an IPv4 or IPv6 subnet network with thenetmask of maskbits.

. dns-src

Specifies a single source address as DNS name. Using DNS namesrequires presence of parameter block entry dns.

. dst

Specifies the destination IP selector. The value of the element is the sameas for the src element.

. dns-dst

Specifies a single destination address as DNS name. Using DNS namesrequires presence of parameter block entry dns.

. ifname

Specifies the interface selector. The value of the element is an interfacename as reported by ipm -i or with the ifconfig command.

. routed-ifname

Specifies interface selector based on the DNS name of the peer. The firstname is resolved, then routed, and the interface name is retrieved from therouting result.

. local-stack

Specifies the a local stack selector, requiring that the packets must comefrom the local stack or they are going to the local stack.

The element takes the attribute direction, which specifies the directionof the packets. The possible values for the attribute are:

- from: requires that the packets are coming from the local stack.

- to: requires that the packets are going to the local stack.

. extension



IPSec policy

Specifies the extension selectors. The element takes the followingattributes:

- id: the number of the extension selector to be set.

- low: the minimum value of the extension selector.

- high: the maximum value of the extension selector.

Note

If any of the above selectors are specified for a rule, they must be given in thisorder. If no IP address selectors are set for a rule, the rule IP protocol type defaultsto IPv4. If you want to create a catch-all rule for IPv6 traffic, you must set the IPprotocol to IPv6, for example, with the IPv6 any address:



<rule>

<src>::</src>

</rule>

The following example has all selector types set for a rule:

Example IPSec rule with selectors



<quicksec>

<policy>





<rule>

<src>10.1.48.7</src>

<dst>10.1.48.8</dst>

<ifname>fxp0</ifname>


<extension id="0" low="42" high="42"/>

</rule>

</policy>

</quicksec>



IPSec

4.4 IKE keyed tunnels

IPSec processing is specified by referencing tunnel elements from rules withthe from-tunnel and to-tunnel attributes. The tunnel elements take thefollowing attributes:

. name

Specifies the name of the tunnel. This must be set and it must be unique inthe configuration.

. ike-life

Specifies the lifetime of the IKE security association (SA) in seconds. Thisis an optional attribute. If the IKE lifetime is not set, the system will use thedefault lifetime (8 hours). Note that it is not possible to configure kilobytelifetimes for IKE SAs.

. transform

Specifies the properties of the IPSec SAs. The value of the attribute is acombination of the following:

- cipher1: allow the first extension cipher algorithm to be used. Asa default, no ciphers are bound to the extension ciphers.

- cipher2: allow the second extension cipher algorithm to be used.As a default, no ciphers are bound to the extension ciphers.

- null: allow null-encryption in ESP. Note that if you do not specifyany encryption algorithms in the transform attribute, the IKEencryption algorithm will be taken from the ike-defaultselements or, if that is not set, from its default value.

- des: allow DES encryption information.

- 3des: allow 3DES encryption algorithm.

- aes: allow AES encryption algorithm.

- aes-ctr: allow AES counter mode encryption algorithm.

- md5: allow MD5 to be used as HMAC and HASH algorithm.

- sha1: allow SHA-1 to be used as HMAC and HASH algorithm.

- xcbc-aes: Allow XCBC-AES to be used as an authenticationalgorithm.

- esp: negotiate ESP transform for IPSec.

The default value for the transform attribute is esp aes 3des sha1md5. See Advanced configuration options for IPSec for details on how tochange the default value.

. flags

Specifies additional flags for the tunnel object. The value of the attribute isa combination of the following:



IPSec policy

- perhost: set the SA granularity to per-host.

- perport: set the SA granularity to per-port.

- pfs-identity: do only one quick mode negotiation per eachIKE SA. Note that if this option is enabled, the host will not senddelete notifications for its IKE peer.

- dont-initiate: never initiate IKE negotiation.

- auto: initiate IKE negotiation when the rule is added. If not set, theIKE negotiation is initiated on the first packet using the rule. If theauto-start option is enabled, you cannot use the perport orperhost SA granularity flags, nor port range selectors.

- aggressive-mode: use aggressive mode in the pre-shared keyIKE SA negotiations. Otherwise the IKE main mode will be used.This affects only the initiator.

- xauth-auth-methods: use special XAUTH IKE authenticationmethods in the IKE SA proposal. The XAUTH IKE authenticationmethods notify the responder that the initiator wants to beauthenticated with XAUTH. This must be configured to interoperatewith some XAUTH gateways.

- allow-cfgmode: allow incoming IKE CFGMODE negotiationfor retrieving remote access client attributes.

- dont-init-cfgmode: do not initiate IKE CFGMODE to sendremote access client attributes. If the option is set, the client muststart IKE CFGMODE negotiation.

- allow-l2tp: allow incoming L2TP sessions.

- proxy-arp: perform proxy ARP for IP addresses sent to remoteaccess clients. Note that this works only on media level interceptors(NetBSD/Ethernet, VxWorks).

- tunnel: force tunnel mode.

- transport: force transport mode.

- disable-anti-replay: disable anti-replay services from theIPSec SAs. Normally the anti-replay services are enabled on IKE-negotiated IPSec SAs. The anti-replay services are always disabledon manually keyed SAs.

- long-seq: enable use of 64-bit sequence numbers on this tunnel.

- no-cert-chains: do not send complete certificate chain in IKEnegotiation.

- enable-outbound-sa-selectors: if a negotiation isperformed in the reverse direction based on a from-tunnel,create an outbound rule based on the used IPSec proposal. Normally,this is not done if a suitable to-tunnel rule does not exist.

- dpd: enable use of dead peer detection (DPD) on this tunnel.

For IKE keyed tunnels, the tunnel elements take the following child elements.At least one of these elements must be specified.


IPSec

. local-ip

Specifies the local IP address to use in the negotiation. Normally, you donot have to specify the local IP address. The policy manager willautomatically select an appropriate local IP address to be used with theremote IKE peer by consulting the system routing tables.

. peer

Specifies the remote IKE peer. This must be configured for tunnel-modenegotiations when the IPSec SA proxy IDs differ from the IKE end points.The content of the element is the peer IP address.

. ike-groups

Specifies the allowed Diffie-Hellman groups. The content of the element isa list of Diffie-Hellman group IDs.

- 1: Group 1 (768 bits)

- 2: Group 2 (1024 bits)

- 5: Group 5 (1536 bits)

- 14: Group 14 (2048 bits)

- 15: Group 15 (3072 bits)

- 16: Group 16 (4096 bits)

- 17: Group 17 (6144 bits)

- 18: Group 18 (8192 bits)

. pfs-groups

Specifies the Perfect Forward Secrecy (PFS) level for the tunnel. Theelement accepts the attribute level (the PFS level) and the value must beone of the following PFS levels:

- request: request PFS but do not fail the negotiation if the remotepeer does not select PFS. This is the default PFS level. SeeChanging DTD default values for how to change the default value.

- require: request PFS and require remote peer to perform it.

If the PFS is requested, it will be done with the same Diffie-Hellman groupas the IKE SA.

. access-group

Name of the access group allowed to use the tunnel. If the access-group element is specified, you must also declare the access groups withthe group element in the params block.

. life

Specifies the IPSec SA lifetime. The content of the element is a numberdescribing the lifetime. The element accepts the attribute type, which isthe type of the lifetime specification. The following types are supported:



IPSec policy

- kbytes: SA lifetime in the kilobytes. This is the default value. Forfurther information on how to change the default value, seeAdvanced configuration options for IPSec.

- seconds: SA lifetime in seconds.

Note

The SA lifetime is not exactly the value given by the user, because the IPSecimplementation adds small variation to the value to avoid too many simultaneouslifetime expirations.

. psk

A pre-shared key to used with the IKE negotiation. The content of theelement is the pre-shared key. The element takes the following attributes:

- name: the name of a named pre-shared key object. If the nameattribute is specified, the pre-shared key must be specified in aparams block.

- ref: the name of a named pre-shared key object. In this case, thepsk element must be empty and the pre-shared key is taken fromthe name psk element, declared in a params block.

- id-type: The type of the IKE ID to be used with the key. Possiblevalues for the ID type are:

dn a distinguished name

ip an IP address

fqdn a fully-qualified domain name

email an e-mail address (RFC 822 name)

key-id A key ID. The key IDs are arbitrary binarystrings.

- id: the ID data.

- encoding: the encoding of the pre-shared key. The followingencodings are supported:

binary The pre-shared key is given in binary format.This is the default value for the attribute.

hex The pre-shared key is given as a hexadecimalstring.

- ike-algorithms


IPSec

Specifies algorithms for IKE SAs. As a default, the algorithms aretaken from the transform attribute and from the global IKE defaultalgorithms. With this element you can explicitly specify thealgorithms that will be used for IKE SAs.

The following example shows how to configure a IKE keyed tunnel that allowspre-shared keys:

Example IKE keyed tunnel that allows pre-share keys



<quicksec>

<policy>

<tunnel name="secure-tunnel">

<psk id-type="email" id="[email protected]">Hello, world!</psk>

</tunnel>



<rule from-tunnel="secure-tunnel"/>


<rule/>


<rule>

<src>::</src>

</rule>

</policy>

</quicksec>

The example policy has only one rule applying the tunnel secure-tunnel.The rule applies the tunnel in from-tunnel direction, meaning that this hostwill not initiate any negotiations. However, it accepts incoming sessions from thetunnel assuming that the remote IKE peer can establish an IKE SAwith this host.


4.5 Manually keyed tunnels

For manually keyed tunnels the key materials and SPI values must be specifiedwhen you are creating the tunnel object. When the tunnel object is created, youcan used it like any other tunnel object. You can refer to it from the ruleelements with the from-tunnel and to-tunnel attributes. For manuallykeyed SAs, the tunnel element takes the following attributes:



IPSec policy

. name

The name of the tunnel. This must be set and it must be unique in theconfiguration.

. transform

The transforms and algorithms for the tunnel. You must only specify onecipher, HMAC, and compression algorithm for the tunnel.

. flags

Additional flags for the tunnel object. The following flags are meaningfulwith the manually keyed tunnels:

- tunnel: force tunnel mode.

- transport: force transport mode.

For manually keyed tunnels, the tunnel element accepts the following childelements in the given order. The manual-key element in mandatory.

. local-ip

Specifies the local IP address to use in the negotiation. Normally you donot have to specify the local IP address. The policy manager willautomatically select an appropriate local IP address to be used with theremote peer by consulting the system routing tables.

. peer

Specifies the remote peer. This must be configured for tunnel-modenegotiations when the IPSec SA proxy IDs differ from the IPSec endpoints. The content of the element is the peer IP address.

. manual-key

Specifies the manual key parameters for the IPSec SA pair. The elementaccepts the following child elements. You must specify one child elementfor each IPSec protocol configured for the tunnel with the transformattribute.

- esp: parameters for the ESP protocol. The element accepts thefollowing attributes:

spi-in The inbound SPI. The values must be greaterthan 255. IPSec reserves the SPI range from 256to 4095 for manually keyed SAs. No IKE keyedSAs will use an SPI value from this range.

spi-out The outbound SPI. The values must be greaterthan 255. IPSec reserves the SPI range from 256to 4095 for manually keyed SAs. No IKE keyedSAs will use an SPI value from this range.


IPSec

encr-key-in The inbound encryption key. This must bespecified if a non-null encryption algorithm isspecified for the tunnel with the transformattribute.

encr-key-outThe outbound encryption key. This must bespecified if a non-null encryption algorithm isspecified for the tunnel with the transformattribute.

auth-key-in The inbound authentication key. This must bespecified if an HMAC algorithm is specified forthe tunnel with the transform attribute.

auth-key-outThe outbound authentication key. This must bespecified if an HMAC algorithm is specified forthe tunnel with the transform attribute.

The following example shows a manually keyed tunnel between two hosts. Thetunnel uses ESP with AES and HMAC-MD5-96.

Example Manually keyed tunnel between two hosts



<quicksec>

<policy>



<tunnel name="hostb-manual" transform="esp aes md5">

<manual-key>

<esp spi-in="256"

encr-key-in="000102030405060708090a0b0c0d0e0f"

auth-key-in="202122232425262728292a2b2c2d2e2f"

spi-out="257"

encr-key-out="101112131415161718191a1b1c1d1e1f"

auth-key-out="303132333435363738393a3b3c3d3e3f"/>

</manual-key>

</tunnel>

<rule to-tunnel="hostb-manual">

<src>10.1.48.7</src>

<dst>10.1.48.8</dst>

</rule>

<rule from-tunnel="hostb-manual">

<src>10.1.48.8</src>

<dst>10.1.48.7</dst>

</rule>


<rule/>




IPSec policy

<rule>

<src>::</src>

</rule>

</policy>

</quicksec>


4.6 Global configuration parameters for IPSec

The params element specifies global configuration parameters for theconfiguration file. From the params element you can configure private keys,authentication services, and so on. Normally these parameters describe more orless static configuration information about the environment where the hostoperates.

If the engine-params element is specified for a params block, it must be atthe beginning of the params block and it must appear only once.

Named pre-shared keys

Normally pre-shared keys are inlined directly in the tunnel objects. You can alsodefine named pre-shared keys in the params block and later refer to them fromthe tunnel object with the psk element's ref attribute. The following exampleshows how to define a named pre-shared key with the name secret.

Example Named pre-shared key



<quicksec>

<params>

<psk name="secret">

id-type="e-mail"

id="[email protected]">Hello, world!</psk>

</params>

<policy>



<tunnel name="hostb">

<psk ref="secret" id-type="ip" id="10.1.48.7"/>

</tunnel>


<src>10.1.48.7</src>

<dst>10.1.48.8</dst>

</rule>


<src>10.1.48.8</src>

<dst>10.1.48.7</dst>


IPSec

</rule>


<rule/>


<rule>

<src>::</src>

</rule>

</policy>

</quicksec>

In the example, the named pre-shared key is defined in the params block. Thedefinition also defines the IKE ID to be used with the key. Later, the key isreferenced from the tunnel element with the psk element's ref attribute. Notehow the IKE identity is overridden in the reference. When an IKE SA isnegotiated with the hostb tunnel, the IP address identity 10.1.48.7 is usedinstead of the e-mail address identity defined with the key.

Engine parameters

Some of the engine parameters can be configured from the configuration file withthe engine-params element. The element takes the following attributes:

. decrement-ttl

A boolean flag describing whether the time to live (TTL) values of IPpackets should be decremented.

. audit-corrupt

A boolean flag describing whether corrupted packets should be auditedwith the ssh_audit_event function.

. drop-if-cannot-audit

A boolean flag describing whether packets should be dropped, if the packethas generated an auditable event which cannot be audited (due to the lackof resources in the auditing framework).

. min-ttl

The minimum value required for a time to live (TTL) field in an IP header.

. audit-total-rate-limit

Rate limit for all audit events, expressed as events/second.

. audit-event-rate-limit

Rate limit for audit events of a single type, expressed as events/second.

. flow-rate-always-allow



IPSec policy

The maximum amount of flow creates that a single slot in the flow ratelimitation table is allowed to own without it ever being considered for ratelimitation.

. flow-rate-always-limit

The maximum amount of flow creates that a second slot in the limitationtable is allowed to own. Any more than this and the flow creates willalways be rate limited.

. flow-rate-usage-threshold

Rate limitation expressed in percentage. If more than this threshold ofmaximum flows are in use, then the rate limitation below will be used.

. flow-rate-max-share

The amount of flow creates over the total requested that is allowed from asingle hash slot.

. fragment-policy

Fragmentation handling policy. The value can be one of the following:

- loose: Loose monitoring of fragments.

- strict: Strict monitoring. Collect full packet before forwarding.

- none: No specified policy, forward as fast as possible.

- nofrags: Disallow all fragments.

. routing

Routing policy. This value can have as a value one of the two tokens,optimized or host.

- If host (the default) is specified, then the host routing table isconsulted as much as possible.

- If optimized is specified, then the interface subnet addresses willbe consulted for routing decisions before the routing table. If theaddress would match an interface subnet address, then that interfacewould be chosen immediately under optimized routing. Theactual impact depends heavily on the host operating system.


4.7 Advanced configuration options for IPSec

The examples below describe a few of the more advanced configuration optionsand things you can do with the XML parser. Many of these examples extend theIPSec DTD with an embedded DTD, defined in the XML file. The embeddedDTD extends the DOCTYPE definition of an XML file:


IPSec


<!DOCTYPE quicksec PUBLIC "quicksec:dtd" "quicksec.dtd" [



]>

<quicksec>

<policy>



<tunnel name="hostb-manual" transform="aes md5 esp">

<manual-key>

<esp spi-in="256"

encr-key-in="000102030405060708090a0b0c0d0e0f"

auth-key-in="202122232425262728292a2b2c2d2e2f"

spi-out="257"

encr-key-out="101112131415161718191a1b1c1d1e1f"

auth-key-out="303132333435363738393a3b3c3d3e3f"/>

</manual-key>

</tunnel>

<rule to-tunnel="hostb-manual">

<src>&hosta;</src>

<dst>&hostb;</dst>

</rule>

<rule from-tunnel="hostb-manual">

<src>&hostb;</src>

<dst>&hosta;</dst>

</rule>



<rule/>

</policy>

</quicksec>



IPSec policy

By redefining parameter entities you can change some attribute default values.


4.7.1 External entities

In XML, you can refer to external entities with an external entity declaration ofthe following format:

<!ENTITY name SYSTEM "URL">

In the declaration, name is the name of the entity and URL specifies an externalURL. The sshipsecpm program supports the following URLs in externalentities:

http://... An HTTP URL.

file://... A file in a local file system.

filename A file in a local file system.


4.7.2 Built-in entities

The IPSec policy manager implements several built-in entities. They can bereferenced from DTDs and XML files using parameter-entity references (%name;) and entity references (&name;), respectively. The following internalentity names are recognised:

quicksec:hostnameThe name of the host as returned by thessh_tcp_get_host_name function.

<!ENTITY hostname PUBLIC "quicksec:hostname" ">

quicksec:version The QuickSec version number.

<!ENTITY version PUBLIC "quicksec:version"">

ifname (index) The name of the index interface number. The interfacenumbers are logged to the system log when ipm process isstarted.

Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: Interface: name=lo ifnum=1

Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: 127.0.0.1/255.0.0.0

Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: ::1/128


IPSec

Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: Interface: name=eth0 ifnum=3


Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: fe80::ff:fe01:201/10





Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: fe80::200:50ff:fe15:4b93/10



Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: Interface: name=bond0 ifnum=7



Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: fe80::192:168:0:1/10


Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: Interface: name=bond1 ifnum=8




Apr 11 09:13:08 src@IPD-0-A/IPD-0-A SS_IPM[295]: 2001:490:ff0:c2ad:0:6:1:13/64




In this example, the value of the public-interfaceentity is "bond1".

<!ENTITY public-interface "quicksec:ifname(0)" "">

ifname (index, type)The name of the index interface of the type type. Possiblevalues for type are:

. any: any interface, no special constraints are set for theinterface type.

. loopback: a loopback interface.

. physical: a physical network interface (not aloopback interface).

For example, with the interface listing above, the value of theloopback entity is "1o0" and the value of the publicentity is "fxp0":

<!ENTITY loopback "quicksec:ifname(0,loopback)" "">

<!ENTITY public "quicksec:ifname(0,physical)" "">




IPSec policy

4.7.3 Input encodings

The default encoding for XML documents is UTF-8. If you do not specify anyinput encoding in the first line of the XML document, the document is assumed tobe in the UTF-8 format. With the encoding attribute, you can select theencoding used in your configuration file. Also, some 16 and 32 bit formats areautomatically recognised when the XML parser starts to read an input file. Thefollowing encodings are supported:

UTF-8 A transformation format of ISO 10646 (RFC 2279).

UTF-16 An encoding of ISO 10646 (RFC 2781).

UTF-16BE UTF-16 in big-endian byte-order.

UTF-16LE UTF-16 in little-endian byte-order.

ISO-10646-UCS-2The 2-octet Basic Multilingual Plane, also known as Unicode.

ISO-10646-UCS-4ISO-10646, the full code space.

ISO-8859-1:1987, ISO-8859-1ISO-8859-1 (Latin1) character set.

ANSI X3.4-1968, ASCII, US-ASCII, us7 bit ASCII.


4.7.4 Changing DTD default values

The IPSec DTD defines default values for various policy element attributes. Thedefault values are implemented as XML’s parameter entities which can beoverridden from the XML file when the policy file is loaded. The followingparameter entities are defined:

default-transformThe default value for the transform attribute of thetunnel element. The default value is "esp aes 3des sha1md5".

default-pfs-level The default value for the level attribute of the pfs element.The default value is "none".

default-life-type The default value for the type attribute of the life element.The default value is "kbytes".

default-rule-type The default value for the type attribute of the rule element.The default value is "pass".

The parameter entities can be overridden from an embedded DTD of an XMLfile. The following example shows how to change the default rule type to "drop":


IPSec

Example Changing DTD default values


<!DOCTYPE quicksec PUBLIC "quicksec:dtd" "quicksec.dtd"> [

<!ENTITY % default-rule-type ’"drop"’>

]>

<quicksec>

<policy>

<rule/>

</policy>

</quicksec>

In the example above, the DOCTYPE line is extended with an embedded DTD.The embedded DTD starts from the "[" character and ends at the "]>" markup.Everything in between is DTD data. All parameter entities defined in anembedded DTD override the corresponding parameter entities at the externalDTD (quicksec:dtd).

When the configuration file is loaded, the policy manager sees the policy as:

<quicksec>

<policy>

<rule type="drop"/>

</policy>

</quicksec>


4.8 Intrusion events

The IPSec toolkit supports audit events that are written to the system log locatedin /var/log/master-syslog in the active CLA node. The audit events arealways related to the IPSec policy manager (IPM).

The system administrator can use some audit events to detect attempts ofbreaking into the system. This kind of functionality is often called intrusiondetection system (IDS), and the related audit events are called intrusion events.More generally, unexpected events, such as corrupted packets, malformed IKEmessages, or attempts to connect to prohibited TCP ports may all be logged.

Below is an example of system log output of an audit event.

Example

...

Mar 24 09:20:47 IPD-0-A SS_IPM: I; 20040908115213: ENGINE_SESSION_START: \

source eth0: destination eth0: tcp: Src IP 172.21.92.35: Dst IP 172.21.92.82: \



IPSec policy

Src Port 22: Dst Port 38529

...

This example audit message has the following parameters:

. the program name that created the audit event, that is, IPM

. date, in the format year-month-day-hour-minute-second (UTC)

. the name of the audit event. The events are listed in the table Supportedaudit events.

. source interface name

. destination interface name

. IP protocol

. source IP address

. destination IP address

. source port

. destination port.

In this example, someone using the IP address 172.21.92.35 initiated an SSHTCP session through the FlexiServer IPD to an internal address of 172.21.92.82.

Supported audit events

The following table describes the supported audit events. Note that some of themhave to be explicitly turned on by editing the IPSec policy file for each particularIPSec or firewall rule.

Table 3. Supported audit events

Event Description

SSH_AUDIT_ENGINE_SESSION_-START

Start of a new TCP session or a new UDP stream.

This must be enabled in the IPSec policy file.

SSH_AUDIT_ENGINE_SESSION_END End of a TCP session or an UDP stream.

This must be enabled in the IPSec policy file.


IPSec

Table 3. Supported audit events (cont.)

Event Description

SSH_AUDIT_CORRUPT_PACKET Suspicious packet is received and dropped. This may beeither simply a malformed packet or an intentionally craftedpacket attack.

Currently the toolkit recognises the following packetattacks:. SSH_ENGINE_ATTACK_LAND

Source and destination address is the same.. SSH_ENGINE_ATTACK_FRAGMENT_DEATH

The IP fragments would assemble in a packet larger than64K.

. SSH_ENGINE_ATTACK_TRACEROUTE

TTL set to a low value in a attempt to TRACEROUTE thenetwork. The minimum allowed TTL value is by default 1.You can also set the value in the IPSec policy file.

. SSH_ENGINE_ATTACK_XMAS_SCAN

TCP attack with all the TCP flags URG, FIN and PSHset.

SSH_AUDIT_FLOOD Someone is trying the flood the network with illegal audita-ble packets and the message rate limit is reached.

The message rate limit is by default 5. You can also set thevalue in the IPSec policy file.

SSH_AUDIT_RULE_MATCH A packet matched an IPSec policy to explicitly drop or re-ject the incoming or outgoing packet. The difference be-tween dropping and rejecting a packet is that the formerdoes it silently without informing the sender.

SSH_AUDIT_AH_SEQUENCE_NUM-BER_OVERFLOW

An attempt to transmit a packet that would result in Se-quence Number overflow if anti-replay is enabled.

The log entry should include the SPI value, date/time,Source Address, Destination Address, and for IPv6 theFlow ID.

SSH_AUDIT_AH_SA_LOOKUP_FAI-LURE

When mapping the IP datagram to the appropriate SA, theSA lookup fails.




IPSec policy


Event Description

SSH_AUDIT_AH_SEQUENCE_NUM-BER_FAILURE

If a received packet does not fall within the receivers slid-ing window, the receiver MUST discard the received IP da-tagram as invalid.

The log entry should include the SPI value, date/time,Source Address, Destination Address, the SequenceNumber, and for IPv6 the Flow ID.

SSH_AUDIT_AH_ICV_FAILURE If the computed and received ICV's do not match, then thereceiver MUST discard the received IP datagram as invalid.

The log entry should include the SPI value, date/timereceived, Source Address, Destination Address, and forIPv6 the Flow ID.

SSH_AUDIT_ESP_SEQUENCE_NUM-BER_OVERFLOW

An attempt to transmit a packet that would result in Se-quence Number overflow if anti-replay is enabled.


SH_AUDIT_ESP_SA_LOOKUP_FAI-LURE

When mapping the IP datagram to the appropriate SA, theSA lookup fails.


SSH_AUDIT_ESP_SEQUENCE_NUM-BER_FAILURE

If a received packet does not fall within the receivers slid-ing window, the receiver must discard the received IP data-gram as invalid.

The log entry should include the SPI value, date/time,Source Address, Destination Address, the SequenceNumber, and for IPv6 the Flow ID.

SSH_AUDIT_ESP_ICV_FAILURE If the computed and received ICV's do not match, then thereceiver MUST discard the received IP datagram as invalid.

The log entry should include the SPI value, date/timereceived, Source Address, Destination Address, and forIPv6 the Flow ID.

SSH_AUDIT_PM_ESP_NULL_NULL_-NEGOTIATION

The other IKE peer tried to negotiate ESP SA with both aNULL encryption and a NULL authentication algorithm.

SSH_AUDIT_IKE_RETRY_LIMIT_-REACHED

The message retry limit is reached when transmittingISAKMP messages.


IPSec


Event Description

SSH_AUDIT_IKE_INVALID_COOKIE When ISAKMP message is received and the cookie valida-tion fails.

SSH_AUDIT_IKE_INVALID_I-SAKMP_VERSION

The Version field validation fails.

SSH_AUDIT_IKE_INVALID_EX-CHANGE_TYPE

The Exchange Type field validation fails.

SSH_AUDIT_IKE_INVALID_FLAGS The Flags field validation fails.

SSH_AUDIT_IKE_INVALID_NEXT_-PAYLOAD

When any of the ISAKMP Payloads are received and theNextPayload field validation fails.

SSH_AUDIT_IKE_INVALID_RESER-VED_FIELD

The value in the RESERVED field is not zero.

SSH_AUDIT_IKE_INVALID_DOI The DOI determination fails.

SSH_AUDIT_IKE_INVALID_SITUA-TION

The Situation determination fails.

SSH_AUDIT_IKE_INVALID_PROPO-SAL

The Security Association Proposal is not accepted.

SSH_AUDIT_IKE_INVALID_SPI The SPI is invalid.

SSH_AUDIT_IKE_BAD_PROPOSAL_-SYNTAX

The proposals are not formed correctly.

SSH_AUDIT_IKE_INVALID_PROTO-COL_ID

The Protocol ID determination fails.

SSH_AUDIT_IKE_DELETE_PAYLOA-D_RECEIVED

The receiver detects an error in Delete Payload.

SSH_AUDIT_IKE_UNEQUAL_PAYLOA-D_LENGTHS

The receiver detects an error in payload lengths.

Audit event parameters

Depending on the audit events, a set of the following audit events parameters iswritten to the system log.



IPSec policy

Table 4. Audit event parameters

Parameter Description

SPI Contains the SPI for the packet which caused the auditableevent. For IKE this is the initiator and responder cookies.

If the length is zero, this value is ignored.

Source address Contains the source address for the packet which causedthe auditable event. For IKE this is the local IP address.


Destination address Contains the destination address for the packet whichcaused the auditable event. For IKE this is the remote IPaddress.


IPv6 flow ID Contains the Flow ID for the packet which caused the audi-table event. This concerns only IPv6 addresses.


Sequence number Contains the sequence number for the packet whichcaused the auditable event.


Text description Additional free format textual description of the event.

IP protocol ID IP packet protocol ID field.

Source port number IP packet source port number field.

Destination port number IP packet destination port number field.

Source interface name The interface name where the packet came in.

Destination interface name The interface name where the packet went out.

IPv4 option name The name of the IPv4 option.

ICMP type and code ICMP packet type and code fields.

IPv6 ICMP type and code ICMP packet type and code fields for IPv6.

TCP header flags TCP header flags which are set.

Key length in bits If the audit event is associated to an IPSec protected tun-nel, the audit event may contain the key length if it is rele-vant to that particular audit event.


IPSec

Table 4. Audit event parameters (cont.)

Parameter Description

Target IP/Host for various op-erations.

Application-level target information. This may be the IP ad-dress or the host name of the target machine of the higherlevel session the audit event is associated. It is not the ac-tual TCP connection.



IPSec policy


IPSec

5 Reserving memory for IPSecPurpose

Use these instructions to reserve physical memory for IPSec.

Summary

The memory reservation for IPSec must be done when the kernel starts, becausethe Linux operating system cannot allocate large amounts of physical memory inthe kernel. The fragmentation of memory after the operating system is startedmakes it difficult to find a large amount of contiguous available memory.

The amount of memory reserved for each IPSec SA is determined by an equationstored in the IPSec kernel module. The equation is based on the most commonSA usage scenarios. It, for example, assumes that most of the IPSec tunnels arebi-directional, and transport mode ESP protected. The current version of theequation calculates 1444 SAs for each megabyte of memory.

Note

For each bi-directional IPSec tunnel, often called a VPN tunnel, you need twoIPSec SAs.

Even though the given value of 1444 SAs for a megabyte of physical memory isnot exact, it is a fairly good estimation for designing the system. For example, ifyou need 500 000 SAs, you have to reserve about 350 megabytes of physicalmemory for IPSec. When the IPSec module is loaded, it outputs the exact amountof the allocated IPSec SAs to the system log.

Steps

1. Reserve memory for IPSec.

a. Edit the /etc/kernelparam file to contain the following line:

ipsec_poolsize=xxxM



Reserving memory for IPSec

where xxx is the amount of memory (in megabytes) to be reservedfor IPSec.

b. Repeat step 1 for each IPD node.

Note

Every IPD node pair (such as IPD-0-A/IPD-0-B or IPD-1-A/IPD-1-B) must havean identical amount of memory reserved for IPSec.

For example, if you change the ipsec_poolsize for IPD-1-A to 500megabytes, you must also change the same value to IPD-1-B.

2. Reboot the node.

3. Verify the changes.

Check the syslog in the active CLA to verify that the changes took placesuccessfully in all updated IPD nodes. Give the following command:

cat /var/log/master-syslog | grep IPSec

If entries such as the following examples can be found in the log, theupdate has been successful:

Nov 29 11:12:24 src@IPD-0-A/IPD-0-A kernel: IPSec found 1984M of total system

memory +64M for IPSec.

Nov 29 11:12:24 src@IPD-0-A/IPD-0-A kernel: IPSec operating with 64M (65536 K) of

memory (92424 SAs).


IPSec

6 Enabling IPSec servicePurpose

You must modify the IPSec policy, start the IPSec policy manager (ipm) process,and reload the new policy to enable IPSec in the network element.

Summary

Before starting the ipm process, you must modify the IPSec policy. The defaultpolicy is to pass all traffic. To make IPSec protect some or all of the traffic, youmust modify the IPSec policy file. The IPSec policy is an XML file, which can beedited with a text editor or an XML editor.

This procedure uses IPD Manager-0 group as an example. This procedure needsto be repeated with all the IPD Manager groups.

The ipm executable is located in the directory /opt/Nokia/SS_IPM/bin.The ipm process is started by high availability services (HAS). Unlocking therecovery groups that IPSec needs starts the ipm process.

By default, the system starts the ipm process with the following command linearguments:

/opt/Nokia/SS_IPM/bin/ipm -i -s -f /etc/opt/Nokia/IPSec/ipsec-policy.xml

The following options are stored in the LDAP directory. You can edit them withthe Parameter Tool. For information on the path, see Reserving memory forIPSec.

Note

Be careful when editing these options. Wrong use of these parameters may renderthe system unusable.



Enabling IPSec service

-D, –debug = debug_levelSpecifies the logging level for the policy manager (user modecode). debug_level is as described forssh_debug_set_level_string. In the simplest case,debug_level can be a numeric value, but it can alsospecify module name patterns and separate log levels for eachmodule. This option is only available if the source tree iscompiled with DEBUG_LIGHT defined (that is, it isconfigured with configure --enable-debug).

-f, –file = URL Specifies the configuration file URL to read. This URL mustpoint to a text file that contains the policy, in the formatdescribed in Basic IPSec configuration. The default policyfile ipsec-policy.xml is located in the directory /etc/opt/Nokia/IPSec.

-h, –help Displays the help text.

-i, –interface-infoPrints the names of available the network interfaces to thestandard output device.

-K, –kernel-debug =debug_levelSpecifies the logging level for the engine (kernel mode code).debug_level is as described forssh_debug_set_level_string. In the simplest case,debug_level can be a numeric value, but it can alsospecify module name patterns and separate log levels for eachmodule. This option is only available if the source tree iscompiled with DEBUG_LIGHT defined (that is, it isconfigured with configure --enable-debug).

-l Enables logging in to the console.

-m, –mem=megabytesSpecifies the real amount of physical memory in the system inunits of megabytes. If the kernel is booted with themem=xxxM boot parameter set to a lower value than the realamount of physical memory in the system, then this extramemory is used by IPSec for SA storage. Starting the ipmwith option -m 0, or without this option, sets up a minimalconfiguration and prints the real amount of physical memoryto the system log.

-p Loads the pass rule and skips loading the policy.

-s Enables logging in using syslog.

-V, –version Prints the version number of the policy manager.

The policy manager also handles the following Unix signals:


IPSec

SIGINT Gracefully quits the policy manager.

SIGHUP Causes the policy manager to reread its policy configurationfile.

Note

Mandatory arguments for long options are mandatory for short options, too.

Steps

1. Log in to the active cluster assistant (CLA) node as root user.

2. Open the IPSec policy file in a text editor and modify it.

The default policy file ipsec-policy.xml is located in the directory /etc/opt/Nokia/IPSec/.

Example Modifying the ipsec-policy.xml file

In this example, the default IPSec policy has been modified to provide thefollowing traffic rules:

. Bypass all SSH (tcp/22) traffic to/from the IPD node.

. Protect all traffic (except SSH) to/from the VPN router-1 protectednetwork (10.0.10/24). The VPN router-1 public address is 10.0.0.10(tunnel endpoint).

. Protect UDP SIP (udp/5060) traffic to/from the VPN router-2protected network (10.0.20/24). All the other traffic to/from VPNrouter-2 is dropped (except SSH). The VPN router-2 public addressis 10.0.0.20 (tunnel endpoint).

. Drop all traffic that does not match the above rules.

. All the IKE connections have the pre-shared secret “password”. TheIKE SAs have x lifetime (default) with VPN router-1, and 28800seconds with VPN router-2.

. The IPSec SAs have x lifetime (default) with VPN router-1 and3600 seconds with VPN router-2. A new IPSec SA is created foreach new port with VPN router-2.



<quicksec>

<policy>



<tunnel name="VPN-1">




 <peer>10.0.0.10</peer>



<psk>password</psk>

</tunnel>







<tunnel name="VPN-2" ike-life="28800" flags="perport">

<peer>10.0.0.20</peer>



<life type="seconds">3600</life>

<psk>password</psk>

</tunnel>



<service name="sip-udp" protocol="udp" dstport="5060"/>



<service name="ssh" protocol="tcp" dstport="22"/>



<rule service="ssh"/>



<rule to-tunnel="VPN-1">

<dst>10.0.10.0/24</dst>

</rule>

<rule from-tunnel="VPN-1">

<src>10.0.10.0/24</src>

</rule>



<rule service="sip-udp" to-tunnel="VPN-2">

<dst>10.0.20.0/24</dst>

</rule>

<rule service="sip-udp" from-tunnel="VPN-2">

<src>10.0.20.0/24</src>

</rule>



<rule type="drop">

</rule>

</policy>

</quicksec>

3. Save the modified IPSec policy file.

4. Unlock the IPDManager-0 recovery group.

Enter:

hascli -u /IPDManager-0

5. Unlock the IPD-0-A recovery group.

Enter:

hascli -u /IPD-0-A


IPSec

6. Unlock the IPD-0-B recovery group.

Enter:

hascli -u /IPD-0-B

7. Unlock the IPDManagerServer for IPD-0-A recovery group.

Enter:

hascli -u /IPD-0-A/FSIPDManagerServer

8. Unlock the IPDManagerServer for IPD-0-B recovery group.

Enter:

hascli -u /IPD-0-B/FSIPDManagerServer

Expected outcome

The ipm process is up and running on the IPD node, and the default policyfile (/etc/opt/Nokia/IPSec/ipsec-policy.xml) is loaded.

Expected outcome

The new IPSec policy is loaded.

Unexpected outcome

If any errors occur, the system records them to the system log in /var/log/master-syslog in the active CLA node. For troubleshooting instructions, seeIPSec is not working properly.

Verification

To check that the policy file has been modified:

Enter: ipmop -show-config

Check the system logs in the active CLA's file /var/log/master-syslog.

The following system log entries indicate successful parsing and loading of thenew policy:

Apr 3 21:04:17 src@IPD-0-A/IPD-0-A SS_IPM[27318]: Reloading policy from /etc/opt/

Nokia/IPSec/ipsec-policy.xml

Apr 3 21:04:17 src@IPD-0-A/IPD-0-A SS_IPM[27318]: Policy rules reloaded from /etc/




opt/Nokia/IPSec/ipsec-policy.xml

Further information

Use the ipmop executable to verify the status of the ipm. For instructions, seeChecking IPSec service.

Note that this procedure needs to be repeated with all the IPD Manager groups.


IPSec

7 Checking IPSec servicePurpose

Check the IPSec policy manager and IPSec in, for example, troubleshootingsituations. Often traffic seems to go through even though it is not encrypted. Youmust always verify that the traffic really is IPSec protected before deploying theservice, as passing information in plain text is a critical security vulnerability.

Summary

Use the ipmop command line tool to manage and retrieve statistics and otherinformation about the IPSec policy manager and IPSec. The ipmop commandmust be executed on the active IP Director (IPD) node (IPD-0-A or IPD-0-B).

The following options are available:

-help Displays the help text.

-show-policy Displays the policy database.

-show-ipsec Displays the IPSec security association database.

-show-ike Displays the active IKE connections and connection details

-show-stat Displays the IPSec global statistics.

-show-config Displays the current configuration settings.

-show-rkey Displays information about the remote key connections.

-reload Reloads the policy.

-kill Closes and exits the ipm program.

-v Provides more information to the commands listed above.

Running ipmop without an argument lists the available options.

Note

The following steps do not need to be done in numerical order. You can alsochoose to do only one step, for example, retrieve statistics.



Checking IPSec service

Steps

1. Verify IKE and IPSec connections.

a. Log in to the active cluster assistant (CLA) node as root user.

b. Check the system log files (/var/log/master-syslog) forIKE and IPSec negotiations. Successful IKE and IPSec negotiationsare reported to the master-syslog file. The following entriesindicate IKE and IPSec security association (SA) creation:

Example Successful IKE and IPSec creation in the syslog file

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: IKE SA [Initiator] negotiation completed:

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]:

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Main Mode using Pre-shared keys (3des-

cbc/sha1)

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Diffie-Hellman group 2


Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Local IKE peer 10.0.0.1 ID 10.0.0.1

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Remote IKE peer 10.0.0.10 ID 10.0.0.10


Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Lifetime: 28800 seconds

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: QM notification `Replay status notification'

(24577)

(size 4 bytes) from 10.0.0.10 for protocol ISAKMP spi[0...-1]=


Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: IPSec SA [Initiator, tunnel] negotiation

completed:


Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Local IKE peer 10.0.0.1 ID 10.0.0.1

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Remote IKE peer 10.0.0.10 ID 10.0.0.10

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Local Proxy ID 10.0.0.1 any

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Remote Proxy ID 10.0.10.0/24 any


Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Inbound SPI: | Outbound SPI: |

Algorithm:

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: ESP [ccb091de] | [f04eca12] | 3des-

cbc

- hmac-sha1-96


Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: Lifetime: 3600 seconds

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: IPSec SA negotiations: 1 done, 1

successful, 0 failed

c. Log in to the active IPD node as root user.

d. Check that IPSec traffic between the IP Director (IPD) node andanother network element is encrypted with, for example,encapsulating security payload (ESP).

Enter:

tcpdump -ni <interface name> -x -s 100


IPSec

Example Tcpdump command

tcpdump -ni eth0 -x -s 100

In this example, the traffic is encrypted:

13:13:13.255159 192.168.1.1 > 192.168.1.2: ESP(spi=0x00000100,seq=0x546) (DF)

4500 0240 0000 4000 4032 b538 c0a8 0101

c0a8 0102 0000 0100 0000 0546 6ad8 d4cc

f8e9 b646 15fd e929 4c3a 77f5 e545 2bad

fbe2 8397 ba02 dfc7 046a 56e8 8bf6 e2f1

1d1b f08f 0394 ec43 c454 6110 8a75 d082

a061 2bab 16ff

13:13:13.275157 192.168.1.1 > 192.168.1.2: ESP(spi=0x00000100,seq=0x547) (DF)

4500 0240 0000 4000 4032 b538 c0a8 0101

c0a8 0102 0000 0100 0000 0547 c760 ff80

64fa 86b9 2745 efbd 8689 4c73 5682 1229

2bd2 b962 4c4e 779b 5ecb 68b0 0b69 8c2e

8b8a 4dff 186a ef8d 8ad5 2d29 2512 b052

af1e 7cdf 3c6d

13:13:13.295160 192.168.1.1 > 192.168.1.2: ESP(spi=0x00000100,seq=0x548) (DF)

4500 0240 0000 4000 4032 b538 c0a8 0101

c0a8 0102 0000 0100 0000 0548 907b 7eda

4674 e533 3642 da69 14ce ef21 1f34 f12b

d205 dd34 8858 5c40 5cb9 469d d564 f837

a8a9 0d82 dfee 4489 c7eb 4368 0413 104d

8245 b7a8 3077

13:13:13.315156 192.168.1.1 > 192.168.1.2: ESP(spi=0x00000100,seq=0x549) (DF)

4500 0240 0000 4000 4032 b538 c0a8 0101

c0a8 0102 0000 0100 0000 0549 e2b7 3989

5a23 12c8 833f c541 baf0 ae5f e281 902c

8de7 c8e5 80bc 8d35 e4fa 4ea6 7eea 6340

4808 ab83 6ee0 01b1 3dbb 5419 26fe f528

d2f1 eb20 06fe

2. Retrieve statistics.

a. Log in to the active IPD node as root user.

b. Enter:

ipmop -show-stat

3. Check trace logs in the system log.

a. Log in to the active cluster assistant (CLA) node as root user.

b. In the /var/log/master-syslog file, entries with ipmconcern IPSec.

Example IPSec trace logs in system log

Mar 24 09:20:47 IPD-0-A SS_IPM[<number>]: IPSec SA

negotiations:




1 done, 1 successful, 0 failed


IPSec

8 Configuring intrusion event monitoringPurpose

Use these instructions to configure what intrusion events are written in the systemlog.

Summary

Usually audit events are written automatically to the system log. Intrusion eventsare a subset of audit events, and they contain infomation of improper,unauthorised, and abnormal system and network activities. You have to configurethe following intrusion events separately:

. SSH_AUDIT_ENGINE_SESSION_START

. SSH_AUDIT_ENGINE_SESSION_END

. SSH_ENGINE_ATTACK_TRACEROUTE

. SSH_AUDIT_FLOOD.

Steps

1. Login to the active CLA as root user.

2. Open the IPSec policy file.

Open the IPSec policy file in /opt/Nokia/IPSec/etc/ipsec-policy.xml.

3. Edit the desired attributes.

. To add the SSH_AUDIT_ENGINE_SESSION_START andSSH_AUDIT_ENGINE_SESSION_END entries to the log, set thevalue for the each attribute rule to log="connections".

. To change the minimum allowed TTL value, set the value for theattribute min-ttl in the element engine-params . This auditevent is logged as SSH_ENGINE_ATTACK_TRACEROUTE.

By default the minimum allowed TTL value is 1.



Configuring intrusion event monitoring

. To change the message limit rate, set the value for the attributeaudit-event-rate-limit in the element engine-params. This audit event is logged as SSH_AUDIT_FLOOD.

By default the message rate limit is 5.

The following example includes all the parameters you canconfigure.

Example



<quicksec>

<params>

<engine-params min-ttl="1" audit-event-rate-limit="10"/>

</params>

<policy>

<tunnel name="sgw" transform="aes md5 esp">

<peer>10.0.0.9</peer>

<psk>foo</psk>

</tunnel>

<rule log="connections" to-tunnel="sgw">

<dst>10.0.9.0/24</dst>

</rule>

<rule log="connections" from-tunnel="sgw">

<src>10.0.9.0/24</src>

</rule>



<rule/>

</policy>

</quicksec>

Expected outcome

The desired intrusion events are written to the system log.


IPSec

9 Monitoring intrusion eventsPurpose

Use these instructions to monitor intrusion event entries written to the system loglocated in /var/log/master-syslog in the active CLA node.

Steps

1. Login to the active CLA as root user.

2. View the log with the cat command.

Use the grep command to list only the audit events for the IPM process.

Enter:

cat /var/log/master-syslog | grep SS_IPM.

Expected outcome

The audit events for the IPM process are listed.



Monitoring intrusion events


IPSec

10 IPSec is not working properlyDescription

If there are problems in the IPSec configuration, the ipm process will not startand all traffic to and from the node stops. The problem is usually in the IPSecservice or in the policy file:

. The IPSec service has not started.

. The syntax in the IPSec policy file is incorrect. In this case, the systemdoes not load the new policy.

. The IPSec configuration is incorrect. In this case, the system loads the newpolicy, but does not pass any traffic through.

Memory reservation for the IPSec service can also cause problems. If a largeamount of memory is reserved for IPSec, it is possible that the amount ofaddressable virtual memory in the kernel is not sufficient.

Symptoms

When the IPSec service is not running, no external incoming or outgoing traffic ispassed.

If the system does not load the new IPSec policy, the system log (/var/log/master-syslog) contains the following types of entries:

Mar 24 09:13:06 IPD-0-A SS_IPM[<number>]: Reloading policy \

from /etc/ipsec-policy.xml

Mar 24 09:13:06 IPD-0-A SS_IPM[<number>]: /etc/ipsec-policy.xml:34:

Reference to an unknown ID "VPX-1"

Mar 24 09:13:06 IPD-0-A SS_IPM[<number>]: Policy rules loading failed

If the system loads the new IPSec policy files, but does not pass traffic through,the IPSec configuration is incorrect.

If the system log contains an error message instead of an IPSec memoryreservation success message such as that described in Reserving memory forIPSec, there is a problem with memory reservation.



IPSec is not working properly

Recoveryprocedures


Steps

1. Log in from the console to the active Cluster Assistant (CLA) node asroot user.

2. Check if the IPDManager is active.

Enter:

hascli -s /IPDManager-0

Expected outcome

The status of the IPDManager-0 recovery group is active. Continue withchecking the IPSec configuration.

Unexpected outcome

The status of the IPDManager-0 recovery group is not active. For moreinformation, check the system log (/var/log/master-syslog) forentries with the SS_IPM keyword.

Checking IPSec configuration

For instructions on how to check the current IPSec configuration, see CheckingIPSec service.

Correcting IPSec policy file

Steps

1. Open the IPSec policy file in a text editor.

The policy file ipsec-policy.xml is located in the directory /etc/opt/Nokia/IPSec/.

2. Locate the error and correct it.

The error message in the system log (/var/log/master-syslog)contains the line number and a description for identifying and correctingthe problem.

3. Save the modified IPSec policy file.


IPSec

4. Reload the new IPSec policy.

Enter:

/opt/Nokia/SS_IPM/bin/ipmop -reload

Handling memory reservation problems

Summary

There is an maximum limit for the amount of physical memory that can bereserved for IPSec. This limit is determined by the amount of addressable virtualmemory that is available in the kernel.

The amount of addressable virtual memory should be 118M more than the size ofthe physical memory reserved for IPSec. For example, if the system has 2048Mof physical memory of which 512M is reserved for IPSec, then at least 640M ofvirtual memory is needed.

Currently the maximum amount of available virtual memory, specified by thekernel parameter VMALLOC_RESERVE, is 704M. Therefore the maximumamount of physical memory that can be reserved for IPSec is 586M (704 - 118).

This limitation results from the way the Linux kernel divides the virtual addressspace between the user space and the kernel. There are methods (patches to thekernel) for overcoming this limitation. They will be addressed in the later releasesof the platform.



IPSec is not working properly

Date post:	26-Oct-2015
Category:	Documents
Upload:	anshul-singhal
View:	62 times
Download:	4 times

IPSec

Documents