Internet DRAFT - draft-moriarty-post-inch-rid

draft-moriarty-post-inch-rid



Extended Incident Handling Working Group            Kathleen M. Moriarty
Internet-draft                                                       EMC
Intended status: Informational                              July 6, 2010
draft-moriarty-post-inch-rid-12.txt 
Expires: January 6, 2011 


              Real-time Inter-network Defense

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.









Internet-Draft                                              July 6, 2010


Abstract


    Network security incidents, such as system compromises, worms,
    viruses, phishing incidents, and denial of service, typically
    result in the loss of service, data, and resources both human and
    system.  Network providers and Computer Security Incident Response
    Teams need to be equipped and ready to assist in communicating and
    tracing security incidents with tools and procedures in place
    before the occurrence of an attack.  Real-time Inter-network
    Defense outlines a proactive inter-network communication method to
    facilitate sharing incident handling data while integrating
    existing detection, tracing, source identification, and mitigation
    mechanisms for a complete incident handling solution.  Combining
    these capabilities in a communication system provides a way to
    achieve higher security levels on networks.  Policy guidelines for
    handling incidents are recommended and can be agreed upon by a 
    consortium using the security recommendations and considerations.




































Moriarty                Expires: January 6, 2011                [Page 2]
Internet-Draft                                              July 6, 2010



                           TABLE OF CONTENTS


Status of this Memo ................................................   1

Copyright Notice ...................................................   1

Abstract ...........................................................   2

1. Normative and Informative .......................................   5
    1.1 Terminology ................................................   5
    1.2 Introduction ...............................................   5
    1.3 Attack Types and RID Messaging .............................   6

2. RID Integration with Network Provider Technologies ..............   8

3. Characteristics of Attacks ......................................   9
    3.1 Integrating Trace Approaches ...............................  11
    3.2 Superset of Packet Information for Traces ..................  11

4. Communication Between Network Providers .........................  12
    4.1 Inter-Network Provider RID Messaging .......................  14
    4.2 RID Network Topology .......................................  16
    4.3 Message Formats ............................................  16
        4.3.1 RID Data Types .......................................  17
            4.3.1.1  Boolean .......................................  17
        4.3.2 RID Messages and Transport ...........................  17
        4.3.3 IODEF-RID Schema .....................................  18
            4.3.3.1 RequestStatus Class ............................  19
            4.3.3.2 IncidentSource Class ...........................  21
            4.3.3.3 RIDPolicy  .....................................  22
        4.3.4  RID Namespace .......................................  25
    4.4 RID Messages ...............................................  26
        4.4.1 TraceRequest .........................................  26
        4.4.2 RequestAuthorization Message .........................  27
        4.4.3 Result Message .......................................  28
        4.4.4 Investigation Message Request ........................  29
        4.4.5 Report Message .......................................  30
        4.4.6 IncidentQuery ........................................  31
    4.5 RID Communication Exchanges ................................  32
        4.5.1 Upstream Trace Communication Flow ....................  34
            4.5.1.1 RID TraceRequest Example .......................  35
            4.5.1.2 RequestAuthorization Message Example ...........  38
            4.5.1.3 Result Message Example .........................  38
        4.5.2 Investigation Request Communication Flow .............  41
            4.5.2.1 Example Investigation Request ..................  41
            4.5.2.2 RequestAuthorization Message Example ...........  43
        4.5.3 Report Communication .................................  44
            4.5.3.1 Report Example .................................  44
        4.5.4 IncidentQuery Communication Flow .....................  46
            4.5.4.1 IncidentQuery Example ..........................  46


Moriarty                Expires: January 6, 2011                [Page 3]
Internet-Draft                                              July 6, 2010



5. RID Schema Definition ...........................................  48

6. Security Considerations .........................................  52
    6.1 Message Transport ..........................................  53
    6.2 Message Delivery Protocol - Integrity and Authentication ...  54
    6.3 Transport Communication ....................................  55
    6.4 Authentication of RID Protocol .............................  55
        6.4.1 Multi-hop TraceRequest Authentication ................  56
    6.5 Consortiums and Public Key Infrastructures .................  58
    6.6 Privacy Concerns and System Use Guidelines .................  58

