Internet Applications: Electronic Mail and Network Management

개요

Chapter 22는 TCP/IP application layer가 실제 distributed application을 어떻게 지원하는지 보여주는 두 사례를 다룬다. 하나는 가장 널리 쓰이는 사용자 application인 electronic mail이고, 다른 하나는 distributed system을 감시하고 제어하기 위한 support application인 network management다.

이 장의 핵심 흐름은 SMTP → MIME → SNMPv1 → SNMPv2 → SNMPv3다. SMTP(Simple Mail Transfer Protocol)는 기본 e-mail transfer를 담당하지만, 원래 simple text block 전송에 맞춰져 있다. MIME(Multipurpose Internet Mail Extensions)는 SMTP/RFC 822의 틀을 유지하면서 multimedia, non-ASCII text, binary data를 e-mail로 보낼 수 있게 확장한다. SNMP(Simple Network Management Protocol)는 management station과 managed device 사이에서 management information을 조회, 설정, 보고하게 하는 표준 protocol family다.

핵심 개념

세부 정리

22.1 Electronic Mail: SMTP and MIME

전자우편(electronic mail)은 distributed system에서 가장 많이 쓰이는 application 중 하나다. TCP/IP suite에서 그 기본 전송 역할을 오래 맡아온 protocol이 SMTP(Simple Mail Transfer Protocol)이다. 하지만 전통적인 SMTP는 simple text message delivery에 맞춰져 있었고, voice, image, video clip 같은 다양한 data type을 mail로 보내려는 요구를 만족시키기 어렵다. 이 한계를 SMTP 위에서 확장한 표준이 MIME(Multipurpose Internet Mail Extensions)이다.

SMTP의 역할과 범위

SMTP는 TCP/IP suite에서 host 간 mail을 transfer하기 위한 standard protocol이며, 원문은 RFC 821로 정의된다고 설명한다. SMTP로 옮기는 message는 보통 RFC 822 형식을 따르지만, SMTP 자체는 message format/content를 거의 해석하지 않는다.

이 관계는 mail envelope 비유로 이해하면 좋다.

즉 SMTP는 “mail content의 의미”가 아니라 “mail을 어느 host의 어느 recipient 쪽으로 넘길 것인가”에 집중한다. Content 자체의 표현력 문제는 나중에 MIME이 맡는다.

Basic Electronic Mail Operation

Figure 22.1은 SMTP가 전체 mail system 안에서 어디에 위치하는지 보여준다. 이 그림에서 중요한 점은 SMTP protocol이 mail system 전체를 정의하지 않는다는 것이다. User agent, outgoing queue, local mailbox, forwarding policy 등은 SMTP 주변의 mail-handling apparatus이고, SMTP 자체는 SMTP sender와 SMTP receiver 사이의 conversation으로 제한된다.

Figure 22.1 · PDF p. 765 · outgoing mail queue에서 SMTP sender가 TCP port 25로 전송하고 SMTP receiver가 mailbox/queue로 넘기는 흐름

Outgoing mail의 흐름은 다음과 같다.

1. User가 user agent를 통해 mail을 작성한다.
2. 생성된 message는 header와 body를 가진다.
3. User agent가 header에서 recipient를 해석해 destination list를 만든다.
4. Mailing list expansion, duplicate removal, mnemonic name을 실제 mailbox name으로 바꾸는 처리가 일어날 수 있다.
5. BCC(blind carbon copy)가 있으면 이를 만족하도록 별도 message를 준비한다.
6. Message text와 destination list가 outgoing mail queue에 들어간다.
7. SMTP sender가 queue에서 message를 꺼내 destination host의 SMTP receiver로 TCP connection을 열고 전송한다.

SMTP sender는 보통 target host의 TCP port 25에 접속한다. Host의 outgoing mail volume이 크면 여러 SMTP sender가 동시에 동작할 수 있고, incoming mail이 서로 지연되지 않도록 SMTP receiver를 필요할 때 생성할 수도 있다.

