IKEv2 Mobility and Multihoming U. Schilcher (mobike) Universitaet Klagenfurt Internet-Draft H. Tschofenig Expires: September 6, 2006 F. Muenz Siemens AG S. Sugimoto Ericsson March 5, 2006 Application Programming Interface to a Trigger Database for MOBIKE draft-schilcher-mobike-trigger-api-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract MOBIKE is a protocol which adds mobility and multihome support for IKEv2. MOBIKE peers continuously exchange a list of available IP addresses each other. A MOBIKE peer should have some information about the status of each address and interface in order to execute Schilcher, et al. Expires September 6, 2006 [Page 1] Internet-Draft API to a Trigger Database for MOBIKE March 2006 the respective actions. Examples may comprise switching from one address or interface to another. This information, which will be referred as trigger, is distributed over a number of protocol daemons at an end host. To make this information available to a MOBIKE daemon, it is necessary to store it centrally at the host (called trigger database) and to enable the protocols to insert the triggers and to allow MOBIKE to obtain timely information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Trigger Database and MIH . . . . . . . . . . . . . . . . . . . 6 4. Trigger Classification . . . . . . . . . . . . . . . . . . . . 8 5. API for the Trigger Database . . . . . . . . . . . . . . . . . 10 6. Supported Message Types . . . . . . . . . . . . . . . . . . . 12 7. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Schilcher, et al. Expires September 6, 2006 [Page 2] Internet-Draft API to a Trigger Database for MOBIKE March 2006 1. Introduction When a MOBIKE daemon [1] is started it first has to build a set of all available addresses (or a subset of them for policy reasons; see [4]) before communicating with another peer. From these addresses, it has to select one of the addresses as the preferred address that will be used as the source address in the communication with the MOBIKE peer. This address set together with the preferred address may change during operation because of several reasons, e.g. an interface is disconnected, a handover between two different link layer technologies takes place or the communication path becomes unavailable due to router failure. Many of the events, which cause the change of the address set, are out of the scope of the MOBIKE protocol itself but need an interaction with other protocols daemons locally at the end host. In order to make MOBIKE working properly, it is really important to know about the status of the available addresses for making reasonable decisions. A number of other protocols running on the end host might have various information necessary to determine whether to switch from one preferred address to another or whether it is necessary to modify the peer address set. An example is the IEEE 802.21 Media Independent Handover (MIH) standard [5], which is currently under development. The MIH is defined as a shim layer in the mobility-management protocol stack of both, the mobile node and the network elements, that provide mobility support. The MIH Function provides abstracted services to higher layers about the status and performance of any link layer technology. To benefit from this information on higher layers, however, the MIH services must be combined with information from upper layers in order to facilitate a basis for decisions above network layer. In this document, we therefore suggest to define an API that allows protocol daemons to insert information (triggers) about addresses and interfaces into a "database" that can later be made available to the MOBIKE daemon (or other protocols). Although, there have been some mechanisms [6][7] that can fulfill some of these requirements, we still need a flexible framework that can handle asynchronous event that takes place at L3 or below, including MIH events. The API will provide similar services to the MOBIKE daemon like MIH does for layer 3 and above. It is based on the BSD routing socket API in a similar fashion as PF_KEY [2] extends the same API for generic key management usage. Schilcher, et al. Expires September 6, 2006 [Page 3] Internet-Draft API to a Trigger Database for MOBIKE March 2006 This document therefore heavily focuses on the functionality offered by the PF_KEY specification and uses the MIH Function as an example for retrieving necessary information for a decision making process. Please note that the authors use the term 'database' in a symbolic way. It is a container for storing information about events. Information about the status of interfaces and addresses might not even be stored directly in this database and could well be implemented using a collection of pointers to the respective information. Schilcher, et al. Expires September 6, 2006 [Page 4] Internet-Draft API to a Trigger Database for MOBIKE March 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. Additionally, the following terms are introduced: o Trigger: Information which is relevant for MOBIKE about an address. o Trigger Database (TDB): Collection of triggers which can be accessed via the API defined in this document. o Media Independent Handover (MIH): Described in IEEE draft 802.21 [5] which is currently under development. The MIH Function provides abstracted services to higher layers about the status and performance of any link layer technology. Schilcher, et al. Expires September 6, 2006 [Page 5] Internet-Draft API to a Trigger Database for MOBIKE March 2006 3. Trigger Database and MIH The following section should give a brief overview for the interaction of Media Independent Handover (MIH) with Trigger Database (TDB) and MOBIKE daemon. The services of MIH are used e.g. for compiling relevant information about interface performance, which is then signalled through the Trigger Database to the MOBIKE daemon. Based on this data, the MOBIKE daemon may select a new preferred address or continues using the current one. +--------------------------------------+ | MOBIKE daemon | | +-------------------+ | | | PF_TRIGGER socket | | | +--------------+----+ | | ^ | | +-----------|-----------|--------------+ | | | | TDB TDB Events Commands | | | v +-----------+--------------------------+ | Trigger Database (TDB) | | (Layer 3 an above) | +--------------------------------------+ ^ | ^ | | | MIH MIH Information Events Commands Service | | | | v v +--------------------------------------+ | Media Independent Handover Function | +--------------------------------------+ ^ | ^ | | | Link Link Information Events Commands Service | | | | v v +--------------------------------------+ | Lower Layers (Layer 2 and below) | +--------------------------------------+ Schilcher, et al. Expires September 6, 2006 [Page 6] Internet-Draft API to a Trigger Database for MOBIKE March 2006 To receive event notifications from the MIH, the Trigger Database must perform two steps: Capability discovery: While the MIH provides many services, not all of them may be supported on a given platform. For learning, which of them are actually supported, the Trigger Database must query the MIH with a "MIH_Capability_Discover.request". The response, a "MIH_Capability_Discover.response" message will then indicate with a bit mask which services are supported. Alternatives and solutions for not supported but required services is done in a future version of this draft. Service registration: Now knowing the supported services, the Trigger Database must register to the services it is interested in with a "MIH_Event_Register.request" message. To confirm registration, the MIH answers with a "MIH_Event_Register.confirm" message and notifies the Trigger Database in case of status change of interfaces. Schilcher, et al. Expires September 6, 2006 [Page 7] Internet-Draft API to a Trigger Database for MOBIKE March 2006 4. Trigger Classification Many different events may cause a change in the address set used by MOBIKE (see [4]). These events can be issued by many different protocols running in kernel or user space. Since the reaction (if any) on a given event depends on the type of the event, a classification of these events is necessary. As an example, we define the following triggers in this document: Trigger type Value Description ---------------------------+-------+------------------------------- TDB_TTYPE_IF_ADDED | 1 | New interface added TDB_TTYPE_IF_REMOVED | 2 | Interface removed TDB_TTYPE_IF_REMOVEDSOON | 3 | Interface is expected to be | | removed soon TDB_TTYPE_IF_ADDRADDED | 4 | New address added to interface TDB_TTYPE_IF_ADDRREMOVED | 5 | Address removed from interface TDB_TTYPE_IF_ADDRCHANGED | 6 | Interface has changed one of its | | addresses (e.g. new DHCP lease) TDB_TTYPE_TUNNEL_ADDED | 7 | IPSec tunnel was established TDB_TTYPE_TUNNEL_CHANGED | 8 | IPSec tunnel conf. changed TDB_TTYPE_TUNNEL_REMOVED | 9 | IPSec tunnel was removed TDB_TTYPE_CONN_ESTABLISHED | 10 | e.g. dial-in network | | has connected TDB_TTYPE_CONN_LOST | 11 | connection to network lost TDB_TTYPE_DEST_UNREACHABLE | 12 | e.g. ICMP packet received TDB_TTYPE_MAX | 13 | Maximum value for trigger types The types TDB_TTYPE_TUNNEL_ADDED, TDB_TTYPE_TUNNEL_CHANGED and TDB_TTYPE_TUNNEL_REMOVED are inspired by [8]. Any listed trigger types will be signalled using the "tdb_trigger" message structure described in Section 7 Details about the supported message types and their formats can be found below: TDB_TTYPE_IF_ADDED: This message is signalled if a new interface comes up and directly refers to the "Link_Up.indication" event notification of the MIH Function. TDB_TTYPE_IF_REMOVED: This message is signalled if an interface is going down and directly refers to the "Link_Down.indication" event notification Schilcher, et al. Expires September 6, 2006 [Page 8] Internet-Draft API to a Trigger Database for MOBIKE March 2006 of the MIH Function. TDB_TTYPE_IF_REMOVEDSOON: This message is signalled if an interface is expected (predicted) to go down within a certain time interval and directly refers to the "Link_Going_Down.indication" event notification of the MIH Function. A future version of this document will add more triggers and a more detailed description of them. Schilcher, et al. Expires September 6, 2006 [Page 9] Internet-Draft API to a Trigger Database for MOBIKE March 2006 5. API for the Trigger Database To access the trigger database, an API is defined. For that purpose the new network protocol family ID PF_TRIGGER has to be defined. The operation of the API is analogue to the PF_KEY interface (see [2]). To access the API, a socket of the family PF_TRIGGER has to be created. To communicate with the Trigger Database, messages are sent and received through the socket with the send() and recv() functions. Any other functions like bind(), connect(), etc. are not supported and MUST NOT have any effects on a socket of the PF_TRIGGER family. The following exhibits a sample socket creation: int s = socket(PF_TRIGGER, SOCK_RAW, PF_TRIGGER); The format of the messages is the following: Each message starts with a fixed header. Appended to this header, there are some payloads depending on the type of the message. The available message types are described in Section 6. Each time when a message is sent to the Trigger Database, it will respond with a message of the same type. This response contains the same payloads as transmitted to the Trigger Database, only some additional information MAY be included (e.g., the Trigger Database assigns an id to each trigger). The normal operation works in the following way: A MOBIKE implementation, which wants to be informed about changes in the Trigger Database, registers itself to the Trigger Database by sending a TDB_REGISTER message. If a protocol daemon wants to add, delete or modify an existing trigger it sends a TDB_ADD, TDB_DELETE or TDB_MODIFY message respectively to the Trigger Database including information that is important to add, delete or modify the trigger. The Trigger Database acknowledges this message with a TDB_ADD, TDB_DELETE or TDB_MODIFY response to the network protocol and with a TDB_NOTIFY message to the registered MOBIKE implementation. This notify message contains information about the newly added, deleted or modified trigger including its ID. All available information about a trigger can be requested with a TDB_GET message. If a MOBIKE implementation no longer wants to receive notifications for changes to the Trigger Database, it sends a TDB_DEREGISTER message. Schilcher, et al. Expires September 6, 2006 [Page 10] Internet-Draft API to a Trigger Database for MOBIKE March 2006 In a future version of this document, we will try to add some information about scenarios to better illustrate the interaction. Schilcher, et al. Expires September 6, 2006 [Page 11] Internet-Draft API to a Trigger Database for MOBIKE March 2006 6. Supported Message Types Several different message types can be sent to the Trigger Database using a PF_TRIGGER socket. The message type is indicated by the tdb_header_msgtype field that is part of the generic message header (see Section 7) and can be one of the following values: Message type Value Description ------------------+---------+------------------------------ TDB_ADD | 1 | Add a trigger to the | | Trigger Database TDB_GET | 2 | Get information about an | | existing trigger. TDB_DELETE | 3 | Delete a trigger from the | | Trigger Database TDB_REGISTER | 4 | Registers an application | | to receive messages for | | each new trigger added. TDB_DEREGISTER | 5 | Deregisters an application | | from receiving messages for | | each new trigger added. TDB_NOTIFY | 6 | A new trigger has been | | added, deleted or updated. TDB_MODIFY | 7 | Modify a trigger in the | | Trigger Database TDB_DUMP | 8 | Dump all Trigger Database | | entries TDB_FLUSH | 9 | Delete all Trigger Database | | entries TDB_MAX | 10 | Generic maximum for message | | types Each message type requires different payloads to be appended. Each payload starts with a generic payload header followed by payload specific data. The generic header has the following structure: struct tdb_payload { uint16_t tdb_payload_len; uint16_t tdb_payload_type; } __attribute__( ( packed ) ); /* sizeof( struct tdb_payload ) == 4 */ The tdb_payload_len field contains the length of the payload divided by 8. The type of the payload is determined by the tdb_payload_type field, which contains one of the following values: Schilcher, et al. Expires September 6, 2006 [Page 12] Internet-Draft API to a Trigger Database for MOBIKE March 2006 Payload type Value Description ---------------------------+---------+------------------------------- TDB_PT_INTERFACE | 1 | Information about an interface TDB_PT_ADDRESS | 2 | The IP address of an interface TDB_PT_TRIGGER | 3 | Trigger id, type, etc. Details about the supported message types and their formats can be found below: TDB_ADD: If an application or network protocol wants to add a new trigger, it sends a TDB_ADD message to the Trigger Database. The new trigger is stored in the Trigger Database and a corresponding TDB_NOTIFY message that indicates that a new trigger has been added is sent to all registered applications. The format of the message is: The TRIGGER payload indicates the type of the trigger and also includes some trigger specific data. The INTERFACE payload is needed to select the appropriate physical interface, the new trigger is related to. For many triggers, an additional address payload is required. It contains, for example, the new address for a TDB_TTYPE_IF_ADDRCHANGED trigger. The response from the Trigger Database contains the same information as the request: TDB_DELETE: A trigger, which is stored inside the Trigger Database, can be deleted using the TDB_DELETE payload. In the request the only information, which has to be specified is the id of the trigger, which is stored in 'TRIGGER(*)'. A corresponding TDB_NOTIFY message that indicates that a trigger has been deleted is sent to all registered applications. The format of the message is: Schilcher, et al. Expires September 6, 2006 [Page 13] Internet-Draft API to a Trigger Database for MOBIKE March 2006 The Trigger Database responds with a message with the following format: In the response, the TRIGGER payload has all fields filled with the correct values. TDB_GET: The TDB_GET message is used to request all available information of a specified trigger. In the request the only information, which has to be specified is the id of the trigger, which is stored in 'TRIGGER(*)'. The format of the message is: The Trigger Database responds with a message of the following format: In the response a fully initialized TRIGGER payload is present. Additionally, INTERFACE payload is present as well as and an optional an ADDRESS payload, if an address is available for the specified trigger. TDB_REGISTER: An application, which is interested in each new trigger, can register itself to the Trigger Database. After the application has registered, it receives a message each time a new trigger has been added to the database. The format of the message is:
No additional payload has to be added. The Trigger Database responds with a message of the same type and with the same content, i.e. its format is:
Schilcher, et al. Expires September 6, 2006 [Page 14] Internet-Draft API to a Trigger Database for MOBIKE March 2006 TDB_DEREGISTER: An application, which is no longer interested in receiving notifications about trigger changes, can de-register itself from the Trigger Database. The format of the message is:
No additional payload has to be added. The Trigger Database responds with a message of the same type and with the same content, i.e. its format is:
TDB_NOTIFY An application that has registered itself to get informed about the new triggers or updates to these triggers, receives a TDB_NOTIFY message. The format of the message is the same as for a TDB_ADD message. The only difference is that some field are filled by the Trigger Database before sending the TDB_NOTIFY message. The format of the message is: Since this message is sent by the Trigger Database itself, a registered application MUST NOT respond to it. TDB_MODIFY: If an application or a network protocol wants to modify a trigger (because its status has changed), it sends a TDB_MODIFY message to the Trigger Database. The new trigger is stored and a corresponding TDB_NOTIFY message that indicates that an existing trigger has been modified is sent to all registered applications. The format of the message is: The TRIGGER payload indicates the type of the trigger and also includes some trigger specific data. The response from the Trigger Database contains the same information as the request: Schilcher, et al. Expires September 6, 2006 [Page 15] Internet-Draft API to a Trigger Database for MOBIKE March 2006 TDB_DUMP: An application, that wants to learn all currently available triggers should send a TDB_DUMP message. Since a TDB_GET message requires a specific trigger id for retrieval, applications which to not know all trigger IDs depend on this message class for learning all unknown triggers. The format of the message is:
The Trigger Database will respond with all currently available triggers entries by serially sending the following message: TDB_FLUSH: For deleting all entries in a Trigger Database, the TDB_FLUSH message is used. Since the TDB_GET message requires a specific trigger id for deletion, reliable cleaning of a Trigger Database can be done with this message. The format of the message is:
The Trigger Database will respond with the following message:
Schilcher, et al. Expires September 6, 2006 [Page 16] Internet-Draft API to a Trigger Database for MOBIKE March 2006 7. Payload Format HEADER: Each message starts with the fixed header. It contains general information about the message and determines, which payloads have to be included in it. It has the following format: struct tdb_header { uint8_t tdb_header_version; uint8_t tdb_header_msgtype; uint8_t tdb_header_errno; uint8_t tdb_header_reserved1; uint16_t tdb_header_msglen; uint16_t tdb_header_reserved2; uint32_t tdb_header_seq; uint32_t tdb_header_pid; } __attribute__( ( packed ) ); /* sizeof( struct tdb_header ) == 16 */ The fields of this structure contain the following values: tdb_header_version: The version of the used PF_TRIGGER interface. This document specifies this API in version 1. tdb_header_msgtype: This field contains the type of the message. All possible values are listed in the table in Section 6. tdb_header_errno: If an error occurred while processing a request, the response will only include the message header without any payloads. The type of the error is indicated by the value in this field. The values are taken from the error number specification of the operating system (e.g. the errno.h file). tdb_header_msglen: The length of the message divided by 8 is stored into this field. tdb_header_seq: This field contains the number of the last message sent incremented by 1. Schilcher, et al. Expires September 6, 2006 [Page 17] Internet-Draft API to a Trigger Database for MOBIKE March 2006 tdb_header_pid: The process id of the program sending the message. If the message is generated inside the kernel, this value is set to zero. INTERFACE: The INTERFACE payload is used to provide all needed information about an active network interface. The format of the INTERFACE payload is the following: struct tdb_interface { uint16_t tdb_interface_len; uint16_t tdb_interface_pltype; uint32_t tdb_interface_selector; uint32_t tdb_interface_type; uint32_t tdb_interface_bandwidth; uint32_t tdb_interface_quality; uint32_t tdb_interface_reserved; } __attribute__( ( packed ) ); /* sizeof( struct tdb_interface ) == 16 */ This fields contain the following values: tdb_interface_len: This field contains the length of the payload divided by 8. tdb_interface_pltype: This field contains the value TDB_PT_INTERFACE. tdb_interface_selector: The tdb_interface_selector field stores interface enumeration information for unique identification (IF #0, #1, #2, ...). When a new interface comes up, this value should be set by the kernel. tdb_interface_type: Classification of an interface, for instance fixed or wireless network link. The MIH Function provides this information by issuing a "MIH_Poll.request" from the Trigger Database, before creating any event notification destined for the MOBIKE daemon. Schilcher, et al. Expires September 6, 2006 [Page 18] Internet-Draft API to a Trigger Database for MOBIKE March 2006 tdb_interface_bandwidth: Information about the maximum bandwidth of an interface. The MIH Function provides this information by issuing a "MIH_Poll.request" from the Trigger Database, before creating any event notification destined for the MOBIKE daemon. tdb_interface_quality: Information about current connection quality of an interface. The MIH Function provides this information by issuing a "MIH_Poll.request" from the Trigger Database, before creating any event notification destined for the MOBIKE daemon. tdb_interface_reserved: This field is reserved for future use and MUST be set to zero. Further information about an interface might be necessary. Especially asymmetric link connectivity/availability in case of wireless connections might be relevant. This is left for future investigation. ADDRESS: The ADDRESS payload is used to provide the IP address of an interface to the Trigger Database or registered application. This information is important for most triggers. But it might be possible that there are trigger types which do not need an ADDRESS payload. The format of the ADDRESS payload is: struct tdb_address { uint16_t tdb_address_len; uint16_t tdb_address_pltype; uint8_t tdb_address_proto; uint8_t tdb_address_prefixlen; uint16_t tdb_address_reserved; } __attribute__( ( packed ) ); /* sizeof( struct tdb_address ) == 8 */ /* followed by some form of struct sockaddr */ Information about IP address and probably ports is provided by a sockaddr structure which is attached to the tdb_address structure. A sockaddr structure is capable of storing both a IPv4 and IPv6 Schilcher, et al. Expires September 6, 2006 [Page 19] Internet-Draft API to a Trigger Database for MOBIKE March 2006 address. The fields of the tdb_address structure contains the following values: tdb_address_len: This field contains the length of the payload including the sockaddr structure divided by 8. tdb_address_pltype: The tdb_address_pltype field contains the value TDB_PT_ADDRESS. tdb_address_proto: The tdb_address_proto field is normally set to zero. However, if is are set in the attached sockaddr needed, then the field SHOULD be set to the protocol number of the upper layer protocol. (e.g. TCP or UDP). This functionality may become relevant for signalling IPSec related information (e.g. tunnel changes) tdb_address_prefixlen: This field contains the prefix length of the address, which might be useful to key management applications, which employ it in access control decisions. If the tdb_address_prefixlen is non-zero the address has a prefix. tdb_address_reserved: The tdb_address_reserved field is reserved for future use and MUST be set to zero. TRIGGER: The TRIGGER payload is used to provide all needed information about a trigger itself, e.g. the trigger type, an id, etc. The notation TRIGGER(*) indicates that only the id field is used to identify the trigger and all other fields SHOULD be set to zero. The format of the TRIGGER payload is the following: struct tdb_trigger { uint16_t tdb_trigger_len; uint16_t tdb_trigger_pltype; uint16_t tdb_trigger_type; uint16_t tdb_trigger_reserved1; uint32_t tdb_trigger_id; uint32_t tdb_trigger_reserved2; } __attribute__( ( packed ) ); /* sizeof( struct tdb_trigger ) == 16 */ Schilcher, et al. Expires September 6, 2006 [Page 20] Internet-Draft API to a Trigger Database for MOBIKE March 2006 This fields contain the following values: tdb_address_len: This field contains the length of the payload divided by 8. tdb_address_pltype: This field contains the value TDB_PT_TRIGGER. tdb_address_type: The type of the trigger is stored into this field. All possible values are listed in the table in section Section 4. tdb_address_id: The id of a trigger is assigned by the Trigger Database itself. In the message sent by userspace programs, which do not know this value (e.g. for TDB_ADD messages), this value MUST be set to zero. Further information about a trigger might be necessary. This is left for future investigation. Schilcher, et al. Expires September 6, 2006 [Page 21] Internet-Draft API to a Trigger Database for MOBIKE March 2006 8. Applicability Even though this document is intended to give a solution for MOBIKE, the API is generic enough to make information available for other protocols as well. The Next Step In Signaling (NSIS) protocol suite, for example, requires access to up-to-date information about IP addresses, interfaces and interactions with mobility protocols. In order to react on mobility events some sort of interaction between the kernel, various signalling protocols (including Mobile IP, IKE/IPsec, etc.) and the NSIS daemon is required (see [9]). Hence, an NSIS daemon supporting mobility could benefit from a generic interface to meet it's requirements for fast and accurate detection of mobility events, address and interface changes. GIMPS, for example, demands immediate reaction in case of a mobility event (e.g., handover). Monitoring procedures of mobility management protocols like Mobile IP are required to react to these mobility events in an appropriate way. The trigger database and it's API could provide necessary information for detecting such a movement (new interface/IP address available, expiring Mobile IP timers). Schilcher, et al. Expires September 6, 2006 [Page 22] Internet-Draft API to a Trigger Database for MOBIKE March 2006 9. IANA Considerations This document defines an IANA registry for the protocol family PF_TRIGGER. An IANA registry might be needed for the different trigger types (for which examples are provided in Section 4). Schilcher, et al. Expires September 6, 2006 [Page 23] Internet-Draft API to a Trigger Database for MOBIKE March 2006 10. Security Considerations This document describes an API which allows information about IP addresses to be obtained at a local host. A malicious application or protocol daemon could disseminate wrong information. This would make other protocols, such as MOBIKE, believe that the status of a particular address has changed. This will likely lead to unexpected protocol behaviour, such as switching between addresses back-and- forth. Hence, a certain trust has to be placed into the applications and protocol daemons that are allowed to access the database to insert, modify or delete triggers. Access control mechanisms might enforce certain rights to use the API or parts of it. Schilcher, et al. Expires September 6, 2006 [Page 24] Internet-Draft API to a Trigger Database for MOBIKE March 2006 11. Acknowledgments The authors would like to thank Murugaraj Shanmugam, Yu Xinwen, Wolfgang Groeting and Stefan Berg for their comments. Furthermore, the authors would like to thank Emanuel Corthay for pointing them to the IEEE 802.21 draft. Schilcher, et al. Expires September 6, 2006 [Page 25] Internet-Draft API to a Trigger Database for MOBIKE March 2006 12. References 12.1. Normative References [1] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", draft-ietf-mobike-protocol-08 (work in progress), February 2006. [2] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 12.2. Informative References [4] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", draft-ietf-mobike-design-08 (work in progress), March 2006. [5] Rajkumar, Ajay., Williams, Michael., Liu, Xiaoyu., and Vivek. Gupta, "Media Independent Handover Services", IEEE-Draft Draft IEEE Standard for Local and Metropolitan Area Networks / IEEE P802.21/D00.01, July 2005. [6] Sklower, K., "Tree-based Packet Routing Table for Berkeley UNIXProceedings of the Winter 1991 USENIX Conference, Dallas, TX, USENIX Association. 1991. pp. 93-103.", 1991. [7] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, "Linux Netlink as an IP Services Protocol", RFC 3549, July 2003. [8] Sugimoto, S. and F. Dupont, "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-01 (work in progress), August 2005. [9] Lee, S., Jeong, S., Tschofenig, H., Fu, X., and J. Manner, "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signalling-02 (work in progress), July 2005. Schilcher, et al. Expires September 6, 2006 [Page 26] Internet-Draft API to a Trigger Database for MOBIKE March 2006 Authors' Addresses Udo Schilcher Universitaet Klagenfurt Klagenfurt, Carinthia 9020 Austria Email: udo.schilcher@edu.uni-klu.ac.at Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Hannes.Tschofenig@siemens.com Franz Muenz Siemens AG Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Franz.Muenz@thirdwave.de Shinta Sugimoto Ericsson Research Japan Nippon Ericsson K.K. Koraku Mori Building 1-4-14, Koraku, Bunkyo-ku Tokyo 112-0004 Japan Phone: +81 3 3830 2241 Email: shinta.sugimoto@ericsson.com Schilcher, et al. Expires September 6, 2006 [Page 27] Internet-Draft API to a Trigger Database for MOBIKE March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schilcher, et al. Expires September 6, 2006 [Page 28]