Managing and Securing Computer Networks INFO-056

(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) Fax: 04 3662989 Email: [email protected] URL: http://progcours.ulg.ac.be/cocoon/cours/INFO0056-1.html

Reference Books

(Chapters 8 and 9 of)

Computer Networking: A Top-Down Approach, 6th_edition.

Jim Kurose, Keith Ross Addison-Wesley, March 2012.

Network Security: PRIVATE Communication in a PUBLIC World,

2nd_edition.

Charlie Kaufman, Radia Perlman, Mike Speciner Prentice Hall, 2002.

(2)

Course content

❒

 

Part 1: Network Management

❒

 

Part 2: Network Security

❒

 

One seminar:

❍ 

IPv6 security

•  by E. Vyncke, CISCO Systems

Evaluation

❒ 

Theory

❍  Oral exam ❍  Weight: 50% ❒ 

Student projects

❍  Two projects: •  Network management •  Network security

❍  Group of (up to) 2 students

(3)

Chapter 1: Network Management

Chapter goals:

❒  Introduction to network management

❍ motivation

❍ major components

❒  Internet network management framework

❍ MIB: management information base

❍ SMI: data definition language

❍ SNMP: protocol for network management

❒  Presentation services: ASN.1

❒  Kurose & Ross (chapter 9) gives an overview

❒  Slides also cover some material from “SNMP, SNMPv2 and

RMON” by William Stallings, Addison Wesley, 1996.

Chapter 1 outline

❒ 

What is network management?

❒ 

Internet-standard management framework

❍ Structure of Management Information: SMI

❍ Management Information Base: MIB

❍ SNMP Protocol Operations and Transport Mappings

(4)

What is network management?

❒ 

autonomous systems (aka “network”):

100s or 1000s of

interacting hardware/software components

❒ 

other complex systems requiring monitoring, control:

❍ jet airplane

❍ nuclear power plant

❍ others?

❒ 

scenarios where network management is useful:

❍ detecting failures of interface cards or links

❍ host monitoring

❍ monitoring traffic

❍ detecting route flapping

❍ monitoring Service Level Agreements (SLAs)

❍ intrusion detection

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

(5)

What is network management? (2)

"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."

Infrastructure for network management

definitions:

managed devices contain managed objects whose data is gathered into a Management Information Base (MIB) NOC: Network Operations Center managed device managed device managed device managed device managing Entity data

managing entity (NOC)

agent data agent data agent data agent data Network Management Protocol

(6)

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 and some supplemental tools

❒ 

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

Origin of SNMP

❒  Three promising approaches emerged:

❍  HEMS (High-Level Entity Management System)

•  Generalization of HMP (Host Management Protocol) which is the first

network management protocol used in the Internet

❍  SNMP (Simple Network Management Protocol)

•  Enhanced version of SGMP

❍  CMOT (CMIP over TCP/IP)

•  CMIP was the Common Management Information Protocol under development

in ISO

❒  In 1988, the Internet Architecture Board (IAB) approved

❍  Further development of SNMP as a short-term solution

❍  CMOT, or even CMIP over OSI protocols, as the long-range solution

•  As it was felt that TCP/IP installations would transition to OSI-based

protocols and services !!!

❍  Both approaches would use the same data base of managed objects

•  Same SMI and MIB to facilitate the transition

❍  HEMS was more capable than SNMP, but the extra effort for a

(7)

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 subnetworks as a whole

Network Management standards

ISO’s CMIP

❒ 

Common Management

Information Protocol

❒ 

designed 1980’s:

the

unifying net

management standard

❒ 

too slowly

standardized

SNMP: Simple Network

Management Protocol

❒ 

Internet roots (SGMP)

❒ 

started simple

❒ 

deployed, adopted rapidly

❒ 

growth: size, complexity

❒ 

currently: SNMP V3

❒ 

de facto

network

management standard

(8)

Chapter 1 outline

❒ 

What is network management?

❒ 

Internet-standard management framework

❒ 

ASN.1

SNMP overview: 4 key parts

❒

 

Management Information Base (MIB):

❍ 

distributed information store of network

management data

❒

 

Structure of Management Information (SMI):

❍ 

data definition language for MIB objects

❒

 

SNMP protocol

