RFC 3067

TERENA'S Incident Object Description and Exchange Format Requirements

📅 published February 2001, from ietf

Okay bestie, welcome to RFC 3067!! 🎀

Network Working Group: J. Arvidsson (Telia CERT), A. Cormack (JANET-CERT), Y. Demchenko (TERENA), J. Meijer (SURFnet) Category: Informational 🧚 Date: February 2001 Obsoletes / Updates: this doc doesn't list anything it obsoletes or updates 💅 Title: TERENA's Incident Object Description and Exchange Format Requirements 🦋

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🍓

okay so the whole point of the Incident Object Description and Exchange Format is to make ONE common data format that CSIRTs (Computer Security Incident Response Teams) can use to describe, archive, and swap info about incidents 🫶 (we're talking alerts, incidents being investigated, archiving, statistics, reporting, etc.). This doc lays out the high-level requirements for that format and explains why each one exists. Examples show up where they're needed so it's not just vibes 💖

1. Conventions used in this document 📚

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 RFC 2119 [1]. 🔥

2. Introduction 🌈

this doc defines the requirements for the Incident object Description and Exchange Format (IODEF), which is the intended product of the Incident Taxonomy Working Group (ITDWG) at TERENA [2] 👑 IODEF is planned to be a standard format that lets CSIRTs swap operational and statistical info. It might also be the foundation for compatible, inter-operable tools for Incident recording, tracking and exchange ✨

another goal is to extend the work of the IETF IDWG (which is currently focused on an Intrusion Detection exchange format and communication protocol) up to describing incidents as higher level elements in Network Security. This will involve CSIRTs and their constituency related issues 🙈

the IODEF set of documents (this one is the first!) will include the IODEF Data Model and an XML DTD specification. More discussion of this doc happens on the ITDWG mailing lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>. The archives are available correspondently at http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and http://hypermail.terena.nl/iodef-list/mail-archive/ 💅

2.1. Rationale 🦋

this work comes from trying to set up cooperation and info exchange between the leading/advanced CSIRTs in Europe and across the FIRST community. These CSIRTs get it: sharing info is the way to process, track, and investigate security incidents together 🫶

Computer Incidents are getting distributed and International, and they involve lots of CSIRTs across borders, languages and cultures 🌍 Post-Incident info and statistics exchange matters a LOT for preventing future Incidents and improving Internet security. The key piece that makes all of this exchange work is a common format for Incident (Object) description 💖

it's probable that IODEF could end up being used for forensic purposes down the line, which means Incident description must be unambiguous and allow for future custody (archiving/documentation) features. no room for confusion here, bestie 🧐

another thing IODEF is aiming for is a higher level Incident description and exchange format than what IDS (Intrusion Detection Systems) and the proposed IDEF (Intrusion Detection Exchange Format) provide. Compatibility with IDEF and other related standards will come from the IODEF requirement on modularity and extensibility ✨ IODEF should vertically be compatible with IDMEF, and IODEF might be able to include or reference an IDMEF Alert message as initial info about an Incident 🎀

2.2. Incident Description Terms 🧚

this section gives definitions for the main terms used in the rest of the doc, so everyone's on the same page 📖

where possible, existing definitions get reused. Some definitions will need extra detail and more thought 🤓

the Taxonomy of the Computer Security Incident related terminology made by TERENA's ITDWG [2] is presented in [12] 👑

2.2.1. Attack ⚔️

an assault on system security that comes from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system 🙅‍♀️

an Attack can be active or passive, by insider or by outsider, or via attack mediator 🌸

2.2.2. Attacker 🦹‍♀️

an Attacker is an individual who attempts one or more attacks in order to achieve an objective(s) 💜

for the purpose of IODEF, an Attacker is described by its network ID, the organisation the network/computer attack was originated from, and physical location information (optional) 🍓

2.2.3. CSIRT 🛡️

CSIRT (Computer Security Incident Response Team) is used in IODEF to refer to the authority handling the Incident and creating the Incident Object Description. The CSIRT is also likely to be involved in evidence collection and custody, incident remedy, etc. 🫶

in IODEF, a CSIRT is represented by its ID, constituency, public key, etc. 🔐

2.2.4. Damage 💥

an intended or unintended consequence of an attack that affects the normal operation of the targeted system or service. Description of Damage may include free text description of the actual result of the attack and, where possible, structured info about the particular damaged system, subsystem or service 😭

2.2.5. Event 🎯

an action directed at a target that is intended to result in a change of state (status) of the target. From the point of view of event origination, an Event can be defined as any observable occurrence in a system or network which resulted in an alert being generated. For example, three failed logins in 10 seconds might indicate a brute-force login attack 👀

2.2.6. Evidence 🔍

Evidence is info relating to an event that proves or supports a conclusion about the event. With respect to security incidents (the events), it may include but is not limited to: a data dump created by an Intrusion Detection System (IDS), data from a syslog file, kernel statistics, cache, memory, temporary file system, or other data that caused the alert or was collected after the incident happened 🧾

special rules and care must be taken when storing and archiving evidence, particularly to preserve its integrity. When necessary, evidence should be stored encrypted 🔒

according to the Guidelines for Evidence Collection and Archiving (Evidence), evidence must be strictly secured. The chain of evidence custody needs to be clearly documented 📋

it is essential that evidence should be collected, archived and preserved according to local legislation ⚖️

2.2.7. Incident 🚨

an Incident is a security event that involves a security violation. An Incident can be defined as a single attack or a group of attacks that can be distinguished from other attacks by the method of attack, identity of attackers, victims, sites, objectives or timing, etc. 🧩

an Incident is a root element of the IODEF. In the context of IODEF, the term Incident is used to mean a Computer Security Incident or an IT Security Incident 👑

however, we should distinguish between the generic definition of 'Incident' (an event that might lead to damage, or damage that isn't too serious) and 'Security Incident' and 'IT Security Incident', which are defined below 👇

  • a) Security incident is an event that involves a security violation. This may be an event that violates a security policy, UAP, laws and jurisdictions, etc. A security incident may also be an incident that has been escalated to a security incident.

A security incident is worse than an incident as it affects the security of or in the organisation. A security incident may be logical, physical or organisational, for example a computer intrusion, loss of secrecy, information theft, fire, or an alarm that doesn't work properly. A security incident may be caused on purpose or by accident. The latter may be if somebody forgets to lock a door or forgets to activate an access list in a router 🙈

  • b) An IT security incident is defined according to [9] as any real or suspected adverse event in relation to the security of a computer or computer network. Typical security incidents within the IT area are: a computer intrusion, a denial-of-service attack, information theft or data manipulation, etc. 💻

