INTERNET-DRAFT George Davey draft-davey-iialp-05.txt Des Moines University Expires: Oct 19, 2006 Dan Arthur Freese Notis Global Internet Paula Davey KIDputer Corporation IIALP Working Group www.abuselog.org April 14, 2006 Iowa Internet Annoyance Logging Protocol (IIALP) pronounced E'-alp Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on Oct 19, 2006. Copyright Notice Copyright (C) The Internet Society 2006. 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 QOS lists for abusing Internet assets exceeding a set limit. 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. 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 vs. Root . . . . . . . . 4 3. Reversible Interoperability with IIALP log files . . . . . . . 5 4. IP Access List Compatibility . . . . . . . . . . . . . . . . . 6 4a. IIALP Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 6 5. Dynamic points based QOS lists . . . . . . . . . . . . . . . . 7 5a. Points System at ISP and Root . . . . . . . . . . . . . . . . 8 6. Anti-Spoofing and Anti-DOS structure . . . . . . . . . . . . . 8 6a. Zombie Proofing . . . . . . . . . . . . . . . . . . . . . . . 11 7. Designed for Integration with SMTP servers . . . . . . . . . 12 7a. Links to SMTP, Null IIALP Records, Abuse Declarations . . . . 12 8. Root IIALP Servers Public vs. Private queries . . . . . . . . 12 8a. Root Server links to originating IIALP Server . . . . . . . . 13 9. Logging AS Number, ICANN Registrar Name, Telephone, etc . . . 13 9a. A New TLD for logging such as .log . . . . . . . . . . . . . 14 10. Upstream IIALP records are condensed Subordinate records. . . 15 10a. Local vs. Upstream Logs and size reduction techniques . . . . 15 11. One Unique complaint per IP per epoch period . . . . . . . . 15 12. Time synchronization and timestamp accuracy expectations . . 16 13. Security and anonymous IIALP annoyance logging . . . . . . . 16 14. Time Stamp TTL digest description and mechanics . . . . . . . 17 15. Template Formats, Containers, and Granular settings . . . . . 17 15a. Global IIALP Server Settings vs. Granular Settings . . . . . 17 15b. Containers and Container Types. . . . . . . . . . . . . . . . 17 15c. XML linear I/O segment and container. . . . . . . . . . . . . 17 16. Statistics for IIALP Servers . . . . . . . . . . . . . . . . 17 17. Sample Template Set 1 for SPAM . . . . . . . . . . . . . . . 18 18. Mechanics of a Template 1 Report Start to Finish. . . . . . . 19 19. IIALP MIME Type and Description . . . . . . . . . . . . . . . 19 0. Introduction Annoyance reporting was not a problem in the early years of the Internet. You simply emailed the 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 Annoyance reporting 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 Annoyance reporting 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 to enter annoyance complaint records into a central system for the Internet. IIALP is automated. IIALP annoyance event records are input into the IIALP Server at the local ISP providing the IP to the abused. IIALP annoyance event records are logged in full detail at the ISP originating IIALP Server. As an IIALP 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 abuse report is logged into an IIALP server. The IIALP system also automatically attempts to notify downstream IIALP Servers that have new annoyance records logged at any Root or subordinate IIALP Server. IIALP annoyance records contain a real-time flag, when the real-time flag is set to 1, it means that the IIALP abuse report was filed in real-time by a computer in real-time and not a person such as from a port scan event caught by a firewall. For real-time IIALP abuse reports, the Root IIALP or Subordinate IIALP Server would query the IIALP 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 or notified to the downstream Subordinate or Rogue IIALP servers by the Root or Subordinate IIALP Servers. IIALP annoyance events flagged real-time, such as an email server anti-virus gateway. Some IIALP annoyance logs are older 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. There are actually 2 TTL values, TTL1 describes the time that the complaint will remain in the IIALP system, and the other TTL, TTL2, describes number of IIALP server hops. Both TTL values are in the time stamp digest of the IIALP abuse report. TTL2 gets decremented by 1 for each hop up the IIALP server hierarchy. 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. Lower level ISP entities lacking an AS Number must use a Rogue IIALP Server and must connect upstream to a Subordinate IIALP Server. This provides an automated way for an ISP holding an AS Number to view all down level ISP entities. This is one thing that is currently missing from the Internet. This is also one area of the Internet that broke down during the rapid expansion of the Internet. Many ISP have no idea how many sub ISPs exist under them. IIALP will provide a tool for ISP to decide weather or not to allow rogue IIALP server or not and to what IIALP peering depth to allow rogue servers to exist. The preferred method is for AS Number holders to contain only 1 rogue down level peering. 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 and Rouge IIALP Servers can contain full and compacted records. 2. Serial Numbers and TTL values at ISP vs. Root. IIALP event records contain a serial number, TTL, and time stamp digest. This time stamp digest will be described in detail in section 14. 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 a Rogue IIALP Server. The TTL and time stamp Digest determines how long the IIALP event record will remain active in the IIALP server. 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. 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 ASCII 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 the time stamp digest. The 3rd line contains an ASCII integer for the IIALP annoyance abuse log template type. Line 3 ASCII Type "1" is for bulk unsolicited email or SPAM Type1. The IIALP server administrator can set which IIALP to accept full or compact records from. In the access list restrictions accepting full compact or both is also defined. If a compact record is specified in the access list for that IIALP server and a full record is requested a compact record will be returned instead. 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, record type, followed by the remainder of the record. The format for a condensed IIALP log file for SPAM (Template 1) 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. IIALP servers can also have custom templates for internal data exchange such as XML, or some other markup language. 4. IP Access-List Compatibility and Certificates. IIALP must have support for access lists both globally and pertaining to each template as well. IP access-list type of communication security to make sure only authorized IIALP servers and clients are requesting and submitting IIALP records. An IIALP server cannot accept abuse records or transmit them until the access list is built. The access list specifies Down-level IP addresses for IIALP clients and servers as well as the up-level IIALP servers that IIALP server is authorized to upload IIALP records to. 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. Allowing support for an SMTP communication interface, allows using existing SMTP certificate infrastructure if desired and allows for SSL communication. This is optional because IIALP conversations are from client to ISP or from ISP to ISP, public queries only result in public results, so encryption is not needed. Also record encoding and encryption is a property of the IIALP template set, and therefore, IIALP by itself does not need a cryptographic transport. 4a. IIALP Vocabulary IIALP conversation uses the following vocabulary. This is the vocabulary thus far. More items will be added The IIALP Vocabulary cHELO? - public start request cHI? - Private start request cHISTR? - echoed Ack request HISTR - echoed Ack reply cHELOSTR? - echoed Ack request HELOSTR - echoed Ack reply OKSTART û public start Ack OKSTARTP - private start Ack cREQSEND? - request to send a record READYSEND - ready to accept a record RECSUC - record uploaded successfully RECFAIL - record upload failed ^ - end of file ^ cPUBRQ? - public query cPRIVRQ? - private query IIALP - start of IIALP log file AWK - yes NAK - no PRIVATE - Private restriction declaration WL? - White List QOS? û QOS cRST - Reset Session and start over cM û Invalid Command Try Again Commands start with a lower case c. Requests end with a ?. ^EOF string marks the end of the IIALP record and cannot be contained in an IIALP record of any type as it terminates the data stream. The ^ character is restricted and the "^EOF" string is forbidden. Likewise the "^EOL" string is forbidden in IIALP records. Byte Echoes are always lower case and exclude characters a-f. The 10 digit Hello Handshake string is comprised of numerical digits 0-9. 5. Dynamic points based QOS 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. Specifically to allow for quick identification of Internet zombie machines. The top abusers are determined dynamically and in most cases instantly. This allows for routers and computers running IIALP to lower the priority of the abusers IP addresses or IP address space for the TTL time period. 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 QOS 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, and release them based on the IIALP TTL specified by the IIALP abuse template for that abuse type. There is also a manual white list that can over-ride the dynamic QOS lists for a particular IIALP server. This way the IIALP administrator can input a white list for known abuse record types. You can query the IIALP server for the current white list for a specific abuse type. An example of this would be a known email server IP, or a known Internet search bot IP that people have been complaining about using IIALP to input abuse complaints. If they query the current white list first, they may not wish to continue the complaint process. The white list is provided by the ISP and is specific to each record. Large white lists may need to be downloaded from an FTP site. For a given IIALP template there can exist white listed Internet assets such as IP addresses for that record. The white list may come back as a ASCII list or as a URL to the ASCII list. The white list takes the form: WL asset#1 asset#2 asset#3 ^EOF Example: WL 209.234.66.150 209.234.66.151 209.234.66.152 ^EOF This example is for IP address assets. 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 QOS lists. For example, for your company wide client computers maybe a system administrator would only want to QOS abusers at the Subordinate level, but for the enterprise core Internet routers, the system administrator may want to use the Root IIALP Servers to generate the QOS 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 this 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. The handshake involves sending a session Identifier that must be repeated for the conversation to continue. Example 1: cHELO OKSTART Example 2: cHELO cHELOSTR?9281370412 HELOSTR9281370412 OKSTART 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. The access list for the IIALP server determines both access and CB value for a given IP address. Access lists are ASCII files on the IIALP server set up by the administrator. IIALP servers can exchange Access lists. Example 1, Global Access List: AL allow IP,CB,BE,AccessLevel 0-9 IP,CB,BE,AccessLevel 0-9 IP,CB,BE,AccessLevel 0-9 deny IP,Reply Type ^EOF Global Reply Types "NAK"-Negative Acknowledgement "PRIVATE"-Only private IIALP access "NULL"-Negative Acknowledgement 0 Bytes, sent after 3 NAKs Granular (Template Based) Reply Types "NAK"-Negative Acknowledgement "PRIVATE"-Only private IIALP access "NULL"-Negative Acknowledgement 0 Bytes, sent after 3 NAKs "CRYPT"-Cryptography is required "CODE"-Encoding is required Wildcards: *=any e.g. IP=209.234.*.*, or IP=*.*.*.* For the IP address range 209.234.160.0 255.255.248.0, the access list for IIALP would look like this: AL allow 209.234.160.*,0.25,B,0 209.234.161.*,0.25,B,0 209.234.162.*,0.25,B,0 209.234.163.*,0.25,B,0 209.234.164.*,0.25,B,0 209.234.165.*,0.25,B,0 209.234.166.*,0.25,B,0 209.234.167.*,0.25,B,0 deny ^EOF Granular (Template Based) Reply Types can contain special reply types. Also duplicate annoyance records from the same IP address will need to be ignored to prevent a person from artificially reproducing IIALP records by mass producing them or sending multiple duplicate records. The Null NAK helps the IIALP server under heavy attack conditions. Normally if a private connection only server gets a public query it will respond "PRIVATE" or "NAK" The IIALP server can also be set to use "" which makes the query appear to be unanswered. The IIALP server can also be set to answer redundant conversation attempts this way. The first time or 2 the IIALP server tells queries formally, after that is just sends a null response. 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 authentic. 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 for the abusing asset. That asset (IP Number, etc.) is ignored for a fixed interval determined by the TTL of the blind record at the root IIALP server. 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 QOS 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. The CB value is determined in the access list. Another setting called Byte Echo (BE) setting. The byte echo is different than the hello echo string as it must be carried through the entire conversation. The BE String is a per conversation string can be applied in the send, receive or both by a setting at 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 Byte Echo has 2 parameters, enable and length. Enable is either I for input echo, O for output echo, B for both input and output echo, and N for no Byte Echo. The other setting is the length of the echo string L. Here are some examples of the format of the Byte Echo: BE=B27 This is a Duplex Byte Echo 27 characters in length. BE=I64 This is an Input echo 64 characters in length. BE=N This specifies no Byte Echo. Using the Byte echo: A byte echo is a lower case ASCII string of characters and excludes the lower case a-f. It is limited in length by the IIALP server. The basic concept of the byte echo is to make the conversation costly in terms of bandwidth to the client if needed. 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 or from the remote side. The remote 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. 6a. Zombie Proofing End user IIALP authentication requires human authentication methods such as a distorted image interpretation. This includes end user communication with Rogue and Subordinate IIALP Servers at the ISP. Rogue IIALP servers must use authentication for communication. Subordinate IIALP server to Root IIALP server communication must also utilize authentication. IIALP Authentication types can be set up by the particular software implementation but must include "man in the middle", "buffer overflow" and "packet stiffing" protection. 7. Designed for Integration with SMTP servers. IIALP needs to be made compatible with the various SMTP implementations whenever possible. This means that some IIALP servers may have an SMTP communications port as well as an IIALP communications port. Information contained in IIALP SPAM abuse records may be linked back to a mail send event on the email server. This is the reason IIALP needs to be built with SMTP compatibility in mind. Like SMTP, IIALP uses TCP to exchange a vocabulary of commands on a custom port like TELNET. The vocabulary is specialized for efficient exchange of abuse logs with emphasis on handshaking, authentication, compression and Internet Zombie proofing. 7a. Links to SMTP, Null IIALP Records, Abuse Declarations 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 local IIALP Server marking the email send event. If a real-time IIALP annoyance record was created for a SPAM email received somewhere else by, for example, a Firewall device, it will be possible to match up the null send events, with future complaint events. This is very helpful for locating open mail Relays, etc. Or verifying an abusing IP address. 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 such as search bot IP access. Abuse declarations are really potential abuse declarations. Abuse declaration records are matched with abuse record templates, so for a particular template, the IIALP server administrator can assign assets that may frequently appear in that type of complaint. An example is if you have an email server, the IP address for your legitimate email server would go in the record named "declared" in the container for type 1 SPAM, which is template container 1. The public (if allowed) could query the IIALP server for a particular AS number to see if this type1 SPAM is coming from their main email server or a virus infected workstation. This would allow a person to Query the IIALP server servicing an Internet ISP for all the legitimate email servers for that ISP. So if you were to get email from any other IP at that ISP, it has a high probability of being SPAM or virus email traffic. 8. Root IIALP Servers Public vs. Private queries Public and private access is determined by the IIALP server Global setting and by the granular settings specified in the template container for the record type based on the records template. If a person from the public Internet makes a query for spam records for the IP 209.234.66.150 and the query is done from 209.234.66.151. First, the IIALP server will check the global access list for public queries to see if the respective query is public or private, Then IIALP will check the template container for granular access that may be allowed based on the template type. 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 can use IIALP to query IIALP Root servers for top threats. 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 at their ISP. 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 law enforcement could operate a Subordinate IIALP Server and compile data from the Root servers to help them find large abusing networks 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. 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 a Rogue or Subordinate IIALP Server. Abused persons or entities can 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, Time Stamp and many other control bytes. Identifying Asset Holder Type (IAHT) is the "thing" that identifies the abuser or the abusing Asset. Traditionally these were IP addresses, but at this time there are 3 types, IIALP allows for an infinite number of IAHT types, the first 3 types are listed below. 1-IP Address and assigned AS Number 2-FQDN and ICAAN registrar 3-PSTN phone number and PSTN Number operator for that number All IIALP abuse records must have one IAHT element and likewise each template must record at least one IAHT. Otherwise, what is the use of reporting anything. 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. 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 company123.com would be listening at IIALP://company123com.log If adopted the .log root DNS server would translate IAHT objects into IIALP:// URLs. Keep in mind the traditional DNS records can be used without the adoption of a new TLD .log. and the creation of a new TLD for IIALP logging would only be needed to control the security of the IIALP TLD's sold by ICANN Registrars. This allows for a simplified method for identifying the asset holders used in Internet abuse acts. Very large companies may have a Subordinate server identified as company123com.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. You could just as easily put things beneath an iialp.org domain: Object IIALP FQDN ---------------- ------------------------------ AS 2252 2252.as.iialp.org +1-555-221-2500 15552212500.tel.iialp.org example.com example.com.dns.iialp.org 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. 10a.Local vs. Upstream Logs and size reduction techniques. For some record types the records are compressed using GZIP supported compression format for that template set. The file compression works on the session layer to make it simple. An IIALP record for a specific template can be compressed using GZIP. 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 IAHT, 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. Because each template specifies at least 1 abusing IAHT and IIALP knows the abused IAHT, then it only allows 1 complaint from IAHTa (the abused) for IAHTb (the abuser) per epoch period. So if a person using IP 209.234.66.150 can only complain about IP 209.234.66.151 one time during the epoch period which usually is 4 hours. If a person gets an abusive call from an abusing PSTN IP phone 515-221-2500, then the IAHT (Abused IP) can only complain about 1 time about the abusing IAHT (Abuser PSTN) 1 time during the epoch period. 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. 12. Time synchronization and timestamp accuracy expectations. All Root, Subordinate and Rogue IIALP Servers must be Stratum 2 NTP. Standard BIOS clocks must be kept within a few milliseconds of GMT. The update period will then depend on whatever is necessary to keep a specific BIOS Real-Time clock within this tolerance level. Multiple time sources are recommended. 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. 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. The security around which information is public and which is private is specified globally for the server and granularly for each template type. These settings are set by the IIALP server administrator and sometimes are specified the template. 14. Time Stamp TTL digest description and mechanics. The Time Stamp Digest (TSD) contains the following thing so far: AT-Abuse Time ST-Server Time TTL-Half Life of Record TTL2-Metric of record SN-Serial Number for record SN-IP of first IIALP server TZO-Time zone offset in minutes originating server RN-Roll Nibble (Root, Subordinate, etc.) Flags Real-Time Compressed TTLC (Custom TTL) Active or Dead 15. Template Formats, Containers, and Granular Settings Template formats are like variable declarations for a computer program. They are arranged lines of text that describe the data type expected length and format. Each line of a template corresponds to a line in the IIALP record. All Data Fields are assumed to be 80 character strings unless otherwise specified in the template. The data types are summarized by the templates being compiled and will become the Root template. In most templates IP addresses should be represented using the standard ::ffff:192.168.0.1 form to eliminate the need for an IPV6 template. In some cases templates may want to specifically use the IPV4 format for whatever reason. 15a. Global IIALP Server Settings vs. Granular Settings This section will describe the granular settings contained within the template including how the template containers are resolved by IIALP. 15b. Containers and Container Types A template set is a specification set for a template format for a full and a condensed record pair. A template is defined by what is in the template container and some template containers may contain many sub-types of complaints in addition to the classical full and compressed styles. Standard types of compression and encryption can be added to the template container in this manner. 15c. XML linear I/O segment and container XML linear I/O segment is a way to exchange IIALP records using XML. It is used to import or export IIALP records between IIALP Servers/clients. If the 1st line of the IIALP file reads IIALPXML Instead of just IIALP this designates the following file is XML and Should be parsed accordingly from the tag to the tag. XML templates are contained in the text templates as a container Which specifies the linear translation between the line item data In the text template and the XML template. The master template which will be published online will contain the XML designations and pointers to the XML container within the other templates. 16. Statistics for IIALP Servers These settings provide the baseline for Network Administrators to set QOS levels to obtain a particular predetermined statistical outcome. IIALP can be used to generate a self measuring t test to see the outcome and probable accuracy of certain blocking levels by guessing the entire population from hit statistics. Basic operational stats will be described in this section tat all IIALP servers must be able to provide the pre-canned data sets for and these statistics sets are also maintained in the template container for each abuse type. 17. Sample Template Set 1 for SPAM A type 1 abuse complaint is bulk unsolicited email or SPAM. *****Full LOG Start***** SMTP (All Hops): SMTP (Last Hop) IP: SMTP (Last Hop) IP Registry/AS Number: SMTP (Last Hop) IP Country/State: SMTP (Last Hop) IP Abuse Email Addresses: SMTP (Last Hop) TLD: SMTP (Last Hop) TLD Registrar: SMTP (Last Hop) TLD Registered Owner Country/State: SMTP (Last Hop) TLD DNS TLD: SMTP (Last Hop) TLD DNS IP: Content IP1: Content IP1 Registry/AS Number: Content IP1 Country/State: Content IP1 Abuse Email Addresses: Content IP2: Content IP2 Registry/AS Number: Content IP2 Country/State: Content IP2 Abuse Email Addresses: Content TLD1: Content TLD1 ICANN Registrar: Content TLD1 ICANN Registrar Abuse Email Address or URL: Content TLD1 Account Contact Country/State: Content TLD1 DNS1 IP: Content TLD1 DNS1 IP DNSMx for TLD1: Content TLD1 DNS1 IP DNSMx for TLD1 Registry/AS Number: Content TLD1 DNS1 IP Registry/AS Number: Content TLD1 DNS1 IP Country/State: Content TLD1 DNS1 IP Abuse Email Addresses: Content TLD1 DNS1 IP TLD: Content TLD1 DNS1 IP TLD DNS TLD: Content TLD1 DNS1 IP TLD DNS TLD ICANN registrar: Content TLD1 DNS1 IP TLD DNS TLD IP: Content TLD1 DNS1 IP TLD DNS TLD DNS IP: Content TLD1 DNS1 IP TLD DNS TLD DNS IP DNSMx for TLD1: Content TLD1 DNS1 IP TLD DNS TLD DNS IP TLD: Content TLD1 DNS1 IP TLD DNS TLD DNS IP TLD ICANN Registrar: Content TLD2: Content TLD2 ICANN Registrar: Content TLD2 Account Contact Country/State: Content TLD2 ICANN Registrar Abuse Email Address or URL: Content TLD2 DNS1 IP: Content TLD2 DNS1 IP DNSMx for TLD2: Content TLD2 DNS1 IP Registry/AS Number: Content TLD2 DNS1 IP Country/State: Content TLD2 DNS1 IP Abuse Email Addresses: Content TLD2 DNS1 IP TLD: Content TLD2 DNS1 IP TLD DNS TLD: Content TLD2 DNS1 IP TLD DNS TLD ICANN registrar: Content TLD2 DNS1 IP TLD DNS TLD IP: Content TLD2 DNS1 IP TLD DNS TLD DNS IP: Content TLD2 DNS1 IP TLD DNS TLD DNS IP DNSMx for TLD2: Content TLD1 DNS1 IP DNSMx for TLD2 Registry/AS Number: Content TLD2 DNS1 IP TLD DNS TLD DNS IP TLD: Content TLD2 DNS1 IP TLD DNS TLD DNS IP TLD ICANN Registrar: Content PSTN Number for product: Content PSTN Number for product Parent Phone Company: Content PSTN Number for product Parent Phone Company Country/State: Content PSTN Number for product Abuse Email Address: Content PSTN Number for product Abuse Address: Content PSTN Number for product Country/State: Removal URL existence: Removal URL IP: Removal URL TLD: Removal URL IP AS Number: *****Full LOG END***** *****Summary LOG START***** SMTP (Last Hop) IP: SMTP (Last Hop) IP Abuse Email Addresses: Content IP: Content Registry/AS Number Content IP Country/State: Content IP Abuse Email Addresses: Content TLD: Content TLD ICANN Registrar: Content TLD1 ICANN Registrar Abuse Email Address or URL: DNS IP: DNS TLD: DNS TLD ICANN Registrar: DNS TLD ICANN Registrar Abuse Email Address or URL: DNS TLD MxDNS IP for TLD: DNS TLD DNS IP: DNS TLD DNS IP Registry/AS Number: DNS TLD DNS TLD: DNS TLD DNS TLD ICANN Registrar: DNS TLD DNS TLD ICANN Registrar Abuse Email Address or URL: Content PSTN Number for product: Content PSTN Number for product Parent Telecom: Content PSTN Number for product Parent Telecom Abuse Email or URL: *****Summary LOG END***** 18. Mechanics of a Template 1 Report Start to Finish This section will describe the path of a type 1 abuse complaint as it flows up the IIALP food chain. 19. IIALP MIME Type and Description Register an IANA MIME type for the IIALP log files. Initial requests will be made for the MIME application/x-iialp This will allow cross platform recognition of the IIALP log file type outside the DOS file extension which is not used by many types of computer systems. It should be emphasized that IIALP log files are merely an interchange file format, and that an implementation should be free to store data locally in whatever form it pleases. For instance in some operating systems, it may be beneficial to use a technique similar to what LDAP uses and create an interchange file format similar to LDIF that can contain an arbitrary number of events in a more human-readable form: # defines a version number for the file as a whole: version: 1.0 event: 6e219760-d51e-11d8-9669-0800200c9a66 type: ube event: 8c486700-d51e-11d8-9669-0800200c9a66 type: ube This also allows extensibility. version 1.1 could add additional fields without impacting readability by 1.0 implementations. This and many other considerations will need to made when designing applications utilizing IIALP. Iowa Internet Annoyance Logging Protocol Comments are desired for contact info see http://www.abuselog.org or call 515-480-1605. draft-davey-iialp-05.txt Expires: Oct 19, 2006 end Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 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.