INTERNET-DRAFT                                           George Davey
draft-davey-iialp-07.txt                        Des Moines University
Expires: July 8, 2007                                      Dan Arthur
                                         Freese Notis Global Internet
                                                          Paula Davey
                                                 KIDputer Corporation
                                                  IIALP Working Group
                                                     www.abuselog.org
                                                          Jan 8, 2007
              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 July 8, 2007.
   
Copyright Notice

   Copyright (C) The Internet Society 2007. 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. Standard XML and TCP security techniques,
  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 limits. 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  . . . . . . . . . . . . . . . . 4
   3.   Reversible Interoperability with IIALP log files . . . . . . . 4
   4.   IP Access List Compatibility . . . . . . . . . . . . . . . . . 5
   4a.  IIALP Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 5
   5.   Dynamic points based QOS lists . . . . . . . . . . . . . . . . 5
   6.   Anti-Spoofing and Anti-DOS Methods for XML over TCP. . . . . . 6
   6a.  Zombie Proofing . . . . . . . . . . . . . . . . . . . . . . . .9
   7.   Designed for Integration with SMTP servers  . . . . . . . . . .9
   7a.  Links to SMTP, Null IIALP Records, Abuse Declarations . . . . .9
   8.   Root IIALP Servers Public vs. Private queries . . . . . . . . 10
   8a.  Root Server links to originating IIALP Server . . . . . . . . 11
   9.   Deciding What to Log in a Template. . . . . . . . . . . . . . 11
   9a.  A New TLD for logging such as .log  . . . . . . . . . . . . . 12
   10.  Upstream IIALP records are condensed Subordinate records. . . 13
   11.  One Unique complaint per IP per epoch period  . . . . . . . . 13
   12.  Time synchronization and timestamp accuracy expectations  . . 14
   13.  Security and anonymous IIALP annoyance logging  . . . . . . . 14
   14.  Timing and Role Related Tags for XML files. . . . . . . . . . 14
   15.  Template Formats, Containers, and Granular settings . . . . . 14
   15a. Global IIALP Server Settings vs. Granular Settings  . . . . . 15
   15b. Containers and Container Types. . . . . . . . . . . . . . . . 15
   15c. XML linear I/O segment and container. . . . . . . . . . . . . 15
   16.  Statistics for IIALP Servers  . . . . . . . . . . . . . . . . 15
   17.  Sample Template Set 1 for SPAM  . . . . . . . . . . . . . . . 15
   



   
   



























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 tag, when the
    real-time tag 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. 
    IIALP Uses another technique called null reporting.  If you
    send bulk email or ping a host you can create a null abuse record
    preemptively so that if someone on the receiving end of the
    perceived abuse logs an IIALP abuse complaint it can be matched
    up with the null record.  This way the abused is duly notified
    that the abusive event was done on purpose and the null record
    may also contain a reason for the ping or bulk email.

    A TTL tag is also specified for each abuse type that allows the
    complaints to expire out of the IIALP system.  This allows the
    system to handle more complaints and also allows the abuse
    template creators to specify how long a particular complaint
    should stay in the system.



1a. ISP Upstream Propagation to Root IIALP Servers.

    IIALP Servers are linked 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.  

    Root IIALP Servers communicate 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.

    The server where the complaint is logged keeps a full record
    of the abuse and passes the compact IIALP record upstream.
     

2.  Serial Numbers and TTL values.


    IIALP event records contain a serial number, TTL, and server IP
    etc.  Some examples of proposed tags for this purpose are 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
    info determines how long the IIALP event record will remain 
    active in the IIALP system.
    The Root IIALP Servers have a fixed TTL value for each 
    complaint type based on the template for that complaint type
    at the root server.  Custom complaints and templates that are
    not specified by the root server system can be used, but will
    not propagate upstream beyond the subordinate IIALP server
    where the custom complaint type is specified.
    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 historical retrieval.
    The TTL can be adjusted from time to time to optimize the
    data storage needed for a specific abuse type in the IIALP
    system.



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
    XML files ending with a .iialp.xml extension.  The XML file uses
    tags to define data parameters being transmitted in the log file.
    The minimum set of tags defines the IIALP file data with a start
    tag <iialp> and an end tag </iialp> and the start tag must be
    the first string in the log file.

    The IIALP XML markup tags also specify such things as TTLs, IPs
    and serial numbers.

    These tags and templates are specified by the root servers in
    HTML/XML folder paths specified by IIALP.


4.  IP Access-List Compatibility and Certificates.

    IIALP servers 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.
    