❍ 

convey manager<->managed object info, commands

❒

 

security, administration capabilities

(9)

MIB: Management Information

Base

❒ 

The foundation of a network management system is

a

data base

containing information about the

elements to be managed

❒ 

Each system maintains a MIB that reflects the

status of the managed resources at that system

❒ 

The MIB must meet

two objectives

:

❍ The object(s) used to represent a particular resource

must be the same at each system

•  Example: A MIB for TCP/IP specifies that the active and passive open counts be stored for connections. Not the active ones and the total number, or …

•  This allows a simple protocol to be written to access the required information

❍ A common scheme (object identification and definition

language) for representation must be used to support interoperability

•  SMI

SMI: Structure of Management

Information

❒ 

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 structure of a particular MIB

❍ defining individual objects, including the syntax and the value of

each object

(10)

Object Naming

question:

how to

name

every possible standard object

(protocol, data, more…) in every possible network

standard

?

answer:

ISO Object Identifier tree:

❍ 

hierarchical naming of all objects

❍ 

each branchpoint has name, number

Check out www.alvestrand.no/objectid/top.html

(11)

Object Naming

question:

object identifier of

udpInDatagrams

(= total # datagrams delivered at this node)

?

answer:

1.3.6.1.2.1.7.1

ISO

ISO-ident. Org.

US DoD

Internet

udpInDatagrams

UDP

MIB2

management

SMI: data definition language

Purpose:

syntax, semantics of

management data

well-defined, unambiguous

❒ 

base data types:

❍ 

straightforward, boring

❒ 

OBJECT-TYPE

❍ 

data type, status,

semantics of managed

object

❒ 

MODULE-IDENTITY

❍ 

groups related objects

into MIB module

Basic Data Types

INTEGER

Integer32

Unsigned32

OCTET STRING

OBJECT IDENTIFIER

IPaddress

Counter32

Counter64

Gauge32

TimeTick

Opaque

(12)

Basic Data Types

❒ 

A subset of the ASN.1 notation is used to define :

❍ each individual object

❍ the entire MIB structure

❒ 

A subset of Universal types is used

❍ e.g. integer, octetstring, object identifier, sequence

❒ 

Some application-wide types are defined, such as:

❍ IPaddress

❍ Counter32: nonnegative integer that can only be incremented up to

232 _{-1 and then wraps around (roll over counter)}

❍ Gauge32: nonnegative integer that can be incremented up to 232 -1

and decremented. If the value increases beyond the maximum value, it will not roll over, it will remain stuck at its maximum value

❍ TimeTick: nonnegative integer that counts the number of 100th of

a second since some identified event. It is thus a relative timer.

MIB

OBJECT-TYPE: OBJECT-TYPE: _OBJECT-TYPE:

objects specified via SMI

OBJECT-TYPE

construct

MIB module specified via SMI

MODULE-IDENTITY

(100 standardized MIBs, more vendor-specific)

MODULE

(13)

SMI: Object, module examples

OBJECT-TYPE:

ipInDelivers

MODULE-IDENTITY:

ipMIB

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" as ip is 1.3.6.1.2.1.4"

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"

(14)

MIB example: UDP module

Object ID Name Type Comments

1.3.6.1.2.1.7.1 udpInDatagrams Counter32 total # datagrams delivered at this node

1.3.6.1.2.1.7.2 udpNoPorts Counter32 # undeliverable datagrams no app at port

1.3.6.1.2.1.7.3 udpInErrors Counter32 # undeliverable datagrams all other reasons

1.3.6.1.2.1.7.4 udpOutDatagrams Counter32 # datagrams sent 1.3.6.1.2.1.7.5 udpTable SEQUENCE one entry for each port

in use by app, gives port # and IP address

Defining table objects

❒ 

SMI supports only one form of structuring of

data:

❍ a simple two-dimensional table with scalar-valued entries

❍ The definition involves the SEQUENCE (OF) ASN.1 type

and the IndexPart of the OBJECT-TYPE macro

❒ 

Example: tcpConnTable

tcpConnTable OBJECT-TYPE"

SYNTAX" "SEQUENCE OF tcpConnEntry"

ACCESS "not-accessible"

STATUS" "mandatory"

DESCRIPTION ""A table containing TCP connection-specific info"" ::= {tcp 13}"

1.3.6.1.2.1.6.13" as tcp is 1.3.6.1.2.1.6"

(15)

Defining table objects (2)

tcpConnEntry OBJECT-TYPE"

SYNTAX" "TCPConnEntry"

DESCRIPTION""Info about a particular TCP connection. An object of" this type is transient, in that it ceases to exist when (or" soon after) the connection makes the transition to the" CLOSED state""

