Liaison statement
Response to "Cybersecurity information exchange framework"

Submission date 2010-11-30
From IETF SEC AREA (Tim Polk)
To ITU-T SG17 (,
Response contact
Technical contact,
Purpose In response
Attachments (None)
Liaison Statement
To: ITU-T SG 17
For Information
Source: IETF Security Area Directors
Subject: Re: Cybersecurity information exchange framework

Thank you for the liaison statement describing SG17’s new cybersecurity
information exchange 
framework (CYBEX) standardization initiative.  Automated mechanisms for
the exchange of cybersecurity
information are a critical requirement for incident reporting and
enable collaborative and coordinated 
incident response.  Given that security incidents often cross
enterprise and national boundaries, the IETF
Security Area applauds SG17’s efforts.  
The IETF also appreciates that the CYBEX framework imports existing
standards and de facto standards 
where appropriate.  In particular, we note that CYBEX references
IETF-developed standards (e.g., IODEF) 
and independent stream RFCs (RFC 3924).  Inclusion of these
specifications in CYBEX both recognizes 
and enhances their value to the community.  While recognizing the
utility of this effort, the IETF is not 
contemplating a framework level effort of its own.  Based on our review
of the liaison and the 
accompanying documents, if a framework is needed to support IETF
standardization activities, 
referencing CYBEX would be the preferred mechanism.
The liaison statement indicates SG17’s desire to extend RFC 5070
(IODEF) to support CYBEX reporting 
requirements. The working group that developed IODEF has closed.
Current activities in this space are 
in focused in the Message Abuse Report Format (MARF) working group
which uses a competing format. 
We do not believe that the MARF work precludes development of new
versions of IODEF, or other work 
leveraging IODEF, but do not expect such work to occur in the IETF.
The IETF is not currently developing new specifications based on IODEF,
so the proposed SG 17 activities 
to address new areas of crime or misuse would not create conflicts or
redundancies.  IODEF was meant 
to be extensible, so it is likely that these areas can be addressed
without revising the base specification.
In this case, SG17's specifications would simply reference RFC 5070,
instead of creating a new version 
of IODEF.  The Security Area suggests that ITU-T register any new
specifications with the Internet 
Assigned Numbers Authority (IANA) so that all IODEF registrations are
collected in a single registry.
If revisions to the base specification are essential, the process
becomes more complicated.  There does 
not seem to be sufficient interest in IODEF within the IETF to support
development of an IODEF version 
2. If SG17 has the energy and interest to pursue this work, it is
probably in the best interest of the 
community to transfer change control of IODEF from the IETF to SG17 so
that a new version can be 
The IETF process for transferring change control requires demonstrating
rough consensus among IETF 
participants.  This process involves drafting and publishing an IETF
stream RFC.  We suggest reviewing 
RFC 4663 as an example of such an RFC.  (The document is available at This process includes an IETF-wide
“Last Call” and evaluation by the
Internet Engineering Steering Group (IESG).  This process can be
completed in a few months, assuming
the proposal is well received by the IETF community.
We should note that IETF does not hold the necessary copyright licenses
to permit transferring change 
control of RFC 5070 at this time. (Since the publication of RFC 5378,
the copyright statements were 
changed to ensure that the IETF will have the necessary rights to
transfer change control for work 
initiated after that time.  Unfortunately, IODEF predates 5378.)  It
will be necessary to identify the 
various contributors and persuade each of them to provide an updated
license agreement.  One of the 
chairs of IODEF has offered to assist with this process, should SG 17
decide to request change control.
There are other efforts underway or under consideration within the IETF
that could potentially 
contribute to the CYBEX framework.  As noted above, the MARF work is
focused on development of an 
Abuse Report Format (ARF) for reporting email abuse.  The base
specification for ARF has been 
published as RFC  5965, and work on two additional specifications
(discovery mechanisms and 
acceptance criteria) is underway.  While the collision of acronyms with
the Assessment Result Format 
(also known as ARF) is unfortunate, we believe RFC 5965 and the
companion specifications would 
complement the existing CYBEX standards.

In the IT Asset Management Domain, the IETF has two families of
standards that should be considered 
for inclusion in CYBEX.  The SNMP protocols and the various management
information bases (MIBs) 
defined by the IETF are a widely used to manage assets based on IETF
protocols. The netconf protocol 
and YANG modules provide an XML-based mechanism for managing the same
assets.  While the MIBs 
and YANG modules defined by the IETF are specifically tailored to
manage assets based on IETF 
protocols, the SNMP and netconf mechanisms are generally applicable. 
The SCAP family of specifications, and their relationship to the IETF
specifications, were the subject of a 
Birds of a Feather session at the Beijing IETF.  The purpose of the BOF
was to inform the IETF community 
about SCAP and identify areas of synergy.  We greatly appreciated the
participation of  Mr. Takeshi 
Takahashi in the BOF to highlight the importance of SCAP to the CYBEX
efforts.  It would be premature 
to speculate as to IETF standardization activities but any work the
IETF would choose to perform in this 
area should only enhance the value of CYBEX in the Internet.
Finally, upon reviewing the compendium of “Network forensic and
vulnerability organizations”, we 
suggest adding the Messaging Abuse Reporting Format (marf) working
group to the current IETF list. 
The marf charter is available at