4a. IIALP Vocabulary

    IIALP conversation uses XML tags and templates to transfer data
    regarding abuse complaints to a central root system.  Examples
    of some tags are listed below but the dynamic list is always
    supplied by the root IIALP servers.

    <iialp>
    <ttl>
    <serial-number>
    <real-time>

    For any 1 abuse type there would typically be 25 to 50 template
    specific tags.  The tags listed above are global to IIALP and
    are specified by the root server in the global template.  The
    global template provides the pieces for defining other templates.


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>
    asset1
    asset2
    asset3
    </wl>

    example:
    <wl>
    209.234.66.150
    209.234.66.151
    209.234.66.152
    </wl>

    This example is for IP address assets.

    


6.  Anti-Spoofing and Anti-DOS Methods for XML over TCP.

    Anti-Spoofing is very important to the integrity of IIALP. A bogus
    report filed on behalf of an unknowing user would not be
    detrimental to IIALP.  Many unique complaints are by design
    weighted more heavily that many abuse complaints from one host.
    Also because IIALP uses HTTP and XML to communicate, the may of
    thousands of previously developed TCP session security tools
    can be used and designed into a specific implementation of IIALP
    running on a server.
    The following are guidelines for best practices that can be used to
    protect the IIALP XML TCP conversation from being tampered with.
    Handshakes between IIALP Server may need to be hardened
    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:

    
    <access-list><allow>
    IP,CB,BE,AccessLevel 0-9
    IP,CB,BE,AccessLevel 0-9
    IP,CB,BE,AccessLevel 0-9
    </allow><deny>
    IP,Reply Type
    </deny></access-list>

    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
  
    IP Access List Example:

    <access-list><allow>
    209.234.160.0
    209.234.161.0
    209.234.162.0
    </allow><deny>
    209.234.163.0
    209.234.164.0
    209.234.165.0
    209.234.166.0
    209.234.167.0    
    </deny></access-list>

    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 NULL 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
    tag 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
    It is recommended that implementations of IIALP  servers
    and applications have some sort of zombie host protection.
    End user IIALP authentication needs 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 may use 
    authentication for communication to queries.
    Subordinate IIALP server to Root IIALP server communication may
    also utilize authentication.
    IIALP Authentication types can be set up by the particular software
    implementation but should  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.

    


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.  IAHT and Deciding What to Log in a Template

    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 info,

    which links to the Subordinate IIALP Servers.  The info
    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 many types, IIALP allows for
    an infinite number of IAHT types.  Examples of 3 of them are
    detailed 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.

    The IHAT attributes are defined by the root servers in the
    global template set.

    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

    The main reasoning for creating a new TLD for this is to
    define a standard by which entities elect into the IIALP
    system to ensure its security from forged listing servers.
    This could also be done using sub domains.

    Establish a new TDN such as .log and the naming convention
    becomes very simple. For example, AS Number 2252 would have
    an IIALP subordinate server listening at
    IIALP://as2252.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 64200 and so could also have
    64200.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
    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.



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.  
    Multiple complaints are recorded within the original
    complaint using the count tag.  Complaint flooding only
    affects the local subordinate IIALP server by causing it to
    increment the count tag to its maximum value specified in
    the complaint template for the complaint type.  Periodically
    the incremented values are propagated upstream.  Each client
    can only create 1 complaint per IAHT, per epoch period. The epoch
    period is determined by the local and Root IIALP Server 
    administrators and or the template.
    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 override
    its value to that of the root it wishes to upload to.  
    
    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 use
    NTP.  Standard BIOS clocks must be kept within a second
    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 critical
    for the proper function of IIALP.  This is especially true with


    IIALP records that have the real-time tag 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. Timing and Role related tags for IIALP XML files
    
examples thus 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
Role-Info (Root, Subordinate, etc.)
Real-Time
Compressed
TTLC (Custom TTL)
Active

    These are to be defined in detail by the IIALP servers.


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
     There are global containers such as IAHT and ROOT.  These
     containers contain templates and template descriptions.  To
     find the Global settings start in the ROOT container.
     Templates are located in the TEMPLATE container.  Much more
     definition in this area will come soon.


15b. Containers and Container Types
    A template set is a specification set for an XML tag 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 sub-containers
    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 using a MIME wrapper.
    

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 XML tag to the XML 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.
  
*Start Full Log*    
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:
*End Full Log*    


*Start Condensed Log*    
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:
*End Condensed Log*    




   
Iowa Internet Annoyance Logging Protocol
Comments are desired for contact info see http://www.abuselog.org 
for details.  All suggestions sent by email must contain IIALP
in the subject line to avoid being treated as spam.
draft-davey-iialp-07.txt
Expires: July 8, 2007
end

Copyright (C) The Internet Society (2007).

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, 
(THE IETF TRUST) 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.