dynfad.conf

mobile ip 在linux下的一种实现

# $Id: dynfad.conf,v 1.64 2001/10/20 13:36:07 jm Exp $
# Foreign Agent configuration file
#
# Dynamic hierarchial IP tunnel
# Copyright (C) 1998-2001, Dynamics group
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation. See README and COPYING for
# more details.
#
#######################################################################
#
# NOTE! 
#	This is an example configuration file designed to give
#	perspective to the system configuration AND to provide
#	a basis for a working simple test environment.
#	The values of some of the parameters may not be the
#	same as the daemon's defaults, so do not get confused.
#
########################################################################
#
# Interfaces to be used for Mobile IP services
# interface: name of the interface, e.g. eth0
# type:
#    1 = both upper and lower direction
#    2 = only upper direction (to upper FA / HA)
#    3 = only lower direction (to lower FA / MN)
#    Note: Only one interface can be used for upper direction, but
#    multiple interfaces can be used for lower direction.
# agentadv:
#    0 = do not send agent advertisements without agent solicitation
#    1 = send agent advertisements regularly
#   -1 = do not send any (even solicited) agent advertisements
# interval: number of seconds to wait between two agentadvs
#           (if allowed for this interface)
# force_IP_addr: local address to be forced for this interface
#		 (can be used to select one of the multiple virtual
#		 addresses); if not entered, the primary address of the
#		 interface is used
#
# In the example below, interface "eth0" can be used for both upper and lower
# directions, Agent Advertisements are sent regularly with the interval
# of 30 s, and the primary address of the eth0 interface is used. 
# Correspondingly, interface "eth1" would allow only lower direction
# connections (connections with MNs or lower FAs) with periodical 
# Agent Advertisements with an interval of 20 s, and a specific IP address
# would be forced to the interface "eth1".
#
# The last entry that is of type upper (or both upper and lower), is
# used to send messages in the upper direction.
#  
INTERFACES_BEGIN
# interface  type  agentadv  interval  force_IP_addr
eth0         1	   1         30
#eth1        3     1         20	       192.168.240.2
INTERFACES_END
########################################################################

# Network Access Identifier (NAI) of this FA
# Unique identifier for this FA. A macro [interface] can be used to get
# the hardware address of an interface in dot-separated format.
NetworkAccessIdentifier "[eth0]@example.com"

# Address of the highest FA
# This address is used in the communication with the HA and it is advertised
# in agent advertisement messages. This should be from the "public side"
# interface of the FA (i.e., the interface that is toward HA or the default
# gateway).
# If this FA is the highest FA for some organization, use its address here.
# In this case, the address would most probably be from the interface that
# is configured for upper direction (type 1 or 2 in the interface list above).
HighestFAIPAddress 192.168.240.1

# Highest FA public key extension hash
# This hash code is used to protect the public key from active
# man-in-the-middle style attacks. Its use is optional, but recommended. If
# this hash is configured, the FA broadcasts it in the agent advertisements
# and the MNs send it in their registration requests to the HA (protected with
# MN-HA authentication extension).
# The hash code is printed by the rsakeygen utility and if used, it must be
# the hash of this organization's highest FA.
# HighestFAPubKeyHash 78439F9EA1FE32EDD8CE2028062DC96A

# Address of the upper FA
# This is the address of the FA to which the requests are forwarded
# on they way to the Home Agent.
# If this is the same as the FA's own IP address,
# then this FA is really the highest FA and the requests are forwarded
# directly to the Home Agent.
UpperFAIPAddress 192.168.240.1

# HighestFA < TRUE | FALSE >
# Whether this FA is the highest FA (i.e. it does not have any upper FAs and
# it communicates directly with the Home Agents).
HighestFA TRUE

# UDP Port that this FA listens to for signaling messages
UDPPort 434
# The port to be used in signaling with the upper FA
UpperFAUDPPort 434
# The port to be used in signaling with the HA
HAUDPPort 434

# RFC 2344 style tunnel hijacking protection requires that the MN uses TTL
# value 255 on all registration request messages and the FAs check this.
# Since RFC 2002 compliant MN implementations do not necessarily set the TTL
# to 255, this may limit the access of those MNs. This option can be used to
# change the checking of the TTL field in the IP header.
# 0 = no TTL checking (i.e. accept any value)
# 1 = check the TTL only in registration requests that ask for reverse
#     tunneling (i.e. the MN should be RFC 2344 compliant and use the TTL 255)
# 2 = check the TTL on every registration requests (this might deny the access
#     of some MN implementations)
RegistrationTTLCheck 1

