INTERNET-DRAFT George Davey draft-davey-iialp-00.txt Des Moines University Expires: August 29, 2004 Dan Arthur Freese Notise Global Internet Paula Davey KIDputer Corporation IIALP Working Group www.abuselog.org Feb 29, 2004 Iowa Internet Annoyance Logging Protocol (IIALP) pronounced I'-alp Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 inappropriate 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft describes a system by which Internet Annoyances can be logged quickly and automatically using IIALP (Iowa Internet Annoyance Logging Protocol). The annoyance logs on a particular IIALP Server are condensed and forwarded up the IIALP hierarchy to central Root IIALP Servers for central annoyance queries. Serial numbers and TTL values keep the individual reports organized and dated. One unique complaint per IP per epoch period prevents flooding. Differences in detail and propagation parameters exist between Root and Subordinate IIALP Servers to allow for more detail to be kept at the originating IIALP Server. Transmission Echoes, Redundant Handshaking, and Hierarchy Structure eliminate erroneous reporting. Routers and software running IIALP can use IIALP to create dynamic black hole lists for offending AS numbers that exceed a threshold. IIALP allows for an infinite number of different types of annoyances to exist but has concise templates for common annoyances such as SPAM. IIALP is a centralized logging system for Internet annoyance event reporting. Internet-Draft Iowa Internet Annoyance Logging Protocol Table of Contents 0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Automated Nuisance Reporting . . . . . . . . . . . . . . . . . 3 1a. ISP Upstream Propagation to Root IIALP Servers . . . . . . . . 4 2. Serial Numbers and TTL values at ISP and at Root . . . . . . . 4 3. Reversible Interoperability with IIALP log files . . . . . . . 5 4. Certificate and IP Access-List Compatibility . . . . . . . . . 5 5. Dynamic points based black hole lists . . . . . . . . . . . . 5 5a. Points System at ISP and Root . . . . . . . . . . . . . . . . 6 6. Anti-Spoofing and Anti-DOS structure . . . . . . . . . . . . . 6 7. Designed for Integration with SMTP servers . . . . . . . . . . 7 7a. Links to SMTP and Local Null IIALP logging . . . . . . . . . . 8 8. Root IIALP Servers Public vs. Private queries . . . . . . . . 8 8a. Root Server links to originating IIALP Server . . . . . . . . 8 9. Logging AS Number, ICANN Registrar Name, Telephone, etc. . . . 9 9a. A New TLD for logging such as .log . . . . . . . . . . . . . 10 10. Upstream IIALP records are condensed Subordinate records. . . 10 10a.Local vs. Upstream Logs and size reduction techniques . . . . 11 11. One Unique complaint per IP per epoch period . . . . . . . . 11 12. Time synchronization and timestamp accuracy expectations . . 12 13. Security and anonymous IIALP annoyance logging . . . . . . . 12 Davey, et al. Expires August 29, 2004 [Page 2] Internet-Draft Iowa Internet Annoyance Logging Protocol 0. Introduction Annoyance reporting was not a problem in the early years of the Internet. You simply emailed the ARIN contact for the Autonomous System (AS) that was annoying you and the system administrator there would cut of the user and launch an investigation into the annoyance and provide the abused with an answer on what happened and what measures were taken to correct the problem. Those were the good old days. Now ARIN contact email addresses are overwhelmed by spam and abuse reporting is more often missed. A centralized automated system for annoyance reporting, including spam, is needed to help protect the Internet end user that does not understand even what an ARIN contact email is. The answer is to design a protocol engineered to bring tranquility and accuracy to the chaos of Internet annoyance logging that is going on today. IIALP is that specific protocol. Designed to fit the needs of the current Internet annoyance logging void and beyond. The following points of function describe specific aspects of IIALP and are described as criteria for a successful Internet annoyance logging system. 1. Automated Nuisance Reporting. IIALP will allow end users and system administrators alike to enter annoyance complaint records into a central system for the Internet. IIALP is automated. Both the end user and the system admin will enter an IIALP annoyance event records into the IIALP Server at their ISP. This IIALP annoyance event record will be logged in full detail at the ISP IIALP Server. As the annoyance event moves up the IIALP hierarchy toward the Root IIALP Server it gets condensed into a summary of the event. All of this occurs automatically once the event is put into the IIALP system. The IIALP system also automatically attempts to notify IIALP Servers that have annoyance records at the Root IIALP Servers. If it were an IIALP annoyance record marked with the real-time flag set, the Root server would query the Subordinate server in an attempt to match the Root IALP record to a null event record at the Subordinate IIALP Server at the abusing IP site. Events that are not real-time are logged at the Subordinate IIALP server by the Root IIALP servers. Some IIALP annoyance events are real-time such as an email server anti-virus gateway. Some IIALP annoyance logs are old news and are not real time. Both have TTL that may be the same or different depending on the IIALP Server administrator settings for that IIALP server. Davey, et al. Expires August 29, 2004 [Page 3] Internet-Draft Iowa Internet Annoyance Logging Protocol 1a. ISP Upstream Propagation to Root IIALP Servers. IIALP Servers are links together using a hierarchy. There are 3 types of IIALP Servers , Root, Subordinate, and Rogue. Rogue IIALP Servers are IIALP Servers that are not associated with an AS Number. These would be operated, for instance, by ISPs that do not control the AS number assigned to their IP Space. Subordinate IIALP Servers are IIALP Servers hosted on Internet Networks that control an AS Number assigned to the IP address space. Root IIALP servers are IIALP Servers at the top of the hierarchy and provide a place for the centralized accumulation of upstream IIALP events and downstream IIALP notifications. Rogue IIALP Servers can only communicate upstream to Subordinate IIALP Servers and cannot communicate upstream to Root IIALP Servers. Rogue IIALP Servers communicate downstream to end users and lower level ISP entities lacking an AS Number. Subordinate IIALP Servers communicate upstream to the IIALP Root servers. Subordinate IIALP Servers communicate downstream to Rogue IIALP Servers and to end users using the IP Space allocated to the AS Number associated with that IIALP Server. Root IIALP Servers communicate upstream to other Root IIALP Servers and downstream only to Subordinate IIALP Servers. IIALP Root servers only contain compacted IIALP records. Subordinate IIALP servers can contain full and compacted records. Rogue IIALP servers can only contain full IIALP records. For every compacted record at the Root or Subordinate IIALP Server, there always will exist an original full IIALP record at the originating Subordinate IIALP Server or at the originating Rogue IIALP Server. 2. Serial Numbers and TTL values at ISP and at Root. IIALP event records contain a serial number, TTL, and time stamp. The serial number for Root IIALP Servers contains enough data to link it back to the matching full record at either the Subordinate IIALP Server or the Rogue IIALP Server. The TTL and time stamp determine how long the IIALP event record will remain in the IIALP system. The Root IIALP Servers have a fixed TTL value for each complaint type. The Subordinate and Rogue IIALP Servers can have different TTL values for different IIALP records as long as the TTL is equal to or greater that that of the Root IIALP Server for a particular annoyance type. Once the TTL has expired for an IIALP annoyance record it is moved from the live system to an archive folder for backup and eventual removal. Root IIALP servers backup all dead records for a fixed time period to be determined at a later date. Davey, et al. Expires August 29, 2004 [Page 4] Internet-Draft Iowa Internet Annoyance Logging Protocol 3. Reversible Interoperability with IIALP log files. IIALP Servers may store and retrieve IIALP annoyance event records in many different ways. Some IIALP Servers may store records in text files and others in a database. All IIALP Servers must have reverse compatibility with IIALP log files. IIALP log files are ASCI files ending with a .log extension. The first 5 characters of the IIALP log file are "IIALP" followed by the version number of IIALP running on the server that created the IIALP log file. This way, no matter what signal and system creates an IIALP Server, the ability to import and export IIALP log files ensures they can be transferred to any other IIALP Server. This is important for compatibility cross-platform exchange of IIALP annoyance records. The second line of the file contains a control byte to determine if the log file is a full or compacted record. ASCI "0" for full and ASCI "1" for compacted. The control byte is followed by an ACSI integer of variable length that determines IIALP annoyance type. Type "1" is for bulk unsolicited email or SPAM. Following all the control bytes is the actual IIALP record in the correct format for that particular type of IIALP annoyance record. The record always starts with the (serial number/TTL/time stamp) digest followed by the remainder of the record. The final format for a condensed IIALP log file for SPAM is on the order of 26 bytes in length. The final format for a full IIALP log file for SPAM is on the order of 256 bytes in length. The log file is the vehicle for IIALP Server annoyance record transfers between IIALP Servers. 4. Certificate and IP Access-List Compatibility. The IIALP must have support for existing public and private certificate infrastructure. The IIALP must also have support for IP access-list type of communication security. These 2 criteria will ensure secure, accurate and reliable reporting of annoyances. These properties will also enhance the security of the abused party. The idea is the protect the abused and expose the abuser. All stages of IIALP implementation and design need to adhere to this important constraint. 5. Dynamic points based black hole lists. One of the most important goals of IIALP is to allow ISP entities and entities at large to query IIALP Servers to determine the top abusers (IP addresses and AS Numbers) for a particular region or, as in the case of the Root IIALP Servers, the entire Internet. Davey, et al. Expires August 29, 2004 [Page 5] Internet-Draft Iowa Internet Annoyance Logging Protocol The top abusers are determined dynamically and in most cases instantly. This allows for routers and computers running IIALP to "black hole" these abuser IP addresses or IP address space. The concept of points based comes from the fact that IIALP is a system for logging annoyances and allows for a query in a form allowing for the query output to be the abusers above a certain abuse threshold number. For instance a query could be for the top 1000 abusers, or it could be for the abusers with over 5000 IIALP SPAM type 1 records the abuser IP Space. The idea is that IIALP keeps track of the abusers and does not in any way block anything by itself. IIALP is used as a tool to generate a "points based" dynamic black hole list. Rich higher level languages such as XML could interface with IIALP and shut down the worlds banking system to an abusing IP address all in real-time. 5a. Points System at ISP vs. Root. The queries at Root, Subordinate and Rogue IIALP Servers with respect to top abusers or abusers with a number of abuse records above a certain value is very similar. This allows the IIALP system to have Rogue, Subordinate, and Root black hole lists. For example, for your computers maybe a system administrator would only want to black hole abusers at the Subordinate level, but for the enterprise core Internet router the system administrator may want to use the Root IIALP Servers to generate the black hole list. Protecting the users from local threats and the routers from distant global threats all in real time using IIALP. 6. Anti-Spoofing and Anti-DOS structure. Anti-Spoofing is very important to the integrity of IIALP. A bogus report filed on behalf of an unknowing user would be detrimental to the accuracy and integrity of IIALP. For the reason the handshake between the client and Rogue or Subordinate IIALP Server must be rigorous enough to ensure that the IP address cannot be masked or manipulated. Redundant handshaking ensures the IP address sending the annoyance event record is really using that IP and is not using spoofing to fake it. This communication safeguard is in addition to the certificate and access-list support in IIALP. Denial of Service (DOS) could also affect the accuracy and availability of IIALP. For this reason the handshake needs to be such that it can quickly ignore multiple attempts to send records by IP addresses that are not permitted to send multiple records. Also duplicate annoyance records from the same IP address will need to be ignored to prevent a person from artificially re-voicing their complaints by mass producing them. Davey, et al. Expires August 29, 2004 [Page 6] Internet-Draft Iowa Internet Annoyance Logging Protocol In case an email virus, for instance, causes the generation millions of bogus complaints against an AS Number that is not involved with writing the virus, there needs to be a way to nullify the records using manual inspection. This is done to avoid damage to the IIALP system not to try and figure out which complaints are DOS and which ones are real. There will need to be 2 types, blind clearing and visible clearing. Blind clearing means the records are deleted and the Subordinate IIALP Servers are alerted to delete as well. Replacing all the IIALP annoyance records for that AS Number with a single blind record that stops the accumulation for a set time interval. That AS number is ignored for a fixed interval determined by the TTL of the blind record. The TTL for a blind record my be different at the local IIALP Server than it is at the Root IIALP server. Visible clearing means the IALP servers keep track of the bogus records as if they were viable, but the IIALP Servers when giving query results will identify the record with a visible clearing flag so that it is counted for statistical reasons, but is not used in any points calculations relating to black hole lists derived using IIALP queries. There is a setting in IIALP called the Circuit Breaker setting (CB). a CB value of 1 = 1 Query/Second The CB Value determines the maximum rate at which an IIALP server can accept requests. The rate varies depending on whether the request is public or private. Another setting called Byte Echo (BE) setting. A BE value of 1 = 1 byte required. This setting can be applied in the send, receive or both by a flag set by the IIALP Server. Only IIALP Servers can require these setting. The remote IIALP client must accept these and other constraints in order to keep the IIALP conversation going with that IIALP Server. The handshake can be made to be costly to the remote IIALP client in terms of bandwidth. Servers that have DOS attacks frequently can implement BE to cause the requests to require lengthy and complex headers to the remote side. The remote side IIALP client may be required to receive these complex headers as well. This keeps lower bandwidth DOS attacks down. Private IIALP sessions would not have BE unless specified by the local IIALP Server administrator. 7. Designed for Integration with SMTP servers. IIALP needs to be made compatible with the various SMTP implementations whenever possible. Davey, et al. Expires August 29, 2004 [Page 7] Internet-Draft Iowa Internet Annoyance Logging Protocol 7a. Links to SMTP and Local Null IIALP logging SMTP servers can log a null IIALP annoyance record at the IIALP Server to mark email send events. Sending email is an event on the SMTP server that is very likely to generate an annoyance report. It is for this reason the IIALP allows for any server implementing IIALP to create a null record at the IIALP Server marking the email send event. If a real-time IIALP annoyance record was created for a SPAM email received somewhere else by a Firewall device, it may be possible to match up many of the sending events, with the complaint events. This is very helpful for locating open mail Relays, etc. Or creating real-time black hole lists. Null records are extremely small and usually carry very long TTL values. Other types of null events such as at the type of null event that might occur, for instance, on a firewall or router device may have a shorter TTL. Many other protocols other than SMTP could also use null IIALP event records to mark events that have potential to generate annoyance. 8. Root IIALP Servers Public vs. Private queries Root IIALP Servers can be queried by the public just like the who-is servers are today. Public queries are a special class that requires specific security criteria set by Root IIALP administrator and the CB value. Public domain and commercial software might use IIALP to query the Root servers for top threats upon start up. Email client software plug-ins using IIALP could allow users to very quickly send an IIALP annoyance report to their local Rogue or Subordinate IIALP Server. Subordinate IIALP Servers are setup by the IIALP admin to query Root IIALP Servers at higher rates than public queries. Law enforcement branches such as the FBI could operate a Subordinate IIALP Server and compile data from the Root servers to help them find large abusers on the Internet. 8a. Root Server links to originating IIALP Server Root IIALP Server records are always linked to Subordinate records which may in tern be linked to Rogue IIALP Server records. The idea is that by querying the Root servers you can find the problem, then by following the links and querying the Subordinate servers you can get the detailed record which may show more data such as optional data fields in a particular IIALP full record. Davey, et al. Expires August 29, 2004 [Page 8] Internet-Draft Iowa Internet Annoyance Logging Protocol The Root IIALP Servers always have only condensed records. When a query is made, only the condensed record is output. It is with the serial number that the link is established to the Subordinate IIALP Server. The serial number points to which Subordinate server it came from. The serial number on the Subordinate IIALP Server record may in turn point to the originating full record on the Rogue IIALP Server. During an investigation the FBI could use IIALP to help identify networks or phone systems where abuse is more common there by narrowing the search helping them save resources. For historical reasons the TTL dead Root IIALP records can be archived forever and can be made available to the public or private by some means. Subordinate and Root IIALP Server operators would also be encouraged to archive the records to DVD-R or some media of choice. Investigators and historians could use the archived data to see what the hot spots may have been at another time. While the live data is very useful in stopping attacks and annoyances, the archived data could offered as historical annoyance trends. 9. Logging AS Number, ICANN Registrar Name, Telephone, etc. What to keep at the Root server condensed records? This will need to have some flexibility as new technologies emerge. Initially the Root servers will keep the timestamp digest, which links to the Subordinate IIALP Servers. The digest also identifies the record type, TTL, etc. The Root IIALP Servers will primarily also keep the following identity types when applicable with each record: IP Address and assigned AS Number FQDN and ICAAN registrar PSTN phone number and PSTN Number operator for that number When a complaint finally makes it to the Root IIALP server, the Root server will try and contact the identities controlling the identifying assets such as IP addresses, domain names, and PSTN phone numbers causing the abuse. A Root server getting a SPAM abuse report originating from an SMTP server IP will send a record of the report to the Subordinate IIALP Server for that IP AS Number. To find asset holders identified in IIALP records a DNS naming convention will need to be established. To locate IIALP servers for a particular AS Number an IIALP service record is placed at the DNS servers serving that AS Number. Davey, et al. Expires August 29, 2004 [Page 9] Internet-Draft Iowa Internet Annoyance Logging Protocol The PSTN companies would have an IIALP Server for taking records from digital abuse where a phone number is associated with it. SPAM with a 1-800 number is an example. Another example would be IP telephony abuse. For the domain naming system IIALP Servers could be established at a particular URL such as IIALP.domain.TLD Whatever the naming convention, it will be important so that Root servers receiving annoyance logs from somewhere on the Internet can let the Subordinate servers know there is a new record that has been added for their asset space or AS Number. 9a. A New TLD for IIALP logging namespace such as .log Establish a new TDN such as .log and the naming convention becomes very simple. For example, AS Number 2252 would have an IIALP Server listening at IIALP://2252.log The PSTN number 515-221-2500 would be listening at IIALP://5152212500.log The FQDN microsoft.com would be listening at IIALP://microsoftcom.log This allows for a simplified method for identifying the asset holders used in Internet abuse acts. A company like Microsoft may have a Subordinate server identified as microsoftcom.log and if it holds an AS Number 56156116165 and so could also have 56156116165.log point to the same Subordinate server. Although It could have 1 Subordinate server for its AS Number and another Subordinate server for its namespace. In the case of PSTN primary circuit holders, an IIALP Server for the PSTN number block might be a separate IIALP Server. The key is to use DNS, either as service records, or a new TLD. Whatever the naming convention, the DNS records will be populated from existing ARIN, PSTN and Domain Registrar Databases information. 10. Upstream IIALP records are condensed Subordinate records. There are 2 basic record templates for each complaint type a full record and a condensed record. The full records are held at the Rogue and Subordinate IIALP Servers and contain more detail of the annoyance. When the full record is passed up to the Root it is exported for transport as a condensed record. The condensed record mostly would contain only the identifying and timing attributes of the full record. Davey, et al. Expires August 29, 2004 [Page 10] Internet-Draft Iowa Internet Annoyance Logging Protocol 10a.Local vs. Upstream Logs and size reduction techniques. For some record types the condensed records might be compressed in a supported compression format for that template set. A template set is a specification set for a template format for a full and a condensed record pair. Supported compression types will likely be added as new technologies arise. Encoding is necessary for SPAM reporting to keep the reports small. For instance a an IP address is expressed in ASCI as a 15 byte word. The IP address, converted to a binary number, encoded to base 36, is represented by 6 ASCI characters. Encoding types will need to be added over time as newer technologies arise. 11. One Unique complaint per IP per epoch period. IIALP would be worthless if IIALP clients were not limited in the number of IIALP annoyance reports made. Each IIALP client can only create 1 complaint per IP, per epoch period. The epoch period is determined by the local and Root IIALP Server administrators. The Root IIALP Servers epoch period is set by the Root IIALP Server administrators to keep the number of records at a manageable level. The Subordinate and Rogue IIALP Servers epoch period is set by the Root IIALP Server administrators to keep the number of records at a manageable value. In the case where the epoch period is longer at the Root than at the Subordinate, the Subordinate will need to retry the upload of the compressed record to the Root IIALP Server. Once the epoch period expires the next retry will complete. The idea is that no one person can make a big impact to the Root IIALP Servers but a million people all annoyed by the same SPAM can make a huge impact. An particular IP address can only complain about each IP address only 1 time during each epoch period. 12. Time synchronization and timestamp accuracy expectations. All Root, Subordinate and Rogue IIALP Servers must be Stratum 1 NTP synchronized. Accuracy for reporting is expected to be within milliseconds of actual GMT. Timing is very critical for the proper function of IIALP. This is especially true with IIALP records that have the real-time flag set. The hopes of finding a matching null record if one exists become quite a bit more difficult if the time is off for IIALP Servers. Davey, et al. Expires August 29, 2004 [Page 11] Internet-Draft Iowa Internet Annoyance Logging Protocol 13. Security and anonymous IIALP annoyance logging. As stated earlier the abused are protected by their AS Number holder or asset holding institution. The IP of the annoyed may be unknown to all but the Subordinate IIALP Server. It may be such that only private queries can get that IP number back. The IP address may be in the record but may not be offered to the public if the abused so desires. 14. IPV6 Considerations. There will certainly need to be record templates made for IPV6 Internet abuse as well. It is too early to tell whether these templates would be a subset of the IPv4 templates or whether IPV6 record templates would be all new. In some cases it may be that both subsets and all new templates both exist. There will be a need to evaluate which scenario make the most sense. end Iowa Internet Annoyance Logging Protocol Comments are desired for contact info see http://www.abuselog.org draft-davey-iialp-00.txt Expires: August 29, 2004 Davey, et al. Expires August 29, 2004 [Page 12]