7. IANA Considerations .............................................  63

8. Summary .........................................................  63

9. Normative References ............................................  64

10. Informative References .........................................  65

11. Acknowledgements ...............................................  66

12. Author Information .............................................  66































Moriarty                Expires: January 6, 2011                [Page 4]
Internet-Draft                                              July 6, 2010


1. Normative and Informative

    The XML schema [4] and transport requirements contained in this
    document are normative, all other information provided is intended
    as informative.  More specifically, the following sections of this
    document are intended as informative: 1, 2, 3, the subsections of 4
    including the introduction to 4, 4.1, and 4.2.
    The following sections of this document are normative:
    The sub-sections of 4 including 4.3, 4.4, 4.5, Section 5,
    and Section 6.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2 Introduction

    Incident handling involves the detection, reporting,
    identification, and mitigation of an attack, whether it be a system
    compromise, socially engineered phishing attack, or a denial of
    service attack.  When an attack is detected, the response may
    include simply filing a report, notification to the source of the
    attack, a request for mitigation, or the request to locate the
    source.  One of the more difficult cases is that in which the
    source of an attack is unknown, requiring the ability to trace the
    attack traffic iteratively upstream through the network for the
    possibility of any further actions to take place.  In cases when
    accurate records of an active session between the victim system and
    the attacker or source system are available, the source is easy to
    identify.  The problem of tracing incidents becomes more difficult
    when the source is obscured or spoofed, logs are deleted, and the
    number of sources is overwhelming.  If the source of an attack is
    known or identified, it may be desirable to request actions be
    taken to stop or mitigate the effects of the attack.

    Current approaches to mitigating the effects of security incidents
    are aimed at identifying and filtering or rate-limiting packets
    from attackers who seek to hide the origin of their attack by
    source address spoofing from multiple locations.  Measures can be
    taken at network provider (NP) edge routers providing ingress,
    egress, and broadcast filtering as a recommended best practice in
    [RFC2827].

    Network providers have devised solutions, in-house or commercial,
    to trace attacks across their backbone infrastructure to either
    identify the source on their network or on the next upstream
    network in the path to the source.  Techniques such as collecting
    packets as traffic traverses the network have been implemented to
    provide the capability to trace attack traffic after an incident
    has occurred.  Other methods use packet-marking techniques or flow-


Moriarty                Expires: January 6, 2011                [Page 5]
Internet-Draft                                              July 6, 2010


    based traffic analysis to trace traffic across the network in real
    time.  The single-network trace mechanisms use similar information
    across the individual networks to trace traffic.  Problems may
    arise when an attempt is made to have a trace continued through the
    next upstream network since the trace mechanism and management may
    vary.

    In the case in which the traffic traverses multiple networks, there
    is currently no established communication mechanism for continuing
    the trace.  If the next upstream network has been identified, a
    phone call might be placed to contact the network administrators in
    an attempt to have them continue the trace.  A communication
    mechanism is needed to facilitate the transfer of information to
    continue traces accurately and efficiently to upstream networks.
    The communication mechanism described in this paper, Real-time
    Inter-network Defense (RID), takes into consideration the
    information needed by various single network trace implementations
    and the requirement for network providers to decide if a trace
    request should be permitted to continue.  The data in RID messages
    is represented in an Extensible Markup Language (XML) [1] document
    using the Incident Object Description Exchange Format (IODEF)
    and RID.  By following this model, integration with other aspects of
    the network for incident handling is simplified.  Finally, methods
    are incorporated into the communication system to indicate what
    actions need to be taken closest to the source in order to halt or
    mitigate the effects of the attack at hand.  RID is intended to
    provide a method to communicate the relevant information between
    Computer Security Incident Response Teams (CSIRTs) while being
    compatible with a variety of existing and possible future detection
    tracing and response approaches.

    Security and privacy considerations are of high concern since
    potentially sensitive information may be passed through RID
    messages.  RID messaging takes advantage of XML security and
    privacy policy information set in the RID schema. The RID schema
    acts as an XML envelope to support the communication of IODEF
    documents for exchanging or tracing information security incidents.
    RID messages are encapsulated for transport, which is defined in a
    separate document.  The authentication, integrity, and
    authorization features each layer has to offer is used to achieve
    a necessary level of security.

