idnits 2.17.1 draft-herbert-ipv6-srh-ah-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 78: '... present) MUST independently and det...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2019) is 1795 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 138 -- Looks like a reference, but probably isn't: '8' on line 140 -- Looks like a reference, but probably isn't: '4' on line 144 -- Looks like a reference, but probably isn't: '1' on line 145 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4302 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-19 ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-6man-segment-routing-header (ref. 'SRH') Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: November 2019 6 May 27, 2019 8 IPv6 Authentication Header with Segment Routing Header Processing 9 draft-herbert-ipv6-srh-ah-00 11 Abstract 13 This specification describes processing of the IPv6 Authentication 14 Header when the IPv6 Segment Routing Header is present in the same 15 packet. Specifically, the handling of mutable fields in the Segment 16 Routing Header for the purposes of computing or verifying the 17 packet's authenticating value is specified. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Handling mutable fields in AH . . . . . . . . . . . . . . . 3 59 1.2 Mutable fields in Segment Routing Header . . . . . . . . . . 3 60 2 Handling mutable SRH fields for ICV calculation . . . . . . . . 4 61 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1 Normative References . . . . . . . . . . . . . . . . . . . 5 65 5.2 Informative References . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1 Introduction 70 This specification describes processing of the IPv6 Authentication 71 Header (AH) [RFC4302] when the IPv6 Segment Routing Header (SRH) 72 [SRH] is present in the same packet. AH is used to authenticate the 73 preceding IPv6 header and extension headers in a packet. 74 Authentication is performed by computing an Integrity Check Value 75 (ICV) over the covered headers and comparing the computed value to 76 that contained in the ICV field of the AH header. Both the sender and 77 receiver (the final destination in the case that a routing header is 78 present) MUST independently and deterministically perform the same 79 computation over the same data. 81 1.1 Handling mutable fields in AH 83 Certain fields may be modified during transit (i.e. mutable fields). 84 To ensure that the sender and receiver both produce the same result 85 in ICV computation for mutable fields, Section 5.3.3.1 of [RFC4302] 86 specifies: 88 * If a field is mutable and its value at the (IPsec) receiver is 89 not predictable, then the value of the field is set to zero for 90 purposes of the ICV computation. 92 * If a field is mutable and its value at the (IPsec) receiver is 93 predictable, then the predicted value is inserted into the field 94 for purposes of the ICV computation. 96 1.2 Mutable fields in Segment Routing Header 98 Per [RFC8200] and [SRH], there are three instances of mutable fields 99 related to segment routing: 101 * IPv6 destination address: The value of the destination address 102 is predicable at the receiver. This is the last address in the 103 segment routing list (destination address set when segments left 104 goes to zero). 106 * Segments left: This is a field in the routing header and it's 107 value is predictable at the receiver. The field's value is 108 decremented at each intermediate destination such that the value 109 at the final destination will be zero. 111 * Mutable SRH TLVs: Per [SRH], if the high order bit of an SRH TLV 112 type is set then the TLV data for the corresponding TLV is 113 mutable. The value of the TLV data for a mutable TLV is not 114 predictable at the receiver. 116 2 Handling mutable SRH fields for ICV calculation 118 When performing the ICV calculation, at either the sender or 119 receiver, the following values are set in the packet for the purpose 120 of the calculation when an SRH header is present: 122 * The IPv6 destination address is set to final address in the 123 segment routing list. 125 * Segments left field in the routing header is set to zero. 127 * For any SRH TLV whose high order bit is set, set the 128 corresponding TLV data to all zeroes. 130 In pseudo code this is: 132 /* opt is a char pointer to the segment routing header, 133 * iph is a pointer to the IP header of the packet 134 */ 136 /* Set segments left to zero */ 137 if (opt[3] != 0) { 138 opt[3] = 0 139 /* Set destination to final address */ 140 iph->dest_address = *(struct ipv6_address *)&opt[8] 141 } 143 /* Determine offset of TLVs */ 144 off = 8 + (opt[4] << 4) 145 len = ((opt[1] + 1) << 3) - off 147 /* Zero data for mutable TLVs */ 148 while (len > 0) { 149 if (opt[off] == 0) { 150 optlen = 1 151 } else { 152 if (opt[off] & 0x80) 153 memset(&opt[off + 2], 0, opt[off + 1]) 154 optlen = opt[off + 1] + 2 155 } 156 off += optlen 157 len -= optlen 158 } 160 3 Security Considerations 162 The subject of this document is security using Segment Routing Header 163 with the Authentication Header. 165 4 IANA Considerations 167 There are no IANA considerations in this document. 169 5 References 171 5.1 Normative References 173 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 174 (IPv6) Specification", STD 86, RFC 8200, DOI 175 10.17487/RFC8200, July 2017, . 178 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 179 10.17487/RFC4302, December 2005, . 182 [SRH] C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. 183 Matsushima, D. Voyer, Ed., "IPv6 Segment Routing Header 184 (SRH)", draft-ietf-6man-segment-routing-header-19 186 5.2 Informative References 188 Author's Address 190 Tom Herbert 191 Quantonium 192 Santa Clara, CA 193 USA 195 Email: tom@quantonium.net