2.2.8. Impact 💸

Impact describes the result of an attack expressed in terms of user community, for example the cost in terms of financial or other disruption 📉

2.2.9. Target 🎯

a computer or network logical entity (account, process or data) or physical entity (component, computer, network or internetwork) 🖥️

2.2.10. Victim 🥺

a Victim is an individual or organisation which suffered the attack described in the incident report 💔

for the purpose of IODEF, a Victim is described by its network ID, organisation and location information 📍

2.2.11. Vulnerability 🕳️

a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy 🙃

most systems have vulnerabilities of some sort, but this does not mean that the systems are too flawed to use. Not every threat results in an attack, and not every attack succeeds. Success depends on the degree of vulnerability, the strength of attacks, and the effectiveness of any countermeasures in use. If the attacks needed to exploit a vulnerability are very difficult to carry out, then the vulnerability may be tolerable. If the perceived benefit to an attacker is small, then even an easily exploited vulnerability may be tolerable. However, if the attacks are well understood and easily made, and if the vulnerable system is employed by a wide range of users, then it is likely that there will be enough benefit for someone to make an attack 😬

2.2.12. Other terms 🧠

other terms used here, like alert, activity, IDS, Security Policy, etc., are defined in related I-Ds, RFCs and standards [3, 6, 7, 8, 9, 10] 📚

3. General Requirements 💅

3.1. The IODEF shall reference and use previously published RFCs where possible. 🫶

Comment:

