idnits 2.17.1
draft-lear-lisp-nerd-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1166.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1177.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1184.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1190.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 4 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 12, 2007) is 6164 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Outdated reference: A later version (-12) exists of
draft-farinacci-lisp-00
** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141)
-- Obsolete informational reference (is this intentional?): RFC 4346 (ref.
'6') (Obsoleted by RFC 5246)
-- Obsolete informational reference (is this intentional?): RFC 977 (ref.
'11') (Obsoleted by RFC 3977)
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Lear
3 Internet-Draft Cisco Systems GmbH
4 Intended status: Experimental June 12, 2007
5 Expires: December 14, 2007
7 NERD: A Not-so-novel EID to RLOC Database
8 draft-lear-lisp-nerd-01.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on December 14, 2007.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 LISP is a protocol to encapsulate IP packets in order to allow end
42 sites to multihome without injecting routes from one end of the
43 Internet to another. This memo specifies a database and a method to
44 transport the mapping of EIDs to RLOCs to routers in a reliable,
45 scalable, and secure manner. Our analysis concludes that transport
46 of of all EID/RLOC mappings scales well to at least 10^7 entries, and
47 that use of DNS or any approach that queries for mappings has
48 substantial operational concerns.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.1. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 3
54 1.2. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 4
55 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 5
56 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
57 2.1. Who are database authorities? . . . . . . . . . . . . . . 6
58 3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 7
59 3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 9
60 3.2. Database Update Format . . . . . . . . . . . . . . . . . . 9
61 4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 10
62 4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 10
63 4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 10
64 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
65 5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 12
66 5.2. Router Throughput Versus Time . . . . . . . . . . . . . . 13
67 5.3. Number of Servers Required . . . . . . . . . . . . . . . . 13
68 5.4. Security Considerations . . . . . . . . . . . . . . . . . 15
69 5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 16
70 6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 18
71 7. Other Distribution Mechanisms . . . . . . . . . . . . . . . . 19
72 7.1. What About DNS as a retrieval model? . . . . . . . . . . . 20
73 7.1.1. Perhaps use a hybrid model? . . . . . . . . . . . . . 21
74 7.2. Use of BGP . . . . . . . . . . . . . . . . . . . . . . . . 21
75 8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 22
76 8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
77 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
82 12.2. Informational References . . . . . . . . . . . . . . . . . 24
83 Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 25
84 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
85 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 25
86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
87 Intellectual Property and Copyright Statements . . . . . . . . . . 27
89 1. Introduction
91 Locator/ID Separation Protocol (LISP) [1] is a protocol whose primary
92 purpose is to separate an ID used by a host and local routing system
93 from the locators advertised by BGP participants on the Internet in
94 general, and the the default free zone (DFZ) in particular. It
95 accomplishes this by establishing a mapping between globally unique
96 endpoint identifiers (EIDs) and routing locators (RLOCs) within the
97 global routing table. This reduces the amount of state change that
98 occurs on routers within the default-free zone on the Internet, while
99 enabling end sites to be multihomed.
101 In early stages of LISP (1 and 1.5) the mapping is either configured
102 into a device or it is learned via control messages between ingress
103 tunnel routers (ITRs) and egress tunnel routers (ETRs) under the
104 assumption that during transition, EIDs will be present within the
105 global routing system, as they are today.
107 In later stages of LISP, the assumption will be that EIDs are not
108 contained within the global routing system, but that instead the
109 mapping from EIDs to RLOCs will be learned through some other means.
110 This memo addresses different approaches to the problem, and
111 specifies a Not-so-novel EID RLOC Database (NERD) and methods to both
112 receive the database and to receive updates.
114 LISP and NERD are both currently experimental stages. The NERD
115 database is specified in such a way that the methods used to
116 distribute or retrieve it may vary over time. Multiple databases are
117 supported in order to allow for multiple data sources. An effort has
118 been made to divorce the database from access methods so that both
119 can evolve independently through experimentation and operational
120 validation.
122 1.1. Base Assumptions
124 In order to specify a mapping it is important to understand how it
125 will be used, and the nature of the data being mapped. In the case
126 of LISP, the following assumptions are pertinant:
128 o The data contained within the mapping changes only on provisioning
129 or configuration operations, and is not intended to change when a
130 link either fails or is restored. Some other mechanism (via LISP
131 or other) handles healing operations, particularly when a tail
132 circuit within an service provider's aggregate goes down.
133 o While weight and priority are defined, these are not hop-by-hop
134 metrics. Hence the information contained within the mapping does
135 not change based on where one sits within the topology.
137 o The purpose of LISP being to reduce control plane overhead by
138 reducing rate X state, updates to the mapping will be relatively
139 rare.
140 o Because LISP and NERD are designed to ease interdomain routing,
141 their use is intended within the inter-domain environment. That
142 is, LISP is best implemented at either the customer edge or
143 provider edge, and there will be on the order of as many ITRs and
144 LISP announcements as there are connections to Internet Service
145 Providers by end customers.
146 o As such, LISP and NERD cannot be the sole means to implement host
147 mobility, although they may be in used in conjunction with other
148 mechanisms. For instance, it would be possible for a mobile node
149 to receive a local address that is an EID and pass that to the
150 correspondant node, who could also make use of an EID. As such
151 use of LISP in this case would be transparent, and no mapping
152 entries are changed for mobility.
153 o As such, there is no interaction with the interior gateway
154 protocol (IGP).
156 1.2. What is NERD?
158 NERD is a Not-so-novel EID to RLOC Database. It consists of the
159 following components:
161 1. a network database format;
162 2. a change distribution format;
163 3. a database retrieval/bootstrapping method;
164 4. a change distribution method.
166 The network database format is compressable. However, at this time
167 we specify no compression method. NERD will make use of potentially
168 several transport methods, but most notably HTTP [2]. HTTP has
169 restart and compression capabilities. It is also widely deployed.
171 There exist many methods to show differences between two versions of
172 a database or a file, UNIX's "diff" being the classic example. In
173 this case, because the data is well structured and easily keyed, we
174 can make use of a very simple format for version differences that
175 simply provides a list of EID/RLOC mappings that have changed using
176 the same record format as the database, and a list of EIDs that are
177 to be removed.
179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
181 document are to be interpreted as described in RFC 2119 [3].
183 1.3. Glossary
185 The reader is once again referred to [1] for a general glossary of
186 terms related to LISP. The following terms are specific to this
187 memo.
189 Base Distribution URI: An Absolute-URI as defined in Section 4.3 of
190 [4] from which other references are relative. The base
191 distribution URI is used to construct a URI to an EID/RLOC mapping
192 database. If more than one NERD is known then there will be one
193 or more base distribution URIs associated with each (although each
194 such base distribution URI may have the same value).
196 EID Database Authority: The authority that will sign database files
197 and updates. It is the source of both.
199 The Authority: Shorthand for the EID Database Authority.
201 NERD: (N)ot-so-novel (E)ID to (R)LOC (D)atabase.
203 Pull Model: An architecture where clients pull only the information
204 they need at any given time, such as when a packet arrives for
205 forwarding.
207 Push Model: An architecture in which clients receive an entire
208 dataset, containing data they may or may not require, such as
209 mappings for EIDs that no host served is attempting to send to.
211 Hybrid Model: An architecture in which clients receive a subset of
212 the entire dataset and query as needed for the rest.
214 2. Theory of Operation
216 What follows is a summary of how NERDs are generated and updated.
217 Specifics can be found in Section 3. The general way in which NERD
218 works is as follows:
220 1. A NERD is generated by an authority that allocates provider
221 independent (PI) addresses (e.g., IANA or an RIR). As part of
222 this process the authority generates a digest for the database
223 and signs it with a private key whose public key is part of an
224 X.509 certificate. [10] That signature along with a copy of the
225 authority's public key is included in the NERD.
227 2. The NERD is distributed to a group of well known servers.
228 3. ITRs retrieve an initial copy of the NERD via HTTP when they come
229 into service.
230 4. ITRs next verify both the validity of the public key and the
231 signed digest. If either fail validation, the ITR attempts to
232 retrieve the NERD from a different source. The process iterates
233 until either a valid database is found or the list of sources is
234 exhausted.
235 5. Once a valid NERD is retrieved, the ITR installs it into both
236 non-volatile and local memory.
237 6. At some point the authority updates the NERD and increments the
238 database version counter. At the same time it generates a list
239 of changes, which it also signs, as it does with the original
240 database.
241 7. Periodically ITRs will poll from their list of servers to
242 determine if a new version of the database exists. When a new
243 version is found, an ITR will attempt to retrieve a change file,
244 using its list of preconfigured servers.
245 8. The ITR validates a change file just as it does the original
246 database. Assuming the change file passes validation, the ITR
247 installs new entries, overwrites existing ones, and removes empty
248 entries, based on the content of the change file.
250 As time goes on it is quite possible that an ITR may probe a list of
251 configured neighbors for a database or change file copy. It is
252 equally possible that neighbors might advertise to each other the
253 version number of their database. Such methods are not explored in
254 detph in this memo, but are mentioned for future consideration.
256 2.1. Who are database authorities?
258 This memo does not specify who the database authority is. That is
259 because there are several possible operational models. In each case
260 the number of database authorities is meant to be small so that ITRs
261 need only keep a small list of authorities, similar to the way a name
262 server might cache a list of root servers.
264 o A single database authority exists. In this case all entries in
265 the database are registered to a single entity, and that entity
266 distributes the database. Because the EID space is provider
267 independent address space, there is no architectural requirement
268 that address space be hierarchically distributed to anyone, as
269 there is with provider-assigned address space. Hence, there is a
270 natural affinity between the IANA function and the database
271 authority function.
272 o Each region runs a database authority. In this case, provider
273 independent address space is allocated to either regional internet
274 registries or to affiliates of such organizations of network
275 operations guilds (NOGs). The benefit of this approach is that
276 there is no single organization that controls the database. It
277 allows one database authority to backup another. One could
278 envision as many as ten database authorities in this scenario.
279 o Each country runs a database authority. This could occur should
280 countries decide to regulate this function. While limiting the
281 scope of any single database authority as the previous scenario
282 describes, this approach would introduce some overhead as the list
283 of database authorities would grow to as many as 200, and possibly
284 more if jurisdictions within countries attempted to regulate the
285 function.
287 As the number of authorities increases the amount of change on that
288 list will also increase, requiring both an update mechanism and the
289 potential need for a discovery mechanism, both of which would be the
290 subject of future work (i.e., not to be found in this memo). For
291 this reason alone, as a starting point two database authorities are
292 recommended, but their selection is left for others.
294 3. NERD Format
296 The NERD consists of a header that contains a database version and a
297 signature that is generated by ignoring the signature field and
298 setting the authentication block length to 0 (NULL). The
299 authentication block itself consists of a signature and a certificate
300 whose private key counterpart was used to generate the signature.
301 The exact format of the authentication block is TBD.
303 Records are kept sorted in numeric order with AFI plus EID as primary
304 key and mask length as secondary. This is so that after a database
305 update it should be possible to reconstruct the database to verify
306 the digest signature, which may be retrieved separately from the
307 database for verification purposes.
309 0 1 2 3
310 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
311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
312 | Schema Vers=1 | DB Code | Database Name Size |
313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
314 | Database Version |
315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316 | Old Database Version or 0 |
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318 | Authentication Block Size | Reserved=0 |
319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
320 | |
321 | Database Name |
322 | |
323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
324 | |
325 | Authentication Block |
326 | |
327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
329 Database Header
331 The DB Code indicates 0 if what follows is an entire database or 1 if
332 what follows is an update. The database file version is incremented
333 each time the complete database is generated by the authority. In
334 the case of an update, the database file version indicates the new
335 database file version, and the old database file version is indicated
336 in the "old DB version" field. The database file version is used by
337 routers to determine whether or not they have the most current
338 database.
340 The database name is a Universal Resource Name (URN) [5] of the
341 following form:
343 dburn = "urn:lisp:3.0:" dbname
344 dbname = 1*(URN Chars) ;; URN Chars is defined in RFC 2141.
346 The purpose of the database name is to allow for more than one
347 database. Such databases would be merged by the router. It is
348 important that an EID/RLOC mapping be listed in no more than one
349 database, lest inconsistencies arise.
351 3.1. NERD Record Format
353 As distributed over the network, NERD records appear as follows:
355 0 1 2 3
356 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
357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
358 | Number of RLOCs | EID Mask Len.| EID AFI |
359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
360 | End point identifier |
361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
362 | Priority 1 | Weight 1 | AFI 1 | Reserved = 0 |
363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
364 | Routing Locator 1 |
365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
366 | Priority 2 | Weight 2 | AFI 2 | Reserved = 0 |
367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
368 | Routing Locator 2 |
369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
370 | Priority 3 | Weight 3 | AFI 3 | Reserved = 0 |
371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
372 | Routing Locator 3... |
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 Priority N and Weight N, and AFI N are associated with Routing
376 Locator N. There will always be at least one routing locator. The
377 minimum record size for IPv4 is 16 bytes. Each additional IPv4 RLOC
378 increases the record size by 8 bytes. The purpose of this format is
379 to keep the database compact, but somewhat easily read. The meaning
380 of weight and priority are described in [1]. The format of the AFI
381 is TBD.
383 3.2. Database Update Format
385 A database update contains a set of changes to an existing database.
386 Each AFI/EID/mask-length tuple may have zero or more RLOCs associated
387 with it. In the case where there are no RLOCs, the EID entry is
388 removed from the database. Records that contain EIDs and mask
389 lengths that were not previously listed are simply added. Otherwise,
390 the old record for the EID and mask length is replaced by the more
391 current information. The record format used by the a database update
392 is the same as described in Section 3.1.
394 4. NERD Distribution Mechanism
396 4.1. Initial Bootstrap
398 Bootstrap occurs when a router needs to retrieve the entire database.
399 It knows it needs to retrieve the entire database because either it
400 has none or an update too substantial to process, as might be the
401 case if a router has been out of service for a substantially lengthy
402 period of time.
404 To bootstrap the router appends the database name plus "/current/
405 entiredb" to a Base Distribution URI and retrieves the file via HTTP.
406 For example, if the configured URI is
407 "http://www.example.com/eiddb/", and assuming a database name of
408 "arin", the router would request
409 "http://www.example.com/eiddb/current/arin/entiredb". Routers MUST
410 check the signature on the database prior to installing it, and MUST
411 check that the database schema matches a schema they understand.
413 N.B., the host component for such URIs MUST NOT resolve to a LISP
414 EID, lest a circular dependency be created.
416 4.2. Retrieving Changes
418 In order to retrieve a set of database changes a router will have
419 previously retrieved the entire database. Hence it knows the current
420 version of the database it has. Its first step for retrieving
421 changes is to retrieve the current version of the database. It does
422 so by appending "current/version" to the base distribution URI and
423 retrieving the file. Its format is text and it contains the integer
424 value of the current database version.
426 Once a router has retrieved the current version it compares version
427 of its local copy. If there is no difference, then the router is up
428 to date and need take no further actions until it next checks.
430 If the versions differ, the router next sends a request for the
431 appropriate change file by appending "current/changes/" and the
432 textual representation of the version of its local copy of the
433 database to the base distribution URI. For example, if the current
434 version of the database is 1105503 and router's version is 1105500,
435 and the base URI and database name are the same as above, the router
436 would request
437 "http://www.example.com/eiddb/arin/current/changes/1105500".
439 The server may not have that change file, either because there are
440 too many versions between what the router has and what is current, or
441 because no such change file was generated. If the server has changes
442 from the routers version to any later version, the server SHOULD
443 issue an HTTP redirect to that change file, and the router SHOULD
444 retrieve and process it. Once it has done so, the router should then
445 repeat the process until it has brought itself up to date. It is
446 thus important for servers to expire old change files in the order in
447 which they were generated.
449 By way of convention, it is suggested that the URIs issued in
450 redirects be of the following form:
452 {base dist. URI}/{dbname}/{more-recent-version}/changes/
453 {older-version}
455 where "base dist. URI" is the base distribution URI, "dbname" is the
456 name of the database, and each version is the textual representation
457 of the integer version value.
459 For example, if the current database version was 1105503 and a router
460 made a request for
461 "http://www.example.com/eiddb/arin/current/changes/1105400" but there
462 was no change file from 1105400 to 1105503, and the server had a
463 group of change files to make the router current, it would issue a
464 redirect to
465 "http://www.example.com/eiddb/arin/110450/changes/1105400" that the
466 router would then process. The router would then make a request for
467 "http://www.example.com/eiddb/arin/current/changes/110450" that the
468 server would have.
470 While it is unlikely that database versions would wrap, as they
471 consists of 32 bit integers, should the event occur, ITRs MUST
472 attempt first to retrieve a change file when their current version
473 number is within 10,000 of 2^32 and they see a version available that
474 is less than 10,000. Barring the availability of a change file, the
475 ITR MUST still assume that the database version has wrapped and
476 retrieve a new copy.
478 5. Analysis
480 We will start our analysis by looking at how much data will be
481 transferred to a router during bootstrap conditions. We will then
482 look at the bandwidth required. Next we will turn our concerns to
483 servers. Finally we will ponder the effect of providing only
484 changes.
486 In the analysis below we treat the overhead of the database header as
487 insignificant (because it is). The analysis should be similar,
488 whether a single database or multiple databases are employed, as we
489 would assume that no entry would appear more than once.
491 5.1. Database Size
493 By its very nature the information to be transported is relatively
494 static and is specifically designed to be topologically insensitive.
495 That is, every ITR is intended to have the same set of RLOCs for a
496 given EID. While some processing power will be necessary to install
497 a table, the amount required should be far less than that of a
498 routing information database because the level of entropy is intended
499 to be lower.
501 Section 3.1 states that mapping information for each EID/Prefix
502 includes a group of RLOCs, each with an associated priority and
503 weight, and that a minimum record size with IPv4 EIDs with at least
504 one RLOC is 16 bytes uncompressed. Each additional IPv4 RLOC costs 8
505 bytes. for the same EID/Prefix requires an additional 10 bytes.
507 +-----------+-------------+-------------+-------------+
508 | 10^n EIDs | 2 RLOC | 4 RLOC | 8 RLOC |
509 +-----------+-------------+-------------+-------------+
510 | 3 | 24,000 | 40,000 | 72,000 |
511 | 4 | 240,000 | 400,000 | 720,000 |
512 | 5 | 2,400,000 | 4,000,000 | 7,200,000 |
513 | 6 | 24,000,000 | 40,000,000 | 72,000,000 |
514 | 7 | 240,000,000 | 400,000,000 | 720,000,000 |
515 | 8 | 2.4GB | 4.0GB | 7.2GB |
516 +-----------+-------------+-------------+-------------+
518 Potential sizes of the NERD in bytes
520 Table 1
522 Entries in the above table are derived as follows:
524 E * (16 + 8 * (R -1 ))
526 where E = number of EIDs (10^n), R = number of RLOCs per EID. 16
527 bytes gets you the first RLOC.
529 Our scaling target is to accommodate 10^7 multihomed systems, as
530 discussed in [8]. At 10^7 entries, a device could be expected to use
531 between 240 and 720 megabytes of RAM for the mapping. At 10^8 we are
532 storing gigabytes of data. No matter the method of distribution, any
533 router that sits in the core of the Internet would require near this
534 amount of memory in order to perform the ITR function. Large
535 enterprise ETRs would be similarly strained, simply due to the
536 diversity of of sites that communicate with one another. The good
537 news is that this is not our starting point, but rather our scaling
538 target, a number that we intend to reach by the year 2050. Our
539 starting point is more likely in the neighborhood of 10^4 or 10^5
540 EIDs, thus requiring between 240KB and 7.2 MB.
542 5.2. Router Throughput Versus Time
544 +-------------------+---------+--------+---------+-------+
545 | Table Size (10^N) | 1mb/s | 10mb/s | 100mb/s | 1gb/s |
546 +-------------------+---------+--------+---------+-------+
547 | 6 | 8 | 0.8 | 0.08 | 0.008 |
548 | 7 | 80 | 8 | 0.8 | 0.08 |
549 | 8 | 800 | 80 | 8 | 0.8 |
550 | 9 | 8,000 | 800 | 80 | 8 |
551 | 10 | 80,000 | 8,000 | 800 | 80 |
552 | 11 | 800,000 | 80,000 | 8,000 | 800 |
553 +-------------------+---------+--------+---------+-------+
555 Number of seconds to process NERD
557 Table 2
559 The length of time it takes to process the database is significant in
560 models where the device acquires the entire table. During this
561 period of time, either the router will be unable to route packets
562 using LISP or it must use some sort of query mechanism for specific
563 EIDs as the rest it populates its table through the transfer.
564 Table 2 shows us that at our scaling target, the length of time it
565 would take for a router using 1 mb/s of bandwidth is about 80
566 seconds. We can measure the processing rate in small numbers of
567 hours for any transfer speed greater than that. The fastest
568 processing time shows us as taking 8 seconds to process an entire
569 table of 10^9 bytes and 80 for 10^10 bytes.
571 5.3. Number of Servers Required
573 As easy as it may be for a router to retrieve, the aggregate
574 information may be difficult for servers to transmit, assuming the
575 information is transmitted in aggregate (we'll revisit that
576 assumption later).
578 +-----------------+-----------+-----------+------------+------------+
579 | # Simultaneous | 10 | 100 | 1,000 | 10,000 |
580 | Requests | Servers | Servers | Servers | Servers |
581 +-----------------+-----------+-----------+------------+------------+
582 | 100 | 57.6 | 5.76 | 5.76 | 5.76 |
583 | 1,000 | 576 | 57.6 | 5.76 | 5.76 |
584 | 10,000 | 5,760 | 576 | 57.6 | 5.76 |
585 | 100,000 | 57,600 | 5,760 | 576 | 57.6 |
586 | 1,000,000 | 576,000 | 57,600 | 5,760 | 576 |
587 | 10,000,000 | 5,760,000 | 576,000 | 57,600 | 5,760 |
588 +-----------------+-----------+-----------+------------+------------+
590 Retrieval time per number of servers in seconds. Assumes average 8
591 RLOCs per EID and that each server has access to 1gb/s and 100%
592 efficient use of that bandwidth and no compression.
594 Table 3
596 Entries in the above table were generated using the following method:
598 For 10^7 entries with eight RLOCs per EID, the table size is 720MB,
599 per our previous table, or 5.76Gb. Assume 1 Gb/s transfer rates and
600 100% utilization. (Protocol overhead is ignored for the time being.)
601 Hence a single transfer X takes 5.76 seconds and can get no faster.
603 With this in mind, each entry is as follows:
605 max(1X,N*X/S)
607 where N=number of transfers, X = 5.76, S = number of servers.
609 If we have a distribution model which every device must retrieve the
610 mapping information upon start, Table 3 shows the length of time in
611 seconds it will take for a given number of servers to complete a
612 transfer to a given number of devices. Put simply, ten thousand well
613 distributed servers could handle ten million requests for the entire
614 database in about an hour and a half. This would be absolute cold
615 start environment with no routers having prior versions of the
616 database stored. As we will see, the number improves markedly when
617 we exchange only changes.
619 +------------+-----------+------------+--------------+--------------+
620 | % Daily | 10 | 100 | 1,000 | 10,000 |
621 | Change | Servers | Servers | Servers | Servers |
622 +------------+-----------+------------+--------------+--------------+
623 | 0.1% | 240 | 24 | 2.4 | 0.24 |
624 | 0.5% | 1,200 | 120 | 12 | 1.2 |
625 | 1% | 2,400 | 240 | 24 | 2.4 |
626 | 5% | 12,000 | 1,200 | 120 | 12 |
627 | 10% | 24,000 | 2,400 | 240 | 24 |
628 +------------+-----------+------------+--------------+--------------+
630 Table 4
632 This table shows us that with 10,000 servers the average transfer
633 time with 1Gb/s links for 10,000,000 routers will be 24 seconds with
634 10% daily change spread over 24 hourly updates. For a 0.1% daily
635 change, that number is 0.24 seconds for a database of size 720MB.
637 The amount of change goes to the purpose of LISP. If its purpose is
638 to provide effective multihoming support to end customers, then we
639 might anticipate relatively random changes. If, on the other,
640 service providers attempt to make use of LISP to provide some form of
641 traffic engineering, we can expect the same data to change more
642 often. We can probably not conclude much in this regard without
643 additional operational experience. The one thing we can conclude is
644 that different applications of the LISP protocol may require new and
645 different distribution mechanisms. Such optimization is left for
646 another day.
648 5.4. Security Considerations
650 Whichever the answer to our previous question, we must consider the
651 security of the information being transported. If an attacker can
652 forge an update or tamper with the database, he can in effect
653 redirect traffic to end sites. Hence, integrity and authenticity of
654 the NERD is critical. In addition, a means is required to determine
655 whether a source is authorized to modify a given database. No data
656 privacy is required. Quite to the contrary, this information will be
657 necessary for any ITR.
659 The first question one must ask is who to trust to provide the ITR a
660 mapping. Ultimately the owner of the EID prefix is most
661 authoritative for the mapping to RLOCs. However, were all owners to
662 sign all such mappings, ITRs would need to know which owner is
663 authorized to modify which mapping, creating a problem of O(N^2)
664 complexity.
666 We can reduce this problem substantially by investing some trust in a
667 small number of entities that are allowed to sign entries. If
668 authority manages EIDs much the same way a domain name registrar
669 handles domains, then the owner of the EID would choose a database
670 authority she or he trusts, and ITRs must trust each such authority
671 in order to map the EIDs listed by that authority to RLOCs. This
672 reduces the amount of management complexity on the ETR to retaining
673 knowledge of O(#authorities), but does require that each authority
674 establish procedures for authenticating the owner of an EID. Those
675 procedures needn't be the same.
677 There are two classic methods to ensure integrity of data:
679 o secure transport of the source of the data to the consumer, such
680 as Transport Layer Security (TLS) [6]; and
681 o provide object level security.
683 These methods are not mutually exclusive, although one can argue
684 about the need for the former, given the latter.
686 In the case of TLS, when it is properly implemented, the objects
687 being transported cannot easily be modified by interlopers or so-
688 called men in the middle. When data objects are distributed to
689 multiple servers, each of those servers must be trusted. As we have
690 seen above, we could have quite a large number of servers, thus
691 providing an attacker a large number of targets. We conclude that
692 some form of object level security is required.
694 Object level security involves an authority signing an object in a
695 way that can easily be verified by a consumer, in this case a router.
696 In this case, we would want the mapping table and any incremental
697 update to be signed by the originator of the update. This implies
698 that we cannot simply make use of a tool like CVS [9]. Instead, the
699 originator will want to generate diffs, sign them, and make them
700 available either directly or through some sort of content
701 distribution or peer to peer network.
703 5.4.1. Use of Public Key Infrastructures (PKIs)
705 X.509 provides a certificate hierarchy that has scaled to the size of
706 the Internet. The system is particularly manageable when there are
707 fewer certificates to manage. The model proposed in this memo makes
708 use of one current certificate per database authority. The three
709 pieces of information necessary to verify a signature, therefore, are
710 as follows:
712 o the certificate of the database authority, which can be provided
713 along with the database;
715 o the certificate authority's certificate; and
716 o A table of database names and distinguished names (DNs) that are
717 allowed to update them.
719 The latter two pieces of information must be very well known and must
720 be configured on each ITR. It is expected that both would change
721 very rarely, and it would not be unreasonable for such updates to
722 occur as part of a normal OS release process.
724 The tools for both signing and verifying are readily available.
725 Openssl [18] provides tools and libraries for both signing and
726 verifying. Other tools commonly exist.
728 Use of PKIs is not without implementation, operational complexity or
729 risk. The following risks and mitigations are identified with NERD's
730 use of PKIs:
732 NERD database authority private key is exposed:
734 In this case an attacker could sign a false database update,
735 either redirecting traffic, or otherwise causing havoc. In this
736 case, the NERD database administrator must revoke its existing key
737 and issue a new one. The certificate is added to a certificate
738 revocation list (CRL), which may be distributed with both this and
739 other databases, as well as through other channels. Because this
740 event is expected to be rare, and the number of database
741 authorities is expected to be small, a CRL will be small. When a
742 router receives a revocation, it checks it against its existing
743 databases, and attempts to update the one that is revoked. This
744 implies that prior to issuing the revocation, the database
745 authority MUST sign an update with the new key. Routers SHOULD
746 discard updates they have already received that were signed after
747 the revocation was generated. If a router cannot confirm that
748 whether the authority's certificate was revoked before or after a
749 particular update, it SHOULD retrieve a fresh new copy of the
750 database with a valid signature.
752 The private key associated with the CA that signed the Authority's
753 certificate is compromised:
755 In this case, it becomes possible for an attacker to masquerade as
756 the database authority. To ameliorate damage, the database
757 authority SHOULD revoke its certificate and get a new certificate
758 issued from a CA that is not compromised. Once it has done so,
759 the previous procedure is followed. The compromised certificate
760 can be removed during the normal operating system upgrade cycle.
762 An algorithm used in either the certificate or the signature is
763 cracked:
765 This is a catastrophic failure and the above forms of attack
766 become possible. The only mitigation is to make use of a new
767 algorithm. In theory this should be possible, but in practice has
768 proven very difficult. For this reason, additional work is
769 recommended to make alternative algorithms available.
771 The Database Authority loses its key or disappears:
773 In this case nobody can update the existing database. There are
774 few programmatic mitigations. If the database authority places
775 its private keys and suitable amounts of information escrow, under
776 agreed upon circumstances, such as no updates for three days, for
777 example, the escrow agent would release the information to a party
778 competent of generating a database update.
780 6. Why not use XML?
782 Many objects these days are distributed as either XML pages or
783 something derived as XML [15], such as SOAP [16],[17]. Use of such
784 well known standards allows for high level tools and library reuse.
785 Why not, then, use these standards in this case? There are two
786 answers to this question. First, the obvious concern is that XML is
787 not known for efficiency of data transport. Being based in text, an
788 IPv4 address is expanded from one octet to three octets, plus either
789 an attribute and quotes or element tags and end tags. Let us presume
790 for the moment a very simple schema that might cause a record to be
791 represented as follows:
793
794
795
796 192.168.1.1
797
798
799
800
801 192.168.1.2
802
803
804
806 With white space removed the uncompressed XML represents 120 bytes
807 versus 20 bytes for the record specified in Section 3.1, representing
808 a five fold expansion. That brings our 920MB database to 4.6GB.
810 The other concern about XML is that version 1.0 of the specification
811 is silent on the order of sibling elements. Specifications other
812 than the base specification state that order is significant. Order
813 is significant to LISP and NERD because once an update is applied to
814 the database it should be possible to verify the signature of the
815 entire database. Prior to applying the signature the XML generator
816 would need to ensure the order of information. That same sort would
817 be required of the router. This seems to add unnecessary fragility
818 to a critical system without much benefit. While there may indeed be
819 uses of an XML representation of the database, these uses are likely
820 to be outside of a router.
822 7. Other Distribution Mechanisms
824 We now consider various different mechanisms. The problem of
825 distributing changes in various databases is as old as databases.
826 The author is aware of two obvious approaches that have been well
827 used in the past. One approach would be the wide distribution of CVS
828 repositories. However, for reasons mentioned in the previous
829 section, CVS is insufficient to the task.
831 The other tried and true approach is the use of periodic updates in
832 the form of messages. Good old NNTP [11] itself provides two
833 separate mechanisms (one push and another pull) to provide a coherent
834 update process. This was in fact used to update molecular biology
835 databases [12] in the early 1990s. Netnews offers a way to determine
836 whether articles with specified Article-Ids have been received. In
837 the case where the mapping file source of authority wishes to
838 transmit updates, it can sign a change file and then post it into the
839 network. Routers merely need to keep a record of article ids that it
840 has received. Initially this is probably overkill, but it may not be
841 so later in this process. Some consideration should be given to a
842 mechanism known to widely distribute vast amounts of data, as
843 instantaneously either the sender or the receiver wishes.
845 To attain an additional level of hierarchy in the distribution
846 network, service providers could retrieve information to their own
847 local servers, and configure their routers with the host portion of
848 the above URI.
850 Another possibility would be for providers to establish an agreement
851 on a small set of anycast addresses for use for this purpose. There
852 are limitations to the use of anycast, particularly with TCP. In the
853 midst of a routing flap anycast address can become all but unusable.
854 Careful study of such a use as well as appropriate use of HTTP
855 redirects is expected.
857 7.1. What About DNS as a retrieval model?
859 It has been proposed that a query/response mechanism be used for this
860 information, and that specifically the domain name system (DNS) [14]
861 be used. The previous models do not preclude the DNS. DNS has the
862 advantage that the administrative lines are well drawn, and that the
863 ID/RLOC mapping is likely to appear very close to these boundaries.
864 DNS also has the added benefit that an entire distribution
865 infrastructure already exists. There are, however, some problems
866 that could impact end hosts when intermediate routers make queries,
867 some of which were first pointed out in [13]:
869 o Any query mechanism offers an opportunity for a resource attack if
870 an attacker can force the ITR to query for information. In this
871 case, all that would be necessary would be for a "botnet" (a group
872 of computers that have been compromised and used as vehicles to
873 attack others) to ping or otherwise contact via some normal
874 service hosts that sit behind the ETR. If the botnet hosts
875 themselves are behind ETRs, the victim's ITR will need to query
876 for each and every one of them, thus becoming part of a classic
877 reflector attack.
878 o Packets will be delayed at the very least, and probably dropped in
879 the process of a mapping query. This could be at the beginning of
880 a communication, but it will be impossible for a router to
881 conclude with certainty that this is the case.
882 o The DNS has a backoff algorithm that presumes that applications
883 are making queries prior to the beginning of a communication.
884 This is appropriate for end hosts who know in fact when a
885 communication begins. An end user may not enjoy a router waiting
886 seconds for a retry.
887 o While the administrative lines may appear to be correct, the
888 location of name servers may not be. If name servers sit within
889 PI address space, thus requiring LISP to reach, a circular
890 dependency is created. This is precisely where many enterprise
891 name servers sit. The LISP experiment should not predicate its
892 success on relocation of such name servers.
894 Never-the-less, DNS may be able to play a role in providing the
895 enterprise control over the mapping of its EIDs to RLOCs. Posit a
896 new DNS record "EID2RLOC". This record is used by the authority to
897 collect and aggregate mapping information so that it may be
898 distributed through one of the other mechanisms. As an example:
900 $ORIGIN 0.10.PI-SPACE.
901 128 EID2RLOC mask 23 priority 10 weight 5 172.16.5.60
902 EID2RLOC mask 23 priority 15 weight 5 192.168.1.5
904 In the above figure network 10.0.128/23 would delegated to some end
905 system, say EXAMPLE.COM. They would manage the above zone
906 information. This would allow a DNS mechanism to work, but it would
907 also allow someone to aggregate the information and distribution a
908 table.
910 7.1.1. Perhaps use a hybrid model?
912 It would be possible to use both a prepopulated database such as NERD
913 and query mechanism (perhaps DNS) to determine an EID/RLOC mapping.
914 The general idea would be to receive a subset of the mappings, say,
915 by taking only the NERD for certain regions. This alleviates the
916 need to drop packets for some subset of destinations under the
917 assumption that one's business is localized to a particular region.
918 If one did not have a local entry for a particular EID one would then
919 make a query.
921 One improvement on simply using DNS to query live would be to
922 periodically walk the entire network, in search of EID2RLOC records,
923 and caching them to non-volatile storage. This has two benefits.
924 First, it prevents resource attacks. Care has to be given to how
925 memory is cached it avoid an attacker causing a performance
926 degradation by attempting to exceed memory limits through a random
927 source attack.
929 As important as resisting attacks, having a complete or near complete
930 copy of the database provides for a faster recovery time when a
931 router goes out of service, for whatever reason. Absent such a
932 mechanism, devices would need to repopulate their local caches
933 through the help of another system, leading to additional system
934 fragility.
936 7.2. Use of BGP
938 Border Gateway Protocol (BGP) [7] is currently used to distribute
939 inter-domain routing throughout the Internet. Why not, then, use BGP
940 to distribute the mapping table? A simple answer is that the objects
941 BGP best handles are routes. While it may be possible to transmit
942 EID/RLOC mappings instead (because they look an awful lot like
943 routes) the rate of updates of EID/RLOC mappings is specifically
944 intended to be considerably less than routes, and would probably
945 require additional dampening mechanisms to ensure that this is so.
947 In addition, the ownership of the mapping does not flow from service
948 providers but rather from end users of the identifiers. It should
949 not be possible for anyone to filter the mapping, other than perhaps
950 ITRs for local policy purposes. The current limited security model
951 for BGP does not fit the general requirements of how the mapping is
952 to be processed.
954 Furthermore, as BGP is currently the lifeblood of the Internet its
955 use for any means other than routing should be strongly scrutinized.
957 This is not to say that BGP has no role to play whatsoever. It may
958 well be possible for routers to exchange database version numbers and
959 perhaps base distribution URIs as extensions or capabilities. This
960 would allow routers to serve their copy of the database to their
961 neighbors, easing the load off the rest of the server infrastructure.
962 How this would be done is future work.
964 8. Deployment Issues
966 While LISP and NERD are intended as experiments at this point, it is
967 already obvious one must give serious consideration to circular
968 dependencies with regard to the protocols used and the elements
969 within them.
971 8.1. HTTP
973 In Section 7.1 we have already seen how DNS can have circular
974 dependencies. In as much as HTTP depends on DNS, either due to the
975 authority section of a URI, or due to the configured base
976 distribution URI, these same concerns apply. In addition, any HTTP
977 server that itself makes use of provider independent addresses would
978 be a poor choice to distribute the database for these exact same
979 reasons.
981 One issue with using HTTP is that it is possible that a middlebox of
982 some form, such as a cache, may intercept and process requests. In
983 some cases this might be a good thing. For instance, if a cache
984 correctly returns a database, some amount of bandwidth is conserved.
985 On the other hand, if the cache itself fails to function properly for
986 whatever reason, end to end connectivity could be impaired. For
987 example, if the cache itself depended on the mapping being in place
988 and functional, a cold start scenario might leave the cache
989 functioning improperly, in turn providing routers no means to update
990 their databases. Some care must be given to avoid such
991 circumstances.
993 9. Conclusions
995 This memo has specified a database format, an update format, a URI
996 convention, an update method, and a validation method for EID/RLOC
997 mappings. We have shown that based on predictions of 10^7 locators,
998 the aggregate database size would be at most 720MB. We have
999 considered the amount of servers to distribute that information and
1000 we have demonstrated the limitations of other well known mechanisms.
1001 This amounts to 24 seconds of processing time per hour at today's
1002 gigabit speeds. We conclude that there is no need for an off box
1003 query mechanism today, and that there are distinct disadvantages for
1004 having such a mechanism in the control plane.
1006 Beyond this we have examined alternatives that allow for hybrid
1007 models that do use query mechanisms, should our operating assumptions
1008 prove overly optimistic. Use of NERD today does not forclose use of
1009 such models in the future, and in fact both models can happily co-
1010 exist.
1012 We leave to future work how the list of databases is distributed, how
1013 BGP can play a role in distributing knowledge of the databases, and
1014 how DNS can play a role in aggregating information into these
1015 databases.
1017 We also leave to future work whether HTTP is the best protocol for
1018 the job, and whether the scheme described in this document is the
1019 most efficient. One could easily envision that when applied in high
1020 delay or high loss environments, a broadcast or multicast method may
1021 prove more effective.
1023 10. IANA Considerations
1025 This memo makes no requests of IANA for any form of registration.
1027 11. Acknowledgments
1029 Dino Farinacci, Patrik Faltstrom, Dave Meyer, Joel Halpern, and
1030 Mohamed Boucadair were very helpful with their reviews of this
1031 document. The astute will notice a lengthy References section. This
1032 work stands on the shoulders of many others' efforts.
1034 12. References
1035 12.1. Normative References
1037 [1] Farinacci, D., "Locator/ID Separation Protocol (LISP)",
1038 draft-farinacci-lisp-00 (work in progress), January 2007.
1040 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1041 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
1042 HTTP/1.1", RFC 2616, June 1999.
1044 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1045 Levels", BCP 14, RFC 2119, March 1997.
1047 [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1048 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
1049 January 2005.
1051 [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
1053 12.2. Informational References
1055 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
1056 Protocol Version 1.1", RFC 4346, April 2006.
1058 [7] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
1059 (BGP-4)", RFC 4271, January 2006.
1061 [8] Carpenter, B., "IETF Plenary Presentation: Routing and
1062 Addressing: Where we are today", March 2007.
1064 [9] Grune, R., Baalbergen, E., Waage, M., Berliner, B., and J.
1065 Polk, "CVS: Concurrent Versions System", November 1985.
1067 [10] International International Telephone and Telegraph
1068 Consultative Committee, "Information Technology - Open Systems
1069 Interconnection - The Directory: Authentication Framework",
1070 CCITT Recommendation X.509, November 1988.
1072 [11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol",
1073 RFC 977, February 1986.
1075 [12] Smith, R., Gottesman, Y., Hobbs, B., Lear, E., Kristofferson,
1076 D., Benton, D., and P. Smith, "A mechanism for maintaining an
1077 up-to-date GenBank database via Usenet", CABIOS , April 1991.
1079 [13] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383,
1080 December 1992.
1082 [14] Mockapetris, P., "Domain names - concepts and facilities",
1083 STD 13, RFC 1034, November 1987.
1085 [15] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
1086 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
1087 October 2000, .
1089 [16] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
1090 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C
1091 Working Draft soap12-part1, June 2002,
1092 .
1094 [17] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
1095 Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", W3C Working
1096 Draft soap12-part2, June 2002,
1097 .
1099 URIs
1101 [18]
1103 Appendix A. To Do
1105 o Specify the authentication block in terms of both the public key
1106 format and the signature.
1108 Appendix B. Changes
1110 This section to be removed prior to publication.
1112 o 01: Massive spelling correction, URI example correction.
1113 o 00: Initial Revision.
1115 Appendix C. Open Questions
1117 This section to be removed prior to publication.
1119 o Should the database contain its name? It is probably sufficient
1120 to merely reference the database by name.
1121 o Should the signature portion be separated from the actual
1122 database? By specifying the signature we hope to reduce
1123 interoperability issues and encourage proper security from the get
1124 go. On the other hand, since the object is opaque it is not clear
1125 how much interoperability we are actually encouraging.
1127 o Should we specify a (perhaps compressed) tarball that treads a
1128 middle ground for the last question, where each update tarball
1129 contains both a signature for the update and for the entire
1130 database, once the update is applied.
1131 o Should we compress? In some initial testing of databases with 1,
1132 5, and 10 million IPv4 EIDs and a random distribution of IPv4
1133 RLOCs, the current format in this document compresses down by a
1134 factor of between 35% and 36%, using Burrows-Wheeler block sorting
1135 text compression algorithm (bzip2). The NERD used random EIDs
1136 with mask lengths varying from 19-29, with probability weighted
1137 toward the smaller masks. This only very roughly reflects
1138 reality. A better test would be to start with the existing
1139 prefixes found in the DFZ.
1141 Author's Address
1143 Eliot Lear
1144 Cisco Systems GmbH
1145 Glatt-com
1146 Glattzentrum, ZH CH-8301
1147 Switzerland
1149 Phone: +41 1 878 7525
1150 Email: lear@cisco.com
1152 Full Copyright Statement
1154 Copyright (C) The IETF Trust (2007).
1156 This document is subject to the rights, licenses and restrictions
1157 contained in BCP 78, and except as set forth therein, the authors
1158 retain all their rights.
1160 This document and the information contained herein are provided on an
1161 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1162 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1163 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1164 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1165 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1166 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1168 Intellectual Property
1170 The IETF takes no position regarding the validity or scope of any
1171 Intellectual Property Rights or other rights that might be claimed to
1172 pertain to the implementation or use of the technology described in
1173 this document or the extent to which any license under such rights
1174 might or might not be available; nor does it represent that it has
1175 made any independent effort to identify any such rights. Information
1176 on the procedures with respect to rights in RFC documents can be
1177 found in BCP 78 and BCP 79.
1179 Copies of IPR disclosures made to the IETF Secretariat and any
1180 assurances of licenses to be made available, or the result of an
1181 attempt made to obtain a general license or permission for the use of
1182 such proprietary rights by implementers or users of this
1183 specification can be obtained from the IETF on-line IPR repository at
1184 http://www.ietf.org/ipr.
1186 The IETF invites any interested party to bring to its attention any
1187 copyrights, patents or patent applications, or other proprietary
1188 rights that may cover technology that may be required to implement
1189 this standard. Please address the information to the IETF at
1190 ietf-ipr@ietf.org.
1192 Acknowledgment
1194 Funding for the RFC Editor function is provided by the IETF
1195 Administrative Support Activity (IASA).