1.3 Attack Types and RID Messaging

    RID messaging is intended for use in coordinating incident handling
    to locate the source of an attack and stop or mitigate the effects
    of the attack.  The attack types include system or network
    compromises, denial of service attacks, or other malicious network
    traffic.  RID is essentially a messaging system coordinating attack
    detection, tracing mechanisms, and the incident handling responses
    to locate the source of traffic.  If a source address is spoofed, a
    more detailed trace of a packet (RID TraceRequest) would be


Moriarty                Expires: January 6, 2011                [Page 6]
Internet-Draft                                              July 6, 2010


    required to locate the true source.  If the source address is
    valid, the incident handling may only involve the use of routing
    information to determine what network provider is closest to the
    source (RID Investigation request) and can assist with the
    remediation.  The type of RID message used to locate a source is
    determined by the validity of the source address.  RID message
    types are discussed in Section 4.3.

    DoS [11] attacks are characterized by large amounts of traffic
    destined for particular Internet locations and can originate from a
    single or multiple sources.  An attack from multiple sources is
    known as a distributed denial-of-service attack (DDoS).  Because
    DDoS attacks can originate from multiple sources, tracing such an
    attack can be extremely difficult or nearly impossible.  Many
    TraceRequests may be required to accomplish the task and may
    require the use of dedicated network resources to communicate
    incident handling information to prevent a DoS against the RID
    system and network used for tracing and remediation.  Provisions
    are suggested to reduce the load and prevent the same trace from
    occurring twice on a single-network backbone discussed in Section 4
    on communication between NPs.  The attacks can be launched from
    systems across the Internet unified in their efforts or by
    compromised systems enlisted as "zombies" that are controlled by
    servers, thereby providing anonymity to the controlling server of
    the attack.  This scenario may require multiple RID traces, one to
    locate the zombies and an additional one to locate the controlling
    server.  DDoS attacks do not necessarily spoof the source of an
    attack since there are a large number of source addresses, which
    make it difficult to trace anyway.  DDoS attacks can also originate
    from a single system or a subset of systems that spoof the source
    address in packet headers in order to mask the identity of the
    attack source.  In this case, an iterative trace through the
    upstream networks in the path of the attack traffic may be
    required.

    RID traces may also be used to locate a system used in an attack
    to compromise another system.  Compromising a system can be
    accomplished through one of many attack vectors, using various
    techniques from a remote host or through local privilege
    escalation attempts.  The attack may exploit a system or
    application level vulnerability that may be the result of a design
    flaw or a configuration issue.  A compromised system, as described
    above, can be used to later attack other systems.  A single RID
    Investigation request may be used in this case since it is probable
    that the source address is valid.  Identifying the sources of
    system compromises may be difficult since an attacker may access
    the compromised system from various sources.  The attacker may also
    take measures to hide their tracks by deleting log files or by
    accessing the system through a series of compromised hosts.
    Iterative RID traces may be required for each of the compromised
    systems used to obscure the source of the attack.  If the source
    address is valid, an Investigation request may be used in lieu of a


Moriarty                Expires: January 6, 2011                [Page 7]
Internet-Draft                                              July 6, 2010


    full RID TraceRequest.

    Once an attack has been reported, CSIRTs may want to query other
    CSIRTs if they have detected an attack or simply report that one
    has taken place.  The Report message can be used to file a report
    without an action taken and an IncidentQuery can be used to ask if
    an attack has been seen by another CSIRT.

    System compromises may result from other security incident types
    such as worms, Trojans, or viruses.  It is often the case that an
    incident goes unreported even if valid source address information
    is available because it is difficult to take any action to mitigate
    or stop the attack.  Incident handling is a difficult task for an
    NP and even at some client locations due to network size and
    resource limitations.