SMTP sender는 queue 처리에서 최적화를 수행할 수 있다.

Error Handling과 Responsibility Boundary

SMTP sender는 destination host unreachable, host down, TCP connection failure, 잘못된 destination address 같은 error를 처리해야 한다. 전송 실패 시 mail을 다시 queue에 넣고 나중에 delivery를 재시도할 수 있지만, 무한히 보관하지는 않는다. 일정 시간이 지나면 포기하고 originator에게 error notification을 돌려줄 수 있다. 사용자가 주소를 잘못 입력했거나 recipient가 다른 host로 이동한 경우에는 가능하면 redirect하고, 불가능하면 오류를 반환한다.

SMTP는 TCP connection 위에서 reliable transfer를 시도하지만, end-to-end delivery guarantee를 제공하지 않는다. SMTP receiver가 “transfer complete”라고 응답했다는 것은 message가 receiver host에 도착했다는 뜻이지, 최종 recipient가 mailbox에서 읽었다는 뜻이 아니다. 원문에 “SNMP does not guarantee”라고 보이는 문맥은 SMTP 설명 흐름상 SMTP의 error indication 한계를 말하는 것으로 이해해야 한다.

책임 경계는 다음처럼 정리할 수 있다.

Message는 보통 originator machine에서 destination machine으로 single TCP connection을 통해 직접 이동한다. 그러나 SMTP forwarding을 거쳐 intermediate machine들을 지날 수도 있다. 사용자가 server sequence 형태로 route를 지정하는 경우도 있고, 더 흔하게는 recipient가 이동해서 forwarding이 필요한 경우다.

SMTP operation은 이후 세부적으로 command와 reply의 연속으로 설명된다. Initiative는 SMTP sender에게 있으며, sender가 TCP connection을 만들고 command를 보내면 receiver는 각 command마다 정확히 하나의 reply를 반환한다.

SMTP Commands와 Replies

SMTP command는 한 줄의 text로 이루어지고, 보통 네 글자 command code로 시작한다. 뒤에 argument field가 붙을 수 있다. Reply도 대개 한 줄이지만, multi-line reply도 가능하다. 중요한 점은 “각 command마다 정확히 하나의 reply”가 온다는 command/response 구조다.

핵심 command는 다음과 같다.

SMTP reply는 three-digit code로 시작한다. Leading digit는 reply category를 나타낸다.

SMTP의 error handling은 code만 외우는 문제가 아니라 “재시도 가능한 실패인가, permanent failure인가”를 구분하는 protocol design이다. Queue 기반 mail system에서는 transient error면 나중에 재시도할 수 있지만, permanent error면 originator에게 notification을 돌려줘야 한다.

SMTP Operation: Connection Setup, Mail Transfer, Connection Closing

SMTP operation은 세 phase로 나뉜다.

Connection setup의 정상 흐름은 다음과 같다.

Sender opens TCP connection
Receiver: 220 Service Ready
Sender:   HELO <domain>
Receiver: 250 OK

Destination mail service가 unavailable하면 receiver는 421 Service Not Available을 반환하고 process는 종료된다.

Mail transfer는 MAIL → RCPT → DATA의 세 logical phase로 구성된다.

RCPT phase를 분리하는 것이 중요하다. Sender가 message body 전체를 먼저 보냈는데 recipient가 unknown이라는 사실을 뒤늦게 알면 bandwidth와 processing overhead가 낭비된다. SMTP는 recipient를 먼저 하나씩 확인하고, receiver가 적어도 한 명 이상의 recipient에 대해 message를 받을 준비가 되었을 때만 DATA로 body를 보낸다.

DATA 이후 receiver가 354 Start mail input; end with <CRLF>.<CRLF>를 반환하면 sender는 message를 ASCII line sequence로 전송한다. Message 끝은 period 하나만 있는 line, 즉 <CRLF>.<CRLF>로 표시된다. Receiver가 message를 accept하면 250 OK를 반환하고, 실패하면 적절한 error code를 반환한다.

