idnits 2.17.1 draft-eastlake-weak-ato-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-eastlake-weak-ato-03.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-weak-ato-03.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-weak-ato-03.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eastlake-weak-ato-03.txt,', but the file name used is 'draft-eastlake-weak-ato-03' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 429: '...end-to-end cookie, then a WATO MUST be...' RFC 2119 keyword, line 432: '...ddress, the WATO MUST be included on o...' RFC 2119 keyword, line 434: '... but always including it SHOULD be the...' RFC 2119 keyword, line 579: '... transmissions MUST be rate limited....' RFC 2119 keyword, line 669: '...WATO, the cookie MUST be changed no le...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 255 has weird spacing: '...s it is not r...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1998) is 9358 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2267' is mentioned on line 140, but not defined ** Obsolete undefined reference: RFC 2267 (Obsoleted by RFC 2827) == Missing Reference: 'RFC1825' is mentioned on line 165, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC 2065' is mentioned on line 171, but not defined ** Obsolete undefined reference: RFC 2065 (Obsoleted by RFC 2535) == Missing Reference: '-1' is mentioned on line 563, but not defined -- Looks like a reference, but probably isn't: '2104' on line 644 -- Looks like a reference, but probably isn't: '1320' on line 658 == Unused Reference: 'RFC 791' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC 792' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC 1320' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC 1825' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC 1883' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC 1885' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'RFC 2104' is defined on line 771, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1320 (Obsoleted by RFC 6150) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1885 (Obsoleted by RFC 2463) ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 22 errors (**), 1 flaw (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Weak Authentication and Tracing Option 2 February 1998 3 Expires August 1998 5 The Weak Authentication and Tracing Option 6 --- ---- -------------- --- ------- ------ 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-eastlake-weak-ato-03.txt, is intended to 13 be become an Proposed Standard RFC. Distribution of this document is 14 unlimited. Comments should be sent to the author. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 30 ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 31 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 33 Abstract 35 The packet switched nature of the Internet Protocol (IP) provides no 36 inherent method to assure that a packet has been issued with a source 37 address authorized for the sender and no inherent method to trace the 38 actual source of a packet. These characteristics make it difficult 39 to take effective action concerning injurious packets which may have 40 originated, by accident or maliciously, virtually anywhere in the 41 Internet. 43 A lightweight IP level option is proposed that provides (1) some 44 assurance that packet's source addresses are authorized for their 45 sender, and (2) limited statistical tracing information such that, if 46 many bad packets are logged, the path to their source will be 47 revealed. 49 These features, even if not implemented throughout the Internet, 50 would provide significantly improved protection against packet level 51 abuse. 53 Table of Contents 55 Status of This Document....................................1 57 Abstract...................................................2 59 Table of Contents..........................................3 61 1. The Packet Spam Problem.................................4 62 2. Other Possible Solutions................................4 63 2.1 Address Filtering......................................4 64 2.2 IPSEC / IPv6...........................................5 66 3. The WATO Solution.......................................6 68 4. Option and Message Formats..............................7 69 4.1 IPv4 Weak Authentication and Tracing Option Format.....7 70 4.2 IPv4 Weak Authentication ICMP Message..................8 71 4.3 IPv6 Weak Authentication and Tracing Option Format.....9 72 4.4 IPv6 Weak Authentication ICMP Message.................10 74 5. WATO State and Processing..............................11 75 5.1 WATO Soft State.......................................11 76 5.2 WATO End-to-End Processing at a Source Host...........12 77 5.3 WATO Adjacent Send Processing.........................12 78 5.4 WATO Adjacent Receive Processing......................13 79 5.5 WATO End-to-End Processing at a Destination Host......14 80 5.6 Weak Authentication ICMP Processing...................14 81 5.7 Multicast Packets.....................................15 83 6. Tracing and Logging....................................16 85 7. Cookies................................................17 86 7.1 Cookie Generation.....................................17 87 7.2 Cookie Rollover.......................................18 88 8. Deployment and Proxies.................................18 90 9. Security Considerations................................20 92 References................................................21 93 Author's Address..........................................21 94 Expiration and File Name..................................22 96 1. The Packet Spam Problem 98 As the Internet increases in size, the probability of accidental or 99 malicious IP packet level accidents or attacks, including denial of 100 service attacks, increases as well. Misconfiguration or bugs in 101 software can produce anomalous and injurious packets. Network 102 interface or other hardware failure can also yield anomalous and 103 injurious packets. And a variety of software designed explicitly to 104 launch denial of service attacks has been widely distributed. 106 In general, the Internet Protocol does not constrain the source 107 address used on packets. Indeed, some forms of mobile IP make use of 108 this and hypothetical future uses of IP may require this liberty. 109 However, as a result, injurious packets can be sent with random or 110 inappropriate source addresses making the true source difficult to 111 locate. 113 The Internet Protocol does not provide a way for a destination to 114 require trace information to be included in a packet. There are 115 trace ("record route") options but they would have to be voluntarily 116 included by the sender, are relatively cumbersome variable length 117 options which may not be able to accommodate all the hops a packet 118 traverses, and include no facilities for authentication. 120 Accidental or malicious denial of service or similar attacks are a 121 difficult problem. They can not be prevented in general. However, 122 the facilities provided by the weak authentication and tracing option 123 (WATO), as described in section 3 below, should make most of such 124 attacks much easier to trace and terminate. 126 2. Other Possible Solutions 128 Address filtering has been suggested to improve the authenticity of 129 IP source addresses and IP security mechanisms are being developed to 130 strongly secure packets; however, as explained below these mechanisms 131 do not answer the needs addressed by the Weak Authentication and 132 Tracing Option (WATO). 134 2.1 Address Filtering 136 To the extent that routers connect an Internet area using limited 137 addresses to the global Internet, they can filter outgoing packets to 138 only permit those with source addresses within those limited 139 addresses and/or filter incoming packets to those with source 140 addresses not within those limited addresses [RFC 2267]. This may be 141 a helpful strategy and is compatible with WATO but has the following 142 problems: 144 Tables of addresses must be maintained and updated at all routers 145 implementing this strategy. 146 The strategy becomes increasingly difficult for high level routers 147 that may be connected via complex, time variant topology. 148 There is no way for a destination to gain any assurance that a packet 149 it receives was in fact so filtered or to request such filtering 150 by a message to the source or any intermediate host. 151 Some mobile IP schemes utilize and hypothetical future uses of IP 152 might require the ability to send packets with non-local source 153 addresses. 154 Address filtering provides no trace information, although it may 155 constrain paths. 157 In contrast, the WATO's weak source address authentication data can 158 be automatically and dynamically maintained and it provides weakly 159 authenticated statistical trace information. A destination can 160 refuse packets that do not have weak authentication and can request 161 that a remote host use WATO. 163 2.2 IPSEC / IPv6 165 Strong IP security mechanisms (IPSEC, IPv6) [RFC1825] are being 166 standardized. However these mechanisms are targeted at the 167 establishment of highly authenticated and/or strongly confidential 168 point to point or process to process channels. For spontaneous 169 Internet communications, they typically require computationally 170 intensive set up, extensive per packet computation, and a deployed 171 public key infrastructure such as DNS security [RFC 2065]. In 172 particular, the amount of computation usually makes authentication at 173 routers impractical. Furthermore, even strongly authenticated packets 174 can be injurious and these strong security measures provides no 175 assistance in packet tracing and relatively little assistance in 176 efficient rejection of packets with forged source addresses. 178 In contrast, the WATO imposes only minimal additional computation, 179 uses no cryptography, and can reject packets based on a trivial 180 examination. 182 3. The WATO Solution 184 The Weak Authentication and Tracing Option (WATO) can weakly 185 authenticate the source address of a unicast packet by demanding that 186 the remote host supply a plain text end-to-end cookie, specified to 187 the source host by the destination host. This cookie is associated 188 with the source/destination IP address ordered pair. These cookies 189 are in essence plain text re-usable passwords that are set up in soft 190 state by ICMP messages. They are not secure against parties that can 191 eavesdrop on the conversation but are reasonably secure against 192 others. 194 The WATO also provides a random sample of one intermediate IP address 195 of a WATO enabled machine in the path any packet follows. If enough 196 packets are logged, the entire path can be mapped as far as WATO 197 equipped intermediate hosts are concerned. These intermediate IP 198 addresses are weakly authenticated by an adjacent node cookie 199 mechanism similar to the end-to-end cookie mechanism described above. 201 The WATO is designed as a fixed format option and should be the first 202 option, if present, so that its fields are a fixed offset from the 203 packet beginning. This enables routers to perform WATO updating and 204 checking efficiently. It is not necessary that all or even any 205 intermediate routers implement WATO in order to gain substantial 206 advantages. 208 4. Option and Message Formats 210 The following subsections describe the WATO option and ICMP message 211 formats. 213 4.1 IPv4 Weak Authentication and Tracing Option Format 215 The IP Version 4 Internet Protocol (IPv4) Weak Authentication and 216 Tracing Option (WATO) is as follows: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | num=100*tbd* | size=00010100 | T-TTL | A-TTL | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Adjacent Cookie | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | End-to-End Cookie | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Adjacent Address | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Trace Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 The first byte is the option number . This number has 100 as 233 its top three bits which is in the range for control options that 234 must be copied into all fragments if a packet is fragmented. 236 The second byte is the option length which is always 20 decimal. (A 237 fixed format is used to minimize processing time and complexity, a 238 particularly important consideration at routers.) The WATO option 239 should be the first option in an IPv4 packet header. 241 T-TTL is the TTL at the time an Adjacent IP Address was copied to the 242 Trace Address field as a packet is transmitted at a network interface 243 (see section 5 below). 245 A-TTL is the TTL at the time this packet was last sent over a link 246 and the Adjacent Address was set to the IP address of the interface 247 on which it was transmitted (or zero if it was transmitted on an 248 unnumbered inter-router point-to-point link) (see section 5 below). 250 The Adjacent Cookie field is used in weak authentication between 251 successive WATO equipped hosts. (If all hosts are WATO equipped, 252 this will be authentication over a single hop link.) The End-to-End 253 Cookie is used for weak authentication from end to end. A cookie 254 value of 0 means the sender believes it is required but unknown. A 255 cookie value of 1 means the sender believes it is not required. All 256 other values are specific cookies. A WATO with both cookies set to 1 257 would be unusual but is permitted. 259 The Trace Address is used for statistical tracing of packets (see 260 section 6 below). 262 4.2 IPv4 Weak Authentication ICMP Message 264 The IP Version 4 Internet Protocol (IPv4) Weak Authentication ICMP 265 message has the following format: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Code | Checksum | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Cookie | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Internet Header + 64 bits of Original Data Datagram | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 The type number is . Values for Code are as follows: 278 0 Reserved 279 1 Adjacent cookie authentication failed. This is sent to the 280 Adjacent Address appearing in a WATO received if (a) the Adjacent 281 Cookie is wrong or 0 when adjacent WATO processing is enabled or (b) 282 the Adjacent Cookie is 1 when WATO is required. 283 2 Spontaneous notification sent to an adjacent IP address due 284 to a change in the adjacent cookie required from the remote address 285 by the ICMP sending host. The "Internet Header +" of the ICMP is 286 meaningless in this case. 287 3 End-to-End cookie authentication failed. The is sent to the 288 packet source address if (a) a WATO is received in a unicast packet 289 with the End-to-End Cookie wrong or 0 when WATO is enabled or (b) the 290 End-to-End Cookie is 1 when WATO is required. 291 4 Spontaneous notification sent to a remote IP address due to a 292 change in the End-to-End cookie required from the remote address by 293 the ICMP sending host. The "Internet Header +" of the ICMP is 294 meaningless in this case. 295 5 Proxy notification. This is used when a host wishes to 296 authorize another host to validly use its source address for a 297 particular destination on an End-to-End basis. It accomplishes this 298 by forwarding the weak authentication ICMP (code 1 or 2) by which it 299 learned the end-to-end cookie the remote system expects. WARNING: 300 unprotected use of this subtype of weak authentication ICMP may 301 expose the cookie to compromise by eavesdropping in a significantly 302 larger portion of the Internet than would be the case if occurance of 303 the cooke was restricted to the source/destination route. 305 4.3 IPv6 Weak Authentication and Tracing Option Format 307 The IP Version 6 Internet Protocol (IPv6) Weak Authentication and 308 Tracing Option (WATO) is as follows: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+ 313 |Option Type=TBD| 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |Opt Data Len=43| W-HOP | T-HOP | A-HOP | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Adjacent Cookie | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | End-to-End Cookie | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 + + 323 | | 324 + Adjacent Address + 325 | | 326 + + 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 + + 331 | | 332 + Trace Address + 333 | | 334 + + 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 The alignment requirement is 8n+3. 340 This option appears within the Hop-by-Hop Option in IPv6. The top 341 three bits of the type are 001. Top two bits zero indicates that the 342 option may be skipped over and forwarded by a host that does not 343 understand the option. The next bit a 1 indicates that the content 344 of the option changes as the packet is forwarded through the Internet 345 and therefor should not be included in checksums. 347 Fields with the same name have the same meaning as for the IPv4 348 option specified in 4.1 above. *-HOP fields correspond to the same 349 *-TTL field for IPv4. The W-HOP field is a copy of the HOP count at 350 the time the WATO was inserted in the packet, possibly the value of 351 the HOP count at the original source host. 353 4.4 IPv6 Weak Authentication ICMP Message 355 The IP Version 6 Internet Protocol (IPv6) Weak Authentication ICMP 356 message has the following format: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Code | Checksum | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Cookie | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | As much of invoking packet | 366 + as will fit without the ICMPv6 packet + 367 | exceeding 576 octets | 369 The type number is which is an error class IPv6 ICMP. 371 Values for Code are the same as for the IPv4 weak authentication ICMP 372 in section 4.2 above. 374 5. WATO State and Processing 376 Subsection 5.1 below describe the minimum data which needs to be 377 maintained at a host to implemented the weak authentication and 378 tracing option (WATO). Subsections 5.2 through 5.6 describe the 379 processing that needs to be performed on a per unicast packet basis. 380 They talk about end-to-end source host processing, adjacent source 381 host processing, adjacent detination host processing, and end-to-end 382 destination host processing, in that order. Finally, section 5.7 383 describes the differences for multicast. Note that any form of state 384 maintenance or processing that results in the same bits on the wire 385 is equally valid. 387 In some cases packets are tunneled through IP in IP encapsulation or 388 the like. This is compatible with WATO, keeping in mind that the 389 entire tunnel will generally appear to any encapsulated WATO as one 390 hop. WATO may be independently used in the outer packet transmission 391 that makes up the tunnel. 393 5.1 WATO Soft State 395 A host participating in WATO processing must maintain some state, as 396 listed below, associated with local/remote IP unicast address ordered 397 pairs. The number of such states and when they are discarded is a 398 matter of local policy. This is soft state in that it can be 399 reconstructed at the expense of exchanging weak authentication ICMP 400 packets. Most implementations will want to keep additional state 401 information such as time of state establishment/update. 403 Local IP Address 404 Remote IP Address 405 Type (adjacent or end-to-end) 406 Send Cookie Status (confirmed/proposed) 407 Send Cookie 408 Required Receive Cookie 410 Local IP Address is not required on a per state basis if the host has 411 only one IP interface address. 413 The send cookie is initialized to zero which is not a valid cookie 414 and is set as specified in section 5.6 on ICMP processing. 416 Receive Cookie need not be included in the state if it can be 417 reconstructed quickly enough as described in section 7.1. 419 It is a matter of local policy as to when the WATO soft state 420 associated with a local/remote IP address pair is discarded. 421 However, if the state has no remote cookie associated with it and the 422 local cookie is reconstructable, it is generally safe to discard the 423 state on receipt of any destination unreachable ICMP. 425 5.2 WATO End-to-End Processing at a Source Host 427 If the destination address of an outgoing packet is an address such 428 that packets from that address would be rejected if received without 429 a WATO having a correct end-to-end cookie, then a WATO MUST be 430 included in an output packet to that address. In the case of the 431 recent receipt of any packet with a WATO from that destination 432 address as a source address, the WATO MUST be included on outgoing 433 packets. If neither of these cases applies, inclusion of the WATO is 434 a matter of local policy but always including it SHOULD be the 435 default. Provisions may be made for disabling originating host WATO 436 processing based on the network interface to be used or destination 437 IP address, such as a list of values and masks for which it is 438 suppressed. (For un-numbered inter-router point to point links, the 439 IP address of each end is considered zero so some other means of 440 designating WATO suppression, such as a hardware interface number, 441 may be needed.) 443 If the WATO is being included, an original source host 445 - sets the trace address and T-TTL (or (T-HOP) fields to zero, 447 - for IPv6, sets the W-HOP field to the IP header HOP field, 449 - sets the End-to-End Cookie field to the end-to-end cookie it has 450 cached for the destination address or to zero if there isn't one, 452 - sets the Adjacent Cookie to one, and then 454 - performs adjacent WATO packet send processing as described 455 immediately below. 457 5.3 WATO Adjacent Send Processing 459 The following processing occurs on each WATO equipped host along the 460 packet's path, including the original source, on the sending of the 461 packet. It should be possible to enable/disable adjacent WATO 462 processing on a per interface basis. Provisions may be made for 463 disabling adjacent host WATO processing based on the adjacent IP 464 address, such as a list of values and masks for which it is 465 suppressed. If adjacent WATO processing is disabled on send, any 466 existing WATO is passed on without modification. 468 If enabled and there isn't a WATO option in the packet, one must be 469 added with the End-to-End cookie set to one and the Trace Address and 470 T-TTL (or T-HOP) fields set to zero (and for IPv6, the W-HOP field 471 set to the IP header HOP field). Insertion of the WATO option at an 472 intermediate point can increase packet size, cause fragmentation, and 473 decrease apparent path MTU. 475 If the WATO option already in a packet has an incorrect length, the 476 packet is dropped. An ICMP parameter problem (with a WATO) is send 477 back (unless the packet's ultimate source is the host where this 478 problem is detected). 480 Then 482 - set the A-TTL (or A-HOP) field to the IP header TTL (or HOP) field, 483 and the Adjacent Address field to the IP address of the interface 484 the packet is being transmitted on, and 486 - set the Adjacent Cookie field to the adjacent cookie it has cached 487 for IP address of the next hop it is being sent to or to zero if 488 there isn't such a cached cookie. 490 - finally, with a 1/16th probability (see section 6), copy the A-TTL 491 (or A-HOP) and Adjacent Address fields into the T-TTL (or T-HOP) 492 and Trace Address fields. 494 5.4 WATO Adjacent Receive Processing 496 The following processing occurs on each WATO equipped host along the 497 packet's path on the receipt of a unicast packet. 499 On an interface where WATO is disabled, no processing is done and the 500 packet is passed on for other processing. 502 On an interface where the WATO is enabled, if a packet is received 503 without this option, an ICMP Destination Unreachable due to 504 Administrative Restriction should be returned with a WATO present on 505 the ICMP IP packet. [Or should this be a new Code for Destination 506 Unreachable? It can't just be the new weak authentication ICMP as 507 the sender may not understand that.] 509 If a packet is received with a wrong length or malformed WATO, an 510 ICMP parameter error (with WATO) is sent back and then the packet is 511 discarded. 513 If the WATO option present has zero, one, or the wrong value for the 514 Adjacent Cookie, an appropriate weak authentication ICMP is sent back 515 with the required adjacent cookie unless the packet is itself a weak 516 authentication ICMP (see section 5.6) addressed to this node in which 517 case that ICMP is processed as if it had a wrong cookie before the 518 weak authentication ICMP is transmitted. Then the packet is 519 discarded. 521 After adjacent WATO receive processing, if the destination address is 522 this host, then perform end-to-end receive processing as describe 523 immediately below. 525 5.5 WATO End-to-End Processing at a Destination Host 527 If WATO processing is disabled for the interface, do nothing. 529 If WATO processing is enabled and the WATO option present has zero, 530 one, or the wrong value for the End-to-End Cookie, an appropriate 531 weak authentication ICMP is sent back with the required cookie unless 532 the packet is itself a weak authentication ICMP (see section 5.6) 533 addressed to this node. In that case the ICMP is processed before 534 the weak authentication ICMP response is transmitted. Then the 535 packet is discarded. 537 If the WATO is OK, the packet is passed on for further processing. 538 (Local policy may also take some action to indicate that the soft 539 state referenced to check the packet was in recent use and should 540 have higher priority for retention that idle soft WATO state.) 542 5.6 Weak Authentication ICMP Processing 544 Weak authentication ICMPs inform a host of what cookie another host 545 will require. However, this information is considered to only be 546 proposed unless it is weakly authenticated by the presence in the 547 weak authentication ICMP packet of a WATO correctly giving the 548 required cookie of the type being set. If it is weakly 549 authenticated, it is considered confirmed. A proposed cookie is 550 remembered in soft state and used only if there is no confirmed 551 cookie. A confirmed cookie replaces any existing confirmed or 552 proposed cookie and is remembered in soft state and used. 554 For example, an ICMP purporting to be from host A is sent to host B 555 stating that host A will require end-to-end cookie Ac. If this ICMP 556 has a WATO giving the correct end-to-end cookie required by host B of 557 host A (i.e., Bc), then Ac becomes the confirmed cookie for future 558 packets from B to A. If this ICMP has a WATO with no or the wrong 559 end-to-end cookie required by B of host A, it may be a forgery. Host 560 B takes Ac only as a proposed cookie and also sends to host A an ICMP 561 informing host A of Bc which is the cookie B is requiring of A. This 562 ICMP to A will have a WATO that gives an earlier confirmed cooked ( 563 Ac[-1] ), if there is one, or the proposed cookie (Ac). 565 Some hosts may adopt a strategy of temporarily retaining a copy of a 566 packet if they expect it to be dropped due to lack of a good cookie 567 and retransmitting it when they get a weak authentication ICMP code 1 568 or 3. 570 5.7 Multicast Packets 572 Normal end-to-end and adjacent WATO processing are not performed on a 573 multicast packet. A WATO option may be present and the adjacent and 574 trace address are set as normal, so statistical tracing is provided, 575 but the cookie fields are unused. 577 A multicast packet may be rejected with a WATO equipped ICMP to 578 indicate that a WATO should be sent on future packets but such 579 transmissions MUST be rate limited. 581 6. Tracing and Logging 583 The weak authentication and tracing option (WATO) provides to the 584 destination system a single sample intermediate IP address along the 585 routed path of each packet. 587 This trace information is only collectable at links on the path where 588 WATO is enabled. The probability of collection at each point is 589 1/16th and overwrites any more remote trace address. This 590 probability was chosen to give good sampling with typical path 591 lengths in the current and foreseeable Internet and provide some 592 sampling even for very long paths. 594 If enough packets are received from the same source and the WATO is 595 enabled on the routers used, a complete path can be determined. While 596 the more random the determination of this 1/16th chance the better, 597 for the WATO application it is usually adequate to use a simple 598 linear congruence generator such as 600 x = ( ( x * 9301 ) + 49297 ) mod 233280 601 n+1 n 603 using 32 bit two's complement arithmetic where x is seeded at system 604 boot time with the date and time in seconds or the like [RFC 1750] 605 and four bits near the middle of each value of successive x's are 606 tested for zero for the 1/16 probability. 608 In attempting to reconstruct a complete path from WATO tracing 609 information, you should use the T-TTL (or T-HOP) count minus the 610 final TTL/HOP value, otherwise an attacker can confuse you by 611 jittering the initial TTL/HOP count. 613 Which incoming packets or WATO values to remember is a local logging 614 decision. 616 7. Cookies 618 As explained below, cookies should be carefully generated and changed 619 periodically. 621 7.1 Cookie Generation 623 It is essential that the cookies used in weak authentication be 624 random in the sense of being hard for an attacker to guess. RFC 1750 625 discusses concepts and methods in this area. 627 The recommended technique is for a host to create a random secret, 628 which is periodically changed (see section 7.2 below), and then 629 calculate the cookie required to be presented by a remote IP address 630 as a function of this secret and that remote address. I.E.: 631 end-to-end-cookie = hash( end-to-end-secret, remote IP address) 632 Different secrets should be used for determining end-to-end and 633 adjacent cookies. Each secret should have at least 32 bits worth of 634 randomness which means that it must be at least 32 bits in length. 636 This method of calculating the required cookies permits WATOs from 637 remote systems to be validated even if the state associated with the 638 local/remote IP address pair has been lost due to cache overflow or 639 other reasons. The required cookie value can simply be regenerated 640 as long as the secret is still known. 642 For end-to-end cookies, the end-to-end secret should be strongly 643 mixed with the remote IP address. For example, calculating the 644 HMAC-MD5 [RFC 1321, 2104] hash of the secret and the remote IP 645 address and using the lower 32 bits of the result as the cookie. 647 While strong mixing is also desirable for adjacent cookies, the 648 implementation of adjacent WATO processing in routers may put a 649 premium on performance. The number of hosts adjacent to a router may 650 be limited to relatively trusted routers. In addition, the low delay 651 and tighter coupling between adjacent hosts may make more frequent 652 adjacent secret changes practical, perhaps on the order of once every 653 few seconds or even more often, giving an attacker little time to 654 calculate or brute force search for a cookie or cookie generating 655 secret. Under such circumstances, it may make sense to consider use 656 of a faster and weaker mixing function such as hashing the 657 concatenation of the secret and the remote IP address with a subset 658 of the calculations called for in MD5 or MD4 [RFC 1321, 1320]. 660 7.2 Cookie Rollover 662 The longer a cookie is used, the greater the probability that it has 663 been compromised through eavesdropping or otherwise. To minimize the 664 loss of weak authentication this would cause, cookies should be 665 changed periodically. In addition, since cookies are associated with 666 an IP source address, they must be changed or new ones generated when 667 a host interface is re-numbered. 669 For end to end WATO, the cookie MUST be changed no less often than 670 daily with a maximum validity time of 26 hours. Since excessive 671 cookie rollover can cause excessive retransmissions and WATO set up 672 packets, it is recommended that end to end cookies not be changed 673 more often than every four minutes. 675 Adjacent cookies SHOULD be changed more frequently than end-to-end 676 cookies. 678 If two communicating systems both change cookies at the same time 679 there is a potential deadlock situation. ("At the same time" means 680 during the period between intersystem packet transmissions which 681 could be a substantial time window.) In particular, if both systems 682 act as described above in section 5, each will start sending weak 683 authentication ICMP messages to the other advertising its new cookie 684 for the IP pair, the new cookie will be treated as a proposed cookie 685 at each end, but it will never displace the old confirmed cookie 686 because these ICMPs will always have WATOs giving the confirmed and 687 now wrong cookie. To solve this problem, all WATO implementations 688 MUST adopt the following strategy: when the cookie to be required 689 from a remote system on an IP pair is changed, any confirmed cookie 690 to be sent for that pair is cleared 692 8. Deployment and Proxies 694 Useful deployment of WATO will require widespread implementation but 695 WATO can be incrementally deployed. 697 End-to-end WATO is useful and requires only that it be implemented at 698 the two end points. Intervening hosts that don't know about WATO 699 will simply pass through packets including the option. 701 Adjacent WATO is useful and generally requires only that the adjacent 702 hosts within some part of the routing mesh implement it. Any such 703 implementation will improve the reliability of WATO tracing 704 information delivered to the destination. 706 Firewalls can proxy for machines behind them so as to support 707 apparent end-to-end WATO without WATO being installed or enabled for 708 hosts behind the firewall. Network address translation (NAT) boxes 709 change the IP address pair to which end-to-end cookies are linked so 710 they MUST proxy both ways simulating end-to-end WATO to both inside 711 and outside hosts, if WATO is required by communications through the 712 NAT box. 714 9. Security Considerations 716 It must be emphasised that the weak authentication and tracing option 717 (WATO) provides only a WEAK form of authentication and tracing. In 718 many cases other security measures, such as IPSEC, should be used in 719 conjunction with the WATO. 721 Widespread deployment of WATO would make it impossible for any host 722 to spray the Internet with packets having forged source addresses 723 that would be accepted at their destinations; however, there would 724 still be systems at high levels is the routing mesh that would be 725 exposed to and could capture cookies for enormous numbers of hosts. 726 Such systems could forge packets with many source addresses and 727 correct WATOs. Systems on backbone shared media trunks have been 728 compromised in the past and used for password sniffing. If 729 compromised, they could be used for cookie sniffing. In addition 730 WATO provides almost no protection against a determined local attack 731 from another machine on the same shared media as the machine you may 732 be trying to protect. 734 The trace information collected by the WATO can also be forged. In 735 particular a system could create a forged trace pattern stretching 736 off to other real or fictitious hosts. That could make it appear 737 that the traced packets only came through the system rather than 738 being originated by it. However, the true source would still be on 739 the apparent trace path. 741 The WATO will provide a major improvement in the situation for the 742 source determination and tracing of injurious packets but it is not a 743 complete solution. It should be considered only one element of 744 security in depth. 746 References 748 [RFC 791] - "Internet Protocol", 09/01/1981, J. Postel 750 [RFC 792] - "Internet Control Message Protocol", 09/01/1981, J. 751 Postel 753 [RFC 1321] - "The MD5 Message-Digest Algorithm", 04/16/1992, R. 754 Rivest. 756 [RFC 1320] - "The MD4 Message-Digest Algorithm", 04/16/1992, R. 757 Rivest. 759 [RFC 1750] - "Randomness Recommendations for Security", 12/29/1994, 760 D. Eastlake, S. Crocker, J. Schiller 762 [RFC 1825] - "Security Architecture for the Internet Protocol", 763 08/09/1995, R. Atkinson 765 [RFC 1883] - "Internet Protocol, Version 6 (IPv6) Specification", 766 01/04/1996, S. Deering, R. Hinden 768 [RFC 1885] - "Internet Control Message Protocol (ICMPv6) for the 769 Internet Protocol Version 6 (IPv6)", 01/04/1996, A. Conta, S. Deering 771 [RFC 2104] - "HMAC: Keyed-Hashing for Message Authentication", 772 02/05/1997, H. Krawczyk, M. Bellare, R. Canetti. 774 [RFC 2267} - "Network Ingress Filtering: Defeating Denial of Service 775 Attacks which employ IP Source Address Spoofing", January 1998, P. 776 Ferguson, D. Senie. 778 Author's Address 780 Donald E. Eastlake 3rd 781 CyberCash, Inc. 782 318 Acton Street 783 Carlisle, MA 01741 USA 785 Telephone: +1 978 287 4877 786 +1 703 620-4200 (main office, Reston, VA) 787 FAX: +1 978 371 7148 788 EMail: dee@cybercash.com 790 Expiration and File Name 792 This draft expires August 1998. 794 Its file name is draft-eastlake-weak-ato-03.txt.