2. RID Integration with Network Provider Technologies

    For the purpose of this document, a network provider (NP) shall be
    defined as a backbone infrastructure manager of a network.  The
    network provider's Computer Security Incident Response Team shall
    be referred to as the CSIRT.  The backbone may be that of an
    organization providing network (Internet or private) access to
    commercial, personal, government, or educational institutions, or
    the backbone provider of the connected network.  The connected
    network provider is an extension meant to include Intranet and
    Extranet providers as well as instances such as a business or
    educational institute's private network.

    NPs typically manage and monitor their networks through a
    centralized network management system (NMS).  The acronym NMS will
    be used to generically represent management systems on a network
    used for the management of network resources.  An Incident Handling
    System (IHS) is used to communicate RID messages and may be
    integrated with an NMS as well as other components of the network.
    The components of the network that may be integrated through the
    RID messaging system include attack or event detection, network
    tracing, and network devices to stop the effects of an attack.

    The detection of security incidents may rely on manual reporting,
    automated intrusion detection tools, and variations in traffic
    types or levels on a network.  Intrusion detection systems (IDS)
    may be integrated into the IHS to create IODEF documents or RID
    messages to facilitate security incident handling. Detection of a
    security incident is outside the scope of this paper; however, it
    should be possible to integrate detection methods with RID
    messaging.

    RID messaging in an IHS is intended to be flexible in order to
    accommodate various traceback systems currently in use as well as
    those that may evolve with technology.  RID is intended to
    communicate the necessary information needed by a trace mechanism


Moriarty                Expires: January 6, 2011                [Page 8]
Internet-Draft                                              July 6, 2010


    to the next upstream NP in the path of a trace.  Therefore, a RID
    message must carry the superset of data required for all tracing
    systems.  If possible, the trace may need to inspect packets to
    determine a pattern, which could assist reverse path
    identification.  This may be accomplished by inspecting packet
    header information such as the source and destination IP addresses,
    ports, and protocol flags to determine if there is a way to
    distinguish the packets being traced from other packets.  A
    description of the incident along with any available automated
    trace data should trigger an alert to the NP's CSIRT for
    further investigation.  The various technologies used to trace
    traffic across a network are described in Section 3.1.

    Another area of integration is the ability to mitigate or stop
    attack traffic once a source has been located.  Any automated
    solution should consider the possible side effects to the network.
    A change control process or a central point for configuration
    management might be used to ensure that the security of the network
    and necessary functionality are maintained and that equipment
    configuration changes are documented.  Automated solutions may
    depend upon the capabilities and current configuration management
    solutions on a particular network.  The solutions may be based on
    HTTPS or an appropriate protocol defined in the transport
    specification.

3. Characteristics of Attacks

    The goal of tracing a security incident may be to identify the
    source or to find a point on the network as close to the origin of
    the incident as possible.  A security incident may be defined as a
    system compromise, a worm or Trojan infection, or a single- or
    multiple-source denial-of-service attack.  Incident tracing can be
    used to identify the source(s) of an attack in order to halt or
    mitigate the undesired behavior.  The communication system,
    RID, described in this paper can be used to trace any type of
    security incident and allows for actions to be taken when the
    source of the attack or a point closer to the source is known or
    has been identified.  The purpose of tracing an attack would be to
    halt or mitigate the effects of the attack through methods such as
    filtering or rate-limiting the traffic close to the source or
    by using methods such as taking the host or network offline.
    Care must also be taken to ensure the system is not abused and to
    use proper analysis in determining if attack traffic is, in fact,
    attack traffic at each NP along the path of a trace. 

    Tracing security incidents can be a difficult task since attackers
    go to great lengths to obscure their identity.  In the case of a
    security incident, the true source might be identified through an
    existing established connection to the attacker's point of origin.
    However, the attacker may not connect to the compromised system for
    a long period of time after the initial compromise or may access
    the system through a series of compromised hosts spread across the