원문의 RFC 821 예시는 이 흐름을 잘 보여준다.

S: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK
S: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK
S: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown@Beta.ARPA>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK

여기서 Smith@Alpha.ARPA가 보낸 message는 Beta.ARPA의 Jones, Green, Brown에게 가려 한다. Receiver는 Jones와 Brown은 accept하지만 Green은 unknown recipient로 reject한다. 하지만 적어도 하나 이상의 recipient가 verified되었으므로 sender는 message text를 전송한다.

Connection closing은 두 단계다. Sender가 QUIT을 보내고 receiver reply를 기다린 뒤 TCP close를 시작한다. Receiver는 QUIT reply를 보낸 뒤 자신의 TCP close를 시작한다. SMTP는 TCP의 full-duplex capability 위에서 동작하지만, protocol conversation 자체는 command/reply 중심으로 순서화되어 있어 half-duplex처럼 보인다.

RFC 822 Message Format

RFC 822는 electronic mail에서 쓰이는 text message format을 정의한다. SMTP는 message 전송에 이 format을 채택한다. RFC 822 관점에서 message는 envelope과 contents로 나뉜다.

RFC 822 message는 text line sequence이며, memo framework를 사용한다. 먼저 rigid format을 따르는 header lines가 나오고, blank line 뒤에 arbitrary text body가 온다. Header line은 보통 keyword: arguments 형식이며, 긴 header line은 여러 줄로 접을 수 있다.

자주 쓰이는 header keyword는 다음과 같다.

간단한 구조는 다음처럼 볼 수 있다.

Date: Tue, 16 Jan 1996 10:37:17 (EST)
From: "William Stallings" <ws@host.com>
Subject: The Syntax in RFC 822
To: Smith@Other-Host.com
Cc: Jones@Yet-Another-Host.com

Hello. This section begins the actual message body.

SMTP와 RFC 822의 관계를 정리하면, SMTP는 “어떻게 host 사이에서 mail을 넘길 것인가”이고 RFC 822는 “넘겨지는 text mail contents가 어떤 header/body 형식을 갖는가”다. 이후 MIME은 이 RFC 822 framework를 유지하면서 nontextual data와 다양한 character set을 다룰 수 있게 확장한다.

MIME이 필요한 이유

MIME(Multipurpose Internet Mail Extensions)은 RFC 822 framework를 확장해 SMTP/RFC 822 mail의 한계를 해결한다. 핵심 요구는 기존 RFC 822 implementation과 compatible하면서도 multimedia mail을 표준적으로 표현하고 운반하는 것이다.

SMTP/822 scheme의 한계는 다음과 같다.

MIME의 목적은 “아무 data나 그냥 SMTP로 보내자”가 아니라, mail transport system이 변형하기 쉬운 환경에서도 content를 안전하게 표현할 수 있는 표준 header, content type, transfer encoding을 정의하는 것이다.

MIME Overview와 Header Fields

MIME specification은 세 요소로 이루어진다.

MIME이 정의한 다섯 header field는 다음과 같다.

Compliant implementation은 MIME-Version, Content-Type, Content-Transfer-Encoding을 지원해야 한다. Content-ID와 Content-Description은 optional이며 recipient implementation이 무시할 수도 있다.

MIME Content Types

MIME의 많은 부분은 content type 정의에 할애된다. Content type은 data의 general type을 나타내고, subtype은 해당 type 안의 specific format을 나타낸다.

multipart type은 boundary parameter가 중요하다. Content-Type: multipart/mixed; boundary="simple boundary"처럼 boundary를 지정하면, body 안 각 part는 새 line에서 --boundary로 시작한다. 마지막 part 뒤에는 --boundary--처럼 boundary 뒤에 hyphen 두 개가 추가된다. 각 part 안에는 optional ordinary MIME header가 올 수 있다.

Multipart subtype은 용도가 다르다.

message type은 mail 안에 또 다른 message 또는 message reference를 넣는 기능을 제공한다.

