idnits 2.17.00 (12 Aug 2021) /tmp/idnits42035/draft-schilcher-mobike-trigger-api-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 690. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 162: '...nnect, etc. are not supported and MUST...' RFC 2119 keyword, line 177: '...onal information MAY be included (e.g....' RFC 2119 keyword, line 342: '...ered application MUST NOT respond to i...' RFC 2119 keyword, line 517: '... then the field SHOULD be set to the ...' RFC 2119 keyword, line 526: '...or future use and MUST be set to zero....' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 18, 2005) is 6150 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'INTERFACE' on line 362 -- Looks like a reference, but probably isn't: 'ADDRESS' on line 362 ** Downref: Normative reference to an Informational RFC: RFC 2367 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: draft-ietf-mobike-design has been published as RFC 4621 == Outdated reference: A later version (-04) exists of draft-sugimoto-mip6-pfkey-migrate-00 == Outdated reference: draft-ietf-nsis-applicability-mobility-signaling has been published as RFC 5980 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IKEv2 Mobility and Multihoming U. Schilcher 3 (mobike) H. Tschofenig 4 Internet-Draft F. Muenz 5 Expires: January 19, 2006 Siemens AG 6 July 18, 2005 8 Application Programming Interface to a Trigger Database for MOBIKE 9 draft-schilcher-mobike-trigger-api-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The purpose of MOBIKE is the creation and maintenance a set of 43 available addresses and provide them to the communication partner. A 44 MOBIKE peer should have some information about the status of each 45 address and interface in order to execute the respective actions. 46 Examples may comprise switching from address or interface to another. 47 This information, which will be referred as trigger, is distributed 48 over a number of protocols daemons at an end host. To make this 49 information available to the MOBIKE daemon it is necessary to store 50 it centrally at the host (called trigger database) and to enable the 51 protocols to insert the triggers and to allow MOBIKE to obtain timely 52 information. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Trigger Classification . . . . . . . . . . . . . . . . . . . 5 59 4. API for the Trigger Database . . . . . . . . . . . . . . . . 6 60 5. Supported Message Types . . . . . . . . . . . . . . . . . . 7 61 6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 12 62 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . 17 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 64 9. Security Considerations . . . . . . . . . . . . . . . . . . 19 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 11.1 Normative References . . . . . . . . . . . . . . . . . . 21 68 11.2 Informative References . . . . . . . . . . . . . . . . . 21 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 70 Intellectual Property and Copyright Statements . . . . . . . 23 72 1. Introduction 74 When a MOBIKE implementation is started first it has to build a set 75 of all available addresses (or a subset of them for policy reasons; 76 see [3]) before communicating with another peer. From these 77 addresses, it has to select one of the addresses as preferred address 78 that will be used as the source address in the communication with the 79 MOBIKE peer. 81 This address set together with the preferred address may change 82 during operation because of several reasons, e.g. an interface could 83 be disconnected or the communication path becomes unavailable due to 84 router failure. Many of the events, which cause the change of the 85 address set, are out of the scope of the MOBIKE protocol itself but 86 need an interaction with other protocols daemons locally at the end 87 host. 89 For MOBIKE to work, it is really important to know about the status 90 of the available addresses in order to make reasonable decisions. A 91 number of other protocols running on the end host might have various 92 information necessary to derive a decision whether to switch from one 93 preferred address to another or whether it is necessary to modify the 94 peer address set. 96 In this document, we therefore suggest to define an API that allows 97 protocol daemons to insert information (triggers) into a "database" 98 that can later be made available to the MOBIKE daemon. The API is 99 based on the BSD routing socket API in a similar fashion as PF_KEY 100 [1] extends the same API for generic key management usage. This 101 document therefore heavily focuses on the functionality offered by 102 the PF_KEY specification. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [2]. 110 Additionally, the following terms are introduced: 112 o Trigger: Information which is relevant for MOBIKE about an 113 address. 115 o Trigger Database (TDB): Collection of triggers which can be 116 accessed via the API defined in this document. 118 3. Trigger Classification 120 Many different events may cause a change in the address set used by 121 MOBIKE (see [3]). These events can be notified by many different 122 protocols running in kernel or user space. Since the reaction (if 123 any) on a given event depends on the type of the event, a 124 classification of these events is necessary. 126 As an example, we define the following triggers in this document: 128 Trigger type Value Description 129 ---------------------------+-------+------------------------------- 130 TDB_TTYPE_IF_ADDED | 1 | New interface added 131 TDB_TTYPE_IF_REMOVED | 2 | Interface removed 132 TDB_TTYPE_IF_ADDRADDED | 3 | New address added to interface 133 TDB_TTYPE_IF_ADDRREMOVED | 4 | Address removed from interface 134 TDB_TTYPE_IF_ADDRCHANGED | 5 | Interface has changed one of its 135 | | addresses (e.g. new DHCP lease) 136 TDB_TTYPE_TUNNEL_ADDED | 6 | IPSec tunnel was established 137 TDB_TTYPE_TUNNEL_CHANGED | 7 | IPSec tunnel conf. changed 138 TDB_TTYPE_TUNNEL_REMOVED | 8 | IPSec tunnel was removed 139 TDB_TTYPE_CONN_ESTABLISHED | 9 | e.g. dial-in network 140 | | has connected 141 TDB_TTYPE_CONN_LOST | 10 | connection to network lost 142 TDB_TTYPE_DEST_UNREACHABLE | 11 | e.g. ICMP packet received 143 TDB_TTYPE_MAX | 12 | Maximum value for trigger types 145 A future version of this document will add more triggers and a more 146 detailed description of them. The types TDB_TTYPE_TUNNEL_ADDED, 147 TDB_TTYPE_TUNNEL_CHANGED and TDB_TTYPE_TUNNEL_REMOVED are inspired by 148 [4]. 150 The above listed trigger types will be signaled using the 151 "tdb_trigger" message structure described in Section 6 153 4. API for the Trigger Database 155 To access the trigger database, an API is defined. For that purpose 156 the new network protocol family ID PF_TRIGGER has to be defined. The 157 operation of the API is analogue to the PF_KEY interface (see [1]). 159 To access the API, a socket of the family PF_TRIGGER has to be 160 created. To communicate with the Trigger Database, messages are sent 161 and received through the socket with the send and recv commands. Any 162 other commands like bind, connect, etc. are not supported and MUST 163 NOT have any effects on a socket of the PF_TRIGGER family. 165 The following exhibits an example socket creation: 167 int s = socket(PF_TRIGGER, SOCK_RAW, PF_TRIGGER); 169 The format of the messages is the following: Each message starts with 170 a fixed header. Appended to this header, there are some payloads 171 depending on the type of the message. The available message types 172 are described in Section 5. 174 Each time when a message is sent to the Trigger Database, it will 175 respond with a message of the same type. This response contains the 176 same payloads as transmitted to the Trigger Database, only some 177 additional information MAY be included (e.g., the Trigger Database 178 assigns an id to each trigger). 180 The normal operation works in the following way: A MOBIKE 181 implementation, which wants to be informed about every new trigger, 182 registers itself to the Trigger Database by sending a TDB_REGISTER 183 message. If a protocol daemon wants to add a new trigger, it sends a 184 TDB_ADD message to the Trigger Database including information that is 185 important for this new trigger. 187 The Trigger Database acknowledges this message with a TDB_ADD 188 response to the network protocol and with a TDB_NOTIFY message to the 189 registered MOBIKE implementation. This notify message contains some 190 information about the new trigger including its id. All information 191 available about the new trigger can be requested with a TDB_GET 192 message. 194 In a future version of this document, we will try to add some 195 information about scenarios to better illustrate the interaction. 197 5. Supported Message Types 199 Several different message types can be sent to the Trigger Database 200 using a PF_TRIGGER socket. The message type is indicated by the 201 tdb_header_msgtype field that is part of the generic message header 202 (see Section 6) and can be one of the following values: 204 Message type Value Description 205 ------------------+---------+------------------------------ 206 TDB_ADD | 1 | Add a trigger to the 207 | | Trigger Database 208 TDB_GET | 2 | Get information about an 209 | | existing trigger. 210 TDB_DELETE | 3 | Delete a trigger from the 211 | | Trigger Database 212 TDB_REGISTER | 4 | Register an application 213 | | to receive a messages for 214 | | each new trigger added. 215 TDB_NOTIFY | 5 | A new trigger has been 216 | | added, deleted or updated. 217 TDB_MODIFY | 6 | Modify a trigger in the 218 | | Trigger Database 219 TDB_DUMP | 7 | Dump all Trigger Database 220 | | entries 221 TDB_FLUSH | 8 | Delete all Trigger Database 222 | | entries 223 TDB_MAX | 9 | Generic maximum for message 224 | | types 226 Each message type requires different payloads to be appended. Each 227 payload starts with a generic payload header followed by payload 228 specific data. The generic header has the following structure: 230 struct tdb_payload { 231 uint16_t tdb_payload_len; 232 uint16_t tdb_payload_type; 233 } __attribute__( ( packed ) ); 234 /* sizeof( struct tdb_payload ) == 4 */ 236 The tdb_payload_len field contains the length of the payload divided 237 by 8. The type of the payload is determined by the tdb_payload_type 238 field, which contains one of the following values: 240 Payload type Value Description 241 ---------------------------+---------+------------------------------- 242 TDB_PT_INTERFACE | 1 | Information about an interface 243 TDB_PT_ADDRESS | 2 | The IP address of an IF 244 TDB_PT_TRIGGER | 3 | Trigger id, type, etc. 246 Details about the supported message types and their formats can be 247 found below: 249 TDB_ADD: 251 If an application or network protocol wants to add a new trigger, 252 it sends a TDB_ADD message to the Trigger Database. The new 253 trigger is stored in the Trigger Database and a corresponding 254 TDB_NOTIFY message that indicates that a new trigger has been 255 added is sent to all registered applications. 257 The format of the message is: 259 261 The TRIGGER payload indicates the type of the trigger and also 262 includes some trigger specific data. The INTERFACE payload is 263 needed to select the appropriate hardware interface, the new 264 trigger is related to. For many triggers, an additional address 265 payload is required. It contains, for example, the new address 266 for a TDB_TTYPE_IF_ADDRCHANGED trigger. 268 The response from the Trigger Database contains the same 269 information as the request: 271 273 TDB_DELETE: 275 A trigger, which is stored inside the Trigger Database, can be 276 deleted using the TDB_DELETE payload. In the request the only 277 information, which has to be specified is the id of the trigger, 278 which is stored in 'TRIGGER(*)'. 280 The format of the message is: 282 284 The Trigger Database responds with a message with the following 285 format: 287 289 In the response, the TRIGGER payload has all fields filled with 290 the correct values. 292 TDB_GET: 294 The TDB_GET message is used to request all available information 295 of a specified trigger. In the request the only information, 296 which has to be specified is the id of the trigger, which is 297 stored in 'TRIGGER(*)'. 299 The format of the message is: 301 303 The Trigger Database responds with a message of the following 304 format: 306 308 In the response a fully initialized TRIGGER payload is present. 309 Additionally, INTERFACE payload is present as well as and an 310 optional an ADDRESS payload, if an address is available for the 311 specified trigger. 313 TDB_REGISTER: 315 An application, which is interested in each new trigger, can 316 register itself to the Trigger Database. After the application 317 has registered, it receives a message each time a new trigger has 318 been added to the database. The format of the message is: 320
322 No additional payload has to be added. The Trigger Database 323 responds with a message of the same type and with the same 324 content, i.e. its format is: 326
328 TDB_NOTIFY 330 An application that has registered itself to get informed about 331 the new triggers or updates to these triggers, receives a 332 TDB_NOTIFY message. The format of the message is the same as for 333 a TDB_ADD message. The only difference is that some field are 334 filled by the Trigger Database before sending the TDB_NOTIFY 335 message. 337 The format of the message is: 339 341 Since this message is sent by the Trigger Database itself, a 342 registered application MUST NOT respond to it. 344 TDB_MODIFY: 346 If an application or a network protocol wants to modify a new 347 trigger (because its status has changed), it sends a TDB_MODIFY 348 message to the Trigger Database. The new trigger is stored and a 349 corresponding TDB_NOTIFY message that indicates that an existing 350 trigger has been modified is sent to all registered applications. 352 The format of the message is: 354 356 The TRIGGER payload indicates the type of the trigger and also 357 includes some trigger specific data. 359 The response from the Trigger Database contains the same 360 information as the request: 362 364 TDB_DUMP: 366 An application, that wants to learn all currently available 367 triggers should send a TDB_DUMP message. Since a TDB_GET message 368 requires a specific trigger id for retrieval, applications which 369 to not know all trigger ids depend on this message class for 370 learning all unknown triggers. The format of the message is: 372
374 The Trigger Database will respond with all currently available 375 triggers entries by serially sending the following message: 377 379 TDB_FLUSH: 381 For deleting all entries in a Trigger Database, the TDB_FLUSH 382 message is used. Since the TDB_GET message requires a specific 383 trigger id for deletion, reliable cleaning of a Trigger Database 384 can be done with this message. The format of the message is: 386
388 The Trigger Database will respond with the following message: 390
392 6. Payload Format 394 HEADER: 396 Each message starts with the fixed header. It contains general 397 information about the message and determines, which payloads have 398 to be included in it. It has the following format: 400 struct tdb_header { 401 uint8_t tdb_header_version; 402 uint8_t tdb_header_msgtype; 403 uint8_t tdb_header_errno; 404 uint8_t tdb_header_reserved1; 405 uint16_t tdb_header_msglen; 406 uint16_t tdb_header_reserved2; 407 uint32_t tdb_header_seq; 408 uint32_t tdb_header_pid; 409 } __attribute__( ( packed ) ); 410 /* sizeof( struct tdb_header ) == 16 */ 412 The fields of this structure contain the following values: 414 tdb_header_version: The version of the used PF_TRIGGER interface. 415 This document specifies this API in version 1. 417 tdb_header_msgtype: This field contains the type of the message. 418 All possible values are listed in the table in Section 5. 420 tdb_header_errno: If an error occurred while processing a request, 421 the response will only include the message header without any 422 payloads. The type of the error is indicated by the value in 423 this field. The values are taken from the error number 424 specification of the operating system (e.g. the errno.h file). 426 tdb_header_msglen: The length of the message divided by 8 is 427 stored into this field. 429 tdb_header_seq: This field contains the number of the last message 430 sent incremented by 1. 432 tdb_header_pid: The process id of the program sending the message. 433 If the message is generated inside the kernel, this value is 434 set to zero. 436 INTERFACE: 438 The INTERFACE payload is used to provide all needed information 439 about an active network interface. 441 The format of the INTERFACE payload is the following: 443 struct tdb_interface { 444 uint16_t tdb_interface_len; 445 uint16_t tdb_interface_pltype; 446 uint32_t tdb_interface_selector; 447 uint32_t tdb_interface_type; 448 uint32_t tdb_interface_quality; 449 } __attribute__( ( packed ) ); 450 /* sizeof( struct tdb_interface ) == 16 */ 452 This fields contain the following values: 454 tdb_interface_len: This field contains the length of the payload 455 divided by 8. 457 tdb_interface_pltype: This field contains the value 458 TDB_PT_INTERFACE. 460 tdb_interface_selector: The tdb_interface_selector field stores 461 interface enumeration information for unique identification (IF 462 #0, #1, #2, ...). When a new interface comes up, this value 463 should be set by the kernel. 465 tdb_interface_type: Information about classification of an 466 interface, for instance Indication, of fixed or wireless 467 network link and theoretical maximum bandwidth. 469 tdb_interface_quality: This field provides quality information 470 about a certain interface for making interface selections 471 possible (e.g. load balancing; handover). This value should be 472 a very general indicator calculated and set by the kernel 473 space. It could be based on latency (ping), signal quality for 474 wireless links, packet-loss rate and average data-throughput/ 475 bandwidth. (Author's note: If a single value is not 476 reasonable, separate indicators for all these evaluation 477 criteria's should be defined.) 479 Further information about an interface might be necessary. This 480 is left for future investigation. 482 ADDRESS: 484 The ADDRESS payload is used to provide the IP address of an 485 interface to the Trigger Database or registered application. This 486 information is important for most triggers. But it might be 487 possible that there trigger types that do not need an ADDRESS 488 payload. 490 The format of the ADDRESS payload is: 492 struct tdb_address { 493 uint16_t tdb_address_len; 494 uint16_t tdb_address_pltype; 495 uint8_t tdb_address_proto; 496 uint8_t tdb_address_prefixlen; 497 uint16_t tdb_address_reserved; 498 } __attribute__( ( packed ) ); 499 /* sizeof( struct tdb_address ) == 8 */ 501 /* followed by some form of struct sockaddr */ 503 Information about IP address and probably ports is provided by a 504 sockaddr structure which is attached to the tdb_address structure. 505 A sockaddr structure is capable of storing both a IPv4 and IPv6 506 address. The fields of the tdb_address structure contains the 507 following values: 509 tdb_address_len: This field contains the length of the payload 510 including the sockaddr structure divided by 8. 512 tdb_address_pltype: The tdb_address_pltype field contains the 513 value TDB_PT_ADDRESS. 515 tdb_address_proto: The tdb_address_proto field is normally set to 516 zero. However, if is are set in the attached sockaddr needed, 517 then the field SHOULD be set to the protocol number of the 518 upper layer protocol. (e.g. TCP or UDP). This functionality 519 may become relevant for signaling IPSec related information 520 (e.g. tunnel changes) 522 tdb_address_prefixlen: This field contains the prefix length of 523 the address. 525 tdb_address_reserved: The tdb_address_reserved field is reserved 526 for future use and MUST be set to zero. 528 TBD: Clarification about the prefix len needs to be provided in a 529 future document version. 531 TRIGGER: 533 The TRIGGER payload is used to provide all needed information 534 about a trigger itself, e.g. the trigger type, an id, etc. The 535 notation TRIGGER(*) indicates that only the id field is used to 536 identify the trigger and all other fields SHOULD be set to zero. 538 The format of the TRIGGER payload is the following: 540 struct tdb_trigger { 541 uint16_t tdb_trigger_len; 542 uint16_t tdb_trigger_pltype; 543 uint16_t tdb_trigger_type; 544 uint16_t tdb_trigger_reserved1; 545 uint32_t tdb_trigger_id; 546 uint32_t tdb_trigger_reserved2; 547 } __attribute__( ( packed ) ); 548 /* sizeof( struct tdb_trigger ) == 16 */ 550 This fields contain the following values: 552 tdb_address_len: This field contains the length of the payload 553 divided by 8. 555 tdb_address_pltype: This field contains the value TDB_PT_TRIGGER. 557 tdb_address_type: The type of the trigger is stored into this 558 field. All possible values are listed in the table in section 559 Section 3. 561 tdb_address_id: The id of a trigger is assigned by the Trigger 562 Database itself. In the message sent by userspace programs, 563 which do not know this value (e.g. for TDB_ADD messages), this 564 value MUST be set to zero. 566 Further information about a trigger might be necessary. This is 567 left for future investigation. 569 7. Applicability 571 Even though this document is intended to give a solution for MOBIKE, 572 the API is generic enough to make information available for other 573 protocols as well. 575 The Next Step In Signaling (NSIS) protocol suite, for example, 576 requires access to up-to-date information about IP addresses, 577 interfaces and interactions with mobility protocols. In order to 578 react on mobility events some sort of interaction between the kernel, 579 various signaling protocols (including Mobile IP, IKE/IPsec, etc.) 580 and the NSIS daemon is required (see [5]). Hence, an NSIS daemon 581 supporting mobility could benefit from a generic interface to meet 582 it's requirements for fast and accurate detection of mobility events, 583 address and interface changes. GIMPS, for example, demands immediate 584 reaction in case of a mobility event (e.g., handover). Monitoring 585 procedures of mobility management protocols like Mobile IP are 586 required to react to these mobility events in an appropriate way. 588 The trigger database and it's API could provide necessary information 589 for detecting such a movement (new interface/IP address available, 590 expiring Mobile IP timers). 592 8. IANA Considerations 594 This document defines an IANA registry for the protocol family 595 PF_TRIGGER. 597 An IANA registry might be needed for the different trigger types (for 598 which examples are provided in Section 3). 600 9. Security Considerations 602 This document describes an API which allows information about IP 603 addresses to be obtained at a local host. A malicious application or 604 protocol daemon could disseminate wrong information. This would make 605 other protocols, such as MOBIKE, believe that the status of a 606 particular address has changed. This will likely lead to unexpected 607 protocol behavior, such as switching between addresses back-and- 608 forth. Hence, a certain trust has to be placed into the applications 609 and protocol daemons that are allowed to access the database to 610 insert, modify or delete triggers. Access control mechanisms might 611 enforce certain rights to use the API or parts of it. 613 10. Acknowledgments 615 The authors would like to thank Murugaraj Shanmugam for his comments. 617 11. References 619 11.1 Normative References 621 [1] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, 622 Version 2", RFC 2367, July 1998. 624 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 625 Levels", March 1997. 627 11.2 Informative References 629 [3] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", 630 draft-ietf-mobike-design-02 (work in progress), February 2005. 632 [4] Sugimoto, S. and F. Dupont, "PF_KEY Extension as an Interface 633 between Mobile IPv6 and IPsec/IKE", 634 draft-sugimoto-mip6-pfkey-migrate-00 (work in progress), 635 February 2005. 637 [5] Lee, S., Jeong, S., Tschofenig, H., Fu, X., and J. Manner, 638 "Applicability Statement of NSIS Protocols in Mobile 639 Environments", 640 draft-ietf-nsis-applicability-mobility-signaling-01 (work in 641 progress), February 2005. 643 Authors' Addresses 645 Udo Schilcher 646 Siemens 647 Otto-Hahn-Ring 6 648 Munich, Bayern 81739 649 Germany 651 Email: USchilcher@siemens.com 653 Hannes Tschofenig 654 Siemens 655 Otto-Hahn-Ring 6 656 Munich, Bayern 81739 657 Germany 659 Email: Hannes.Tschofenig@siemens.com 660 Franz Muenz 661 Siemens AG 662 Otto-Hahn-Ring 6 663 Munich, Bayern 81739 664 Germany 666 Email: Franz.Muenz@thirdwave.de 668 Intellectual Property Statement 670 The IETF takes no position regarding the validity or scope of any 671 Intellectual Property Rights or other rights that might be claimed to 672 pertain to the implementation or use of the technology described in 673 this document or the extent to which any license under such rights 674 might or might not be available; nor does it represent that it has 675 made any independent effort to identify any such rights. Information 676 on the procedures with respect to rights in RFC documents can be 677 found in BCP 78 and BCP 79. 679 Copies of IPR disclosures made to the IETF Secretariat and any 680 assurances of licenses to be made available, or the result of an 681 attempt made to obtain a general license or permission for the use of 682 such proprietary rights by implementers or users of this 683 specification can be obtained from the IETF on-line IPR repository at 684 http://www.ietf.org/ipr. 686 The IETF invites any interested party to bring to its attention any 687 copyrights, patents or patent applications, or other proprietary 688 rights that may cover technology that may be required to implement 689 this standard. Please address the information to the IETF at 690 ietf-ipr@ietf.org. 692 Disclaimer of Validity 694 This document and the information contained herein are provided on an 695 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 696 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 697 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 698 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 699 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 702 Copyright Statement 704 Copyright (C) The Internet Society (2005). This document is subject 705 to the rights, licenses and restrictions contained in BCP 78, and 706 except as set forth therein, the authors retain all their rights. 708 Acknowledgment 710 Funding for the RFC Editor function is currently provided by the 711 Internet Society.