the IETF has already developed a bunch of standards in the areas of networks and security that are actually deployed in the present Internet. Current standards provide a framework for compatibility of IODEF with other related technologies, which is necessary to operate/implement IODEF in practice. Another compatibility issue for IODEF is its general compatibility with IDEF, which is currently being developed by the IETF IDEWG. In the interest of time and compatibility, defined and accepted standards should be used wherever possible ⏰

In particularly, IODEF specification proposals SHOULD rely heavily on existing communications, encryption and language standards, where possible 🔐

4. Description Format 🌟

4.1. IODEF shall support full internationalization and localization. 🌍✨

Comment: Some Incidents need CSIRTs from different countries, cultures and geographic regions to team up, so the IODEF description must be formatted so it can be shown to an operator in a local language and with local presentation formats 💅. The metalanguage for IODEF identifiers and labels is considered to be English, but a local IODEF implementation might translate those identifiers and labels into the local language and presentation if necessary 🗣️. Localized presentation of dates, time and names may also be required 📅. When messages contain text strings and names that need characters other than Latin-1 (or ISO 8859-1), the information preferably should be represented using the ISO/IEC IS 10646-1 character set and encoded using the UTF-8 transformation format, and optionally using local character sets and encodings [13] 🫶.

4.2. The IODEF must support modularity in Incident description to allow aggregation and filtering of data. 🧩

Comment: It's suggested that an Incident description written in IODEF might include external information, for example from IDS, or reference externally stored evidence custody data. Or that information might be removed from the current IODEF description, for example for privacy or security reasons 🔐. Another real-life reason for this is to let some CSIRTs and managers filter and/or aggregate data in IODEF descriptions for statistics, reporting and high-level Incident information exchange between CSIRTs and/or their constituency and sponsors 📊.

So the IODEF descriptions MUST be structured to facilitate these operations. This also implies strong IODEF semantics 🎀.

4.3. IODEF must support the application of an access restriction policy attribute to every element. 🔒

Comment: IODEF Incident descriptions can contain sensitive or private information, like passwords, person and organisation identifiers, or forensic information (evidence data) 🙈. In some cases they may be exposed to unauthorised people, and this can happen a lot when CSIRTs or other involved bodies exchange Incident information 📨. Some cases can be handled by encrypting IODEF elements, but that won't always be possible 😮‍💨.

So, to prevent accidental disclosure of sensitive data, parts of the IODEF object must be marked with access restriction attributes 🚫. These markings will be especially useful when they're used with automated processing systems 🤖.

5. Communications Mechanisms Requirements 📡

5.1. IODEF exchange will normally be initiated by humans using standard communication protocols, for example, e-mail, WWW/HTTP, LDAP. 🙋‍♀️

Comment: An IODEF description is normally created by a human using a special or standard text editor ✍️. The IODEF is meant to be processed by automated Incident handling systems, but it still must be human readable, so it can be viewed and browsed with standard tools like browsers, spreadsheet programs or database tools such as MS Excel or Access 💻. Incident information exchange will normally require authorisation by an operator or CSIRT manager, so it isn't expected to be started automatically 🛑. The job of an Incident handling system is to provide help and tools for doing the exchange 🧰.

It's important to tell apart the purposes of the machine-readable, exchangeable IDEF Intrusion message format and the human-oriented, human-created IODEF Incident description 👯‍♀️.

Communications security requirements will be applied separately according to local policy, so this document doesn't define them 🔐.

6. Message Contents 💌

6.1. The root element of the IO description should contain a unique identification number (or identifier), IO purpose and default permission level 🆔

Comment: A unique identification number (or identifier) is necessary to tell one Incident apart from another 👀. It's suggested that the unique identification number contains at least information about the IO creator, meaning the CSIRT or related body 🏢. The classification of the Incident may also be used to form a unique identification number 🏷️. The IO purpose controls which elements are included in the IODEF object 🎯. Purposes may include incident alert/registration, handling, archiving, reporting or statistics 📚. The purpose, incident type or status of Incident investigation may require different levels of access permission for the Incident information 🔑.

It's considered that the root element of the IODEF will be <INCIDENT>, and additional information will be treated as attributes of the root element 🌸.