Moriarty                Expires: January 6, 2011                [Page 9]
Internet-Draft                                              July 6, 2010


    network.  Other methods of obscuring the source may include
    targeting the host with the same attack from multiple sources using
    both valid and spoofed source addresses.  This tactic can be used
    to compromise a machine and leave the difficult task of locating the
    true origin for the administrators. Security incidents, including
    DDoS attacks, can be difficult or nearly impossible to trace
    because of the nature of the attack.  Some of the difficulties in
    tracing attacks include the following:

      O the attack originates from multiple sources;

      O the attack may include various types of traffic meant to
        consume server resources, such as a SYN flood attack without a
        significant increase in bandwidth utilization;

      O the type of traffic could include valid destination services,
        which cannot be blocked since they are essential services to
        business, such as DNS servers at an NP or HTTP requests sent to
        an organization connected to the Internet;

      O the attack may utilize varying types of packets including TCP,
        UDP, ICMP, or other IP protocols;

      O the attack may be from 'zombies', which then require additional
        searches to locate a controlling server as the true origin of
        the attack;

      O the attack may use a very small number of packets from any
        particular source, thus making a trace after the fact nearly
        impossible.

    If the source(s) of the attack cannot be determined from IP address
    information or tracing the increased bandwidth utilization, it may
    be possible to trace the traffic based on the type of packets seen
    by the client.  In the case of packets with spoofed source
    addresses, it is no longer a trivial task to identify the source of
    an attack.  In the case of an attack using valid source addresses,
    methods such as the traceroute utility can be used to fairly
    accurately identify the path of the traffic between the source and
    destination of an attack.  If the true source has been identified,
    actions should be taken to halt or mitigate the effects of the
    attack by reporting the incident to the NP or the upstream NP
    closest to the source.  In the case of a spoofed source address,
    other methods can be used to trace back to the source of an attack.
    The methods include packet filtering, packet hash comparisons, IP
    marking techniques, ICMP traceback, and packet flow analysis.  As
    in the case of attack detection, tracing traffic across a single
    network is a function that can be used with RID in order to provide
    the networked ability to trace spoofed traffic to the source, while
    RID provides all the necessary information to accommodate the
    approach used on any single network to accomplish this task.  RID
    can also be used to report attack traffic close to the source where


Moriarty                Expires: January 6, 2011               [Page 10]
Internet-Draft                                              July 6, 2010


    the IP address used was determined to be valid or simply to report
    that an incident occurred.

3.1 Integrating Trace Approaches

    There have been many separate research initiatives to solve the
    problem of tracing upstream packets to detect the true source of
    attack traffic.  Upstream packet tracing is currently confined to
    the borders of a network or an NP's network.  Traces require access
    to network equipment and resources, thus potentially limiting a
    trace to a specific network.  Once a trace reaches the boundaries
    of a network, the network manager or NP adjacent in the upstream
    trace must be contacted in order to continue the trace.  NPs have
    been working on individual solutions to accomplish upstream tracing
    within their own network environments.  The tracing mechanisms
    implemented thus far have included proprietary or custom solutions
    requiring specific information such as IP packet header data, hash
    values of the attack packets, or marked packets.  Hash values are
    used to compare a packet against a database of packets that have
    passed through the network in the case of "Hash Based IP 
    Traceback" [7].  Other research solutions involve marking packets
    as explained in "ICMP Traceback Messages" [8], "Practical Support
    for IP Traceback" [10], the IP Flow Information eXport (IPFIX)
    protocol [RFC3917], and IP Marking [6]. The single network
    traceback solutions were considered in developing RID to
    determine the information needed to accomplish an inter-network
    trace where different solutions may be in place.

