2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Internet Engineering Task Force Dulaunoy
|
|
|
|
|
|
Internet-Draft CIRCL
|
|
|
|
|
|
Intended status: Informational Kaplan
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Expires: June 20, 2014 CERT.at
|
2013-12-09 16:06:56 +00:00
|
|
|
|
Vixie
|
|
|
|
|
|
Farsight Security, Inc.
|
|
|
|
|
|
hs. Stern
|
|
|
|
|
|
Cisco
|
2013-12-17 16:33:31 +00:00
|
|
|
|
December 17, 2013
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Passive DNS - Common Output Format
|
|
|
|
|
|
draft-ietf-dulaunoy-kaplan-pdns-cof-01
|
|
|
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
|
|
|
|
|
|
This document describes the output format used between Passive DNS
|
|
|
|
|
|
query interface. The output format description includes also a
|
|
|
|
|
|
common meaning per Passive DNS system.
|
|
|
|
|
|
|
|
|
|
|
|
Status of this Memo
|
|
|
|
|
|
|
|
|
|
|
|
By submitting this Internet-Draft, each author represents that any
|
|
|
|
|
|
applicable patent or other IPR claims of which he or she is aware
|
|
|
|
|
|
have been or will be disclosed, and any of which he or she becomes
|
|
|
|
|
|
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
|
|
|
|
|
|
|
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering
|
|
|
|
|
|
Task Force (IETF). Note that other groups may also distribute
|
|
|
|
|
|
working documents as Internet-Drafts. The list of current Internet-
|
|
|
|
|
|
Drafts is at http://datatracker.ietf.org/drafts/current/.
|
|
|
|
|
|
|
|
|
|
|
|
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."
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
This Internet-Draft will expire on June 20, 2014.
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 1]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
|
|
|
|
|
|
|
|
|
|
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
|
|
|
|
|
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
|
|
|
|
|
|
2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
|
|
|
|
|
3. Common Output Format . . . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
|
3.1. Overview and Example . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
|
3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
|
3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
|
3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
|
3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
|
3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
|
3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
|
3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
|
3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
|
3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . . 5
|
2013-12-17 16:33:31 +00:00
|
|
|
|
3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . . 5
|
2013-12-09 16:06:56 +00:00
|
|
|
|
3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
|
3.4.2. zone_time_first . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
|
3.4.3. zone_time_last . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
|
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
|
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
|
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
|
2013-12-17 16:33:31 +00:00
|
|
|
|
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
|
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
|
2013-12-09 16:06:56 +00:00
|
|
|
|
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
|
|
|
|
|
|
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . . 7
|
|
|
|
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
|
|
|
|
|
|
Intellectual Property and Copyright Statements . . . . . . . . . . 9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 2]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Introduction
|
|
|
|
|
|
|
|
|
|
|
|
Passive DNS is a technique described by Florian Weimer in 2005 in
|
|
|
|
|
|
Passive DNS replication, F Weimer - 17th Annual FIRST Conference on
|
|
|
|
|
|
Computer Security. Since then multiple Passive DNS implementations
|
|
|
|
|
|
evolved over time. Users of these Passive DNS servers query a server
|
|
|
|
|
|
(often via Whois [Ref: WHOIS] or HTTP and ReST), parse the results
|
|
|
|
|
|
and process them in other applications.
|
|
|
|
|
|
|
|
|
|
|
|
There are multiple implementation of Passive DNS software. Users of
|
|
|
|
|
|
passive DNS query each implementation and aggregate the results for
|
|
|
|
|
|
their search. This document describes the output format of three
|
|
|
|
|
|
Passive DNS Systems which are in use today and which already share a
|
|
|
|
|
|
nearly identical output format. As the format and the meaning of
|
|
|
|
|
|
output fields from each Passive DNS need to be consistent, we propose
|
|
|
|
|
|
in this document a solution to commonly name each field along with
|
|
|
|
|
|
their corresponding interpretation. The format format is following a
|
|
|
|
|
|
simple key-value structure in JSON [RFC4627] format. The benefit of
|
|
|
|
|
|
having a consistent Passive DNS output format is that multiple client
|
|
|
|
|
|
implementations can query different servers without having to have a
|
|
|
|
|
|
separate parser for each individual server.
|
|
|
|
|
|
[https://github.com/chrislee35/passivedns-client] currently
|
|
|
|
|
|
implements multiple parsers due to a lack of standardization. The
|
|
|
|
|
|
document does not describe the protocol (e.g. whois, HTTP REST or
|
|
|
|
|
|
XMPP) nor the query format used to query the Passive DNS. Neither
|
|
|
|
|
|
does this document describe "pre-recursor" Passive DNS Systems.
|
|
|
|
|
|
|
|
|
|
|
|
1.1. Requirements Language
|
|
|
|
|
|
|
|
|
|
|
|
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 [RFC2119].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Limitation
|
|
|
|
|
|
|
|
|
|
|
|
As a Passive DNS can include protection mechanisms for their
|
|
|
|
|
|
operation, results might be different due to those protection
|
|
|
|
|
|
measures. These mechanisms filter out DNS answers if they fail some
|
|
|
|
|
|
criteria. The bailiwick algorithm (c.f.
|
|
|
|
|
|
http://www.isc.org/files/passive_dns_hardening_handout.pdf) protects
|
|
|
|
|
|
the Passive DNS Database from cache poisoning attacks [ref: Dan
|
|
|
|
|
|
Kaminsky]. Another limitiation that clients querying the database
|
|
|
|
|
|
need to be aware of is that each query simply gets an snapshot-answer
|
|
|
|
|
|
of the time of querying. Clients MUST NOT rely on consistent
|
|
|
|
|
|
answers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 3]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. Common Output Format
|
|
|
|
|
|
|
|
|
|
|
|
The formatting of the answer follows the JSON [RFC4627] format. The
|
|
|
|
|
|
order of the fields is not significant for the same resource type.
|
|
|
|
|
|
That means, the same name tuple plus timing information identifies a
|
|
|
|
|
|
unique answer per server.
|
|
|
|
|
|
|
|
|
|
|
|
3.1. Overview and Example
|
|
|
|
|
|
|
|
|
|
|
|
The intent of this output format is to be easily parseable by
|
|
|
|
|
|
scripts. Every implementation MUST support the JSON output format.
|
|
|
|
|
|
|
|
|
|
|
|
A sample output using the JSON format:
|
|
|
|
|
|
|
|
|
|
|
|
... (list of )...
|
|
|
|
|
|
{ "count": 97167,
|
|
|
|
|
|
"time_first": "1277353744",
|
|
|
|
|
|
"rrtype": "A", "rrname": "google-public-dns-a.google.com.",
|
|
|
|
|
|
"rdata": "8.8.8.8",
|
|
|
|
|
|
"time_last": "1386405372" }
|
|
|
|
|
|
... (separated by newline)...
|
|
|
|
|
|
|
|
|
|
|
|
3.2. Mandatory Fields
|
|
|
|
|
|
|
|
|
|
|
|
Implementation MUST support all the mandatory fields.
|
|
|
|
|
|
|
|
|
|
|
|
The tuple (rrtype,rrname,rdata) will always be unique within one
|
|
|
|
|
|
answer per server.
|
|
|
|
|
|
|
|
|
|
|
|
3.2.1. rrname
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the name of the queried resource.
|
|
|
|
|
|
|
|
|
|
|
|
3.2.2. rrtype
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the resource record type as seen by the passive
|
|
|
|
|
|
DNS. The key is rrtype and the value is in the interpreted record
|
|
|
|
|
|
type. If the value cannot be interpreted the decimal value is
|
|
|
|
|
|
returned following the principle of transparency as described in RFC
|
|
|
|
|
|
3597 [RFC3597]. The resource record type can be any values as
|
|
|
|
|
|
described by IANA in the DNS parameters document in the section 'DNS
|
|
|
|
|
|
Label types' (http://www.iana.org/assignments/dns-parameters).
|
|
|
|
|
|
Currently known and supported textual descritptions of rrtypes are:
|
|
|
|
|
|
A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6 A
|
|
|
|
|
|
client MUST be able to understand these textual rtype values. In
|
|
|
|
|
|
addition, a client MUST be able to handle a decimal value (as
|
|
|
|
|
|
mentioned above) as answer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 4]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.2.3. rdata
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the data of the queried resource. In general,
|
|
|
|
|
|
this is to be interpreted as string. Depending on the rtype, this
|
|
|
|
|
|
can be an IPv4 or IPv6 address, a domain name (as in the case of
|
|
|
|
|
|
CNAMEs), an SPF record, etc. A client MUST be able to interpret any
|
|
|
|
|
|
value which is legal as the right hand side in a DNS zone file RFC
|
|
|
|
|
|
1035 [RFC1035] and RFC 1034 [RFC1034]. If the rdata came from an
|
|
|
|
|
|
unknown DNS resource records, the server must follow the transparency
|
2013-12-17 16:33:31 +00:00
|
|
|
|
principle as described in RFC 3597 [RFC3597].
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
3.2.4. time_first
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the first time that the record / unique tuple
|
|
|
|
|
|
(rrname, rrtype, rdata) has been seen by the passive DNS. The date
|
|
|
|
|
|
is expressed in seconds (decimal ascii) since 1st of January 1970
|
|
|
|
|
|
(unix timestamp). The time zone MUST be UTC.
|
|
|
|
|
|
|
|
|
|
|
|
3.2.5. time_last
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the last time that the unique tuple (rrname,
|
|
|
|
|
|
rrtype, rdata) record has been seen by the passive DNS. The date is
|
|
|
|
|
|
expressed in seconds (decimal ascii) since 1st of January 1970 (unix
|
|
|
|
|
|
timestamp). The time zone MUST be UTC.
|
|
|
|
|
|
|
|
|
|
|
|
3.3. Optional Fields
|
|
|
|
|
|
|
|
|
|
|
|
Implementation SHOULD support one or more field.
|
|
|
|
|
|
|
|
|
|
|
|
3.3.1. count
|
|
|
|
|
|
|
|
|
|
|
|
Specifies how many answers were received with the set of answers
|
|
|
|
|
|
(i.e. same data). The number of requests is expressed as a decimal
|
|
|
|
|
|
value.
|
|
|
|
|
|
|
|
|
|
|
|
Specifies the number of times this particular event denoted by the
|
|
|
|
|
|
other type fields has been seen in the given time interval (between
|
|
|
|
|
|
time_last and time_first). Decimal number.
|
|
|
|
|
|
|
|
|
|
|
|
3.3.2. bailiwick
|
|
|
|
|
|
|
|
|
|
|
|
The bailiwick is the best estimate of the apex of the zone where this
|
|
|
|
|
|
data is authoritative. String.
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
3.4. Additional Fields
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Implementations MAY support the following fields:
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 5]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.4.1. sensor_id
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the sensor information where the record was seen.
|
|
|
|
|
|
The sensor_id is an opaque byte string as defined by RFC 5001 in
|
|
|
|
|
|
section 2.3 [RFC5001].
|
|
|
|
|
|
|
|
|
|
|
|
3.4.2. zone_time_first
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the first time that the unique tuple (rrname,
|
|
|
|
|
|
rrtype, rdata) record has been seen via zone file import. The date
|
|
|
|
|
|
is expressed in seconds (decimal ascii) since 1st of January 1970
|
|
|
|
|
|
(unix timestamp). The time zone MUST be UTC.
|
|
|
|
|
|
|
|
|
|
|
|
3.4.3. zone_time_last
|
|
|
|
|
|
|
|
|
|
|
|
This field returns the last time that the unique tuple (rrname,
|
|
|
|
|
|
rrtype, rdata) record has been seen via zone file import. The date
|
|
|
|
|
|
is expressed in seconds (decimal ascii) since 1st of January 1970
|
|
|
|
|
|
(unix timestamp). The time zone MUST be UTC.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4. Acknowledgements
|
|
|
|
|
|
|
|
|
|
|
|
Thanks to the Passive DNS developers who contributed to the document.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5. IANA Considerations
|
|
|
|
|
|
|
|
|
|
|
|
This memo includes no request to IANA.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6. Security Considerations
|
|
|
|
|
|
|
|
|
|
|
|
In some cases, Passive DNS output might contain confidential
|
|
|
|
|
|
information and its access might be restricted. When an user is
|
|
|
|
|
|
querying multiple Passive DNS and aggregating the data, the
|
|
|
|
|
|
sensitivity of the data must be considered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7. References
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
7.1. Normative References
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
|
|
|
|
|
STD 13, RFC 1034, November 1987.
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
|
|
|
|
|
specification", STD 13, RFC 1035, November 1987.
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 6]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
|
|
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
|
|
|
|
|
|
|
|
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
|
|
|
|
|
(RR) Types", RFC 3597, September 2003.
|
|
|
|
|
|
|
|
|
|
|
|
[RFC4627] Crockford, D., "The application/json Media Type for
|
|
|
|
|
|
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
|
|
|
|
|
|
|
|
|
|
|
|
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
|
|
|
|
|
|
RFC 5001, August 2007.
|
|
|
|
|
|
|
|
|
|
|
|
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
|
|
|
|
|
|
|
|
|
|
|
|
7.2. Informative References
|
|
|
|
|
|
|
|
|
|
|
|
[I-D.narten-iana-considerations-rfc2434bis]
|
|
|
|
|
|
Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
|
|
|
|
|
IANA Considerations Section in RFCs",
|
|
|
|
|
|
draft-narten-iana-considerations-rfc2434bis-09 (work in
|
|
|
|
|
|
progress), March 2008.
|
|
|
|
|
|
|
|
|
|
|
|
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
|
|
|
|
|
|
June 1999.
|
|
|
|
|
|
|
|
|
|
|
|
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
|
|
|
|
|
|
Text on Security Considerations", BCP 72, RFC 3552,
|
|
|
|
|
|
July 2003.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix A. Appendix
|
|
|
|
|
|
|
|
|
|
|
|
This becomes an Appendix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Authors' Addresses
|
|
|
|
|
|
|
|
|
|
|
|
Alexandre Dulaunoy
|
|
|
|
|
|
CIRCL
|
|
|
|
|
|
41, avenue de la gare
|
|
|
|
|
|
Luxembourg, L-1611
|
|
|
|
|
|
LU
|
|
|
|
|
|
|
|
|
|
|
|
Phone: (+352) 247 88444
|
|
|
|
|
|
Email: alexandre.dulaunoy@circl.lu
|
|
|
|
|
|
URI: http://www.circl.lu/
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 7]
|
|
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-09 16:06:56 +00:00
|
|
|
|
Leon Aaron Kaplan
|
|
|
|
|
|
CERT.at
|
|
|
|
|
|
Karlsplatz 1/2/9
|
|
|
|
|
|
Vienna, A-1010
|
|
|
|
|
|
AT
|
|
|
|
|
|
|
|
|
|
|
|
Phone: +43 1 5056416 78
|
|
|
|
|
|
Email: kaplan@cert.at
|
|
|
|
|
|
URI: http://www.cert.at/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Paul Vixie
|
|
|
|
|
|
Farsight Security, Inc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Phone:
|
|
|
|
|
|
Email: paul@redbarn.org
|
|
|
|
|
|
URI: /
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Henry Stern
|
|
|
|
|
|
Cisco
|
|
|
|
|
|
1741 Brunswick Street, Suite 500
|
|
|
|
|
|
Halifax, Nova Scotia B3J 3X8
|
|
|
|
|
|
Canada
|
|
|
|
|
|
|
|
|
|
|
|
Phone: +1 408 922 4555
|
|
|
|
|
|
Email: hestern@cisco.com
|
|
|
|
|
|
URI: http://www.cisco.com/security
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 8]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title December 2013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Full Copyright Statement
|
|
|
|
|
|
|
|
|
|
|
|
Copyright (C) The IETF Trust (2013).
|
|
|
|
|
|
|
|
|
|
|
|
This document is subject to the rights, licenses and restrictions
|
|
|
|
|
|
contained in BCP 78, and except as set forth therein, the authors
|
|
|
|
|
|
retain all their rights.
|
|
|
|
|
|
|
|
|
|
|
|
This document and the information contained herein are provided on an
|
|
|
|
|
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
|
|
|
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
|
|
|
|
|
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
|
|
|
|
|
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
|
|
|
|
|
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
|
|
|
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Intellectual Property
|
|
|
|
|
|
|
|
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
|
|
|
|
Intellectual Property Rights or other rights that might be claimed to
|
|
|
|
|
|
pertain to the implementation or use of the technology described in
|
|
|
|
|
|
this document or the extent to which any license under such rights
|
|
|
|
|
|
might or might not be available; nor does it represent that it has
|
|
|
|
|
|
made any independent effort to identify any such rights. Information
|
|
|
|
|
|
on the procedures with respect to rights in RFC documents can be
|
|
|
|
|
|
found in BCP 78 and BCP 79.
|
|
|
|
|
|
|
|
|
|
|
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|
|
|
|
|
assurances of licenses to be made available, or the result of an
|
|
|
|
|
|
attempt made to obtain a general license or permission for the use of
|
|
|
|
|
|
such proprietary rights by implementers or users of this
|
|
|
|
|
|
specification can be obtained from the IETF on-line IPR repository at
|
|
|
|
|
|
http://www.ietf.org/ipr.
|
|
|
|
|
|
|
|
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
|
|
|
|
copyrights, patents or patent applications, or other proprietary
|
|
|
|
|
|
rights that may cover technology that may be required to implement
|
|
|
|
|
|
this standard. Please address the information to the IETF at
|
|
|
|
|
|
ietf-ipr@ietf.org.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-17 16:33:31 +00:00
|
|
|
|
Dulaunoy, et al. Expires June 20, 2014 [Page 9]
|
2013-12-09 16:06:56 +00:00
|
|
|
|
|