application/octet-stream은 general binary data를 나타낸다. RFC 2045는 receiving implementation이 이를 file로 저장하거나 program input으로 사용할 수 있게 제안한다. 이 subtype은 MIME이 “mail body는 사람이 읽는 text”라는 가정을 벗어나 binary payload까지 담는다는 점을 잘 보여준다.

MIME Transfer Encodings

Content-Transfer-Encoding은 content를 mail transport가 안전하게 운반할 수 있는 representation으로 바꾸는 방법을 표시한다. 이 field는 여섯 값을 가질 수 있다.

7bit, 8bit, binary는 실제 encoding을 수행했다기보다 data의 성질을 알려주는 값이다. MIME이 실제로 정의하는 두 encoding scheme은 quoted-printable과 base64다. 두 scheme은 서로 다른 trade-off를 가진다.

Quoted-printable은 unsafe character를 = 뒤에 two-digit hexadecimal octet value로 표현한다. 예를 들어 ASCII form feed의 8-bit 값 decimal 12는 =0C로 표현된다. Printable ASCII range의 많은 문자는 그대로 두지만, = 자체는 encoding 대상이다. Line 끝의 tab/space는 transport agent가 바꾸거나 제거할 수 있으므로 hex representation으로 표현해야 한다. Encoded line이 76 characters를 넘을 것 같으면 soft line break를 삽입한다.

base64, 즉 radix-64 encoding은 arbitrary binary input을 universally representable printable character output으로 바꾼다. Control character를 쓰지 않고, RFC 822에서 의미가 있는 hyphen도 character set에서 제외한다. Character set은 A-Z, a-z, 0-9, +, /의 64개와 padding character =로 구성된다.

Figure 22.2 · PDF p. 779 · 24-bit binary input을 네 개의 radix-64 printable character, 즉 32-bit output으로 mapping하는 방식

Base64의 기본 단위는 3 octets = 24 bits다. 이를 6-bit group 네 개로 나누고, 각 6-bit value를 printable character 하나로 mapping한다. 각 output character는 실제 저장/전송 시 보통 8-bit ASCII로 표현되므로 24-bit input이 32-bit output이 된다.

원문 예시는 다음과 같다.

Input binary: 00100011 01011100 10010001
Input hex:    235C91

Split into 6-bit groups:
001000 110101 110010 010001

Decimal values:
8, 53, 50, 17

Radix-64 characters:
I1yR

ASCII bytes with zero parity:
01001001 00110001 01111001 01010010
Hex output:
49317952

MIME의 핵심 설계 감각은 “content semantics”와 “transport safety”를 분리하는 것이다. Content-Type은 body가 무엇인지 말하고, Content-Transfer-Encoding은 그 body를 낡고 다양한 mail transport system을 통과해도 안전한 byte/text representation으로 어떻게 포장했는지 말한다.

22.2 Network Management: SNMP

조직의 network와 distributed processing system이 커질수록 두 가지 사실이 분명해진다. 첫째, network와 관련 resources/applications는 조직 운영에 필수적이다. 둘째, 규모가 커질수록 장애 지점이 늘어나고, network 전체 또는 일부가 중단되거나 performance가 수용 불가능한 수준으로 떨어질 가능성도 커진다.

대규모 reliable network는 사람이 수동으로만 관리하기 어렵다. 특히 multi-vendor equipment가 섞이면 monitoring, control, management information을 표준화한 automated network management tools가 필요하다. 이 요구에 대응하는 가장 널리 쓰이는 표준이 SNMP(Simple Network Management Protocol)다.

Network Management System

network management system은 network monitoring과 control을 위한 tool들의 집합이다. 원문은 통합의 의미를 두 가지로 설명한다.

Network management system은 기존 network component 위에 incremental hardware/software addition을 올리는 방식이다. Host computer, communication processor, network switch, router 등에 management software가 들어가고, system은 network 전체를 unified architecture로 바라본다. 각 point에는 address/label이 부여되고, element/link attribute가 system에 알려져 있으며, active elements는 network control center에 status information을 정기적으로 feedback한다.