INDEX " "{tcpConnLocalAddress, tcpConnLocalPort, " tcpConnRemAddress, tcpConnRemPort}"

-- These 4 items are necessary and sufficient to distinguish a row" ::= {tcpConnTable 1}"

TCPConnEntry ::= SEQUENCE { tcpConnState INTEGER,"

tcpConnLocalAddress IpAddress," tcpConnLocalPort INTEGER (0..65535)," tcpConnRemAddress IpAddress," tcpConnRemPort INTEGER (0..65535)}" --Only these 5 are visible to network management" tcpConnState OBJECT-Type" …" 1.3.6.1.2.1.6.13.1" 1.3.6.1.2.1.6.13.1.1" 1.3.6.1.2.1.6.13.1.2" …"

Chapter 1 outline

❒ 

What is network management?

❒ 

Internet-standard management framework

(16)

SNMP Protocol

❒

 

Basic Concepts:

❍ 

SNMP in the protocol stack

❍ 

Operations supported by SNMP

❍ 

Communities and Community Names

❍ 

Instance Identification

❍ 

Lexicographical Ordering

SNMP in the protocol stack

Management station! Manager process" SNMP" UDP" IP" Network-dependent" Host! Agent process" SNMP" UDP" User processes" HTTP, …" TCP" IP" Network-dependent protocols" Agent process" SNMP" UDP" IP" Network-dependent" protocols" Router! Network" manager" Central MIB"

(17)

SNMP Proxies

Manager process" SNMP" UDP" IP" Network-" dependent" protocols" Management station! Proxy! Agent process" SNMP" UDP" IP" Network-" dependent" protocols" Protocol" architecture " used by " proxied" device" Network-" dependent" protocols" Mapping function" Management process" Protocol" architecture " used by " proxied" device" Network-" dependent" protocols" Proxied device! Network" Network"

Operations supported by SNMP

Two ways to convey MIB info, commands:

request/response mode

trap mode

Port 161 Port 162 agent data managed device managing entity agent data managed device managing entity

trap msg

request

response

(18)

SNMP protocol: message types

GetRequest

GetNextRequest

GetBulkRequest

Mgr-to-agent: “get me data”

(instance, next in list, block)

Message type

Function

InformRequest

Mgr-to-Mgr: here’s MIB value

SetRequest

Mgr-to-agent: set MIB value

Response

Agent-to-mgr: value, response to

Request

Trap

Agent-to-mgr: inform manager

of exceptional event

SNMP protocol: message formats

…. PDU type (0-3) Request ID Error Status (0-5) Error

Index Name Value Name Value

…. PDU type 4 Enterprise Agent Addr Trap Type (0-7) Specific code Time

stamp Name Value

Get/set header Variables to get/set

Trap header Trap info

(19)

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

network entity and the generation of the trap

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

(20)

Communities

❒ 

A management station usually manages several

objects

❒ 

But an object may be managed by several

management stations

❍ Each managed station must be able to control the use of

its MIB by a number of distinct management stations

❍ There are two aspects in this control:

•  Authentication service: authentication of manager

•  Access policy: different privileges to different managers

❍ These aspects relate to security for which SNMP (v1 and

v2) provides only a primitive and limited capacity, namely the concept of a community

Communities and Community Names

❒ 

A

SNMP community

is a relationship between an SNMP

agent and a set of SNMP managers that define

authentication and access control characteristics

❒ 

The community concept is a

local

one defined at the

managed

system

❒ 

The managed system establishes one community for each

desired combination of authentication and access control

characteristics

❒ 

Each community is given a

unique

(within this agent)

community name

❍ The same name may be used by different managed agents with

different meanings

❒ 

The management stations are provided with and must

employ the community name in all get and set operations

❍ A management station must keep track of the community name(s)

associated with each of the agents that it wishes to access

Version" Community" SNMP PDU"

(21)

Authentication service

❒

 

SNMP (v1 and v2) provides for only a trivial

scheme for authentication

❒

 

Every message from a management station

includes a community name

❍ 

It functions as a password

❒

 

With this limited form of authentication,

many network managers will be reluctant to

allow anything other than network

monitoring (get and trap)

❒

 

Network control is clearly a more sensitive

area

Access Policy

❒ 

Two aspects

❍ 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

clause

(22)

Relationship Between MIB ACCESS

Category and SNMP ACCESS Mode

SNMP Access Mode! MIB ACCESS! Category! READ-ONLY! READ-WRITE! read-only! write-only! not accessible!

Available for get and trap operations"

Available for get and trap" operations"

Available for get, set, and trap" operations"

Available for get and trap " operations, but the value is "

implementation-specific"

Available for get, set, and trap" operations, but the value is"

implementation-specific" for get and trap operations" Unavailable"

read-write!

Administrative concepts

❒ 

The combination of a SNMP community and a

SNMP community profile is an SNMP

access policy

SNMP"

agent" set of SNMPmanagers"" SNMP MIBview" " access modeSNMP" "

SNMP community"

(community name)" SNMP communityprofile" "

(23)

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

Instance Identification in SNMP

❒

 

Two techniques:

❍ 

Serial-access

technique

•  Based on a lexicographic ordering of objects

– The lexicographical order is defined later

•  Useful to access object instances sequentially

– Get-next request

❍ 

Random-access

technique

(24)

Random Access

❒

 

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

that row

❍ 

one set of values of the INDEX objects

Example: connection state

tcpConnEntry OBJECT-TYPE"

SYNTAX" "TCPConnEntry"

DESCRIPTION ""Info about a particulat TCP connection. An object of" this type is transient, in that it ceases to exist when (or" soon after) the connection makes the transition to the" CLOSED state""

INDEX " "{tcpConnLocalAddress, tcpConnLocalPort, " tcpConnRemAddress, tcpConnRemPort}" ::= {tcpConnTable 1}"

TCPConnEntry ::= SEQUENCE { tcpConnState INTEGER,"

tcpConnLocalAddress IpAddress," tcpConnLocalPort INTEGER (0..65535)," tcpConnRemAddress IpAddress," tcpConnRemPort INTEGER (0..65535)}" 1.3.6.1.2.1.6.13.1" 1.3.6.1.2.1.6.13.1.1" 1.3.6.1.2.1.6.13.1.2" …"

The connection state of the connection indexed by (10.0.0.99, 12, 9.1.2.3, 15)"

(25)

Random access to other objects

❒ 

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

(26)

SNMP security and administration

❒ 

View-based access control

❍ SNMP entity maintains database of access rights,

policies for various users

❍ this database is itself accessible as managed object!

❒ 

In SNMP v3:

❍ community-based “security model” NOT used

❍ encryption: DES-encrypt SNMP message, needs shared

secret key

❍ authentication: compute, send MIC(m,k): compute hash

(MIC = Message Integrity Code) over the concatenation of message (m) and secret shared key (k)

❍ protection against playback: use nonce

Chapter 1 outline

❒ 

What is network management?

❒ 

Internet-standard management framework

(27)

The presentation problem

Q:

does perfect memory-to-memory copy

solve “the communication problem”?

A:

not always!

problem:

different data format, storage conventions

struct { char code; int x; } test; test.x = 259; test.code=‘a’ a 00000001 00000011 a 00000011 00000001 test.code test.x test.code test.x

host 1 format host 2 format

A real-life presentation problem:

aging 60 s

hippie

2012 teenager

grandma

Groovy!

? ?

?

? ?

?

(28)

Presentation problem: potential solutions

1. Sender learns receiver’s format. Sender translates into receiver’s format. Sender sends.

– real-world analogy?

– pros and cons

?

2. Sender sends. Receiver learns sender’s format. Receiver translate into receiver-local format

– real-world-analogy?

– pros and cons?

3. Sender translates to host-independent format. Sends. Receiver translates to receiver-local format.

– real-world analogy?

– pros and cons?

❍ 

Needs machine-independent, OS-independent,

language-independent method for describing data

types!

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

format

2012 teenager aging 60 s hippie grandma presentation service presentation service presentation service “Groovy!” “It is pleasing to me!” “It is pleasing to me!”

“Cat’s pajamas!” “Awesome, dude!”

! ! ! ! ! ! ! !

(29)

ASN.1: Abstract Syntax Notation 1

❒

 

ISO standard

X.680

❍ 

used extensively in Internet

❍ 

like eating vegetables, knowing this “good for you”!

❒

 

defined data types

, object constructors

❍ 

like SMI

❒

 

BER: Basic Encoding Rules

❍ 

specify how ASN.1-defined data objects to be

transmitted

❍ 

each transmitted object has Type, Length, Value

(TLV) encoding

Abstract Syntax - Example

EmployeeRecord ::=

[APPLICATION 0]

SET

{

[0]

name

ISO646STRING

[1]

address

ISO646STRING

[2]

idNumber

EmployeeNoType}

EmployeeNoType ::= INTEGER

(30)

ASN.1 Compilers

❒

 

ASN.1 compilers translate ASN.1 into classical

programming languages: C, C++, Java, …

❒

 

Packet formats and data types are specified in

ASN.1

❍ 

MIB objects are also specified in ASN.1

❒

 

The ASN.1 compiler generates:

❍ 

One programming language type per ASN.1 type

❍ 

Encoding/decoding functions:

• Mapping local representation into a commonly agreed

transfer syntax

• Applies the Basic Encoding Rules (BER)

Role of tags

❒ 

ASN.1 uses tags to remove ambiguities on type

components

❍ Tags also used later by languages such as XML

❒ 

Example:

EmployeeRecord ::= SET { name

ISO646STRING

address ISO646STRING

idNumber EmployeeNoType}

EmployeeNoType ::= INTEGER

❒ 

Without tags, it would be impossible to discriminate the

name and address fields in an 'EmployeeRecord'

(31)

Classes of tags

❒ 

A tag is composed of two parts: its class and its number

❒ 

Classes of tags:

❍ UNIVERSAL class •  Universal types

•  1: BOOLEAN, 2: INTEGER, 3: BITSTRING, 4: OCTETSTRING, 6: Object-Identifier, 9: REAL, 10: ENUMERATED TYPE,

12: SEQUENCE (OF), 13: SET (OF), 23,24: TIME

❍ APPLICATION class

•  The numbers are assigned by the standards that describe the protocols

•  Their semantics are local to an application

❍ CONTEXT class

•  Used to remove ambiguities in the types

❍ PRIVATE class

Implicit tags

EmployeeRecord ::= "

[APPLICATION 0] IMPLICIT SET { "[0] name "ISO646STRING" " " " "[1] address "ISO646STRING" " " " "[2] idNumber "EmployeeNoType}" EmployeeNoType ::= INTEGER"

CONTEXT tag" APPLICATION 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

(32)

TLV Encoding

Idea:

transmitted data is self-identifying

❍  T: data type, one of ASN.1-defined types •  This actually means the tag

❍  L: length of data in bytes

❍  V: value of data, encoded according to ASN.1 standard •  If T is structured, then V is a set of component types (all

encoded recursively in the TLV style)

Class:" 00: UNIVERSAL" 01: APPLICATION" 10: CONTEXT" 11: PRIVATE" 0: simple type" 1: structured type" Number"

If tag number ≥ 31, then number is set to 31 and the next bytes contain the actual tag number (length + value)"

TLV

encoding:

example

Length, 5 bytes

Type=4, octet string

Length, 2 bytes

Type=2, integer

lastname ::= OCTET STRING weight ::= INTEGER

{weight, 259} {lastname, “smith”}

module of data type declarations written

in ASN.1

instances of data type specified in module

Basic Encoding Rules (BER) 3 1 2 2 h t i m s 5 4 transmitted byte stream

Value, 5 octets (chars)

(33)

Network Management: summary

❒ 

network management

❍ 

extremely important: 80% of network “cost”

❍ 

ASN.1 for data description

❍ 

SNMP protocol as a tool for conveying

information

❒ 

Network management: more art than science

❍ 

what to measure/monitor?

❍ 