3.2 Superset of Packet Information for Traces

    In order for network traffic to be traced across a network, an
    example packet from the attack must be sent along with the
    TraceRequest or Investigation request.  According to the research
    for Hash-based IP Traceback, all of the non-changing fields of an
    IP header along with 8 bytes of payload are required to provide
    enough information to uniquely trace the path of a packet.  The
    non-changing fields of the packet header and the 8 bytes of payload
    are the superset of data required by most single-network tracing 
    systems used; limiting the shared data to the superset of the
    packet header and 8 bytes of payload prevents the need for sharing
    potentially sensitive information that may be contained in the
    data portion of a packet.  

    The RecordItem class in the IODEF is used to store a
    hexadecimal formatted packet including all packet header
    information plus 8 bytes of payload or the entire packet contents.
    The above trace systems do not require a full packet, but it may be
    useful in some cases, so the option is given to allow a full packet
    to be included in the data model.

    If a subset of a packet is used, the research presented in "Hash-
    based IP Traceback", [7] provide guidlelines to establish a minimum


Moriarty                Expires: January 6, 2011               [Page 11]
Internet-Draft                                              July 6, 2010


    requirement for distinguishing packets.  The full packet and content
    SHOULD be provided, but the minimum requirement MUST be provided.
    The reserach from [7] found that the first 28 invariant bytes of a
    packet (masked IP header plus the first bytes of the payload) are
    sufficient to differentiate almost all non-identical IPv4 packets.
    RID requires the first 28 invariant bytes of an IP v4 packet in
    order to perform a trace.  RID requires the first 48 invariant
    bytes for an IP v6 packet in order to distinguish the packet in a
    trace.  Refernece [7] for additional details.

    The input mechanism for packets to be traced should be flexible
    to allow intrusion detection systems or packet sniffers to provide
    the information.  The system creating the RID message should also
    use the packet information to populate the Incident class
    information in order to avoid human error and also allow a system
    administrator to override the automatically populated information.

4. Communication Between Network Providers

    Note: The introduction and sub-sections 4.1 and 4.2 are
    informative, with the exception of references to IODEF/RID
    Transport, [RFCYYYY].  Sub-sections 4.3, 4.4, 4.5 are normative.

    Expediting the communication between CSIRTs is essential when
    responding to a security-related incident, which may cross network
    access points (Internet backbones) between providers.  As a result
    of the urgency involved in this inter-NP security incident
    communication, there must be an effective system in place to
    facilitate the interaction.  This communication policy or system
    should involve multiple means of communication to avoid a single
    point of failure.  Email is one way to transfer information about
    the incident, packet traces, etc.  However, e-mail may not be
    received in a timely fashion or be acted upon with the same urgency
    as a phone call or other communication mechanism.

    Each NP should dedicate a phone number to reach a member of their
    respective CSIRT. The phone number could be dedicated to inter-NP
    incident communications and must be a hotline that provides a 24x7
    live response.  The phone line should reach someone who would have
    the authority, expertise, and the means to expedite the necessary
    action to investigate the incident.  This may be a difficult policy
    to establish at smaller NPs due to resource limitations, so another
    solution may be necessary.  An outside group may be able to serve
    this function if given the necessary access to the NPs network.
    The outside resource should be able to mitigate or alleviate the
    financial limitations and any lack of experienced resource
    personnel.

    A technical solution to trace traffic across a single NP may
    include homegrown or commercial systems for which RID messaging
    must accommodate the input requirements.  The IHS used on the NP's
    backbone by the CSIRT to coordinate the trace across the single