6.2. The content of the IODEF description should contain the type of the attack if it is known. 🗡️

It's expected that this type will be drawn from a standardized list of events. A new type of event may use a temporary implementation-specific type if the event type has not yet been standardized 🧪.

Comment: Incident handling can involve lots of different staff members and teams, so it's essential that common terms are used to describe incidents 🗣️💕.

If the event type hasn't been standardized yet, a temporary type definition might be given by the team that created the IO 🛠️. It's expected that a new type name will be self-explanatory and derived from a similar, existing type definition 💡.

6.3. The IODEF description must be structured such that any relevant advisories, such as those from CERT/CC, CVE, can be referenced. 📣

Comment: Using standard advisories and lists of known Attacks and Vulnerabilities lets people use their recommendations for Incident handling and prevention 🛡️. This information might be included as an attribute of the attack or vulnerability type definition 🎀.

6.4. IODEF may include a detailed description of the attack that caused the current Incident. 🎬

Comment: A description of the attack includes information about the attacker and victim, what the attack looked like, and the possible impact 👾. In the early stage of Intrusion alert and Incident handling there's likely to be minimal information. During handling, this grows to be enough for Incident investigation and remedy 📈. The <ATTACK> element should be one of the main elements of an Incident description 👑.

Comment: For lots of purposes, an Incident description doesn't need many details about the specific event(s)/activity that caused the Incident 🙆‍♀️. This information may be referenced as external information, by means of a URL 🔗. In some cases it might be convenient to store evidence separately when it has different access permissions 🗂️. It's foreseen that another standard will be proposed for evidence custody [5] 🔮.

6.6. The IODEF description MUST contain the description of the attacker and victim. 😈🎯

Comment: This information is necessary to identify the source and target of the attack 🎯. The minimum information about the attacker and victim is their IP or Internet addresses. Extended information will identify their organisations, which lets CSIRTs take appropriate measures for their particular constituency 🏳️‍🌈.

6.7. The IODEF description must support the representation of different types of device addresses, e.g., IP address (version 4 or 6) and Internet name. 🌐

Comment: The sites an attack is launched from might have addresses at different levels of the network protocol hierarchy, like Data layer 2 MAC addresses or Network layer 3 IP addresses 🧠. The devices involved in an intrusion event might also use addresses that aren't IP-centric, like ATM-addresses 🏧. It's also understood that information about the source and target of the attack might be obtained from IDS and include the IP address, the MAC address, or both 🦋.

6.8. IODEF must include the Identity of the creator of the Incident Object (CSIRT or other authority). This may be the sender in an information exchange or the team currently handling the incident. 🪪

Comment: The identity of the Incident description creator is often valuable information for Incident response 💖. In one possible scenario, the attack may progress through the network. Comparing corresponding incidents reported by different authorities might give some extra information about where the attack came from 🕵️‍♀️. This is also useful information at the post-incident information handling/exchange stage 📝.

6.9. The IODEF description must contain an indication of the possible impact of this event on the target. The value of this field should be drawn from a standardized list of values if the attack is recognized as known, or expressed in a free language by responsible CSIRT team member. 💥

Comment: Information about the possible impact of the event on the target system shows what the attacker is trying to do, and it's critical data for CSIRTs to take action and assess the damage 🧐. If no reference information (advisories) is available, this field may be filled in based on CSIRT team experience 🙌.

It's expected that most CSIRTs will build Incident handling support systems based on existing advisories (such as those from CERT/CC, CVE, etc.). These usually contain lists of possible impacts for identified attacks 📋.

This also relates to the development of IDEF, which will be implemented in intelligent IDS that can retrieve information from standard databases of attacks and vulnerabilities [3] 🧠✨.

6.10. The IODEF must be able to state the degree of confidence in the report information. 🎲

Comment: This is essential at the stage of Incident creation, especially when intelligent automatic IDS or expert systems are used 🤖. These normally use statistical engines to estimate the probability of an event 📉.

6.11. The IODEF description must provide information about the actions taken in the course of this incident by previous CSIRTs. 🏃‍♀️💨

