draft-ietf-lwig-minimal-esp-04.txt   draft-ietf-lwig-minimal-esp-05.txt 
Light-Weight Implementation Guidance (lwig) D. Migault Light-Weight Implementation Guidance (lwig) D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Guggemos Intended status: Informational T. Guggemos
Expires: October 3, 2021 LMU Munich Expires: October 15, 2021 LMU Munich
April 1, 2021 April 13, 2021
Minimal ESP Minimal ESP
draft-ietf-lwig-minimal-esp-04 draft-ietf-lwig-minimal-esp-05
Abstract Abstract
This document describes a minimal implementation of the IP This document describes a minimal implementation of the IP
Encapsulation Security Payload (ESP) defined in RFC 4303. Its Encapsulation Security Payload (ESP) defined in RFC 4303. Its
purpose is to enable implementation of ESP with a minimal set of purpose is to enable implementation of ESP with a minimal set of
options to remain compatible with ESP as described in RFC 4303. A options to remain compatible with ESP as described in RFC 4303. A
minimal version of ESP is not intended to become a replacement of the minimal version of ESP is not intended to become a replacement of the
RFC 4303 ESP. Instead, a minimal implementation is expected to be RFC 4303 ESP. Instead, a minimal implementation is expected to be
optimized for constrained environment while remaining interoperable optimized for constrained environment while remaining interoperable
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 3, 2021. This Internet-Draft will expire on October 15, 2021.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Security Parameter Index (SPI) (32 bit) . . . . . . . . . . . 4 3. Security Parameter Index (SPI) (32 bit) . . . . . . . . . . . 4
3.1. Considerations over SPI generation . . . . . . . . . . . 4 3.1. Considerations over SPI generation . . . . . . . . . . . 5
4. Sequence Number(SN) (32 bit) . . . . . . . . . . . . . . . . 6 4. Sequence Number(SN) (32 bit) . . . . . . . . . . . . . . . . 6
5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Next Header (8 bit) . . . . . . . . . . . . . . . . . . . . . 9 6. Next Header (8 bit) . . . . . . . . . . . . . . . . . . . . . 9
7. ICV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. ICV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Cryptographic Suites . . . . . . . . . . . . . . . . . . . . 10 8. Cryptographic Suites . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
random generation. With the adoption of IPsec by IoT devices with random generation. With the adoption of IPsec by IoT devices with
minimal IKEv2 [RFC7815] and ESP Header Compression (EHC) with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC) with
[I-D.mglt-ipsecme-diet-esp] or [I-D.mglt-ipsecme-diet-esp] or
[I-D.mglt-ipsecme-ikev2-diet-esp-extension], it becomes crucial that [I-D.mglt-ipsecme-ikev2-diet-esp-extension], it becomes crucial that
ESP implementation designed for constrained devices remains inter- ESP implementation designed for constrained devices remains inter-
operable with the standard ESP implementation to avoid a fragmented operable with the standard ESP implementation to avoid a fragmented
usage of ESP. This document describes the minimal properties an ESP usage of ESP. This document describes the minimal properties an ESP
implementation needs to meet to remain interoperable with [RFC4303] implementation needs to meet to remain interoperable with [RFC4303]
ESP. In addition, this document also provides a set of options to ESP. In addition, this document also provides a set of options to
implement these properties under certain constrained environments. implement these properties under certain constrained environments.
This document does not update or modify RFC 4303, but provides a
compact description of how to implement the minimal version of the
protocol. RFC 4303 remains the authoritative description.
For each field of the ESP packet represented in Figure 1 this For each field of the ESP packet represented in Figure 1 this
document provides recommendations and guidance for minimal document provides recommendations and guidance for minimal
implementations. The primary purpose of Minimal ESP is to remain implementations. The primary purpose of Minimal ESP is to remain
interoperable with other nodes implementing RFC 4303 ESP, while interoperable with other nodes implementing RFC 4303 ESP, while
limiting the standard complexity of the implementation. limiting the standard complexity of the implementation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
 End of changes. 7 change blocks. 
9 lines changed or deleted 12 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/