draft-ietf-lwig-minimal-esp-01.txt   draft-ietf-lwig-minimal-esp-02.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: May 1, 2021 LMU Munich Expires: May 6, 2021 LMU Munich
October 28, 2020 November 2, 2020
Minimal ESP Minimal ESP
draft-ietf-lwig-minimal-esp-01 draft-ietf-lwig-minimal-esp-02
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, but instead to enable a limited implementation to RFC 4303 ESP, but instead to enable a limited implementation to
interoperate with implementations of RFC 4303 ESP. interoperate with implementations of RFC 4303 ESP.
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 May 1, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 7, line 11 skipping to change at page 7, line 11
SN can be encoded over 32 bits or 64 bits - known as Extended SN can be encoded over 32 bits or 64 bits - known as Extended
Sequence Number (ESN). As per [RFC4303], the support ESN is not Sequence Number (ESN). As per [RFC4303], the support ESN is not
mandatory. The determination of the use of ESN is based on the mandatory. The determination of the use of ESN is based on the
largest possible value a SN can take over a session. When SN is largest possible value a SN can take over a session. When SN is
incremented for each packet, the number of packets sent over the life incremented for each packet, the number of packets sent over the life
time of a session may be considered. However, when the SN is time of a session may be considered. However, when the SN is
incremented differently - such as when time is used - the maximum incremented differently - such as when time is used - the maximum
value SN needs to be considered instead. Note that the limit of value SN needs to be considered instead. Note that the limit of
messages being sent is primary determined by the security associated messages being sent is primary determined by the security associated
to the key rather than the SN. The security of the key used to to the key rather than the SN. The security of all data protected
encrypt decreases with each message being sent and a node MUST ensure under a given key decreases slightly with each message and a node
the limit is not reached - even though the SN would permit it. In a MUST ensure the limit is not reached - even though the SN would
constrainted environment, it is likely that the implementation of a permit it. In a constrainted environment, it is likely that the
rekey mechanism is preferred over the use of ESN. implementation of a rekey mechanism is preferred over the use of ESN.
5. Padding 5. Padding
The purpose of padding is to respect the 32 bit alignment of ESP or The purpose of padding is to respect the 32 bit alignment of ESP or
block size expected by an encryption transform - such as AES-CBC for block size expected by an encryption transform - such as AES-CBC for
example. ESP MUST have at least one padding byte Pad Length that example. ESP MUST have at least one padding byte Pad Length that
indicates the padding length. ESP padding bytes are generated by a indicates the padding length. ESP padding bytes are generated by a
succession of unsigned bytes starting with 1, 2, 3 with the last byte succession of unsigned bytes starting with 1, 2, 3 with the last byte
set to Pad Length, where Pad Length designates the length of the set to Pad Length, where Pad Length designates the length of the
padding bytes. padding bytes.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
include mechanisms to prevent a nonce to repeat for example. When a include mechanisms to prevent a nonce to repeat for example. When a
node is provisioned with a session key that is used across reboot, node is provisioned with a session key that is used across reboot,
the implementer MUST ensure that the mechanisms put in place remain the implementer MUST ensure that the mechanisms put in place remain
valid across reboot as well. valid across reboot as well.
It is RECOMMENDED to use ESP in conjunction of key management It is RECOMMENDED to use ESP in conjunction of key management
protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 protocols such as for example IKEv2 [RFC7296] or minimal IKEv2
[RFC7815]. Such mechanisms are responsible to negotiate fresh [RFC7815]. Such mechanisms are responsible to negotiate fresh
session keys as well as prevent a session key being use beyond its session keys as well as prevent a session key being use beyond its
life time. When such mechanisms cannot be implemented and the life time. When such mechanisms cannot be implemented and the
session key is, for example, provisioned, the nodes SHOULD ensure session key is, for example, provisioned, the nodes MUST ensure that
that keys are not used beyond their life time and that the keys are not used beyond their life time and that the appropriated
appropriated use of the key remains across reboots. use of the key remains across reboots - e.g. conditions on counters
and nonces remains valid.
When a node generates its key or when random value such as nonces are When a node generates its key or when random value such as nonces are
generated, the random generation MUST follow [RFC4086]. generated, the random generation MUST follow [RFC4086]. In addition
[SP-800-90A-Rev-1] provides appropriated guidances to build random
generators based on deterministic random functions.
11. Acknowledgment 11. Acknowledgment
The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero
Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson for their Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson for their
valuable comments. In particular Scott Fluhrer suggested to include valuable comments. In particular Scott Fluhrer suggested to include
the rekey index in the SPI as well as the use of transform resilient the rekey index in the SPI as well as the use of transform resilient
to nonce misuse. to nonce misuse.
12. References 12. References
skipping to change at page 14, line 5 skipping to change at page 13, line 21
[I-D.nikander-esp-beet-mode] [I-D.nikander-esp-beet-mode]
Nikander, P. and J. Melen, "A Bound End-to-End Tunnel Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-09 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09
(work in progress), August 2008. (work in progress), August 2008.
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV:
Nonce Misuse-Resistant Authenticated Encryption", Nonce Misuse-Resistant Authenticated Encryption",
RFC 8452, DOI 10.17487/RFC8452, April 2019, RFC 8452, DOI 10.17487/RFC8452, April 2019,
<https://www.rfc-editor.org/info/rfc8452>. <https://www.rfc-editor.org/info/rfc8452>.
[SP-800-90A-Rev-1]
Elain, E. and J. Kelsey, "Recommendation for Random Number
Generation Using Deterministic Random Bit Generators",
<https://csrc.nist.gov/publications/detail/sp/800-90a/rev-
1/final>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-00: First version published. -00: First version published.
-01: Clarified description -01: Clarified description
-02: Clarified description -02: Clarified description
 End of changes. 7 change blocks. 
13 lines changed or deleted 22 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/