SNMPv1 Basic Concepts

SNMPv1은 원래 TCP/IP network와 internetwork를 관리하기 위한 tool로 개발되었지만, 이후 여러 networking environment로 확장되었다. SNMP라는 이름은 protocol 하나만 가리키기보다 protocol, database definition, associated concepts를 포함한 network management specification collection을 가리킨다.

SNMP network management model의 key elements는 다음 네 가지다.

Management station은 standalone device일 수도 있고 shared system 위 capability일 수도 있다. 최소한 management applications, human manager interface, manager 요구를 remote element monitoring/control로 바꾸는 capability, managed entities에서 추출한 management information database를 가진다. 이 중 SNMP standardization의 직접 대상은 remote monitoring/control로 변환하는 capability와 management information database 쪽이다.

Agent는 management station으로부터 information request와 action request를 받고, 중요한 event를 unsolicited information 형태로 management station에 비동기적으로 제공할 수 있다.

MIB와 Managed Object

SNMP에서 network resource는 object로 표현된다. Object는 managed agent의 한 aspect를 나타내는 data variable이다. 이 object들의 collection이 MIB(Management Information Base)다.

MIB는 management station이 agent에 접근하는 access point collection처럼 동작한다.

SNMP protocol family가 제공하는 기본 capability는 세 가지다.

Centralized vs Distributed Network Management

전통적인 centralized management에서는 하나의 host가 network management station 역할을 하고, 나머지 device들은 agent software와 MIB를 가진다. 그러나 network가 커지고 traffic load가 커지면 이 구조는 부담이 커진다. 모든 agent report가 central headquarters까지 가야 하므로 management station의 processing burden과 network traffic이 증가한다.

이때 더 적합한 방식이 decentralized/distributed management다.

Figure 22.3 · PDF p. 782 · top-level management server, intermediate manager, agent로 나뉜 distributed network management 구성

Distributed scheme에서는 여러 top-level management station, 즉 management server가 network 일부를 직접 관리한다. 많은 agent에 대해서는 intermediate manager에게 책임을 위임한다. Intermediate manager는 아래쪽 agent에 대해서는 manager 역할을 하고, 위쪽 management server에 대해서는 agent 역할을 한다. 이 architecture는 processing burden을 분산하고 total network traffic을 줄인다.

SNMPv1 Protocol Architecture

SNMP는 TCP/IP suite의 application-level protocol이며, UDP(User Datagram Protocol) 위에서 동작하도록 의도되었다. Standalone management station에는 central MIB 접근을 제어하고 network manager에게 interface를 제공하는 manager process가 있다. Manager process는 UDP, IP, network-dependent protocol 위에서 SNMP를 사용해 network management를 수행한다.

Figure 22.4 · PDF p. 783 · management station, host, router에서 SNMP가 UDP/IP 위에 배치되는 SNMPv1 configuration

Agent device도 SNMP, UDP, IP를 구현해야 한다. 또한 SNMP message를 해석하고 agent의 MIB를 제어하는 agent process가 필요하다. 해당 device가 FTP 같은 다른 application도 지원하면 TCP도 함께 필요할 수 있다. Figure 22.4에서 shaded 부분은 managed operational environment이고, unshaded 부분은 network management function을 지원하는 protocol/process다.

SNMP가 UDP에 의존하기 때문에 SNMP 자체도 connectionless다. Management station과 agent 사이에 ongoing connection을 유지하지 않는다. 대신 각 exchange가 별도의 transaction이다. 이 단순성은 overhead를 낮추지만, reliable stream이나 session state에 기대지 않는 방식으로 management operation을 설계해야 한다는 뜻이기도 하다.

SNMPv1 Message Role

Figure 22.5는 management application과 SNMP manager/agent 사이에서 message가 어떤 역할을 하는지 더 직접적으로 보여준다.

Figure 22.5 · PDF p. 784 · SNMP manager가 GetRequest, GetNextRequest, SetRequest를 보내고 agent가 GetResponse/Trap으로 응답·보고하는 구조

