Internet Engineering Task Force A. Kennard, Ed. Internet-Draft FireBrick Ltd Intended status: Informational T. Pratchett Expires: October 3, 2015 (posthumously) April 2015 Recommended explicit padding bytes used in Internet related protocols draft-kennard-01 Abstract Suggestion for pattern used for explicit padding content, with particular examples for Ethernet packet padding. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 3, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kennard & Pratchett Expires October 3, 2015 [Page 1] Internet-Draft Choice of Explicit Padding April 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Why use explicit padding . . . . . . . . . . . . . . . . . . 2 3. Choice of padding . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Why not a simple repeating byte pattern . . . . . . . . . 3 3.2. Why 18 bytes . . . . . . . . . . . . . . . . . . . . . . 3 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction It is common for padding to be needed in various protocols. In some cases it is preferable for the padding to be explicitly defined where the corresponding protocol does not otherwise define the padding to be used. In the case of Ethernet packets it is necessary for the packet to be padded to 64 bytes. Unfortunately it is not at all uncommon for this padding to simply be the previous content of memory or buffer and so cause unrelated data from another packet to be 'leaked' when short packets are sent and padding required. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Why use explicit padding Where padding is not explicitely defined in a protocol definition and is not explicited coded in the software design it is common for the content of the padding to 'leak' information that may happen to be in memory previously. This is particularly noticeable in small microcontroller based systems where code has been created from scratch rather than using standard libraries and the author has simply chosen not to specify the padding. Kennard & Pratchett Expires October 3, 2015 [Page 2] Internet-Draft Choice of Explicit Padding April 2015 This RFC recommends that the software designer include explicit padding in the code in such cases rather than leave it to chance. This is primarily a security consideration. 3. Choice of padding An obvious choice for padding is simple NUL (0x00) bytes. However, it is common for memory content to contain NUL bytes when otherwise uninitialised. It is therefore not obvious if explicit padding has been used or whether it just happens to have come out as NUL by chance. The proposed padding for Ethernet packets is a sequence of '*' characters (decimal 42) followed by the following fixed string of 18 bytes ending just before the Ethernet CRC bytes. 47 4E 55 20 54 65 72 72 79 50 72 61 74 63 68 65 74 74 3.1. Why not a simple repeating byte pattern The padding could be a simple repeating pattern such as '*' characters, but using a specific identifiable pattern, such as this, helps diagnose any issues with buffer overrun. The pattern will clearly align with the end of the packet in a packet dump. 3.2. Why 18 bytes The most common cases of Ethernet padding being visible are a zero payload IPv4 ICMP ping packet and reply, or an IPv4 ARP packet. In both cases 18 bytes of padding are required. The choice of padding is such that on a typical network dump (such as tcpdump) will show the 18 bytes as 4 bytes on the end of one line, and then a final 14 bytes on the next line. This specific pattern creates a nice readable string when displaying ASCII characters in such a format (e.g. tcpdump -X). 4. Acknowledgements This RFC is based on the Clacks system overhead. For more details, see the collected works of Sir Terry Pratchett and the Discworld series, and specifically [Going_Postal]. Kennard & Pratchett Expires October 3, 2015 [Page 3] Internet-Draft Choice of Explicit Padding April 2015 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations Failing to have defined padding in a protocol can result in leaking of data from other memory locations or previous packets. This proposal helps ensure such leaks do not happen. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [Going_Postal] Pratchett, T., "Going Postal", 2004, . Authors' Addresses Rev Adrian Kennard (editor) FireBrick Ltd Enterprise Court Bracknell, Berks RG12 1QS GB Email: undecided.adrian@firebrick.co.uk Sir Terry Pratchett (posthumously) Ankh Morpork Discworld Kennard & Pratchett Expires October 3, 2015 [Page 4]