draft-ietf-lwig-minimal-esp-06.txt		draft-ietf-lwig-minimal-esp-07.txt
	Light-Weight Implementation Guidance (lwig) D.M. Migault		Light-Weight Implementation Guidance (lwig) D.M. Migault
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational T.G. Guggemos		Intended status: Informational T.G. Guggemos
	Expires: 27 January 2022 LMU Munich		Expires: 1 April 2022 LMU Munich
	26 July 2021		28 September 2021
	Minimal ESP		Minimal ESP
	draft-ietf-lwig-minimal-esp-06		draft-ietf-lwig-minimal-esp-07
	Abstract		Abstract
	This document describes a minimal implementation of the IP		This document describes a minimal IP Encapsulation Security Payload
	Encapsulation Security Payload (ESP) defined in RFC 4303. Its		(ESP) defined in RFC 4303. Its purpose is to enable implementation
	purpose is to enable implementation of ESP with a minimal set of		of ESP with a minimal set of options to remain compatible with ESP as
	options to remain compatible with ESP as described in RFC 4303. A		described in RFC 4303. A minimal version of ESP is not intended to
	minimal version of ESP is not intended to become a replacement of the		become a replacement of the RFC 4303 ESP. Instead, a minimal
	RFC 4303 ESP. Instead, a minimal implementation is expected to be		implementation is expected to be optimized for constrained
	optimized for constrained environment while remaining interoperable		environment while remaining interoperable with implementations of RFC
	with implementations of RFC 4303 ESP. Some constraints include		4303 ESP. In addition, this document also provides some
	limiting the number of flash writes, handling frequent wakeup / sleep		considerations to implement minimal ESP in a constrained environment
	states, limiting wakeup time, or reducing the use of random		which includes limiting the number of flash writes, handling frequent
	generation.		wakeup / sleep states, limiting wakeup time, or reducing the use of
			random generation.
	This document does not update or modify RFC 4303, but provides a		This document does not update or modify RFC 4303, but provides a
	compact description of how to implement the minimal version of the		compact description of how to implement the minimal version of the
	protocol. RFC 4303 remains the authoritative description.		protocol. RFC 4303 remains the authoritative description.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		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."
	This Internet-Draft will expire on 27 January 2022.		This Internet-Draft will expire on 1 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	The SPI has a local significance to index the Security Association		The SPI has a local significance to index the Security Association
	(SA). From [RFC4301] section 4.1, nodes supporting only unicast		(SA). From [RFC4301] section 4.1, nodes supporting only unicast
	communications can index their SA only using the SPI. On the other		communications can index their SA only using the SPI. On the other
	hand, nodes supporting multicast communications must also use the IP		hand, nodes supporting multicast communications must also use the IP
	addresses and thus SA lookup needs to be performed using the longest		addresses and thus SA lookup needs to be performed using the longest
	match.		match.
	For nodes supporting only unicast communications, it is recommended		For nodes supporting only unicast communications, it is recommended
	to index SA with the SPI only. The index may be based on the full 32		to index SA with the SPI only. The index may be based on the full 32
	bits of SPI or a subset of these bits. Some other local constraints		bits of SPI or a subset of these bits. The node may require a
	on the node may require a combination of the SPI as well as other		combination of the SPI as well as other parameters (like the IP
	parameters to index the SA.		address) to index the SA.
	Values 0-255 must not be used. As per section 2.1 of [RFC4303],		Values 0-255 must not be used. As per section 2.1 of [RFC4303],
	values 1-255 are reserved and 0 is only allowed to be used internally		values 1-255 are reserved and 0 is only allowed to be used internally
	and it must not be sent on the wire.		and it must not be sent on the wire.
	[RFC4303] does not require the SPI to be randomly generated over 32		[RFC4303] does not require the SPI to be randomly generated over 32
	bits. However, this is the recommended way to generate SPIs as it		bits. However, this is the recommended way to generate SPIs as it
	provides some privacy benefits and avoids, for example, correlation		provides some privacy benefits and avoids, for example, correlation
	between ESP communications. To randomly generate a 32 bit SPI, the		between ESP communications. To randomly generate a 32 bit SPI, the
	node generates a random 32 bit valueand checks it does not fall in		node generates a random 32 bit valueand checks it does not fall in
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	observer is likely to be able to determine the constrained devices of		observer is likely to be able to determine the constrained devices of
	the network. In some cases, these nodes may host a very limited		the network. In some cases, these nodes may host a very limited
	number of applications - typically a single application - in which		number of applications - typically a single application - in which
	case the SPI would provide some information related to the		case the SPI would provide some information related to the
	application of the user. In addition, the device or application may		application of the user. In addition, the device or application may
	be associated with some vulnerabilities, in which case specific SPI		be associated with some vulnerabilities, in which case specific SPI
	values may be used by an attacker to discover vulnerabilities.		values may be used by an attacker to discover vulnerabilities.
	While the use of randomly generated SPIs may reduce the leakage or		While the use of randomly generated SPIs may reduce the leakage or
	privacy of security related information by ESP itself, these		privacy of security related information by ESP itself, these
	information may also be leaked otherwise and a privacy analysis		information may also be leaked otherwise. As a result, a privacy
	should consider at least the type of information as well the traffic		analysis should consider at least the type of information as well the
	pattern. Typically, temperature sensors, wind sensors, used outdoors		traffic pattern before determining non random SPI can be used.
	do not leak privacy sensitive information and mosty of its traffic is		Typically, temperature sensors, wind sensors, used outdoors do not
			leak privacy sensitive information and mosty of its traffic is
	expected to be outbound traffic. When used indoors, a sensor that		expected to be outbound traffic. When used indoors, a sensor that
	reports every minute an encrypted status of the door (closed or		reports every minute an encrypted status of the door (closed or
	opened) leaks truly little privacy sensitive information outside the		opened) leaks truly little privacy sensitive information outside the
	local network.		local network.
	3. Sequence Number(SN) (32 bit)		3. Sequence Number(SN) (32 bit)
	According to [RFC4303], the Sequence Number (SN) is a mandatory 32		According to [RFC4303], the Sequence Number (SN) is a mandatory 32
	bits field in the packet.		bits field in the packet.
End of changes. 6 change blocks.
	22 lines changed or deleted		24 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/