Internet DRAFT - draft-wiley-lisp-ddtxfer
draft-wiley-lisp-ddtxfer
Network Working Group G. Wiley, Ed.
Internet-Draft Verisign, Inc.
Intended status: Experimental March 12, 2012
Expires: September 13, 2012
LISP-DDT Database Transfer
draft-wiley-lisp-ddtxfer-01
Abstract
This draft describes a protocol for transferring a LISP Delegated
Database Tree (LISP-DDT) between DDT nodes and for notifying DDT
nodes that the database has changed. In the absence of a formally
defined protocol the LISP-DDT database is transferred using files
containing device configuration commands. This protocol provides for
transferring a complete database or the deltas between two versions
of the database. This document does not describe the use of DDT as
part of the LISP mapping service.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and 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."
This Internet-Draft will expire on September 13, 2012.
Copyright Notice
Copyright (c) 2012 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
(http://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
Wiley Expires September 13, 2012 [Page 1]
Internet-Draft LISP DDT Database Transfer March 2012
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 Simplified BSD License.
1. Introduction
References to the LISP-DDT database in this document are intended to
refer specifically to the portion of the LISP-DDT database that has
been delegated to the DDT node, not the entire database.
An operator that offers a LISP-DDT service faces a few problems
(similar to those faces by the operator of a DNS resolution service):
o How to replicate the LISP-DDT database from one host/device to
another to support redundant platforms or to support operational
maintenance.
o Transfering the LISP-DDT between dissimilar platforms, for example
between network devices offered by competing network device
vendors that rely on different configuration commands.
o How to transfer portions of the LISP-DDT database rather than the
entire database (to deal with the eventual large database).
o How to notify an interested DDT node that the LISP-DDT database
has changed
The focus for this document is to define a protocol for the transfer
of the LISP-DDT database between DDT XFR nodes that addresses these
problems. The local representation of the data in the LISP-DDT
database on the DDT node is outside the scope of this document.
In the absence of a well described line protocol an operator might
send a list of OS commands to run on the DDT node that would populate
the LISP DDT database, however even this approach requires an
operational protocol to ensure a reliable/repeatable transfer of the
LISP DDT database.
There are two types of transfers, both are limited to only the
portion of the database that has been delegated to the DDT node. A
full transfer sends the entire set of entries in the database for
which the DDT node is authoritative. An incremental transfer sends
only the portion of that set of entries in the database that has
changed (based on the version of the database on the receiving node).
LISP-DDT bears some resemblance to the Domain Name Service (DNS) in
the sense that it provides an indirect vector to the target data.
Wiley Expires September 13, 2012 [Page 2]
Internet-Draft LISP DDT Database Transfer March 2012
Think of a LISP-DDT query as the analog to a DNS name server (NS)
query, and a LISP map request as the analog to a DNS address (A)
query (LISP-DDT does not store the EID to RLOC mappings returned in a
map request).
DDT XFR clients that need to be notified of changes to the DDT
database may subscribe to the appropriate DDT XFR server and are
asynchronously notified of changes. A DDT XFR client always
initiates a transfer by sending a request to the authoritative DDT
XFR server.
LISP-DDT database transfer introduces the use of a monotonically
increasing 64-bit serial number that identifies a version of a
portion of a LISP-DDT database. Each delegated portion of the
database (identified by a unique Extended EID-prefix) has a distinct
serial number which is maintained by the authoritative DDT XFR
server. One or more changes to the contents of the LISP-DDT database
increments the serial number. Once a serial number is used it may
never be reused. This feature ensures that a DDT XFR client can
reliably determine whether its copy of the LISP-DDT database is
consistent with the one offered by the DDT XFR server. This serial
number is analogous to the DNS SOA serial number.
1.1. LISP-DDT
LISP-DDT defines a database key for identifying EID mappings to RLOCs
in the EID numbering space. This key (the Extended EID prefix) is
comprised of the following fields:
+---------------------------------+-------------------------+
| Field | Size |
+---------------------------------+-------------------------+
| Key-ID | 16 bits |
| Instance Identifier (IID) | 32 bits |
| Address Family Identifier (AFI) | 16 bits |
| EID-prefix | variable length per AFI |
+---------------------------------+-------------------------+
See [LISP-DDT] for a more complete discussion of the key fields.
The root DDT XFR server is the apex of the hierarchy and is
identified by the key: Key-ID=0, IID=0, AFI=0, EID-prefix=0/0
It is useful to note that a DDT node does not necessarily imply a
single host, in fact it is more likely implemented as a collection of
hosts operating behind a VIP or via some other mechanism that allows
for active redundant components.
Wiley Expires September 13, 2012 [Page 3]
Internet-Draft LISP DDT Database Transfer March 2012
1.2. Network Transport
TCP is used exclusively as the transport for LISP-DDT transfer
sessions as opposed to other LISP messages which are sent via UDP.
1.3. Terminology
Note that for the sake of consistency many of these definitions were
lifted directly from [LISP-DDT].
Extended EID (XEID): a LISP EID, optionally extended with a non-
zero Instance ID (IID) if the EID is intended for use in a context
where it may not be a unique value, such as on a Virtual Private
Network where "private" address space is used. See "Using
Virtualization and Segmentation with LISP" in [LISP] for more
discussion of Instance IDs.
XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT Key-ID (provided
to allow the definition of multiple databases; currently always
zero in this version of DDT, with other values reserved for future
use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used
as a key index into the database.
DDT node: a network infrastructure component responsible for
specific XEID-prefix and for delegation of more-specific sub-
prefixes to other DDT nodes.
Authoritative DDT node: The DDT map server that is authoritative for
a portion of the LISP-DDT database is identified as an
"authoritative DDT node/server" and is the exclusive source for an
authoritative copy of the portion of the LISP-DDT database that
has been delegated to that DDT map server.
DDT XFR client: The DDT node that is requesting a LISP-DDT database
transfer from a DDT XFER server. A DDT XFR client would likely be
a device/host that may serve as a DDT server following the
transfer.
DDT XFR server: The DDT node that receives a request for a LISP-DDT
database transfer and functions as the source of the LISP-DDT
database is the DDT XFR server. DDT XFR servers never initiate a
transfer, however they may send notification messages to DDT XFR
clients that have subscribed to the portion of the database for
which the DDT server is authoritative.
Wiley Expires September 13, 2012 [Page 4]
Internet-Draft LISP DDT Database Transfer March 2012
Full Transfer: A full LISP-DDT database transfer (FDDTXFR) describes
the transfer of the entire portion of the LISP-DDT database for
which a DDT-node is authoritative. The transfer does not include
portions of the database that are delegated to other DDT nodes.
Incremental Transfer: An incremental LISP-DDT database transfer
(IDDTXFR) is a transfer of the differences between two serial
numbers of the LISP-DDT database for which a DDT XFR server is
authoritative. The current serial number and the serial number
provided by the DDT XFR client determine the context of the
differences.
serial number: A monotonically increasing number that indicates a
specific version of the portion of the LISP-DDT database
identified by a unique Extended EID-prefix. There may be more
than one material difference between versions of the database even
though the serial number is incremented once.
session: A LISP-DDT database transfer session ("session") includes
all communication between the DDT XFR client and DDT XFR server
involved in requesting and responding to a request for the
transfer of a portion of the LISP-DDT database.
For definitions of other acronyms (EID, RLOC, etc.) see [LISP] and
[LISP-DDT].
1.4. 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. LISP-DDT Database Transfer Request
Immediately after the network connection is established from a DDT
XFR client to a DDT XFR server the DDT XFR client sends a transfer
request message. The LISP-DDT transfer message is very similar to
the LISP Map-Request.
Wiley Expires September 13, 2012 [Page 5]
Internet-Draft LISP DDT Database Transfer March 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=9 |F|I|N| Reserved | EID mask-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Key ID | MAC Digest Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MAC Digest Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial number . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Serial number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key-ID | Instance Identifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Instance Identifier | Address Family Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID-prefix . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . EID-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP-DDT Transfer Request Message Format
Packet field descriptions:
Type=9: DDT Transfer request, this four bit value identifies the
packet type (other LISP packet types are defined in the respective
Internet Drafts).
F (bit flag): If this bit is set then this is a full transfer
request.
I (bit flag): If this bit is set then this is an incremental
transfer request.
N (bit flag): If this bit is set then this is a notification that
the serial number for the portion of the database identified by
the Extended EID has changed.
EID mask-len: The EID mask length (in bits) of the EID-prefix, not
including the three fields that prefix the EID-prefix.
Wiley Expires September 13, 2012 [Page 6]
Internet-Draft LISP DDT Database Transfer March 2012
MAC Key ID: Identifies the Message Authentication Code (MAC) digest
algorithm per [LISP].
MAC Digest length: Length in bytes of the following MAC digest data.
MAC Digest Data: The MAC digest data depends on the MAC Key ID
specified and is calculated on all of the fields that follow in
this message.
Serial number: In the case of an incremental transfer the DDT XFR
client populates this 64-bit value with the current serial number
so that the DDT XFR server can attempt to determine which database
changes must be sent. This field is ignored for full transfers.
Key-ID: 16 bit Key-ID for the X-EID prefix being requested.
Instance Identifier: 32 bit Instance Identifier for the X-EID prefix
being requested.
AFI: 16 bit Address Family Identifier for the X-EID prefix being
requested.
EID-prefix: The variable length EID-prefix (per AFI) for the XEID
prefix being requested. This length is also available in the
header of the packet.
3. Full LISP-DDT Database Transfer
A full LISP-DDT database transfer is initiated by a DDT XFR client as
a FDDTXFR request sent to a DDT XFR server. A DDT XFR server may
choose to ignore full transfer requests received from the same DDT
XFR client more than once in a 12 hour period.
This request is answered by successive DDTDAT messages until the
entire portion of the database is sent from the DDT XFR server.
4. Incremental LISP-DDT Database Transfer
An incremental LISP-DDT database transfer is initiated by a DDT XFR
client as a IDDTXFER request sent to a DDT XFR server. The DDT XFR
client specifies a serial number which is used by the DDT XFR server
to determine which changes must be sent in the reply.
The DDT XFR server should respond to the IDDTXFER request with an
IDDTXFER reply that includes only the changes between the specified
serial number and the current serial number. The DDT XFR server may
Wiley Expires September 13, 2012 [Page 7]
Internet-Draft LISP DDT Database Transfer March 2012
choose to respond with an FDDTXFER reply if the changes between the
serial numbers are no longer available to the DDT XFR server.
The DDT XFR client must be prepared to receive an FDDTXFER reply in
response to a IDDTXFER request.
5. LISP-DDT Transfer Data Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=11|F|I|H|N| Reserved |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MAC Key ID | MAC Digest Length |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MAC Digest Data ~
b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
i | Initial Serial number . . . |
t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . Initial Serial number |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Current Serial number . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . Current Serial number |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A|R|L|Reserved | Record TTL . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R |...Record TTL | Locator Count | EID mask-len | DB Key-ID... |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | ...DB Key-ID | Instance Identifier . . . |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r |...Instance ID | EID-AFI | Reserved |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EID-prefix . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o| Unused Flags |R| Loc-AFI |
| c+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP-DDT Transfer Data Message Format
Packet field descriptions are identical to those for the LISP Map
Wiley Expires September 13, 2012 [Page 8]
Internet-Draft LISP DDT Database Transfer March 2012
Reply, new fields are described below:
Type=11: DDT Transfer Data Message, this four bit value identifies
the packet type (other LISP packet types are defined in the
respective Internet Drafts).
F (bit flag): If this bit is set then this is a response to a full
transfer request.
I (bit flag): If this bit is set then this is a response to an
incremental transfer request.
H (bit flag): If this bit is set then the data header is included in
the message. This header includes the message digest and serial
numbers of the versions of the database. The header typically is
included only in the first data message sent in response to a
request.
N (bit flag): NXDB, this bit is set in a response if the portion of
the database requested is not delegated to the DDT XFR server
responding to the request. If this bit is set then the Extended
EID-prefix is populated with the values specified in the original
request.
MAC Key ID: Identifies the Message Authentication Code (MAC) digest
algorithm per [LISP].
MAC Digest length: Length in bytes of the following MAC digest data.
MAC Digest Data: The MAC digest data depends on the MAC Key ID
specified and is calculated on all of the fields that follow in
this message.
Initial Serial number: In an IDDTXFER reply, the initial serial
number is the serial number specified in the IDDTXFER request
provided that serial number was used to generate the changes
specified in the data messages. In a FDDTXFER request or in the
case that the DDT XFR server could not determine the changes
between the specified and current serial numbers then this field
is filled with 0's. If the H bit is not set then this serial
number is not present and the Extended EID prefix begins at this
location in the packet.
Current Serial number: In both the IDDTXFER and FDDTXFER reply, the
current serial number is provided in this field. If the H bit is
not set then this serial number is not present.
Wiley Expires September 13, 2012 [Page 9]
Internet-Draft LISP DDT Database Transfer March 2012
A (bit flag): For incremental transfers this bit is set to indicate
that the Extended EID prefix is to be added to the database. If
this bit is not set then the Extended EID prefix is to be removed
from the database. In cases where the Extended EID prefix is
duplicated by the add, the record is replaced in the database.
R (bit flag): For incremental transfers this bit is set to indicate
that the Extended EID prefix is to be removed from the database.
The A and R bits are mutually exclusive.
L (bit flag): This bit is set only in the last record of the DDTXFER
reply to indicate that no more records follow.
6. LISP-DDT Database Transfer Notify
A DDT XFR server maintains a list of DDT XFR clients that have
subscribed to the portion of the LISP-DDT database tree delegated to
that DDT XFR server. A DDT XFR client subscribes to a DDT XFR server
by communicating with the DDT XFR server operator who then configures
the DDT XFR server to send notifications. When the DDT XFR server
increments the serial number for the delegated portion of the
database, all DDT XFR clients are notified of the change via a
DDTNTFY message which is identical to a DDTXFER request message with
the N bit set.
Notifications are sent to DDT XFR clients within five minutes of the
change to the serial number. A DDT XFR server may choose to only
send the most recent/current serial number rather than all of the
serial numbers that were used between notifications to a DDT XFR
client.
Notifications are delivered via a reliable transport (TCP) and the
DDT XFR server must attempt to connect with the DDT XFR client and
send the notification at least three times within a three minute
window no more frequently than once per minute. The DDT XFR server
may choose a higher number of attempts at sending the notification,
but not more frequently than once per minute.
7. Acknowledgments
Special thanks to folks that offered their considerable experience in
building and operating large scale DNS platforms and helping
translate this experience to LISP-DDT database transfers including
Dave Blacka, Piet Barber and Sean Mountcastle. I also appreciate the
time that Neel Goyal and Ramin Ali Dousti have put into this effort.
Wiley Expires September 13, 2012 [Page 10]
Internet-Draft LISP DDT Database Transfer March 2012
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
There are a few Security considerations specific to LISP-DDT Database
Transfers that are incremental to the LISP-DDT specification. Most
of the security related requirements are satisfied by the use of TLS.
Although TLS as described in RFC 5246 [RFC5246] is intended to be
transparent to the application protocol, certain details should be
addressed to ensure consistent implementation of LISP-DDT Transfer.
These details are addressed in a separate document.
Two of the approaches to implementing security related features in
the protocol are to offer the secure service on an alternate port or
to allow session endpoints to upgrade an existing session via TLS.
The preferred approach to securing LISP-DDT Transfer is to offer the
secure service on an alternate port from the "un-secure" service.
The primary motivation for this approach is to improve operational
efficiency, for example this makes it easier to deploy a footprint
that efficiently allocates hardware used to accelerate TLS
termination.
An alternative to offering the secure service on an different network
port is to support session upgrades. In this case either endpoint of
a LISP-DDT transfer session may upgrade that session via TLS similar
to the approach taken to upgrade an HTTP session via TLS as described
in RFC 2817 [RFC2817].
The use of TLS provides for the three primary security
considerations:
o Host authentication, both DDT XFR server and DDT XFR client can be
reasonably confident of the identity of the other endpoint.
o Transfer integrity, the contents of the transfer can be reasonably
assured to be unadulterated. The use of a message digest as is
currently specified for the protocol affords message integrity as
well.
o Transfer confidentiality, the contents of the transfer will be
essentially opaque to hosts outside the session.
10. References
Wiley Expires September 13, 2012 [Page 11]
Internet-Draft LISP DDT Database Transfer March 2012
10.1. Normative References
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP),
draft-ietf-lisp-22.txt", February 2012.
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface,
draft-ietf-lisp-ms-12.txt (work in progress)",
October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
10.2. Informative References
[LISP-DDT]
Fuller, V., "LISP Delegated Database Tree,
draft-ietf-lisp-ddt-01.txt (work in progress)",
October 2011.
Appendix A. Open Issues
o A subscription message to manage DDT XFR client subscriptions to
DDT XFR servers for portions of the database would be very useful.
This requires a robust mechanism for authenticating subscribe/
unsubscribe requests as part of the application protocol rather
than relying entirely on TLS.
o Compression should be included in the specification as an optional
feature. This will become more important as LISP is more widely
adopted and the size of the LISP-DDT increases.
o Do we need to support some sort of discovery protocol, for example
should a DDT XFR client be able to not specify some portion of the
extended EID prefix so that a DDT XFR server can reply with a
"default" database or offer some means to walk the portion of the
tree delegated to the DDT XFR server?
Wiley Expires September 13, 2012 [Page 12]
Internet-Draft LISP DDT Database Transfer March 2012
Author's Address
Glen Wiley (editor)
Verisign, Inc.
12061 Bluemont Way
Reston, Va 20190
USA
Phone:
Email: gwiley@verisign.com
Wiley Expires September 13, 2012 [Page 13]
