Page -> Foreign Agent | Vistas : Página Discusión Ver fuente Historial |
De DIT-CDC
Revisión a fecha de 09:37 28 feb 2007; Gabi (Discusión | contribuciones)
# : 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 1 #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 "simba_fa" # 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). # If you don't want to configure FA hierarchies, write here the FA IP address HighestFAIPAddress 193.146.185.73 # 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 193.146.185.73 # 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 #It's recommended to keep these values for compatibility with other RFC 2002 implementations. # 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