Management station은 management application을 대신해 세 종류의 SNMP message를 발행한다.

Port 번호도 role을 반영한다. Management request는 UDP port 161로 보내고, agent의 trap은 UDP port 162로 보낸다.

SNMPv1의 장점은 이름 그대로 단순성이다. Limited and easily implemented MIB, streamlined protocol, scalar variables와 two-dimensional tables 중심 구조 덕분에 다양한 vendor의 management station과 agent software가 interoperability를 달성하기 쉽다. 단점도 여기서 나온다. 기능이 제한적이고, security facility가 부족하다. 이 기능적/보안적 결함이 SNMPv2와 SNMPv3로 이어진다.

SNMPv2 Elements

SNMPv2는 SNMPv1처럼 network management application을 만들기 위한 framework를 제공한다. Fault management, performance monitoring, accounting 같은 application 자체는 표준 범위 밖이고, SNMPv2는 management information을 표현하고 교환하는 infrastructure를 제공한다.

SNMPv2의 essence는 management information exchange protocol이다. Network management system의 각 player는 local MIB를 유지한다. SNMPv2 standard는 이 information의 structure와 allowable data types를 정의하며, 이 정의를 SMI(Structure of Management Information)라고 부른다. SMI는 management information을 정의하기 위한 language처럼 볼 수 있다.

Figure 22.6 · PDF p. 785 · manager server, element manager, agent가 SNMPv2 manager/agent role로 연결되는 managed configuration

SNMPv2는 centralized management와 distributed management를 모두 지원한다. Distributed strategy에서는 일부 system이 manager와 agent 역할을 모두 수행한다.

SNMPv2 exchange도 simple request/response type protocol이며, 보통 UDP 위에서 구현된다. Exchange가 discrete request-response pair 성격이므로 ongoing reliable connection이 필요하지 않다.

SMI: Structure of Management Information

SMI는 MIB를 정의하고 구성하는 general framework다. 세 가지를 정한다.

SMI의 철학은 simplicity와 extensibility다. MIB는 simple data types만 저장할 수 있고, 복잡한 data structure 생성/검색을 지원하지 않는다. Scalar와 scalar의 two-dimensional array인 table을 중심으로 한다. 이는 더 풍부한 기능을 제공하는 OSI systems management와 대비된다. SNMPv2가 complex data type을 피하는 이유는 implementation을 단순화하고 interoperability를 높이기 위해서다. Vendor-created data type이 inevitable한 상황에서 제한을 느슨하게 두면 interoperability가 무너지기 쉽다.

대표 allowable data types는 다음과 같다.

SNMPv2 PDU Format과 Protocol Operation

SNMPv2의 basic unit of exchange는 message다. Message는 outer message wrapper와 inner PDU(Protocol Data Unit)로 구성된다. Outer message header는 security와 관련되고, inner PDU는 management operation 자체를 담는다.

Figure 22.7 · PDF p. 787 · SNMPv2 PDU의 request-id, error-status, GetBulk field, variable-bindings 구조

SNMPv2 PDU에서 자주 등장하는 field는 다음과 같다.

SNMPv2가 운반할 수 있는 주요 PDU는 다음과 같다.

SNMPv2의 중요한 개선점은 partial response와 bulk retrieval이다. SNMPv1에서는 GetRequest 안 변수 중 하나라도 unsupported이면 noSuchName error로 전체가 실패할 수 있었다. SNMPv2는 relevant MIB view에 없는 variable에 대해 identifier와 error code를 variable-bindings list에 넣으면서 가능한 값은 함께 반환할 수 있다. GetBulkRequest는 large table이나 많은 object를 가져올 때 request-response 횟수를 줄인다.

SetRequest는 atomic하다. Variable-bindings list의 모든 variable을 update할 수 있으면 모두 반영하고 Response-PDU에 값을 포함한다. 하나라도 실패하면 아무 값도 update하지 않으며, error-status와 error-index가 실패 이유와 위치를 나타낸다.

SNMPv3 Security

