HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:43:51 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 25 Nov 1996 13:38:00 GMT ETag: "2e98c7-a09e-3299a138" Accept-Ranges: bytes Content-Length: 41118 Connection: close Content-Type: text/plain INTERNET-DRAFT Weak Authentication and Tracing Option 26 November 1996 Expires 25 May 1997 The Weak Authentication and Tracing Option --- ---- -------------- --- ------- ------ Donald E. Eastlake 3rd Status of This Document This draft, file name draft-eastlake-weak-ato-00.txt, is intended to be become an Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT Weak Authentication and Tracing Option Abstract The packet switched nature of the Internet Protocol (IP) provides no inherent method to assure that a packet has been issued with a source address authorized for use by the sender and no inherent method to trace the actual source of a packet. These characteristics make it difficult to take effective action concerning injurious packets which may have originated, by accident or maliciously, virtually anywhere in the Internet. A lightweight IP level option is proposed that provides (1) some assurance that packets are authorized by a host along the path routed through when the packet's source address is used as a destination address, and (2) limited statistical tracing information such that, if many bad packets are logged, the path to their source will usually be revealed. Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT Weak Authentication and Tracing Option Table of Contents Status of This Document....................................1 Abstract...................................................2 Table of Contents..........................................3 1. The Packet Spam Problem.................................4 2. Other Possible Solutions................................4 2.1 Address Filtering......................................4 2.2 IPSEC / IPv6...........................................5 3. The WATO Solution.......................................6 4. Option and Message Formats..............................7 4.1 IPv4 Weak Authentication and Tracing Option Format.....7 4.2 IPv4 Weak Authentication ICMP Message..................8 4.3 IPv6 Weak Authentication and Tracing Option Format.....9 4.4 IPv6 Weak Authentication ICMP Message.................10 5. WATO State and Processing..............................11 5.1 WATO Soft State.......................................11 5.2 WATO End-to-End Processing at a Source Host...........11 5.3 WATO Adjacent Send Processing.........................12 5.4 WATO Adjacent Receive Processing......................13 5.5 WATO End-to-End Processing at a Destination Host......14 5.6 Weak Authentication ICMP Processing...................14 5.7 Multicast Packets.....................................14 6. Tracing and Logging....................................16 7. Cookies................................................17 7.1 Cookie Generation.....................................17 7.2 Cookie Rollover.......................................18 8. Tunneling and Fragmentation............................19 9. Deployment.............................................19 10. Security Considerations...............................20 References................................................21 Author's Address..........................................21 Expiration and File Name..................................21 Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT Weak Authentication and Tracing Option 1. The Packet Spam Problem As the Internet increases in size, the probability of accidental or malicious IP packet level accidents or attacks, including denial of service attacks, increases as well. Misconfiguration or bugs in software can produce anomalous and injurious packets. Network interface or other hardware failure can also yield anomalous and injurious packets. And a variety of software designed explicitly to launch denial of service attacks has been widely distributed. In general, the Internet Protocol does not constrain the source address used on packets. Indeed, some forms of mobile IP make use of and hypothetical future uses of IP may require this liberty. However, as a result, injurious packets can be sent with random or inappropriate source addresses making the true source difficult to locate. The Internet Protocol does not provide a way for a destination to require trace information to be included in a packet. There are trace ("record route") options but they would have to be voluntarily included by the sender, are relatively cumbersome variable length options which may not be able to accommodate all the hops a packet traverses, and include no facilities for any authentication. Accidental or malicious denial of service or similar attacks are a difficult problem. They can not be prevented in general. However, the facilities provided by the weak authentication and tracing option (WATO), as described in section 3 below, should make most of such attacks much easier to trace and terminate. 2. Other Possible Solutions Address filtering has been suggested to improve the authenticity of IP source addresses and IP security mechanisms are being developed to strongly secure packets; however, as explained below these mechanisms do not answer the needs addressed by the Weak Authentication and Tracing Option (WATO). 2.1 Address Filtering To the extent that routers connect an Internet area using limited addresses to the global Internet, they can filter outgoing packets to only permit those with source addresses within those limited addresses and/or filter incoming packets to those with source addresses not within those limited addresses. This may be a helpful Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT Weak Authentication and Tracing Option strategy and is compatible with WATO but has the following problems: Tables of addresses must be maintained and updated at all routers implementing this strategy. The strategy becomes increasingly difficult for high level routers that may be connected via complex, time variant topology. There is no way for a destination to gain any assurance that a packet it receives was in fact so filtered or to request such filtering by a message to the source or any intermediate host. Some mobile IP schemes utilize and hypothetical future uses of IP might require the ability to send packets with non-local source addresses. Address filtering provides no trace information, although it may constrain paths. In contrast, the WATO's weak source address authentication data can be automatically and dynamically maintained and it provides weakly authenticated statistical trace information. A destination can refuse packets that do not have weak authentication and can request that a remote host use WATO. 2.2 IPSEC / IPv6 Strong IP security mechanisms (IPSEC, IPv6) [RFC1825] are being standardized. However these mechanisms are targeted at the establishment of highly authenticated and/or strongly confidential host to host or process to process channels. For spontaneous Internet communications, they typically require computationally intensive set up, extensive per packet computation, and a deployed public key infrastructure. In particular, the amount of computation usually makes authentication at routers impractical. Furthermore, even strongly authenticated packets can be injurious and these strong security measures provides no assistance in packet tracing and relatively little assistance in efficient rejection of packets with forged source addresses. In contrast, the WATO imposes only minimal additional computation, uses no cryptography, and can frequently reject packets based on a trivial examination. Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT Weak Authentication and Tracing Option 3. The WATO Solution The Weak Authentication and Tracing Option (WATO) can weakly authenticate the source address of a unicast packet by demanding that the remote host supply in this option a plain text end-to-end cookie, supplied to the source host by the destination host. This cookie is associated with the source/destination IP address ordered pair. These cookies are in essence plain text re-usable passwords that are set up in soft state by ICMP messages. They are not secure against parties that can eavesdrop on the conversation but are reasonably secure against others. The WATO also provides a random sample of one intermediate IP address of a WATO enabled router in the path any packet follows. If enough packets are logged, the entire path can be mapped as far as WATO equipped intermediate hosts are concerned. These intermediate IP addresses are weakly authenticated by an adjacent node cookie mechanism similar to the end-to-end cookie mechanism described above. The WATO is designed as a fixed format option and should be the first option, if present, so that its fields are a fixed offset from the packet beginning. This enables routers can perform WATO updating and checking efficiently. Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT Weak Authentication and Tracing Option 4. Option and Message Formats The following subsections describe the WATO option and ICMP message formats. 4.1 IPv4 Weak Authentication and Tracing Option Format The Version 4 Internet Protocol (IPv4) Weak Authentication and Tracing Option (WATO) is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | num=100*tbd* | size=00010100 | T-TTL | A-TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacent Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trace Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first byte is the option number . This number is in the range for control options that must be copied into all fragments if a packet is fragmented. The second byte is the option length which is always 20 decimal. A rigid fixed format is used to minimize processing time and complexity, a particularly important consideration at routers. The WATO option should be the first option in an IPv4 packet header. T-TTL is the TTL at the time an Adjacent IP Address was copied to the Trace Address field as a packet is transmitted. A-TTL is the TTL at the time this packet was last sent over a link and the Adjacent Address was set to the IP address of the interface on which it was transmitted (or zero if it was transmitted on an unnumbered inter-router point-to-point link). The Adjacent Cookie field is used in weak authentication between successive WATO equipped hosts. (If all hosts are WATO equipped, this will be authentication over a single hop link.) The End-to-End Cookie is used for weak authentication from end to end. A cookie value of zero means the sender believes it is required but unknown. A cookie value of one means the sender believes it is not required. All other values are specific cookies. A WATO with both cookies one Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT Weak Authentication and Tracing Option would be unusual but is permitted. The Trace Address is used for statistical tracing of packets (see section 6 below). 4.2 IPv4 Weak Authentication ICMP Message The Version 4 Internet Protocol (IPv4) Weak Authentication ICMP message has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Data Datagram | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type number is . Values for Code are as follows: 0 Reserved 1 Adjacent cookie authentication failed. This is sent to the Adjacent Address appearing in a WATO received if the Adjacent Cookie is wrong or zero when adjacent WATO processing is enabled or is one when WATO is required. 2 Spontaneous notification sent to an adjacent IP address due to a change in the adjacent cookie required from the remote address by the sending host. The "Internet Header +" of the ICMP is meaningless in this case. 3 End-to-End cookie authentication failed. The is sent to the packet source address if a WATO is received in a unicast packet with the End-to-End Cookie wrong or zero when WATO is not disabled or is one when WATO is required. 4 Spontaneous notification sent to a remote IP address due to a change in the End-to-End cookie required from the remote address by the sending host. The "Internet Header +" of the ICMP is meaningless in this case. 5 Proxy notification. This is used when a host wishes to authorize another host to validly use its source address for a particular destination on an End-to-End basis. It accomplishes this by forwarding the weak authentication ICMP (code 1 or 2) by which it learned the cookie the remote system expects to weakly authenticate the source address. WARNING: unprotected use of this subtype of weak authentication ICMP may expose the cookie to compromise by eavesdropping in a significantly larger portion of the Internet than would be the case if occurance of the cooke was restricted to the source/destination route. Donald E. Eastlake 3rd [Page 8] INTERNET-DRAFT Weak Authentication and Tracing Option 4.3 IPv6 Weak Authentication and Tracing Option Format The Version 6 Internet Protocol (IPv6) Weak Authentication and Tracing Option (WATO) is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+ |Option Type=TBD| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=43| W-HOP | T-HOP | A-HOP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacent Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Adjacent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Trace Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [should IPv6 cookies be 64 bit? probably not worth going to more than 32 bits given the other weaknesses of the WATO.] The alignment requirement is 8n+3. This option appears within the Hop-by-Hop Option in IPv6. The top three bits of the type are 001. Top two bits zero indicates that the option may be skipped over and forwarded by a host that does not understand the option. The next bit a 1 indicates that the content of the option changes as the packet is forwarded through the Internet. Fields with the same name have the same meaning as for the IPv4 option. *-HOP fields correspond to the same *-TTL field for IPv4. The W-HOP field is a copy of the HOP count at the time the WATO was inserted in the packet, possibly the value the HOP count was set to at the original source host. Donald E. Eastlake 3rd [Page 9] INTERNET-DRAFT Weak Authentication and Tracing Option 4.4 IPv6 Weak Authentication ICMP Message The Version 6 Internet Protocol (IPv6) Weak Authentication ICMP message has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | + as will fit without the ICMPv6 packet + | exceeding 576 octets | The type number is which is an error class IPv6 ICMP. Values for Code are the same as for the IPv4 weak authentication ICMP. Donald E. Eastlake 3rd [Page 10] INTERNET-DRAFT Weak Authentication and Tracing Option 5. WATO State and Processing Subsection 5.1 below describe the minimum data which needs to be maintained at a host to implemented the weak authentication and tracing option (WATO), subsections 5.2 through 5.6 describe the processing that needs to be performed on a per unicast packet basis, and section 5.7 describes the differences for multicast. Note that any form of state maintenance or processing that results in the same bits on the wire is equally valid. 5.1 WATO Soft State A host participating in WATO processing must maintain some state associated with local/remote IP unicast address pairs as listed below. The number of such states and when they are discarded is a matter of local policy. This is soft state in that it can be reconstructed at the expense of exchanging weak authentication ICMP packets. Most implementations will need additional state information such as time of state establishment/update. Local IP Address Remote IP Address Type (adjacent or end-to-end) Send Cookie Status (confirmed/proposed) Send Cookie Required Receive Cookie Local IP Address is not required in the state on a host with only one IP interface address. The send cookie is initialized to zero which is not a valid cookie and is set as specified in section 5.6 on ICMP processing. Receive Cookie need not be included in the state if it can be reconstructed quickly enough as described in section 7.1. It is a matter of local policy as to when that WATO soft state associated with a local/remote IP address pair is discarded. However, if the state has no remote cookie associated with it and the local cookie is reconstructable, it is generally safe to discard the state on receipt of any destination unreachable ICMP. 5.2 WATO End-to-End Processing at a Source Host If the destination address of an outgoing packet is an address such that packets from that address would be rejected if received without Donald E. Eastlake 3rd [Page 11] INTERNET-DRAFT Weak Authentication and Tracing Option a WATO having a correct end-to-end cookie, then a WATO MUST be included in an output packet to that address. In the case of the recent receipt of any packet with a WATO from that destination address as a source address, the WATO MUST be included on outgoing packets. If neither of these cases applies, inclusion of the WATO is a matter of local policy but always including it SHOULD be the default. Provisions may be made for disabling originating host WATO processing based on the network interface to be used or destination IP address, such as a list of values and masks for which it is suppressed. (For un-numbered inter-router point to point links, the IP address of each end is considered zero.) If the WATO is being included, an original source host - sets the trace address and T-TTL (or (T-HOP) fields to zero, - for IPv6, sets the W-HOP field to the IP header HOP field, - sets the End-to-End Cookie field to the end-to-end cookie it has cached for the destination address or to zero if there isn't one, - sets the Adjacent Cookie to one, and then - performs adjacent WATO packet send processing as described immediately below. 5.3 WATO Adjacent Send Processing The following processing occurs on each WATO equipped host along the packet's path on the sending of the packet. It should be possible to enable/disable adjacent WATO processing on a per interface basis. Provisions may be made for disabling adjacent host WATO processing based on the adjacent IP address, such as a list of values and masks for which it is suppressed. If disabled on send, any existing WATO is passed on without modification. If enabled and there isn't a WATO option in the packet, one must be added with the End-to-End cookie set to one and the Trace Address and T-TTL (or T-HOP) fields set to zero (and for IPv6, the W-HOP field set to the IP header HOP field). If the WATO option already in a packet has an incorrect length, the packet is dropped. An ICMP parameter problem (with a WATO) is send back (unless the packet's ultimate source is the host where this problem is detected). Then Donald E. Eastlake 3rd [Page 12] INTERNET-DRAFT Weak Authentication and Tracing Option - set the A-TTL (or A-HOP) field to the IP header TTL (or HOP) field, and the Adjacent Address field to the address of the interface the packet is being transmitted on, and - set the Adjacent Cookie field to the adjacent cookie it has cached for IP address of the next hop it is being sent to or to zero if there isn't such a cached cookie. - finally, with a 1/16th probability (see section 6), copy the A-TTL (or A-HOP) and Adjacent Address fields into the T-TTL (or T-HOP) and Trace Address fields. 5.4 WATO Adjacent Receive Processing The following processing occurs on each WATO equipped host along the packet's path on the receipt of a unicast packet. On an interface where WATO is disabled, no processing is done and the packet is passed on for other processing. On an interface where the WATO is enabled, if a packet is received without this option, an ICMP Destination Unreachable due to Administrative Restriction should be returned with a WATO present on the ICMP IP packet. [Or should this be a new Code for Destination Unreachable? It shouldn't just be the new weak authentication ICMP as the sender may not understand that.] If a packet is received with a wrong length or malformed WATO, an ICMP parameter error (with WATO) is sent back and then the packet is discarded. If the WATO option present has zero, one, or the wrong value for the Adjacent Cookie, an appropriate weak authentication ICMP is sent back with the required adjacent cookie unless the packet is itself a weak authentication ICMP (see section 5.6) addressed to this node in which case that ICMP is processed as if it had a wrong cookie before the weak authentication ICMP is transmitted. Then the packet is discarded. After adjacent WATO receive processing, if the destination address is this host, then perform end-to-end receive processing as describe immediately below. Donald E. Eastlake 3rd [Page 13] INTERNET-DRAFT Weak Authentication and Tracing Option 5.5 WATO End-to-End Processing at a Destination Host If WATO processing is disabled for the interface, do nothing. If WATO processing is enabled and the WATO option present has zero, one, or the wrong value for the End-to-End Cookie, an appropriate weak authentication ICMP is sent back with the required cookie unless the packet is itself a weak authentication ICMP (see section 5.6) addressed to this node in which case that ICMP is processed as if it had a wrong cookie before the weak authentication ICMP is transmitted. Then the packet is discarded. If the WATO is OK, the packet is passed on for further processing. 5.6 Weak Authentication ICMP Processing Weak authentication ICMPs inform a host of what cookie another host will require. However, this information is considered to only be proposed unless it is weakly authenticated by the presence in the weak authentication ICMP packet of a WATO correcting giving the required cookie of the type being set. If it is weakly authenticated, it is considered confirmed. A proposed cookie is remembered and used only if there is no confirmed cookie. A confirmed cookie replaces any existing confirmed or proposed cookie and is remembered and used. For example, an ICMP purporting to be from host A is sent to host B stating that host A will require end-to-end cookie Ac. If this ICMP has a WATO giving the correct end-to-end cookie required by host B of host A (i.e., Bc), then Ac becomes the confirmed cookie for future packets from B to A. If this ICMP has a WATO with no or the wrong end-to-end cookie required by B of host A, it may be a forgery. Host B takes Ac only as a proposed cookie and also sends to host A an ICMP informing host A of Bc which is the cookie B is requiring of A. This ICMP to A will have a WATO that gives an earlier confirmed cooked ( Ac[-1] ), if there is one, or the proposed cookie (Ac). Some hosts may adopt a strategy of retaining a copy of a packet if they expect it to be dropped due to lack of a good cookie and retransmitting it when they get a weak authentication ICMP code 1 or 3. 5.7 Multicast Packets Normal end-to-end and adjacent WATO processing are not performed on a multicast packet. A WATO option may be present and the adjacent and Donald E. Eastlake 3rd [Page 14] INTERNET-DRAFT Weak Authentication and Tracing Option trace address are set as normal, so statistical tracing is provided, but the cookie fields are unused. A multicast packet may be rejected with a WATO equipped ICMP to indicate that a WATO should be sent on future packets but such transmissions should be rate limited. Donald E. Eastlake 3rd [Page 15] INTERNET-DRAFT Weak Authentication and Tracing Option 6. Tracing and Logging The weak authentication and tracing option (WATO) provides to the destination system a single sample intermediate IP address along the routed path of each packet. This trace information is only collectable at links on the path where WATO is enabled. The probability of collection at each point is 1/16th and overwrites any more remote trace address. This probability was chosen to give good sampling with typical path lengths in the current and foreseeable Internet and provide some sampling even for very long paths. If enough packets are received from the same source and the WATO is enabled on the routers used, a complete path can be determined. While the more random the determination of this 1/16th chance the better, for the WATO application it is usually adequate to use a simple linear congruence generator such as x = ( ( x * 9301 ) + 49297 ) mod 233280 n+1 n using 32 bit two's complement arithmetic where x is seeded at system boot time with the date and time in seconds or the like [RFC1750] and the middle four bits of each value of successive x's are tested for zero for the 1/16 probability. In attempting to reconstruct a complete path from WATO tracing information, you should use the T-TTL (or T-HOP) count minus the final TTL/HOP value, otherwise an attacker can confuse you by jittering the initial TTL/HOP count. Which incoming packets or WATO values to remember is a local logging decision. Donald E. Eastlake 3rd [Page 16] INTERNET-DRAFT Weak Authentication and Tracing Option 7. Cookies As explained below, cookies should be carefully generated and changed periodically. 7.1 Cookie Generation It is essential that the cookies used in weak authentication be random in the sense of being hard for an attacker to guess. RFC 1750 discusses concepts and methods in this area. The recommended technique is for a host to create a random secret, which is periodically changed (see section 7.2 below), and then calculate the cookie required to be presented by a remote IP address as a function of this secret and that remote address. I.E.: end-to-end-cookie = hash( end-to-end-secret, remote IP address) Different secrets should be used for determining end-to-end and adjacent cookies. Each secret should have at least 32 bits worth of randomness which means that it must be at least 32 bits in length. This method of calculating the required cookies permits WATOs from remote systems to be validated even if the state associated with the local/remote IP address pair has been lost due to cache overflow or other reasons. The required cookie value can simply be regenerated. For end-to-end cookies, the end-to-end secret should be strongly mixed with the remote IP address. For example, calculating the HMAC-MD5 [RFC1321, HMAC] hash of the secret and the remote IP address and using the lower 32 bits of the result as the cookie. While strong mixing is also desirable for adjacent cookies, the implementation of adjacent WATO processing in routers may put a premium on performance. The number of hosts adjacent to a router may be limited to relatively trusted routers. In addition, the low delay and tighter coupling between adjacent hosts may make more frequent adjacent secret changes practical, perhaps on the order of once every few seconds or even more often, giving an attacker little time to calculate or brute force search for a cookie or cookie generating secret. Under such circumstances, it may make sense to consider use of a faster weaker mixing function such as use as hashing the concatenation of the secret and the remote IP address with a subset of the calculations called for in MD5 or MD4. Donald E. Eastlake 3rd [Page 17] INTERNET-DRAFT Weak Authentication and Tracing Option 7.2 Cookie Rollover The longer a cookie is used, the greater the probability that it has been compromised through eavesdropping or otherwise. To minimize the loss of weak authentication this would cause, cookies should be changed periodically. In addition, since cookies are associated with an IP source address, they must be changed or new ones generated when a host interface is re-numbered. For end to end WATO, the cookie MUST be changed no less often than daily with a maximum validity time of 26 hours. Since excessive cookie rollover can cause excessive retransmissions and WATO set up packets, it is recommended that end to end cookies not be changed more often than every four minutes. Adjacent cookies should be changed more frequently than end-to-end cookies. If two communicating systems both change cookies at the same time there is a potential deadlock situation. (At the same time just means during the period between intersystem packet transmissions which could be a substantial time interval.) In particular, if both systems act as described above in section 5, each will start sending weak authentication ICMP messages to the other advertising its new cookie for the IP pair, the new cookie will be treated as a proposed cookie at each end, but it will never displace the old confirmed cookie because these ICMPs will always have WATOs giving the confirmed and now wrong cookie. To solve this problem, all WATO implementations MUST adopt the following strategy: when the cookie to be required from a remote system on an IP pair is changed, any confirmed remote cookie for that pair is cleared Donald E. Eastlake 3rd [Page 18] INTERNET-DRAFT Weak Authentication and Tracing Option 8. Tunneling and Fragmentation In some cases packets are tunneled through IP in IP encapsulation or the like. This is compatible with WATO, keeping in mind that the entire tunnel will generally appear to any encapsulated WATO as one hop. WATO may be independently used in the outer packet transmission that makes up the tunnel. Insertion of the WATO option at an intermediate point can increase packet size, cause fragmentation, and decrease apparent path MTU. 9. Deployment Useful deployment of WATO will require widespread implementation but WATO can be incrementally deployed. End-to-end WATO is useful and requires only that it be implemented at the two end points. Intervening hosts that don't know about WATO will simply pass through packets including the option. Adjacent WATO is useful and generally requires only that the adjacent hosts within some part of the routing mesh implement it. This will improve the reliability of WATO tracing information delivered to the destinantion. Firewalls can proxy for machines behind them so as to support apparent end-to-end WATO without WATO being installed or enabled for hosts behind the firewall. Network address translation (NAT) boxes change the IP address pair to which end-to-end cookies are linked so they MUST proxy both ways simulating end-to-end WATO to both inside and outside hosts, if WATO is required by communications through the NAT box. Donald E. Eastlake 3rd [Page 19] INTERNET-DRAFT Weak Authentication and Tracing Option 10. Security Considerations It can not be emphasised too strongly that the weak authentication and tracing option (WATO) provides only a WEAK form of authentication and tracing. In many cases other security measures, such as IPSEC, should be used in conjunction with the WATO. Widespread deployment of WATO would mean that it would no longer be possible for any host to spray the Internet with packets having forged source addresses that would be accepted at their destinations; however, there would still be systems at high levels is the routing mesh that would be exposed to and could capture cookies for enormous numbers of hosts. Such systems could forge packets with many source addresses and correct WATOs. Systems on backbone shared media trunks have been compromised in the past and used for password sniffing. If compromised, they could certainly also be used for cookie sniffing. In addition WATO provides almost no protection again a determined local attack from another machine on the same shared media as the machine you may be trying to protect. The trace information collected by the WATO can also be forged. In particular a system could create a forged trace pattern stretching off to other real or fictitious hosts. Analysis of enough packets should enable tracing the path back to the host which is doing the forging unless it is on your local media. The WATO will provide a major improvement in the situation for the source determination and tracing of injurious packets but it is not a complete solution. It should be considered only one element of security in depth. Donald E. Eastlake 3rd [Page 20] INTERNET-DRAFT Weak Authentication and Tracing Option References [RFC 791] - "Internet Protocol", 09/01/1981, J. Postel [RFC 792] - "Internet Control Message Protocol", 09/01/1981, J. Postel [RFC1321] - MD5 [RFC 1750] - "Randomness Recommendations for Security", 12/29/1994, D. Eastlake, S. Crocker, J. Schiller [RFC 1825] - "Security Architecture for the Internet Protocol", 08/09/1995, R. Atkinson [RFC 1883] - "Internet Protocol, Version 6 (IPv6) Specification", 01/04/1996, S. Deering, R. Hinden [RFC 1885] - "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", 01/04/1996, A. Conta, S. Deering Author's Address Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 508 287 4877 +1 703 620-4200 (main office, Reston, VA) FAX: +1 508 371 7148 EMail: dee@cybercash.com Expiration and File Name This draft expires 25 May 1997. Its file name is draft-eastlake-weak-ato-00.txt. Donald E. Eastlake 3rd [Page 21]