# Socket priority for signaling sockets (UDP) can be set with SO_PRIORITY to
# allow easier QoS configuration. If this argument is set, the given value is
# used as a priority for the signaling socket. E.g. CBQ class can be used to
# make sure that signaling is not disturbed by other traffic on a congested
# link.
# This feature is still undocumented and can be left commented.
#
# SocketPriority 1

# Tunnel interface name (FA will use names line TUNL0, TUNL1, ...)
TunnelDevice "TUNL"

# The start of the range of routing tables that this FA can use.
# Linux kernel 2.2.X has 256 routing tables (0 .. 255), but 0, 253, 254, and
# 255
# are reserved.
RoutingTableStart 1
# The end of the range of routing tables that this FA can use. Defaults to 252.
RoutingTableEnd 252
# Available routing table range defaults to 1-252.

###############################################################################
# FA must keep track of the authorized network addresses.
# This list can be used to limit the allowed IP addresses from which the
# registration requests can be sent (lower FAs or MNs).
#
# To allow classless subnetting, also the netmask is included in the list.
# AUTHORIZEDNETWORKS is a list that has a pair
# [ networkaddress ]/[ netmask ]
# on each row separated by the line breaks.
# Here is an example: 
#
#AUTHORIZEDNETWORKS_BEGIN
# [ networkaddress ]/[ netmask ]
#192.168.240.0/255.255.255.0
#192.168.240.0/24
#AUTHORIZEDNETWORKS_END
#
# This does not limit the connections by IP address
AUTHORIZEDNETWORKS_BEGIN
# [ networkaddress ]/[ netmask ]
0.0.0.0/0.0.0.0
AUTHORIZEDNETWORKS_END
#
# Whether or not this FA allows MNs to be connected directly (i.e. whether it
# can be the lowest FA)
AllowMobileNodes TRUE
#
###############################################################################
# A Foreign Agent may have optional security associations with other nodes
# (FA, HA, MN).
#
# If the security association exists the session key can be
# encrypted with the help of shared secret and thus man-in-the-middle
# style attacks can be prevented. If no security association is set
# for a certain Foreign Agent - Foreign Agent pair, public key encryption
# (RSA) is used.
#
# The following list contains the shared secrets indexed by SPI (and
# IP address of the other node).
#
# The node field specifies the type of the node. It used to select the
# approriate authentication extension type.
#    1 = FA
#    2 = HA
#    3 = MN
# The algorithm field specifies the method used for authentication and
# key distribution:
#    1: MD5/prefix+suffix (a.k.a. keyed-MD5) [RFC 2002]
#    4: HMAC-MD5 [RFC 2104]
#    5: SHA-1 [FIPS 180-1]
#    6: HMAC-SHA1 [RFC 2104]
# Note! MD5/prefix+suffix has known weaknesses and use of HMAC-MD5 is
# recommented. MD5/prefix+suffix algorithm is for backwards compatability with
# older versions that do not support more secure HMAC-MD5.
#
# Shared secret can be given as a HEX code string, i.e. two characters (0-F)
# correspond to one octet. The shared secret can also be given as a character
# string (e.g. "ABCDE" corresponds to 4142434445).
# Note: RFC 2002 specifies that the default key size is 128 bits (i.e.
# 16 bytes or 32 hex 'characters'). Dynamics supports also other key lengths.
#
FA_SECURITY_BEGIN
# SPI		Node IP		Node	Alg.	Shared Secret
#2001		192.168.0.1	1	4	0123456789ABCDEF
#2002		192.168.0.2	2	4	"eslkfj89jr3hduh3R!as"
FA_SECURITY_END
#
# RSA key file
FAKeyFile "/etc/dynfad.key"


# Mobile IPv4 Challenge/Response (RFC 3012)

# Dynamics supports Mobile IPv4 Challenge/Response protocol as an optional
# addition to the Mobile IP registration. This is not used in a default setup
# because the extensions used for challenges will prevent MNs that do not
# support this addition from using the FA at all.
EnableChallengeResponse FALSE

# Number of last advertised challenges that will be accepted (default value
# given in RFC 3012: 2).
ChallengeWindow 2

# Length of the challenge to be used (in bytes; 0 .. 255)
ChallengeLength 4

