El daño causado a la víctima / sobreviviente

The concept of Internet-based management was introduced by Internet Engineering Task Force (IETF). In contrast to OSI approach, IETF did not define a specialized standard for Internet Management Architecture. Current Internet management architectures are tailored based on the underlying communication protocols. The main two communication protocols defined by IETF for the purpose of exchanging management information are Simple Network Management Protocol (SNMP) and NETwork CONFiguration Protocol (NETCONF).

The Internet management architecture that is based on SNMP framework is called In- ternet Standard Management Framework or simply SNMP framework. For the NETCONF, up to writing this dissertation, there is no proposed management architecture for NET- CONF. Therefore, the remaining of this section will concentrate on the Internet Standard Management Framework.

IETF has defined three versions of Simple Network Management Protocol: SNMPv1, SNMPv2 and SNMPv3. Regardless of SNMP versions, the fundamental elements of Internet Standard Management Framework are the same in the three versions [17], which are:

• A set of SNMP entities that take either the role of agent or manager. An SNMP entity with the role of agent provides remote access to SNMP entity with the role of manager. Moreover, management applications are executed at the manager side.

• A management protocol to exchange management information. • Management information.

The specifications of the Internet Standard Management Framework are entirely information- oriented. The framework consists of the followings:

• A data definition language called Structure of Management Information (SMI). • A definition of management information or Management Information Base (MIB). • A definition of a protocol for information exchange called Simple Network Management

Protocol (SNMP).

• Security and Administration.

2.3.3.1 Structure of Management Information (SMI)

The SMI defines precisely how managed objects are described and named for the purpose of management. SMI notations are taken from OSI’s ASN.1 language. There are two versions of the SMI: SMIv1 and SMIv2. SMIv1 is described in RFCs 1155, 1212 and 1215 while SMIv2 is described in RFCs 2578, 2579 and 2580. SMIv2 extends SMIv1 by adding new data types, enhancing object definition and adding SNMPv2 node to MIB tree as we will explain later. The SMI is divided into three parts:

• Module definitions, which are used to define information modules using the SMI no- tation MODULE-IDENTITY.

• Object definitions, which are used to describe and name managed objects. Object definition starts with the SMI notation OBJECT-TYPE.

• Notification definitions, which are used to define events emitted by SNMP agent entity. Notification definition starts with the SMI notation NOTIFICATION-TYPE.

Root Node iso(1) ccit(0) joint(2) org(3) DoD (6) Internet(1) directory(1) management (2) experimental (3) private(4) security(5) SNMPv2 (6) Mail(7) MIB-II(1) enterprises(1)

Figure 2.9: SMI object tree

To uniquely identify each managed object, the SMI introduces a naming scheme, which is basically a tree-like hierarchy. The top of the tree is called the root node and the leaves represent the actual management variables or information to be monitored or controlled. Except the root node, each node in the tree has a name and an integer number. An object ID is made up of a series of integers separated by dots based on traversing the tree starting from the root node and ending at the leaf node. Figure 2.9 shows a few top levels of this MIB tree.

2.3.3.2 Management Information Base (MIB)

To identify all managed objects that can be controlled and monitored, a large number of Management Information Base (MIB) standards have been developed. Among these MIBs is MIB-II defined in RFC 1213. MIB-II is considered the most important and probably best known MIB; it contains all information to manage the basic TCP/IP protocol suite. The structure of this MIB is simple: management information that belongs to the same protocol is aggregated together to form a group. There are nine groups defined in MIB-II: system group, interfaces group, the address translation group, the IP group, the ICMP group,

the TCP group, the UDP group, the EGP group, the transmission group and the SNMP group. The other standard MIBs contain information related to other Internet services such as routing protocols, ATM, SONET, etc. In addition, there are MIBs related to physical devices such as repeaters, switches and routers.

Next to standardized MIBs, there are also a large number of enterprise specific MIBs. Unfortunately, there is no clear structure to explain the relationships between these MIBs; the only indication of a MIB’s purpose is its name.

2.3.3.3 Protocol Definition

SNMP entities that take the role of agent may have a set of standard MIBs and enterprise specific MIBs that need to be controlled and monitored. The SNMP standard defines a set of operations applied to the Object IDs found in MIBs. There is no SNMP operation to create or delete Object IDs. Also, SNMP defines only one operation (called set) to control an Object ID. We will discuss SNMP protocol in more details in section 2.4.2.

2.3.3.4 Security and Administration

The original SNMP framework (SNMPv1) had a simple authentication scheme in which two SNMP entities exchange a password called community name. The problem is that community string names are transmitted in plain text. Any attacker who sniffs the network can easily discover the password. In addition, management information is exchanged without any encryption. These weaknesses allow several threats on the network management such as masquerading, modification of information or even packet reordering.

SNMPv2 framework revises version 1 and introduces a new scheme called party-based security (RFC 1441 to 1452). This version is known as SNMPv2p. However, because of the extensive and complicated security model, SNMPv2p was not well received in the market. Attempts at simplifying the proposal were undertaken and other developments were produced under the names SNMPv2*, SNMPv2u and SMNPv2c. SNMPv2u is based

SNMP Entity Dispatcher SNMP Engine Message Processing Subsystem Security Subsystem Access Control Subsystem Application Command generator Command responder Notification receiver Notification originator Proxy forwarder Other Figure 2.10: SNMPv3 Entity

on a user-oriented security model while SNMPv2c is based on community strings similar to SNMPv1 [37]. Needless to say, this proliferation resulted in market confusion and motivated IETF to introduce SNMPv3.

SNMPv3 is the latest version of SNMP. Its main contribution to network management is security. It provides message integrity, authentication and encryption. SNMPv3 introduces two concepts: security model and security level. Security model is an authentication strategy that is set up for a user and a group in which the user resides. A security level is the permitted level of security within a security model. Together will determine which security mechanism is employed when exchanging management information [25].

SNMPv3 entity has a single engine to perform the message processing as shown in Fig- ure 2.10. When an application wants to send SNMP PDUs to the other SNMP entity, the engine first accepts the SNMP datagram to be sent from SNMP application level, performs the appropriate security functions, encapsulates the PDU into an SNMPv3 message, and finally dispatches the message out to the network. When the engine receives an SNMPv3 message from the network, it performs the necessary decryption and authentication functions before passing the PDU to the SNMP applications.