< draft-ietf-nat-snmp-alg-04.txt		draft-ietf-nat-snmp-alg-05.txt >
	Network Working Group D. Raz		Network Working Group D. Raz
	Internet-Draft Lucent Technologies		Internet-Draft Lucent Technologies
	Expires: December 29, 2000 J. Schoenwaelder		Expires: January 5, 2001 J. Schoenwaelder
	TU Braunschweig		TU Braunschweig
	B. Sugla		B. Sugla
	ISPSoft Inc.		ISPSoft Inc.
	June 30, 2000		July 7, 2000
	An SNMP Application Level Gateway for Payload Address Translation		An SNMP Application Level Gateway for Payload Address Translation
	draft-ietf-nat-snmp-alg-04.txt		draft-ietf-nat-snmp-alg-05.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 35 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	To view the entire list of Internet-Draft Shadow Directories, see		To view the entire list of Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/iid-abstracts.txt		http://www.ietf.org/ietf/iid-abstracts.txt
	This Internet-Draft will expire on December 29, 2000.		This Internet-Draft will expire on January 5, 2001.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	Abstract		Abstract
	This document describes the Application Level Gateway (ALG) for the		This document describes the Application Level Gateway (ALG) for the
	Simple Network Management Protocol (SNMP) by which IP addresses in		Simple Network Management Protocol (SNMP) by which IP addresses in
	the payload of SNMP packets are statically mapped from one group to		the payload of SNMP packets are statically mapped from one group to
	skipping to change at page 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	8. Current Implementations . . . . . . . . . . . . . . . . . . . 14		8. Current Implementations . . . . . . . . . . . . . . . . . . . 14
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
	A. Description of the Encoding of SNMP Packets . . . . . . . . . 16		A. Description of the Encoding of SNMP Packets . . . . . . . . . 16
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19		Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The need for IP address translation arises when a network's internal		The need for IP address translation arises when a network's internal
	IP addresses cannot be used outside the network either for security		IP addresses cannot be used outside the network. Using basic network
	reasons or because they are invalid for use outside the network.		address translation allows local hosts on such private networks
	Using basic network address translation allows local hosts on such		(addressing realms) to transparently access the external global
	private networks (addressing realms) to transparently access the		Internet and enables access to selective local hosts from the
	external global Internet and enables access to selective local hosts		outside. In particular it is not unlikely to have several addressing
	from the outside. This solution is becoming widely popular as the		realms that are using the same private IPv4 address space within the
	range of IPv4 addresses is limited. In particular it is not unlikely		same organization.
	to have several addressing realms that are using the same private
	IPv4 address space within the same organization.
	In many of these cases, there is a need to manage the local		In many of these cases, there is a need to manage the local
	addressing realm from a manager site outside the domain. However,		addressing realm from a manager site outside the domain. However,
	managing such a network presents unique problems and challenges.		managing such a network presents unique problems and challenges.
	Most available management applications use SNMP (Simple Network		Most available management applications use SNMP (Simple Network
	Management Protocol) to retrieve information from the network		Management Protocol) to retrieve information from the network
	elements. For example, a router may be queried by the management		elements. For example, a router may be queried by the management
	application about the addresses of its neighboring elements. This		application about the addresses of its neighboring elements. This
	information is then sent by the router back to the management		information is then sent by the router back to the management
	station as part of the payload of an SNMP packet. In order to retain		station as part of the payload of an SNMP packet. In order to retain
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	the embedded private IPv4 address with 135.180.140.202 leads to the		the embedded private IPv4 address with 135.180.140.202 leads to the
	OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A. This		OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A. This
	example shows that an advanced SNMP ALG may change the overall		example shows that an advanced SNMP ALG may change the overall
	packet size since IP addresses embedded in an OID can change the		packet size since IP addresses embedded in an OID can change the
	size of the ASN.1/BER encoded OID.		size of the ASN.1/BER encoded OID.
	Another effect of an advanced SNMP ALG is that it changes the		Another effect of an advanced SNMP ALG is that it changes the
	lexicographic ordering of rows in conceptual tables as seen by the		lexicographic ordering of rows in conceptual tables as seen by the
	SNMP manager. This may have severe side-effects for management		SNMP manager. This may have severe side-effects for management
	applications that use lexicographic ordering to retrieve only parts		applications that use lexicographic ordering to retrieve only parts
	of a conceptual table. Some SNMP managers check lexicographic		of a conceptual table. Many SNMP managers check lexicographic
	ordering to detect loops caused by broken agents. Such a manager		ordering to detect loops caused by broken agents. Such a manager
	will incorrectly report agents behind an advanced SNMP ALG as broken		will incorrectly report agents behind an advanced SNMP ALG as broken
	SNMP agents.		SNMP agents.
	4.3 Packet Size and UDP Checksum		4.3 Packet Size and UDP Checksum
	Changing an IpAddress value in an SNMP packet does not change the		Changing an IpAddress value in an SNMP packet does not change the
	size of the SNMP packet. A basic SNMP ALG does therefore never		size of the SNMP packet. A basic SNMP ALG does therefore never
	change the size of the underlying UDP packet.		change the size of the underlying UDP packet.
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	packet may have the effect that the Response PDU can not be		packet may have the effect that the Response PDU can not be
	processed anymore. Thus, an advanced SNMP ALG may cause some SNMPv3		processed anymore. Thus, an advanced SNMP ALG may cause some SNMPv3
	interactions to fail.		interactions to fail.
	In both cases, the UDP checksum must be adjusted when making an IP		In both cases, the UDP checksum must be adjusted when making an IP
	address translation. We can use the algorithm from [18], but a small		address translation. We can use the algorithm from [18], but a small
	modification must be introduced as the modified bytes may start on		modification must be introduced as the modified bytes may start on
	an odd position. The C code shown in Figure 3 adjusts the checksum		an odd position. The C code shown in Figure 3 adjusts the checksum
	to a replacement of one byte in an odd or even position.		to a replacement of one byte in an odd or even position.
	Unlike TCP, the UDP checksum can be set to 0, which makes all the
	applications ignore it. This can be used by an SNMP ALG if the
	computational resources are limited.
	void checksumbyte(unsigned char *chksum, unsigned char *optr,		void checksumbyte(unsigned char *chksum, unsigned char *optr,
	unsigned char *nptr, int odd)		unsigned char *nptr, int odd)
	/* assuming: unsigned char is 8 bits, long is 32 bits,		/* assuming: unsigned char is 8 bits, long is 32 bits,
	we replace one byte by one byte in an odd position.		we replace one byte by one byte in an odd position.
	- chksum points to the chksum in the packet		- chksum points to the chksum in the packet
	- optr points to the old byte in the packet		- optr points to the old byte in the packet
	- nptr points to the new byte in the packet		- nptr points to the new byte in the packet
	- odd is 1 if the byte is in an odd position 0 otherwise		- odd is 1 if the byte is in an odd position 0 otherwise
	*/		*/
	{ long x, old, new;		{ long x, old, new;
	skipping to change at page 11, line 7 ¶		skipping to change at page 10, line 52 ¶
	An advanced SNMP ALG described in Section 4.2 achieves better		An advanced SNMP ALG described in Section 4.2 achieves better
	transparency. However, an advanced SNMP ALG can only claim to be		transparency. However, an advanced SNMP ALG can only claim to be
	transparent for the set of data types (textual conventions)		transparent for the set of data types (textual conventions)
	understood by the advanced SNMP ALG implementation and for a given		understood by the advanced SNMP ALG implementation and for a given
	set of MIB modules. The price paid for better transparency is		set of MIB modules. The price paid for better transparency is
	additional complexity, potentially increased SNMP packet sizes and		additional complexity, potentially increased SNMP packet sizes and
	mixed up lexicographic ordering. Especially with SNMPv3, there is		mixed up lexicographic ordering. Especially with SNMPv3, there is
	an opportunity that communication fails due to increased packet		an opportunity that communication fails due to increased packet
	sizes. Management applications that rely on lexicographic ordering		sizes. Management applications that rely on lexicographic ordering
	may show erroneous behaviour.		will show erroneous behaviour.
	Both, basic and advanced SNMP ALGs, introduce problems when using		Both, basic and advanced SNMP ALGs, introduce problems when using
	SNMPv3 security features. The SNMPv3 authentication mechanism		SNMPv3 security features. The SNMPv3 authentication mechanism
	protects the whole SNMP message against modifications while the		protects the whole SNMP message against modifications while the
	SNMPv3 privacy mechanism protects the payload of SNMPv3 messages		SNMPv3 privacy mechanism protects the payload of SNMPv3 messages
	against unauthorized access. Thus, an SNMP ALG must have access to		against unauthorized access. Thus, an SNMP ALG must have access to
	all localized keys in use in order to modify SNMPv3 messages without		all localized keys in use in order to modify SNMPv3 messages without
	invalidating them. Futhermore, the SNMP ALG must track any key		invalidating them. Futhermore, the SNMP ALG must track any key
	changes in order to function. More details on the security		changes in order to function. More details on the security
	implications of using SNMP ALGs can be found in Section 6.		implications of using SNMP ALGs can be found in Section 6.
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 27 ¶
	messages with authentication and optionally encryption (auth/noPriv		messages with authentication and optionally encryption (auth/noPriv
	and auth/priv) can only be processed by an SNMP ALG which supports		and auth/priv) can only be processed by an SNMP ALG which supports
	the corresponding cryptographic algorithms and which has access to		the corresponding cryptographic algorithms and which has access to
	the keys in use. Furthermore, as keys may be updated, the SNMP ALG		the keys in use. Furthermore, as keys may be updated, the SNMP ALG
	must have a mechanism that tracks key changes (either by analyzing		must have a mechanism that tracks key changes (either by analyzing
	the key change interactions or by propagating key changes by other		the key change interactions or by propagating key changes by other
	mechanisms). Second, the computational complexity of processing SNMP		mechanisms). Second, the computational complexity of processing SNMP
	messages may increase dramatically. The message has to be decrypted		messages may increase dramatically. The message has to be decrypted
	before the translation takes place. If any translation is done the		before the translation takes place. If any translation is done the
	hash signature used to authenticate the message and to protect its		hash signature used to authenticate the message and to protect its
	integrity must be recomputed. This process may take time and thus it		integrity must be recomputed.
	may be required to track and modify the timeliness variable
	(msgAuthoritativeEngineTime) in the SNMP message.
	In general, key exchange protocols are complicated and designing an		In general, key exchange protocols are complicated and designing an
	SNMP ALG which maintains the keys for a set of SNMP engines is a		SNMP ALG which maintains the keys for a set of SNMP engines is a
	non-trivial task. The User-based Security Model for SNMPv3 [12]		non-trivial task. The User-based Security Model for SNMPv3 [12]
	defines a mechanism which takes a password and generates localized		defines a mechanism which takes a password and generates localized
	keys for every SNMP engine. The localized keys have the property		keys for every SNMP engine. The localized keys have the property
	that a compromised single localized key does not automatically give		that a compromised single localized key does not automatically give
	an attacker access to other SNMP engines, even if the key for other		an attacker access to other SNMP engines, even if the key for other
	SNMP engines is derived from the same password.		SNMP engines is derived from the same password.
End of changes. 10 change blocks.
	22 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/