Mobile IP Working Group D. Cong & M. Hamlen, editor INTERNET DRAFT Motorola expires in six months C. Perkins, editor IBM December 1995 The Definitions of Managed Objects for the Security function of IP Mobility Support draft-ietf-mobileip-mib-sec-00.txt Status of this Memo This document is a submission by the Mobile-IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@smallworks.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security function definied in the Mobile IP Protocol. Cong, Hamlen & Perkins expires in six months [Page 1] Internet Draft Mobile IP MIB Definition December 18, 1995 Table of Contents 1. The Network Management Framework ...................... 2 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 2 3. Overview .............................................. 3 3.1 Object Selection Criteria ............................ 3 3.2 Structure of the Mobile IP ........................... 3 3.3 MIB Groups ........................................... 4 4. Definitions ........................................... 4 5. Acknowledgements ...................................... 9 6. Security Considerations ............................... 9 7. References ............................................ 10 8. Chair's Address ....................................... 11 9. Editor's Address ...................................... 11 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. STD 17/RFC 1213 which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [3] defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. 2.1. Format of Definitions Cong, Hamlen & Perkins expires in six months [Page 2] Internet Draft Mobile IP MIB Definition December 18, 1995 Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. 3. Overview 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, the authors have applied some criteria to select managed objects for the Mobile IP Protocol. (1) Partition management functionality among the Mobile Node, Home Agent, and Foreign Agent according to the partitioning seen in the Mobile IP Protocol. For example, the editors minimize the management requirements in the Mobile Node. (2) Require that objects be essential for either fault or configuration management. (3) Limit the total number of objects. (4) Exclude objects which are simply derivable from others in this or other MIBs. 3.2. Structure of the Mobile IP This section describes the basic model of Mobile IP used in developing the Mobile IP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The Mobile IP Protocol introduces these new funtional entities: Mobile Node A host or router that changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without losing connectivity and without changing its IP address. Home Agent A router on a mobile node's home network which tunnels packets for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Foreign Agent Cong, Hamlen & Perkins expires in six months [Page 3] Internet Draft Mobile IP MIB Definition December 18, 1995 A router on a mobile node's visited network which provides routing services to the mobile node when it registers. The foreign agent detunnels and delivers packets to the mobile node that were tunneled by the mobile node's home agent. In the reverse direction, the foreign agent may serve as a default router for registered mobile node. This document specifies the objects used in managing one of these entities; namely, the Mobile node. 3.3. MIB Groups The definitions of managed objects for Mobile IP have been organized into several MIB groups: (1) The Mobile Node Group (2) The Foreign Agent Group (3) The Home Agent Group (4) The Security Group (Optional) The first three groups are related to the three entities defined in the Mobile IP Protocol specification. The Security Group is an optional group for all three entities, because it includes security configurations for each Mobile IP entity. If an agent seeking to implement the Mobile IP MIB does not support SNMPv2 with privacy, it is strongly advised that the Security Group not be implemented. This document specifies the Security Group. 4. Definitions MIP-SEC-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, IpAddress, TimeTicks FROM RFC1155-SMI DisplayString FROM RFC1213-MIB mip FROM MIP-MN-MIB OBJECT-TYPE FROM RFC-1212; -- Extend the MIB definitions mipSecurity OBJECT IDENTIFIER ::= { mip 4 } -- Mobile IP Security Group Cong, Hamlen & Perkins expires in six months [Page 4] Internet Draft Mobile IP MIB Definition December 18, 1995 -- Optional Group for mobile node, foreign agent, and home agent. -- Mobile IP security association list mipSecAssocTable OBJECT-TYPE SYNTAX SEQUENCE OF MipSecAssocEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing mobility security associations. This table is maintained by the security administrator." ::= { mipSecurity 1 } mipSecAssocEntry OBJECT-TYPE SYNTAX MipSecAssocEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "One particular mobility security association." INDEX { mipSecPeerAddress, mipSecSPI } ::= { mipSecAssocTable 1 } MipSecAssocEntry ::= SEQUENCE { mipSecPeerAddress IpAddress, mipSecSPI INTEGER, mipSecAlgorithmType DisplayString, mipSecAlgorithmMode DisplayString, mipSecKey OCTET STRING, mipSecReplayMethod INTEGER } mipSecPeerAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IP address of the peer entity with which this node shares the mobility security association." ::= { mipSecAssocEntry 1 } mipSecSPI OBJECT-TYPE SYNTAX INTEGER (SIZE(0..32)) ACCESS read-write STATUS mandatory DESCRIPTION "The SPI is the index within the mobility security association which selects the specific security paramters to be used to authenticate the peer, i.e. the rest of the Cong, Hamlen & Perkins expires in six months [Page 5] Internet Draft Mobile IP MIB Definition December 18, 1995 variables in this MipSecAssocEntry." ::= { mipSecAssocEntry 2 } mipSecAlgorithmType OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION "Type of security algorithm (e.g. Keyed MD5)." ::= { mipSecAssocEntry 3 } mipSecAlgorithmMode OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION "Security mode used by this algorithm." ::= { mipSecAssocEntry 4 } mipSecKey OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "The shared secret key for the security associations." ::= { mipSecAssocEntry 5 } mipSecReplayMethod OBJECT-TYPE SYNTAX INTEGER { timestamps(1), nonces(2), other(3) } ACCESS read-write STATUS mandatory DESCRIPTION "The replay method supported for this SPI within this mobility security association." ::= { mipSecAssocEntry 6 } -- Mobile IP security violation total counter mipSecTotalViolations OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of security violations." Cong, Hamlen & Perkins expires in six months [Page 6] Internet Draft Mobile IP MIB Definition December 18, 1995 ::= { mipSecurity 2 } -- Mobile IP security violation table mipSecViolationTable OBJECT-TYPE SYNTAX SEQUENCE OF MipSecViolationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing information about security violations." ::= { mipSecurity 3 } mipSecViolationEntry OBJECT-TYPE SYNTAX MipSecViolationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about one particular security violation." INDEX { mipSecViolatorAddress, mipSecViolatorSPI } ::= { mipSecViolationTable 1 } MipSecViolationEntry ::= SEQUENCE { mipSecViolatorAddress IpAddress, mipSecViolatorSPI INTEGER, mipSecViolationCounter Counter, mipSecRecentViolationTime TimeTicks, mipSecRecentViolationID1 INTEGER, mipSecRecentViolationID2 INTEGER, mipSecRecentViolationReason INTEGER } mipSecViolatorAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "Violator's IP address." ::= { mipSecViolationEntry 1 } mipSecViolatorSPI OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "If the security violation is due to an identification mismatch, then this is the SPI from the Mobile-Home Authentication Extension. If the security violation is Cong, Hamlen & Perkins expires in six months [Page 7] Internet Draft Mobile IP MIB Definition December 18, 1995 due to an invalid authenticator, then this is the SPI from the offending authentication extension. In all other cases, it should be set to zero." ::= { mipSecViolationEntry 2 } mipSecViolationCounter OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of security violations for this {peer,SPI} pair." ::= { mipSecViolationEntry 3 } mipSecRecentViolationTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "Time of the most recent security violation for this {peer,SPI} pair." ::= { mipSecViolationEntry 4 } mipSecRecentViolationID1 OBJECT-TYPE SYNTAX INTEGER (SIZE(0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "Low-order 32 bits of identification used in request or reply of the most recent security violation for this {peer,SPI} pair." ::= { mipSecViolationEntry 5 } mipSecRecentViolationID2 OBJECT-TYPE SYNTAX INTEGER (SIZE(0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "High-order 32 bits of identification used in request or reply of the most recent security violation for this {peer,SPI} pair." ::= { mipSecViolationEntry 6 } mipSecRecentViolationReason OBJECT-TYPE SYNTAX INTEGER { noMobilitySecurityAssociation(1), badAuthenticator(2), badIdentifier(3), Cong, Hamlen & Perkins expires in six months [Page 8] Internet Draft Mobile IP MIB Definition December 18, 1995 badSPI(4), missingSecurityExtension(5), other(6) } ACCESS read-only STATUS mandatory DESCRIPTION "Reason for the most recent security violation for this {peer,SPI} pair." ::= { mipSecViolationEntry 7 } END 5. Acknowledgments This document was produced by the Mobile IP working group. The editors wish to thank Jim Solomon, for his encouragement, patience, and help. Thanks to Fredrick Tarberg and Fredrik Broman (KTH) for their initial efforts on MIB definitions. Thanks to Frank Kastenholz(FTP), for his comments on the initial MIB from KTH. 6. Security Considerations The Mobile IP MIB affords the network operator the ability to configure and control the Mobile IP links of a particular system, including the Mobile IP authentication protocols, and shared secret key. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate, optional, MIB Groups. As the MIB Group is the quantum of implementation within a MIB, the implementor of the MIB may elect not to implement these groups. (2) The implementor may choose to implement the variables which present a security risk so that they may not be written, i.e., the variables are READ-ONLY. This method still presents a security risk, and is not recommended, in that the variables, specifically the Mobile IP Security Association variables, may be easily read. (3) Using SNMPv2, the operator can place the variables into MIB views which are protected in that the parties which have access to those MIB views use authentication and Cong, Hamlen & Perkins expires in six months [Page 9] Internet Draft Mobile IP MIB Definition December 18, 1995 privacy protocols, or the operator may elect to make these views not accessible to any party. In order to facilitate this placement, all security-related variables are placed in separate MIB Tables. This eases the identification of the necessary MIB View Subtree. (4) The Mobile IP Security MIB contains several objects which are very sensitive from a security point of view. Thus, in order to preserve the integrity, security and privacy of the Mobile IP security features, an implementation will allow access to this MIB only via SNMPv2 and then only for parties which are privacy enhanced. Other access modes, e.g., SNMPv1 or SNMPv2 without privacy-enhancement, are very dangerous and the security of the IP Mobility Support may be compromised. The other way to access this information is by use of SNMPv1 in concert with the IP security protocols (AH and ESP). This can also be done in a secure fashion. 7.0 References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. Cong, Hamlen & Perkins expires in six months [Page 10] Internet Draft Mobile IP MIB Definition December 18, 1995 [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991. [8] Solomon J., "Mobile IP Protocol Applicability Statement", Internet Draft -- work in progress, December, 1995. [9] Perkins C., "IP Mobility Support", Internet Draft -- work in progress, December, 1995. [10] Perkins C., "IP Encapsulation within IP". Internet Draft -- work in progress, October 1995. [11] Perkins C., "Minimal Encapsulation within IP". Internet Draft -- work in progress, July 1995. [12] Hanks S. et. al., "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. 8. Chair's Addresses The working group can be contacted via the current chairs: Jim Solomon Tony Li Motorola, Inc. cisco systems 1301 E. Algonquin Rd. 170 W. Tasman Dr. Schaumburg, IL 60196 San Jose, CA 95134 Work: +1-708-576-2753 Work: +1-408-526-8186 E-mail: solomon@comm.mot.com E-mail: tli@cisco.com 9. Editor's Address Questions about this memo can also be directed to: David Cong Room 3149 Motorola 1301 East Algonquin Rd. Schaumburg, IL 60196 Work: +1-708-576-1357 Fax: +1-708-538-3472 E-mail: cong@comm.mot.com Cong, Hamlen & Perkins expires in six months [Page 11] Internet Draft Mobile IP MIB Definition December 18, 1995 Mark Hamlen Room 4413 Motorola 1301 East Algonquin Rd. Schaumburg, IL 60196 Work: +1-708-576-0346 Fax: +1-708-538-6150 E-mail: hamlen@comm.mot.com Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-7007 E-mail: perk@watson.ibm.com Cong, Hamlen & Perkins expires in six months [Page 12]