Moriarty                Expires: January 6, 2011               [Page 12]
Internet-Draft                                              July 6, 2010


    network requires a method to accept and process RID messages and
    relay trace requests to the system, as well as to wait for
    responses from the system to continue the RID request process as
    appropriate.  In this scenario, each NP would maintain its own
    RID/IHS and integrate with a management station used for network
    monitoring and analysis. An alternative for NPs lacking sufficient
    resources may be to have a neutral third party with access to the
    NP's network resources who could be used to perform the incident
    handling functions.  This could be a function of a central
    organization operating as a CSIRT for the Internet as a whole
    or within a consortium that may be able to provide centralized
    resources.  Consortiums would consist of a group of NPs and/or
    CSIRTs that agree to participate in the RID communication protocol
    with an agreed-upon policy and communication protocol facilitating
    the secure transport of IODEF/RID XML documents.  Transport for RID
    messages is specified in the IODEF/RID Transport [RFCYYYY]
    document.

    One goal of RID is to prevent the need to permit access to other
    network's equipment through the use of a standard messaging
    mechanism to enable IHSs to communicate incident handling
    information to other networks in a consortium or in neighboring
    networks.  The third party mentioned above may be used in this
    technical solution to assist in facilitating incident handling
    and possibly traceback through smaller NPs.  The RID messaging
    mechanism may be a logical or physical out-of-band network to
    ensure the communication is secure and unaffected by the state of
    the network under attack.  The two management methods would
    accommodate the needs of larger NPs to maintain full management
    of their network, and the third party option could be available to
    smaller NPs who lack the necessary human resources to perform
    incident handling operations.  The first method enables the
    individual NPs to involve their network operations staff to
    authorize the continuance of a trace or other necessary response to
    a RID communication request through their network via a
    notification and alerting system.  The out-of-band logical solution
    for messaging may be permanent virtual circuits configured with a
    small amount of bandwidth dedicated to RID communications between
    NPs.

    The network used for the communication should consist of
    out-of-band or protected channels (direct communication links) or
    encrypted channels dedicated to the transport of RID messages. The
    communication links would be direct connections between network
    peers who have agreed upon use and abuse policies through the use
    of a consortium.  Consortiums might be linked through policy
    comparisons and additional agreements to form a larger web or
    iterative network of peers that correlates to the traffic paths
    available over the larger web of networks.  The maintenance of the
    individual links is the responsibility of the two network
    peers hosting the link.  Contact information, IP addresses of RID
    systems and other information must be coordinated between bilateral


Moriarty                Expires: January 6, 2011               [Page 13]
Internet-Draft                                              July 6, 2010


    peers by a consortium and may use existing databases, such as the
    Routing Arbiter. The security, configuration, and confidence rating
    schemes of the RID messaging peers must be negotiated by peers and
    must meet certain overall requirements of the fully connected
    network (Internet, government, education, etc.) through the peering
    and/or a consortium-based agreement.

    RID messaging established with clients of an NP may be negotiated
    in a contract as part of a value-added service or through a service
    level agreement.  Further discussion is beyond the scope of this
    document and may be more appropriately handled in network peering
    or service level agreements.

    Procedures for incident handling need to be established and well
    known by anyone that may be involved in incident response.  The
    procedures should also contain contact information for internal
    escalation procedures, as well as for external assistance groups 
    such as a CSIRT, CCCERT, GIAC, and the FBI or other assisiting
    government organization in the country of the investigation.

4.1 Inter-Network Provider RID Messaging

    In order to implement a messaging mechanism between RID
    communication or IHS systems, a standard protocol and format is
    required to ensure inter-operability between vendors.  The messages
    would have to meet several requirements in order to be meaningful
    as they traverse multiple networks.  RID provides the framework
    necessary for communication between networks involved in the
    incident handling, possible traceback, and mitigation of a security
    incident.  Several message types described in Section 4.3 are
    necessary to facilitate the handling of a security incident.  The
    message types include the Report, IncidentQuery, TraceRequest,
    RequestAuthorization, Result, and the Investigation request message.
    The Report message is used when an incident is to be filed on a
    RID system or associated database, where no further action is
    required.  An IncidentQuery message is used to request information
    on a particular incident.  A TraceRequest message is used when the
    source of the traffic may have been spoofed.  In that case, each
    network provider in the upstream path who receives a trace request
    will issue a trace across


		

		

		

		    

		        
		    

		


		

	        
		

		    

		        
		        

		            gipoco.com
		            is neither affiliated with the authors of this page nor responsible
		            for its contents. This is a safe-cache copy of the original web site.