Comment: The IODEF describes an Incident throughout its entire life, from Alert to closing and archiving 🗓️. It's essential to track all actions taken by all involved parties 👣. This helps determine what further action needs to be taken, if any 🔎. It's especially important when CSIRTs exchange Incident information while they're still investigating 🤝.

6.12. The IODEF must support reporting of the time of all stages along Incident life-time. ⏰

Comment: Time matters for both reporting and correlation 📊. It's one of the main components that can identify the same Incident or attack, especially if it's launched from many sites or spread across the network 🌍. Time is also essential for tracking the life of an Incident, including Incident exchange between CSIRTs while they're investigating 🕰️.

6.13. Time shall be reported as the local time and time zone offset from UTC. (Note: See RFC 1902 for guidelines on reporting time.) 🕒🌏

Comment: For event correlation purposes, it's important that the manager can normalize the time information reported in the IODEF descriptions 💅✨.

6.14. The format for reporting the date must be compliant with all current standards for Year 2000 rollover, and it must have sufficient capability to continue reporting date values past the year 2038.

okay so the date format has to be totally Y2K-proof, and it has to keep working past 2038 🕰️✨ no cap, this is giving long-term planning energy.

Comment:

okay bestie, the IODEF is supposed to describe an Incident for its whole life-time 💅 and with archiving, that could be forever 😭. So any implementation that limits how time values can be written (like the 2038 date problem in "Unix time") MUST be avoided. We're not doing that again 🙅‍♀️💀

6.15. Time granularity in IO time parameters shall not be specified by the IODEF.

the IODEF is not gonna tell you how precise your timestamps have to be 🧚 that's on you and your system 💖

Comment:

ngl the time data can come from so many places 🌸 existing info systems, incident reports, IDS data, or other event tools, and each one might have its own granularity (like, one is super precise and another is kinda vague). So for implementation, it should be possible to handle time at different stages based on what the local system can actually do 🫶

6.16. The IODEF should support confidentiality of the description content.

the design you pick should be able to support a bunch of encryption algorithms, and it has to adapt to a wide variety of environments 🔐✨

Comment:

IODEF Incident descriptions can hold super sensitive stuff 👀 like forensic data (evidence data), passwords, or info about people and organisations, and an attacker would be obsessed with getting their hands on that 😈 Incident info usually lives on a networked computer, which could be exposed to attacks or get compromised 😭 and it can travel over uncontrolled network segments too. So the content has to be protected from unauthorised access and modification 🛡️

Also, the legal rules for privacy and encryption are different in every region and country, and they keep changing 🌍 so it's really important that the design can support different encryption options, and that the user can adapt it to their own environment 💅 Extra protection during communication is possible too, but that's outside the IODEF's scope, since it would mean stricter rules for IO archiving and storing in general 🙈

6.17. The IODEF should ensure the integrity of the description content.

same energy here 🫶 the design should support a variety of integrity mechanisms and adapt to a wide variety of environments 🔥

Comment:

special measures should be taken to stop malicious IO changes 🚫 like, nobody gets to edit the evidence and get away with it 😤

Extra measures for securing the Incident during communication are possible too, but that's outside the IODEF's scope 🦋

6.18. The IODEF should ensure the authenticity and non-repudiation of the message content.

Comment:

okay so authenticity and accountability matter to SO many teams 👑 especially since everyone wants to handle IOs automatically now 🤖 That's why it MUST be included in the IODEF 💜 And because this matters a lot to teams talking to each other, implementing these requirements is strongly RECOMMENDED 🫶✨

6.19. The IODEF description must support an extension mechanism which may be used by implementers. This allows future implementation-specific or experimental data. The implementer MUST indicate how to interpret any included extensions.

the IODEF needs a way to add extensions 🧩 for future stuff, implementation-specific stuff, or experimental data 🧪 and whoever adds an extension MUST say how to read it 📝

Comment:

implementers might want to add extra data 🎀 like internal stuff, or stuff their Incident handling system needs to run properly 🛠️ That data might get removed or kept in external communications, that's up to them, but it's essential to mark it as additional so other systems don't misread it 🙅‍♀️

6.20. The semantics of the IODEF description must be well defined.

Comment:

