idnits 2.17.1 draft-templin-sealopt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2012) is 4481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-42 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational January 13, 2012 5 Expires: July 16, 2012 7 The SEAL IPv6 Destination Option 8 draft-templin-sealopt-01.txt 10 Abstract 12 The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a 13 mid-layer header designed for the encapsulation of an inner network 14 layer packet within outer network layer headers. SEAL also supports 15 a transport mode of operation, where the inner payload corresponds to 16 an ordinary transport layer payload. However, SEAL can also provide 17 benefit when used as an IPv6 destination option that contains a 18 digital signature inserted by the source. The source can thereafter 19 use the signature to verify that any ICMPv6 messages received 20 actually came from a router on the path, while destinations that 21 share a secret key with the source can verify the signature to ensure 22 data origin authentication. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 16, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. SEAL IPv6 Destination Option . . . . . . . . . . . . . . . . . 3 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The Subnetwork Encapsulation and Adaptation Layer (SEAL) 71 [I-D.templin-intarea-seal] provides a mid-layer encapsulation 72 designed for the encapsulation of an inner network layer packet 73 within outer network layer headers, i.e., in a very similar manner as 74 for GRE [RFC1701] and IPsec AH [RFC4302]. SEAL also supports a 75 transport mode of operation, where the encapsulated payload 76 corresponds to an ordinary transport layer protocol payload. 78 However, SEAL can also provide benefit when used as an IPv6 79 destination option [RFC2460] that contains a digital signature 80 inserted by the source. The source can thereafter use the signature 81 to verify that any ICMPv6 messages [RFC4443] received actually came 82 from a router on the path, while destinations that share a secret key 83 with the source can verify the signature to ensure data origin 84 authentication. 86 2. SEAL IPv6 Destination Option 88 The SEAL IPv6 destination option can be inserted in either a "short 89 form" or a "long form". In short form, the option includes a digital 90 signature. In long form the option also includes an Identification 91 value useful for anti-replay sequencing. The short form is formatted 92 as shown in Figure 1: 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Option Type | Opt Data Len=4| 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Signature | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 Figure 1: SEAL IPv6 Destination Option Format - Short Form 102 Option Type (8) an 8-bit field that encodes the destination option 103 code for SEAL, with the value '00' in the high-order two bits. 105 Option Data Length (8) an 8-bit length of the option data field 106 measured in octets. Set to 4 in short format, and set to 8 in 107 long format. 109 Digital Signature (32) 110 a 32-bit digital signature. When a cryptographic signature is 111 used, covers the leading 128 bytes of the packet beginning with 112 the destination option header (or up to the end of the packet). 113 The value 128 is chosen so that at least the IPv6 extension 114 headers and the leading portion of the inner packet are covered by 115 the signature. 117 The long form is formatted as shown in Figure 2 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Option Type | Opt Data Len=8| 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Signature | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Identification | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Figure 2: SEAL IPv6 Destination Option Format - Long Form 128 Identification (32) 129 a 32-bit per-packet identification field. Set to a monotonically- 130 incrementing 32-bit value for each packet transmitted, beginning 131 with 0. 133 The IPv6 source inserts a SEAL destination option when it needs to 134 ensure that any resulting ICMPv6 error messages came from a router on 135 the path and not from an off-path attacker. When the source receives 136 an ICMPv6 error message, it verifies that the signature is correct. 137 When a cryptographic signature is used, the source calculates the 138 signature over the leading 128 bytes of the packet based on a secret 139 hashing algorithm of its choosing. The source should choose a 140 hashing algorithm that would make it extremely difficult for an off- 141 path attacker to guess. 143 The destination may or may not recognize the SEAL destination option. 144 If the destination does not recognize the option, it skips the option 145 and processes the next option. If the destination recognizes the 146 option (and if the option contains a cryptographic signature), the 147 destination may either verify or ignore the signature according to 148 its configuration. If the destination is configured to verify the 149 signature, then it should accept the packet if the signature is 150 correct and discard the packet if the signature is incorrect. 152 3. IANA Considerations 154 The IANA is instructed to allocate an IPv6 destination option for 155 SEAL, with the value '00' in the high-order two bits. 157 4. Security Considerations 159 The source can use the SEAL destination option to verify that ICMPv6 160 messages were delivered by an on-path router and not an off-path 161 attacker. The signature may also be useful for other authenticating 162 purposes, e.g., if the destination shares a secret key with the 163 source. The packet identification field may also be useful for anti- 164 replay sequencing. 166 5. Acknowledgments 168 This work was motivated by recent discussions on the 6man mailing 169 list, and build on earlier investigations with SEAL. Sreenatha Setty 170 provided valuable comments that helped clarify aspects of the 171 document. 173 6. References 175 6.1. Normative References 177 [I-D.templin-intarea-seal] 178 Templin, F., "The Subnetwork Encapsulation and Adaptation 179 Layer (SEAL)", draft-templin-intarea-seal-42 (work in 180 progress), December 2011. 182 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 183 (IPv6) Specification", RFC 2460, December 1998. 185 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 186 Message Protocol (ICMPv6) for the Internet Protocol 187 Version 6 (IPv6) Specification", RFC 4443, March 2006. 189 6.2. Informative References 191 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 192 Routing Encapsulation (GRE)", RFC 1701, October 1994. 194 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 195 December 2005. 197 Author's Address 199 Fred L. Templin (editor) 200 Boeing Research & Technology 201 P.O. Box 3707 202 Seattle, WA 98124 203 USA 205 Email: fltemplin@acm.org