draft-ietf-mile-implementreport-07.txt   draft-ietf-mile-implementreport-08.txt 
MILE C. Inacio MILE C. Inacio
Internet-Draft CMU Internet-Draft CMU
Intended status: Informational D. Miyamoto Intended status: Informational D. Miyamoto
Expires: November 16, 2016 UTokyo Expires: December 1, 2016 UTokyo
May 15, 2016 May 30, 2016
MILE Implementation Report MILE Implementation Report
draft-ietf-mile-implementreport-07 draft-ietf-mile-implementreport-08
Abstract Abstract
This document is a collection of implementation reports from vendors, This document is a collection of implementation reports from vendors,
consortiums, and researchers who have implemented one or more of the consortiums, and researchers who have implemented one or more of the
standards published from the IETF INCident Handling (INCH) and standards published from the IETF INCident Handling (INCH) and
Management Incident Lightweight Exchange (MILE) working groups. Management Incident Lightweight Exchange (MILE) working groups.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2016. This Internet-Draft will expire on December 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Consortiums and Information Sharing and Analysis Centers 2. Consortiums and Information Sharing and Analysis Centers
(ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3
2.2. Advanced Cyber Defence Centre . . . . . . . . . . . . . . 3 2.2. Advanced Cyber Defence Centre . . . . . . . . . . . . . . 3
2.3. Research and Education Networking Information Sharing and 2.3. Research and Education Networking Information Sharing and
Analysis Center . . . . . . . . . . . . . . . . . . . . . 4 Analysis Center . . . . . . . . . . . . . . . . . . . . . 3
3. Open Source Implementations . . . . . . . . . . . . . . . . . 4 3. Open Source Implementations . . . . . . . . . . . . . . . . . 4
3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 4 3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 4
3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 4 3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 4
3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 5 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 5
4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 6 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 6
4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 7 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 7
4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 8 4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 8
5. Vendors with Planned Support . . . . . . . . . . . . . . . . 8 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 8
5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 8 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 8
5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 9 5.2. DAEDALUS, NICT . . . . . . . . . . . . . . . . . . . . . 8
6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 9
6.1. Collaborative Incident Management System . . . . . . . . 9 6.1. Collaborative Incident Management System . . . . . . . . 9
6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 10 6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 10
6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10 6.3. US Department of Energy CyberFed . . . . . . . . . . . . 10
7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11
7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 11 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 11
7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 48 skipping to change at page 2, line 48
11. Informative References . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document is a collection of implementation reports from vendors This document is a collection of implementation reports from vendors
and researchers who have implemented one or more of the standards and researchers who have implemented one or more of the standards
published from the INCH and MILE working groups. The standards published from the INCH and MILE working groups. The standards
include: include:
o Incident Object Description Exchange Format (IODEF) v1, RFC5070, o Incident Object Description Exchange Format (IODEF) v1, RFC5070
[RFC5070],
o Incident Object Description Exchange Format (IODEF) v2, o Incident Object Description Exchange Format (IODEF) v2,
RFC5070-bis, RFC5070-bis,
o Extensions to the IODEF-Document Class for Reporting Phishing, o Extensions to the IODEF-Document Class for Reporting Phishing,
RFC5901 RFC5901 [RFC5901],
o Sharing Transaction Fraud Data, RFC5941
o IODEF-extension for Structured Cybersecurity Information, RFCXXXX o Sharing Transaction Fraud Data, RFC5941 [RFC5941],
o Real-time Inter-network Defense (RID), RFC6545 o Real-time Inter-network Defense (RID), RFC6545 [RFC6545],
o Transport of Real-time Inter-network Defense (RID) Messages over o Transport of Real-time Inter-network Defense (RID) Messages over
HTTP/TLS, RFC6546. HTTP/TLS, RFC6546 [RFC6546],
o Incident Object Description Exchange Format (IODEF) Extension for o Incident Object Description Exchange Format (IODEF) Extension for
Structured Cybersecurity Information, RFC7203 Structured Cybersecurity Information, RFC7203 [RFC7203].
The implementation reports included in this document have been The implementation reports included in this document have been
provided by the team or product responsible for the implementations provided by the team or product responsible for the implementations
of the mentioned RFCs. Additional submissions are welcome and should of the mentioned RFCs. Additional submissions are welcome and should
be sent to the draft editor. A more complete list of be sent to the draft editor. A more complete list of
implementations, including open source efforts and vendor products, implementations, including open source efforts and vendor products,
can also be found at the following location: can also be found at the following location:
http://siis.realmv6.org/implementations/ http://siis.realmv6.org/implementations/
skipping to change at page 4, line 10 skipping to change at page 3, line 51
fight against botnets. ACDC provides a solutions to mitigate on- fight against botnets. ACDC provides a solutions to mitigate on-
going attacks, as well as consolidating information provided by going attacks, as well as consolidating information provided by
various stakeholders into a pool of knowledge. Within ACDC, IODEF is various stakeholders into a pool of knowledge. Within ACDC, IODEF is
one of the supported schema for exchanging the information. one of the supported schema for exchanging the information.
2.3. Research and Education Networking Information Sharing and Analysis 2.3. Research and Education Networking Information Sharing and Analysis
Center Center
Research and Education Networking Information Sharing and Analysis Research and Education Networking Information Sharing and Analysis
Center (REN-ISAC) is a private community of the research and higher Center (REN-ISAC) is a private community of the research and higher
education members fro sharing threat information, and employs IODEF education members for sharing threat information, and employs IODEF
formatted-message to exchange information. formatted-message to exchange information.
REN-ISAC also recommends to use of the IODEF attachment provided with REN-ISAC also recommends to use an IODEF attachment provided with a
the notification email be processed rather than relying on parsing of notification email for processing rather than relying on parsing of
the email body text. The interface provided by REN-ISAC are designed the email body text. The interface provided by REN-ISAC are designed
for dealing with such email. to handle such email.
http://www.ren-isac.net/notifications/using_iodef.html http://www.ren-isac.net/notifications/using_iodef.html
3. Open Source Implementations 3. Open Source Implementations
3.1. EMC/RSA RID Agent 3.1. EMC/RSA RID Agent
The EMC/RSA RID agent is an open source implementation of the The EMC/RSA RID agent is an open source implementation of the IETF
Internet Engineering Task Force (IETF) standards for the exchange of standards for the exchange of incident and indicator data. The code
incident and indicator data. The code has been released under an MIT has been released under an MIT license and development will continue
license and development will continue with the open source community with the open source community at the Github site for RSA
at the Github site for RSA Intelligence Sharing: Intelligence Sharing:
https://github.com/RSAIntelShare/RID-Server.git https://github.com/RSAIntelShare/RID-Server.git
The code implements the RFC6545, Real-time Inter-network Defense The code implements the RFC6545, Real-time Inter-network Defense
(RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
supports the evolving RFC5070-bis Incident Object Description supports the evolving RFC5070-bis Incident Object Description
Exchange Format (IODEF) data model from the work in the IETF working Exchange Format (IODEF) data model from the work in the IETF working
group Managed Incident Lightweight Exchange (MILE). group Managed Incident Lightweight Exchange (MILE).
3.2. NICT IODEF-SCI implementation 3.2. NICT IODEF-SCI implementation
skipping to change at page 6, line 11 skipping to change at page 5, line 52
o applications receiving badly constructed or malicious data which o applications receiving badly constructed or malicious data which
could exploit a vulnerability (known or unknown) could exploit a vulnerability (known or unknown)
Deep-Secure Guards support HTTPS and XMPP (optimised server to server Deep-Secure Guards support HTTPS and XMPP (optimised server to server
protocol) transports. The Deep-Secure Guards support transfer of XML protocol) transports. The Deep-Secure Guards support transfer of XML
based business content by creating a schema to translate the known based business content by creating a schema to translate the known
good content to and from the intermediate format. This means that good content to and from the intermediate format. This means that
the Deep-Secure Guards can be used to protect: the Deep-Secure Guards can be used to protect:
o IODEF/RID using the HTTPS transport binding (RFC 6546) o IODEF/RID using the HTTPS transport binding (RFC6546)
o IODEF/RID using an XMPP binding o IODEF/RID using an XMPP binding
o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02) o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02)
o STIX/TAXII using the HTTPS transport binding o STIX/TAXII using the HTTPS transport binding
Deep-Secure Guards also support the SMTP transport and perform deep Deep-Secure Guards also support the SMTP transport and perform deep
content inspection of content including XML attachments. The Mail content inspection of content including XML attachments. The Mail
Guard supports S/MIME and Deep Secure are working on support for the Guard supports S/MIME and Deep Secure are working on support for the
upcoming PLASMA standard which enables information centric policy upcoming PLASMA standard which enables information centric policy
enforcement of data. enforcement of data.
4.2. IncMan Suite, DFLabs 4.2. IncMan Suite, DFLabs
The Incident Object Description Exchange Format, documented in the The Incident Object Description Exchange Format, documented in the
RFC 5070, defines a data representation that provides a framework for RFC5070, defines a data representation that provides a framework for
sharing information commonly exchanged by Computer Security Incident sharing information commonly exchanged by Computer Security Incident
Response Teams (CSIRTs) about computer security incidents. IncMan Response Teams (CSIRTs) about computer security incidents. IncMan
Suite implements the IODEF standard for exchanging details about Suite implements the IODEF standard for exchanging details about
incidents, either for exporting and importing activities. This has incidents, either for exporting and importing activities. This has
been introduced to enhance the capabilities of the various CSIRT, to been introduced to enhance the capabilities of the various CSIRT, to
facilitate collaboration and sharing of useful experiences, conveying facilitate collaboration and sharing of useful experiences, conveying
awareness on specific cases. awareness on specific cases.
The IODEF implementation is specified as an XML schema, therefore all The IODEF implementation is specified as an XML schema, therefore all
data are stored in an xml file: in this file all data of an incident data are stored in an xml file: in this file all data of an incident
skipping to change at page 10, line 17 skipping to change at page 10, line 13
standard. standard.
6.2. Automated Incident Reporting - AirCERT 6.2. Automated Incident Reporting - AirCERT
AirCERT was implemented by CERT/CC of Carnegie Mellon's Software AirCERT was implemented by CERT/CC of Carnegie Mellon's Software
Engineering Institute CERT division. AirCERT was designed to be an Engineering Institute CERT division. AirCERT was designed to be an
Internet-scalable distributed system for sharing security event data. Internet-scalable distributed system for sharing security event data.
The AirCERT system was designed to be an automated collector of flow The AirCERT system was designed to be an automated collector of flow
and IDS alerts. AirCERT would collect that information into a and IDS alerts. AirCERT would collect that information into a
relational database and be able to share reporting using IODEF and relational database and be able to share reporting using IODEF and
IDMEF. AirCERT additionally used SNML to exchange information about Intrusion Detection Message Exchange Format [RFC4765]. AirCERT
the network. AirCERT was implemented in a combination of C and perl additionally used SNML to exchange information about the network.
modules and included periodic graphing capabilities leveraging AirCERT was implemented in a combination of C and perl modules and
RRDTool. included periodic graphing capabilities leveraging RRDTool.
AirCERT was intended for large scale distributed deployment and AirCERT was intended for large scale distributed deployment and
eventually the ability to sanitize data to be shared across eventually the ability to sanitize data to be shared across
administrative domains. The architecture was designed to allow administrative domains. The architecture was designed to allow
collection of data at a per site basis and to allow each site to collection of data at a per site basis and to allow each site to
create data sharing based on its own particular trust relationships. create data sharing based on its own particular trust relationships.
6.3. US Department of Energy CyberFed 6.3. US Department of Energy CyberFed
The CyberFed system was implemented and deployed by Argonne National The CyberFed system was implemented and deployed by Argonne National
Laboratory to automate the detection and response of attack activity Laboratory to automate the detection and response of attack activity
against Department of Energy (DoE) computer networks. CyberFed against Department of Energy (DoE) computer networks. CyberFed
automates the collection of network alerting activity from various automates the collection of network alerting activity from various
perimeter network defenses and logs those events into its database. perimeter network defenses and logs those events into its database.
CyberFed then automatically converts that information into blocking CyberFed then automatically converts that information into blocking
information transmitted to all participants. The original information transmitted to all participants. The original
implementation used IODEf messages wrapped in an XML extension to implementation used IODEF messages wrapped in an XML extension to
manage a large array of indicators. The CyberFed system was not manage a large array of indicators. The CyberFed system was not
designed to describe a particular incident as much as to describe a designed to describe a particular incident as much as to describe a
set of current network blocking indicators that can be generated and set of current network blocking indicators that can be generated and
deployed machine-to-machine. deployed machine-to-machine.
CyberFed is primarily implemented in Perl. Included as part of the CyberFed is primarily implemented in Perl. Included as part of the
CyberFed system are scripts which interact with a large number of CyberFed system are scripts which interact with a large number of
firewalls, IDS/IPS devices, DNS systems, and proxies which operate to firewalls, IDS/IPS devices, DNS systems, and proxies which operate to
implement both the automated collection of events as well as the implement both the automated collection of events as well as the
automated deployment of blacking. automated deployment of blacking.
Currently CyberFed supports multiple exchange formats including IODef Currently CyberFed supports multiple exchange formats including IODEF
and STIX. OpenIOC is also a potential exchange format that DoE is and STIX. OpenIOC is also a potential exchange format that DoE is
considering. considering.
7. Implementation Guide 7. Implementation Guide
The section aims at sharing the tips for development of IODEF-capable The section aims at sharing the tips for development of IODEF-capable
systems. systems.
7.1. Code Generators 7.1. Code Generators
For implementing IODEF-capable systems, it is feasible to employ code For implementing IODEF-capable systems, it is feasible to employ code
generators for XML Schema Document (XSD). The generators are used to generators for XML Schema Document (XSD). The generators are used to
save development costs since they automatically create useful save development costs since they automatically create useful
libraries for accessing XML attributes, composing messages, and/or libraries for accessing XML attributes, composing messages, and/or
validating XML objects. The IODEF XSD was defined in section 8 of validating XML objects. The IODEF XSD was defined in section 8 of
RFC 5070, and is availabe at http://www.iana.org/assignments/xml- RFC5070, and is availabe at http://www.iana.org/assignments/xml-
registry/schema/iodef-1.0.xsd. registry/schema/iodef-1.0.xsd.
However, there still remains some problem. Due to the complexity of However, there still remains some problem. Due to the complexity of
IODEF XSD, some code generators could not generate from the XSD file. IODEF XSD, some code generators could not generate from the XSD file.
The tested code generators were as follows. The tested code generators were as follows.
o XML::Pastor [XSD:Perl] (Perl) o XML::Pastor [XSD:Perl] (Perl)
o RXSD [XSD:Ruby] (Ruby) o RXSD [XSD:Ruby] (Ruby)
skipping to change at page 11, line 50 skipping to change at page 11, line 50
There is no recommended workaround, however, a double conversion of There is no recommended workaround, however, a double conversion of
XSD file is one option to go through the situation; it means XSD is XSD file is one option to go through the situation; it means XSD is
serialized to XML, and it is again converted to XSD. The resultant serialized to XML, and it is again converted to XSD. The resultant
XSD was process-able by the all tools above. XSD was process-able by the all tools above.
It should be noted that IODEF uses '-' (hyphen) symbols in its It should be noted that IODEF uses '-' (hyphen) symbols in its
classes or attributes, listed as follows. classes or attributes, listed as follows.
o IODEF-Document Class; it is the top level class in the IODEF data o IODEF-Document Class; it is the top level class in the IODEF data
model described in section 3.1 of [RFC5070]. model described in section 3.1 of RFC5070.
o The vlan-name and vlan-num Attribute; according to section 3.16.2 o The vlan-name and vlan-num Attribute; according to section 3.16.2
of [RFC5070], they are the name and number of Virtual LAN and are of RFC5070, they are the name and number of Virtual LAN and are
the attributes for Address class. the attributes for Address class.
o Extending the Enumerated Values of Attribute; according to section o Extending the Enumerated Values of Attribute; according to section
5.1 of [RFC5070], it is a extension techniques to add new 5.1 of RFC5070, it is a extension techniques to add new enumerated
enumerated values to an attribute, and has a prefix of "ext-", values to an attribute, and has a prefix of "ext-", e.g., ext-
e.g., ext-value, ext-category, ext-type, and so on. value, ext-category, ext-type, and so on.
According to the language specification, many programing language According to the language specification, many programing language
prohibit to contain '-' symbols in the name of class. The code prohibit to contain '-' symbols in the name of class. The code
generators must replace or remove '-' when building the librarlies. generators must replace or remove '-' when building the librarlies.
They should have the name space to restore '-' when outputting the They should have the name space to restore '-' when outputting the
XML along with IODEF XSD. XML along with IODEF XSD.
7.2. iodeflib 7.2. iodeflib
iodeflib is an open source implementation written in Python. This iodeflib is an open source implementation written in Python. This
skipping to change at page 14, line 7 skipping to change at page 14, line 7
10. Security Considerations 10. Security Considerations
This draft provides a summary of implementation reports from This draft provides a summary of implementation reports from
researchers and vendors who have implemented RFCs and drafts from the researchers and vendors who have implemented RFCs and drafts from the
MILE and INCH working groups. There are no security considerations MILE and INCH working groups. There are no security considerations
added in this draft because of the nature of the document. added in this draft because of the nature of the document.
11. Informative References 11. Informative References
[RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion
Detection Message Exchange Format (IDMEF)", RFC 4765,
DOI 10.17487/RFC4765, March 2007,
<http://www.rfc-editor.org/info/rfc4765>.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
DOI 10.17487/RFC5070, December 2007, DOI 10.17487/RFC5070, December 2007,
<http://www.rfc-editor.org/info/rfc5070>. <http://www.rfc-editor.org/info/rfc5070>.
[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
Class for Reporting Phishing", RFC 5901, Class for Reporting Phishing", RFC 5901,
DOI 10.17487/RFC5901, July 2010, DOI 10.17487/RFC5901, July 2010,
<http://www.rfc-editor.org/info/rfc5901>. <http://www.rfc-editor.org/info/rfc5901>.
skipping to change at page 14, line 31 skipping to change at page 14, line 36
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, DOI 10.17487/RFC6545, April 2012, RFC 6545, DOI 10.17487/RFC6545, April 2012,
<http://www.rfc-editor.org/info/rfc6545>. <http://www.rfc-editor.org/info/rfc6545>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546, Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012, DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>. <http://www.rfc-editor.org/info/rfc6546>.
[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
Incident Object Description Exchange Format (IODEF)
Extension for Structured Cybersecurity Information",
RFC 7203, DOI 10.17487/RFC7203, April 2014,
<http://www.rfc-editor.org/info/rfc7203>.
[XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)", [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
<http://www.microsoft.com/>. <http://www.microsoft.com/>.
[XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++", [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
<http://www.codesynthesis.com/>. <http://www.codesynthesis.com/>.
[XSD:Java] [XSD:Java]
Project Kenai, "JAXB Reference Implementation", Project Kenai, "JAXB Reference Implementation",
<https://jaxb.java.net/>. <https://jaxb.java.net/>.
 End of changes. 26 change blocks. 
38 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/