sun.com docs.sun.com My Sun Worldwide Sites

Previous Previous     Contents     Index     Next Next

GlobalSecurityParameters Section

The GlobalSecurityParameters section contains the labels maxClockSkew, HA-FAauth, MN-FAauth, Challenge, and KeyDistribution. This section has the following syntax:

[GlobalSecurityParameters]
     MaxClockSkew = n
     HA-FAauth = <yes/no>
     MN-FAauth = <yes/no>
     Challenge = <yes/no>
     KeyDistribution = files

The Mobile IP protocol provides message replay protection by allowing timestamps to be present in the messages. If the clocks differ, the home agent returns an error to the mobile node with the current time and the mobile node can register again by using the current time. You use the MaxClockSkew label to configure the maximum number of seconds that differ between the home agent and the mobile node's clocks. The default value is 300 seconds.

The HA-FAauth and MN-FAauth labels enable or disable the requirement for home-foreign and mobile-foreign authentication, respectively. The default value is disabled. You use the challenge label so that the foreign agent issues challenges to the mobile node in its advertisements. The label is used for replay protection. The default value is disabled here, also.

The following table describes the labels and values that you can use in the GlobalSecurityParameters section.

Table 29-2 GlobalSecurityParameters Section Labels and Values

Label

Value

Description

MaxClockSkew

n

The number of seconds that mipagent accepts as a difference between its own local time and the time that is found in registration requests

HA-FAauth

yes or no

Specifies if HA-FA authentication extensions must be present in registration requests and replies

MN-FAauth

yes or no

Specifies if MN-FA authentication extensions must be present in registration requests and replies

Challenge

yes or no

Specifies if the foreign agent includes challenges in its mobility advertisements

KeyDistribution

files

Must be set to files

Pool Section

Mobile nodes can be assigned dynamic addresses by the home agent. Dynamic address assignment is done within the mipagent daemon independently of DHCP. You can create an address pool that can be used by mobile nodes by requesting a home address. Address pools are configured through the Pool section in the configuration file.

The Pool section contains the BaseAddress and Size labels. The Pool section has the following syntax:

[Pool pool-identifier]
     BaseAddress = IP-address
     Size = size


Note - If you use a Pool identifier, then it must also exist in the mobile node's Address section.


You use the Pool section to define address pools that can be assigned to the mobile nodes. You use the BaseAddress label to set the first IP address in the pool. You use the Size label to specify the number of addresses available in the pool.

For example, if IP addresses 192.168.1.1 through 192.168.1.100 are reserved in pool 10, the Pool section has the following entry:

[Pool 10]
     BaseAddress = 192.168.1.1
     Size = 100


Note - Address ranges should not encompass the broadcast address. For example, you should not assign BaseAddress = 192.168.1.200 and Size = 60, because this range encompasses the broadcast address 192.168.1.255.


The following table describes the labels and values that are used in the Pool section.

Table 29-3 Pool Section Labels and Values

Label

Value

Description

BaseAddress

n.n.n.n

First address in the address pool

Size

n

Number of addresses in the pool

SPI Section

Because the Mobile IP protocol requires message authentication, you must identify the security context by using a security parameter index (SPI). You define the security context in the SPI section. You must include a different SPI section for each security context that is defined. A numerical ID identifies the security context. The Mobile IP protocol reserves the first 256 SPIs. Therefore, you should use only SPI values greater than 256. The SPI section contains security-related information, such as shared secrets and replay protection.

The SPI section also contains the ReplayMethod and Key labels. The SPI section has the following syntax:

[SPI SPI-identifier]
     ReplayMethod = <none/timestamps>
     Key = key

Two communicating peers must share the same SPI identifier. You must configure them with the same key and replay method. You specify the key as a string of hexadecimal digits. The maximum length is 16 bytes. For example, if the key is 16 bytes long, and contains the hexadecimal values 0 through f, the key string might resemble the following:

Key = 0102030405060708090a0b0c0d0e0f10

Keys must have an even number of digits, corresponding to the two digits per byte representation.

The following table describes the labels and values that you can use in the SPI section.

Table 29-4 SPI Section Labels and Values

Label

Value

Description

ReplayMethod

none or timestamps

Specifies the type of replay authentication used for the SPI

Key

x

Authentication key in hexadecimal

Address Section

The Solaris implementation of Mobile IP enables you to configure mobile nodes using one of three methods. Each method is configured in the Address section. The first method follows the traditional Mobile IP protocol, and requires that each mobile node have a home address. The second method enables a mobile node to be identified through its Network Access Identifier (NAI). The last method enables you to configure a default mobile node, which can be used by any mobile node that has the proper SPI value and related keying material.

Mobile Node

The Address section for a mobile node contains the Type and SPI labels that define the address type and SPI identifier. The Address section has the following syntax:

[Address address]
     Type = node
     SPI = SPI-identifier

You must include an Address section in a home agent's configuration file for each mobile node that is supported.

If Mobile IP message authentication is required between the foreign agent and home agent, you must include an Address section for each peer with which an agent needs to communicate.

The SPI value that you configure must represent an SPI section that is present in the configuration file.

You can also configure private addresses for a mobile node.

The following table describes the labels and values that you can use in the Address section for a mobile node.

Table 29-5 Address Section Labels and Values (Mobile Node)

Label

Value

Description

Type

node

Specifies that the entry is for a mobile node

SPI

n

Specifies the SPI value for the associated entry

Mobility Agent

The Address section for a mobility agent contains the Type and SPI labels that define the address type and SPI identifier. This section also contains IPsec request, reply, and tunnel labels. The Address section for a mobility agent has the following syntax:

[Address address]
     Type = agent
     SPI = SPI-identifier
     IPsecRequest = action {properties} [: action {properties}]
     IPsecReply = action {properties} [: action {properties}]
     IPsecTunnel = action {properties} [: action {properties}]

You must include an Address section in a home agent's configuration file for each mobility agent that is supported.

If Mobile IP message authentication is required between the foreign agent and the home agent, you must include an Address section for each peer with which an agent needs to communicate.

The SPI value that you configure must represent an SPI section that is present in the configuration file.

The following table describes the labels and values that you can use in the Address section for a mobility agent.

Table 29-6 Address Section Labels and Values (Mobility Agent)

Label

Value

Description

Type

agent

Specifies that the entry is for a mobility agent

SPI

n

Specifies the SPI value for the associated entry

IPsecRequest

apply or permit (see following note)

IPsec properties to invoke for registration requests to and from this mobility agent peer

IPsecReply

apply or permit (see following note)

IPsec properties to invoke for registration replies to and from this mobility agent peer

IPsecTunnel

apply or permit (see following note)

IPsec properties to invoke for tunnel traffic to and from this mobility agent peer


Note - The apply values correspond to outbound datagrams. The permit values correspond to inbound datagrams. Therefore, IPsecRequest apply values and IPsecReply permit values are used by the foreign agent to send and receive registration datagrams. The IPsecRequest permit values and the IPsecReply apply values are used by the home agent to receive and send registration datagrams.


Previous Previous     Contents     Index     Next Next
Company Info Contact Terms of Use Privacy Copyright 1994-2007 Sun Microsystems, Inc.