the IODEF is a human-oriented format for Incident description 🧠 so the description should be readable by humans 📖 Automatic parsing tools are expected but shouldn't be critically necessary 🤖 So IODEF must provide good semantics, because those are the key to understanding what the description actually contains ✨ Sometimes the description will be used for automatic decision making, so it's super important that it gets interpreted correctly 💯 That's an argument for using language-based semantics 🗣️

The metalanguage for IODEF identifiers and labels is proposed to be English 🇬🇧 but a local IODEF implementation might translate identifiers and labels into the local language and presentations when needed 🌈

7. IODEF extensibility ✨

7.1. The IODEF itself MUST be extensible.

this is non-negotiable 👑 when new technologies and automated Incident handling systems need the IODEF to grow, it has to be able to include new information 🌱

Comment:

besides needing to extend the IODEF for new Incident handling tools, it's also suggested that the IODEF incorporate new developments from related standardisation areas 🧠 like IDEF for IDS, or a special format for evidence custody 🔍 The procedure for extension should be based on CSIRT/IODEF community acceptance and approval 🫶

8. Security Considerations 💀🔐

This memo describes requirements to an Incident Object Description and Exchange Format 📄 which aims to define a common data format for describing, archiving, and exchanging information about incidents between CSIRTs (including alert, incident in investigation, archiving, statistics, reporting, etc.) 🗂️ So implementing the IODEF is subject to security considerations, and they're kind of a big deal 😤 Particular security requirements for access restriction indication are discussed in section 4.3 🔒 and the requirements for Incident description confidentiality, integrity, authenticity and non-repudiation are described in sections 6.16, 6.17, 6.18 🛡️✨

9. References 📚

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Incident Taxonomy and Description Working Group Charter - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/
  • [3] Intrusion Detection Exchange Format Requirements by Wood, M. - December 2000, Work in Progress.
  • [4] Intrusion Detection Message Exchange Format Extensible Markup Language (XML) Document Type Definition by D. Curry, H. Debar - February 2001, Work in Progress.
  • [5] Guidelines for Evidence Collection and Archiving by Dominique Brezinski, Tom Killalea - July 2000, Work in Progress.
  • [6] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998.
  • [7] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
  • [8] Establishing a Computer Security Incident Response Capability (CSIRC). NIST Special Publication 800-3, November, 1991
  • [9] Handbook for Computer Security Incident Response Teams (CSIRTs), Moira J. West-Brown, Don Stikvoort, Klaus-Peter Kossakowski. - CMU/SEI-98-HB-001. - Pittsburgh, PA: Carnegie Mellon University, 1998.
  • [10] A Common Language for Computer Security Incidents by John D. Howard and Thomas A. Longstaff. - Sandia Report: SAND98-8667, Sandia National Laboratories - http://www.cert.org/research/taxonomy_988667.pdf
  • [11] Best Current Practice of incident classification and reporting schemes currently used by active CSIRTs. - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/BCPreport1.rtf
  • [12] Taxonomy of the Computer Security Incident related terminology - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/i-taxonomy_terms.html
  • [13] Multilingual Support in Internet/IT Applications. - http://www.terena.nl/projects/multiling/

Acknowledgements 🫶

This document was discussed at the Incident Taxonomy and Description Working Group seminars (http://www.terena.nl/task-forces/tf-csirt/tf-csirt000929prg.html#itdwg) in the frame of TERENA Task Force TF-CSIRT (http://www.terena.nl/task-forces/tf-csirt/). Incident Taxonomy and Description Working Group at TERENA can be contacted via the mailing lists <incident-taxonomy@terena.nl> or <iodef@terena.nl>, and archives are available correspondently at http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and http://hypermail.terena.nl/iodef-list/mail-archive/ 💖

Authors' Addresses 🧚

Jimmy Arvidsson Telia CERT EMail: Jimmy.J.Arvidsson@telia.se

Andrew Cormack JANET-CERT EMail: Andrew.Cormack@ukerna.ac.uk

Yuri Demchenko TERENA EMail: demch@terena.nl

Jan Meijer SURFnet EMail: jan.meijer@surfnet.nl

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 💅

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from