SNMPv2는 SNMPv1의 많은 functional deficiency를 해결했지만, security deficiency는 남아 있었다. 이를 보완하기 위해 SNMPv3가 정의되었다. SNMPv3는 완전히 새로운 management protocol을 제공한다기보다, 기존 SNMPv2와 함께 사용할 overall SNMP architecture와 security capabilities를 정의한다.

SNMPv3의 중요한 service는 세 가지다.

SNMPv3 security service는 service를 요청하는 user identity에 의해 governed된다. 이 identity는 principal로 표현되며, individual, application, group일 수 있다.

Authentication은 message authentication code를 사용한다. Sender principal은 SNMP message에 authentication code를 포함한다. 이 code는 message contents, sending/receiving party identity, transmission time, sender/receiver만 알아야 하는 secret key의 function이다. Receiver는 같은 secret key로 code를 다시 계산해 incoming value와 비교한다. 일치하면 authorized manager가 보낸 message이며 transit 중 변경되지 않았다고 판단할 수 있다. 실제 authentication code는 Internet-standard authentication mechanism인 HMAC이다.

중요한 practical point는 shared secret key가 USM 내부에서 자동으로 생성/분배되는 것이 아니라 preconfigured되어야 한다는 점이다. Configuration manager나 network manager가 SNMP manager와 agent database에 secret key를 넣어야 하며, 수동 또는 USM 외부 secure data transfer를 사용할 수 있다.

Privacy facility도 manager principal과 agent principal이 shared secret key를 가져야 한다. Privacy를 사용하도록 configured되면 양자 사이 traffic은 DES(Data Encryption Standard)로 encrypted된다.

Access control은 agent가 manager별로 MIB access level을 다르게 제공하게 한다. 제한은 두 가지 방향으로 이루어진다.

Agent는 manager별 access policy를 preconfigured table로 유지한다. 이 점에서 SNMPv3는 Chapter 21의 authentication, privacy/confidentiality, access control 개념을 network management protocol에 직접 적용한 사례다.

연결 관계

Chapter 22의 두 application은 서로 성격이 다르지만 application-layer protocol 설계의 공통 원칙을 보여준다.

앞 장과의 연결도 뚜렷하다. SMTP는 TCP의 reliable byte stream을 사용하지만 application-level acknowledgement는 제한적이다. SNMP는 UDP의 low-overhead datagram model을 사용해 management exchange를 discrete transaction으로 처리한다. MIME의 base64/radix-64는 data representation과 line-oriented mail transport의 제약을 맞추는 encoding 문제이며, SNMPv3의 HMAC/DES는 Chapter 21의 MAC과 symmetric encryption이 실제 protocol security에 쓰이는 예다.

오해하기 쉬운 내용

면접 질문

1. SMTP의 책임 범위와 user agent/mailbox/local queue의 책임을 구분해 설명하라.
2. SMTP에서 MAIL, RCPT, DATA command를 분리한 이유를 설명하라.
3. SMTP reply code의 leading digit가 의미하는 category를 설명하라.
4. RFC 821과 RFC 822의 차이를 설명하라.
5. MIME이 SMTP/RFC 822의 어떤 한계를 해결하는지 예를 들어 설명하라.
6. Content-Type과 Content-Transfer-Encoding의 차이를 설명하라.
7. quoted-printable과 base64(radix-64) encoding의 사용 상황과 trade-off를 설명하라.
8. SNMP의 management station, agent, MIB, network management protocol의 역할을 설명하라.
9. SNMP가 UDP 위에서 동작할 때 얻는 장점과 설계상 주의점을 설명하라.
10. SNMPv1의 GetRequest, GetNextRequest, SetRequest, GetResponse, Trap의 차이를 설명하라.
11. SNMPv2에서 GetBulkRequest-PDU와 partial response가 왜 개선점인지 설명하라.
12. SNMPv3의 USM, VACM, HMAC, DES가 각각 어떤 보안 서비스를 제공하는지 설명하라.

핵심 용어 정리