1 1-1 Managing and Securing Computer Networks INFO-056 Prof. Guy Leduc Université de Liège Institut Montefiore, B28 B-4000 Liège 1 Phone: 04 3662698 ou 2696 (secrétariat) Email: [email protected]URLs: http://progcours.ulg.ac.be/cocoon/cours/INFO0056-1.html http://www.montefiore.ulg.ac.be/~leduc/cours/GSRI.html 1-2 Reference Books (Chapter 8 and sections 4.4, 5.5 and 5.7 of) Computer Networking: A Top-Down Approach, 7 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2016. Computer Networks and Internets, 6 th Edition Douglas E. Comer Pearson Education, 2015 (Chapter 31) Network Security: PRIVATE Communication in a PUBLIC World, 2 nd edition. Charlie Kaufman, Radia Perlman, Mike Speciner Prentice Hall, 2002.
33
Embed
Managing and Securing Computer Networks INFO-056leduc/cours/ISIR/GSRI-ch1.pdf · Managing and Securing Computer Networks INFO-056 ... it will not roll over, ... (100 standardized
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Management Functional Areas ❒ Performance management
❍ Monitoring: track activities on the network (response time, bottlenecks, …)
❍ Controlling: adjust to improve performance ❒ Fault management
❍ Detection, isolation, and correction of abnormal operation ❍ Fault ≠ Error
❒ Configuration and name management ❍ Initializing a network and gracefully shutting it down ❍ Maintaining, adding, and updating the relationships among
components ❒ Accounting management
❍ Enable charges to be established for the use of resources ❒ Security management
❍ Managing information protection and access-control ❍ Generating, distributing, and storing encryption keys
"Network management includes the deployment, integration and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate, and control the network and element resources to meet the real-time, operational performance, and Quality of Service requirements at a reasonable cost."
Origin of TCP/IP Network Management ❒ In early days, ICMP (Internet Control Message
Protocol) was used to provide feedback about problems ❍ echo-reply with or without timestamps, source routing,
record routes, … ❍ PING program (1983) ❍ Traceroute program (1987) by Van Jacobson
❒ The Internet growth, with associated management domains for subparts, required a standardized protocol ❍ In 1987, SGMP: Simple Gateway Monitoring Protocol
❒ Need for more general-purpose network management tool
The SNMP Evolution ❒ Binding the two protocols at the object level became impractical
❍ In OSI, managed objects are seen as sophisticated entities with attributes, associated procedures, and notification capabilities, and other more complex characteristics based on the object-oriented technology
❍ In SNMP, objects are not really objects at all from the point of view of object-oriented technology
• simply variables with a few basic characteristics, such as data type, read-only or read-write attributes, …
❒ IAB thus relaxed the condition on common SMI and MIB ❍ Progress on SNMP was rapid, and SNMP became widely available on
vendor equipment ❍ SNMP became the network management protocol, just as TCP/IP
became the protocol suite for data transfer ❍ Enhancements to SNMP have been pursued
• e.g. RMON (Remote Monitoring) to monitor LANs as a whole
❒ The SMI ❍ identifies the data types that can be used in the MIB ❍ specifies how resources within the MIB are represented and
named ❒ For simplicity and extensibility within the MIB, the MIB
can store only simple data types: ❍ Scalars, two-dimensional arrays
❒ Interoperability requires that the SMI provides standardized techniques for: ❍ defining the MIB structure ❍ defining individual objects, including the syntax and the value of
ipInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The total number of input datagrams successfully delivered to IP user- protocols (including ICMP)” ::= {ip 9}
ipMIB MODULE-IDENTITY LAST-UPDATED “941101000Z” ORGANIZATION “IETF SNPv2 Working Group” CONTACT-INFO “ Keith McCloghrie …” DESCRIPTION “The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.” REVISION “019331000Z” ……… ::= {mib-2 48} 1.3.6.1.2.1.4.9
Defining Objects - Syntax • An object (e.g. tcpMaxConn) is an instance of OBJECT-
TYPE with the following key components:– Syntax: i.e. the abstract syntax of the object, defined in ASN.1– Access: i.e. the way in which the objects may be accessed (e.g. read-only,
read-write, write-only, not-accessible)– Status: the implementation support required for this object (e.g. mandatory,
optional, deprecated: mandatory but likely to be removed soon, obsolete: not needed any more)
– Description (optional): a textual description of the semantics– Reference (optional): a textual cross-reference to an object defined in some
other MIB– Index: used in defining tables. It is present if the object type corresponds to a
conceptual row of a table– Default (optional): default value at object creation– Value Notation: The name used to access this object via SNMP (e.g. {ip 9})
❒ Basic Concepts: ❍ SNMP in the protocol stack ❍ Operations supported by SNMP ❍ Communities and Community Names ❍ Instance Identification ❍ Lexicographical Ordering
SNMP PDU fields ❒ request-id: used to distinguish among outstanding requests by
providing each request with a unique ID ❒ error-status: used to indicate that an error occurred while
processing the request ❍ noError, noSuchName, badValue, readOnly, …
❒ error-index: when error-status is different from noError, it may provide additional information by indicating which variable in a list caused the exception
❒ variablebindings: a list of names and corresponding values ❍ except for GetRequest where the values are null
❒ enterprise: type of object generating trap ❒ agent-addr: address of object generating trap ❒ trap type: generic trap type
❍ linkdown, linkup, authentication-Failure, … ❒ time-stamp: time elapsed between the last (re)initialization of the
Trap-directed polling ❒ Problem with a large number of agents ❒ In essence, the network is not made to carry management
information that the manager does not need, and agents are not made to respond to frequent requests for uninteresting information
❒ The preferred strategy is: ❍ At initialization time (and perhaps at infrequent intervals), a
management station can poll all of the agents it knows for some key information (e.g. interface characteristics, baseline performance statistics)
❍ Each agent is responsible for notifying the management station of any unusual event (e.g. agent has crashed and is rebooted, a link fails, an overload). Agents report these events by the trap message
❍ When alerted, a management station may choose to take some action. Typically to direct polls to the agent and perhaps some nearby agents in order to diagnose any problem
❒ This trap-directed polling can result in substantial savings of network capacity and agent processing time
❍ SNMP MIB view: a subset of the objects within a MIB • Different MIB views may be defined for each community • The set of objects in a view need not belong to a single subtree
of the MIB ❍ SNMP access mode: an element of the set {READ-ONLY,
READ-WRITE} • An access mode is defined for each community
❒ The combination of a MIB view and an access mode is called a community profile ❍ A community profile thus consists of a defined subset of the
MIB at the agent, plus an access mode ❒ Recall also that each MIB object has its own ACCESS
Object Instance Identification ❒ We know that every object in the MIB has a unique object
identifier, which is defined by the position of the object in the tree-structured MIB
❒ However, when an access is made to a MIB, via SNMP or some other means, it is a specific instance of an object that is wanted, not an object type
❒ This distinction is essential for objects that appear in tables ❍ Called columnar objects ❍ For them the object identifier alone does not suffice to identify
the instance • There is one instance of each object for every row in the table • Therefore we need some convention by which a specific instance of an
object within a table may be identified ❒ Reference to object instances is protocol-specific
❍ It is not defined in the MIB ❍ We’ll consider SNMP specific instance identification
❒ An instance of a scalar object of a particular row of a table is the concatenation of ❍ the object type identifier of the table object ❍ the suffix that identifies a row object ❍ the suffix that identifies the scalar element in
❒ For table and row objects, no instance identifier is defined ❍ They are not leaf objects ❍ Their ACCESS characteristic is listed as "not-accessible"
❒ For scalar objects, there is no ambiguity between the object type and an instance of that object (one-to-one relationship) ❍ For consistency with tabular objects, and to distinguish
between an object type and an object instance, SNMP dictates that the instance identifier of a scalar object consists of its object identifier concatenated with 0
Lexicographical Ordering ❒ An object identifier is a sequence of integers that reflects a
hierarchical or tree structure of the objects in the MIB ❒ Sequences of integers exhibit a lexicographical ordering ❒ That ordering corresponds to traversing the tree of objects
identifiers in depth-first mode with child nodes of a common parent depicted in ascending numerical order
❒ This ordering extends to object instance identifiers ❒ An ordering is important when the manager does not know the exact
makeup of the MIB view that an agent presents to it ❍ By using the get-next operation, the SNMP management station can ask
the next object in that ordering ❍ It works even if the supplied identifier is not valid, i.e. does not exist in
the MIB • In that case, this is the next valid identifier that is returned
Solving the presentation problem 1. Translate local-host format to host-independent format 2. Transmit data in host-independent format 3. Translate host-independent format to remote-host
[APPLICATION 0] IMPLICIT SET { [0] name ISO646STRING[1] address ISO646STRING[2] idNumber EmployeeNoType}
EmployeeNoType ::= INTEGER
CONTEXT tagAPPLICATION tag
(Implicit) UNIVERSAL tag
❒ APPLICATION 0 identifies the EmployeeRecord type and its constructor (SET)
❒ However this constructor (SET) has a (universal) tag too, which is now redundant
❒ To avoid the encoding of the two tags (APPLICATION 0 and SET), ASN.1 uses the keyword IMPLICIT ❍ Only the APPLICATION 0 tag will be part of the encoding
❒ For CONTEXT tags, the class is not explicitly written ❒ UNIVERSAL tags are implicit