# Whether the FA requires the challenge to be present in every registration
# request (if not present, request will be denied with MISSING_CHALLENGE
# error). If 'EnableChallengeResponse' is TRUE, the challenge is required from
# MNs which do not have a security association with the FA. With
# 'RequireChallenge' TRUE, the challenge is required also from the MNs that
# have the security association.
RequireChallenge FALSE

# Whether the FA adds new challenge to all the registration replies.
ChallengeInRegReply TRUE


# AAA Keys for Mobile IP (draft-ietf-mobile-aaa-key-07.txt)

# The FA can be configured to deny registration replies that do not have
# an Unsolicited MN-FA Key Material From AAA extension for an MN that does
# not have a security association with the FA.
RequireMNFASecAssoc FALSE

###############################################################################

# The maximum number of tunnels (confirmed bindings) going through this FA
# The default value for MaxBindings is 20.
# If more than MaxBindings Mobile Nodes try to register, the new registrations
# are refused.
MaxBindings 100

# The maximum number of pending registration requests (unconfirmed bindings)
# the FA is willing to maintain (typically 5 according to rfc2002-bis draft).
# Additional registrations will be rejected until at least one of the pending
# registrations has been completed or has timed out.
# Zero means no limit on pending registration requests.
MaxPending 5

# The number of seconds after which pending registration requests MAY be
# deleted. Zero means do not force pending registration request deletion
# before their requested lifetime has expired.
DeletePendingAfter 7

# EnableFADecapsulation < TRUE | FALSE >
EnableFADecapsulation TRUE

# Triangle tunnel means that the packages to MNs are sent via the HA, but
# packages from MN are routed directly (i.e. FA use normal IP routing).
# EnableTriangleTunneling < TRUE | FALSE >
EnableTriangleTunneling TRUE

# Reverse tunnel means bi-directional tunneling in which both the packages
# from and to MN are send via HA
# EnableReverseTunneling < TRUE | FALSE >
EnableReverseTunneling TRUE

# Force FA to use reverse tunneling even if triangle tunneling is requested.
ForceReverseTunneling FALSE

# FA may require registration even from those MNs which have acquired a
# co-located care-of address. This option selects whether the agent
# advertisements messages have 'Registration required' flag or not
RegistrationRequired TRUE

# DefaultTunnelLifetime is the maximum lifetime advertised for this FA.
# This should not be greater than any of the maximum lifetimes configured
# for upper FAs (i.e. best to use the same maximum for whole FA organization).
# The lifetime is defined in seconds, default value is 400.
# The request timer will be limited with this value.
# Special case: 65535 (or more) seconds mean unlimited time (the binding will
# not expire)
FADefaultTunnelLifetime 600

# FA uses a packet socket for raw L2 header access. When sending registration
# messages, this is only used between the lowest FA and the MN. Current code
# does not implement fragmentation and packets larget than the used MTU are
# thus probably dropped. FA can be configured to not use packet socket when
# sending frames, but this may require broadcast ARP for MN's home address
# in the foreign network. This is against RFC 2002, so it should be used only
# if the packet socket does not work.
# Possible values for PacketSocketMode:
#    0 = use packet socket when sending registration replies to MN (default)
#    1 = do not use packet socket at all for sending registration messages
PacketSocketMode 0

# The log messages are written through syslog service. The facility to be
# used defaults to LOG_LOCAL0, but it can be set with this parameter
# to any of the possible facilities (LOG_AUTHPRIV, LOG_DAEMON, and so on).
# The processing of log messages is defined in /etc/syslog.conf file.
SyslogFacility LOG_DAEMON

# Foreign Agents use unix domain sockets to communicate through their API
# interfaces.
# The group and owner must be names as strings, no groupIDs or userIDs are
# allowed. The file permissions are set in octal values like in chmod(1).
# The configuration parameters of the two API sockets are as follows:
FAAPIReadSocketPath "/var/run/dynamics_fa_read"
FAAPIReadSocketGroup "root"
FAAPIReadSocketOwner "root"
FAAPIReadSocketPermissions 0766
#
FAAPIAdminSocketPath "/var/run/dynamics_fa_admin"
FAAPIAdminSocketGroup "root"
FAAPIAdminSocketOwner "root"
FAAPIAdminSocketPermissions 0700
#
# Every configuration file must end with the keyword 'END'.
END