idnits 2.17.1
draft-lear-lisp-nerd-04.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 1174.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1185.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1192.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1198.
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 2 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 (April 11, 2008) is 5859 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Outdated reference: A later version (-12) exists of
draft-farinacci-lisp-06
** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 4346 (ref.
'7') (Obsoleted by RFC 5246)
== Outdated reference: A later version (-05) exists of
draft-fuller-lisp-alt-01
== Outdated reference: A later version (-04) exists of
draft-meyer-lisp-cons-03
Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 April 11, 2008
5 Expires: October 13, 2008
7 NERD: A Not-so-novel EID to RLOC Database
8 draft-lear-lisp-nerd-04.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 October 13, 2008.
35 Abstract
37 LISP is a protocol to encapsulate IP packets in order to allow end
38 sites to multihome without injecting routes from one end of the
39 Internet to another. This memo specifies a database and a method to
40 transport the mapping of EIDs to RLOCs to routers in a reliable,
41 scalable, and secure manner. Our analysis concludes that transport
42 of of all EID/RLOC mappings scales well to at least 10^8 entries.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
47 1.1. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 3
48 1.2. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 4
49 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 5
50 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
51 2.1. Database Updates . . . . . . . . . . . . . . . . . . . . . 5
52 2.2. Communications between ITR and ETR . . . . . . . . . . . . 6
53 2.3. Who are database authorities? . . . . . . . . . . . . . . 7
54 3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 8
55 3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 9
56 3.2. Database Update Format . . . . . . . . . . . . . . . . . . 10
57 4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 10
58 4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 10
59 4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 11
60 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
61 5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 12
62 5.2. Router Throughput Versus Time . . . . . . . . . . . . . . 14
63 5.3. Number of Servers Required . . . . . . . . . . . . . . . . 14
64 5.4. Security Considerations . . . . . . . . . . . . . . . . . 16
65 5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 17
66 5.4.2. Other Risks . . . . . . . . . . . . . . . . . . . . . 19
67 6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 19
68 7. Perhaps use a hybrid model? . . . . . . . . . . . . . . . . . 20
69 8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 21
70 8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
71 9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 21
72 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22
73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
77 13.2. Informational References . . . . . . . . . . . . . . . . . 23
78 Appendix A. Generating and verifying the database signature
79 with OpenSSL . . . . . . . . . . . . . . . . . . . . 24
80 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 25
81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
82 Intellectual Property and Copyright Statements . . . . . . . . . . 27
84 1. Introduction
86 Locator/ID Separation Protocol (LISP) [1] separates an IP address
87 used by a host and local routing system from the locators advertised
88 by BGP participants on the Internet in general, and in the default
89 free zone (DFZ) in particular. It accomplishes this by establishing
90 a mapping between globally unique endpoint identifiers (EIDs) and
91 routing locators (RLOCs). This reduces the amount of state change
92 that occurs on routers within the default-free zone on the Internet,
93 while enabling end sites to be multihomed.
95 In some mapping distribution approaches to LISP the mapping is
96 learned via data-triggered control messages between ingress tunnel
97 routers (ITRs) and egress tunnel routers (ETRs) through an alternate
98 routing topology [14]. In other approaches of LISP, the mapping from
99 EIDs to RLOCs is instead learned through some other means. This memo
100 addresses different approaches to the problem, and specifies a Not-
101 so-novel EID RLOC Database (NERD) and methods to both receive the
102 database and to receive updates.
104 NERD is offered primarily as a way to avoid dropping packets, the
105 underlying assumption being that dropping packets is bad for
106 applications and end users. Those who do not agree with this
107 underlying assumption may find that other approaches make more sense.
109 LISP and NERD are both currently experimental protocols. The NERD
110 database is specified in such a way that the methods used to
111 distribute or retrieve it may vary over time. Multiple databases are
112 supported in order to allow for multiple data sources. An effort has
113 been made to divorce the database from access methods so that both
114 can evolve independently through experimentation and operational
115 validation.
117 1.1. Base Assumptions
119 In order to specify a mapping it is important to understand how it
120 will be used, and the nature of the data being mapped. In the case
121 of LISP, the following assumptions are pertinent:
123 o The data contained within the mapping changes only on provisioning
124 or configuration operations, and is not intended to change when a
125 link either fails or is restored. Some other mechanism such as
126 the use of LISP Reachability Bits with mapping replies handles
127 healing operations, particularly when a tail circuit within an
128 service provider's aggregate goes down. NERD can be used as a
129 verification method to ensure that whatever operational mapping
130 changes an ITR receives are authorized.
132 o While weight and priority are defined, these are not hop-by-hop
133 metrics. Hence the information contained within the mapping does
134 not change based on where one sits within the topology.
135 o A purpose of LISP being to reduce control plane overhead by
136 reducing "rate X state" complexity, updates to the mapping will be
137 relatively rare.
138 o Because LISP and NERD are designed to ease interdomain routing,
139 their use is intended within the inter-domain environment. That
140 is, LISP is best implemented at either the customer edge or
141 provider edge, and there will be on the order of as many ITRs and
142 EID Prefixes as there are connections to Internet Service
143 Providers by end customers.
144 o As such, NERD cannot be the sole means to implement host mobility,
145 although NERD may be in used in conjunction with other mechanisms.
146 For instance, it would be possible for a mobile node to receive a
147 local address that is an EID and pass that to the correspondent
148 node, who could also make use of an EID. As such use of LISP in
149 this case would be transparent, and no mapping entries are changed
150 for mobility.
152 1.2. What is NERD?
154 NERD is a Not-so-novel EID to RLOC Database. It consists of the
155 following components:
157 1. a network database format;
158 2. a change distribution format;
159 3. a database retrieval/bootstrapping method;
160 4. a change distribution method.
162 The network database format is compressible. However, at this time
163 we specify no compression method. NERD will make use of potentially
164 several transport methods, but most notably HTTP [2]. HTTP has
165 restart and compression capabilities. It is also widely deployed.
167 There exist many methods to show differences between two versions of
168 a database or a file, UNIX's "diff" being the classic example. In
169 this case, because the data is well structured and easily keyed, we
170 can make use of a very simple format for version differences that
171 simply provides a list of EID/RLOC mappings that have changed using
172 the same record format as the database, and a list of EIDs that are
173 to be removed.
175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
177 document are to be interpreted as described in RFC 2119 [3].
179 1.3. Glossary
181 The reader is once again referred to [1] for a general glossary of
182 terms related to LISP. The following terms are specific to this
183 memo.
185 Base Distribution URI: An Absolute-URI as defined in Section 4.3 of
186 [6] from which other references are relative. The base
187 distribution URI is used to construct a URI to an EID/RLOC mapping
188 database. If more than one NERD is known then there will be one
189 or more base distribution URIs associated with each (although each
190 such base distribution URI may have the same value).
192 EID Database Authority: The authority that will sign database files
193 and updates. It is the source of both.
195 The Authority: Shorthand for the EID Database Authority.
197 NERD: (N)ot-so-novel (E)ID to (R)LOC (D)atabase.
199 AFI Address Family Identifier.
201 Pull Model: An architecture where clients pull only the information
202 they need at any given time, such as when a packet arrives for
203 forwarding.
205 Push Model: An architecture in which clients receive an entire
206 dataset, containing data they may or may not require, such as
207 mappings for EIDs that no host served is attempting to send to.
209 Hybrid Model: An architecture in which some information is pushed
210 toward the receiver from a source and some information is pulled
211 by the receiver.
213 2. Theory of Operation
215 Operational functions are split into two components: database updates
216 and state exchange between ITR and ETR during a communication.
218 2.1. Database Updates
220 What follows is a summary of how NERDs are generated and updated.
221 Specifics can be found in Section 3. The general way in which NERD
222 works is as follows:
224 1. A NERD is generated by an authority that allocates provider
225 independent (PI) addresses (e.g., IANA or an RIR) which are used
226 by sites as EIDs. As part of this process the authority
227 generates a digest for the database and signs it with a private
228 key whose public key is part of an X.509 certificate. [10] That
229 signature along with a copy of the authority's public key is
230 included in the NERD.
231 2. The NERD is distributed to a group of well known servers.
232 3. ITRs retrieve an initial copy of the NERD via HTTP when they come
233 into service.
234 4. ITRs are preconfigured with a group of certificates whose private
235 keys are used by database authorities to sign the NERD. This
236 list of certificates should be configurable by administrators.
237 5. ITRs next verify both the validity of the public key and the
238 signed digest. If either fail validation, the ITR attempts to
239 retrieve the NERD from a different source. The process iterates
240 until either a valid database is found or the list of sources is
241 exhausted.
242 6. Once a valid NERD is retrieved, the ITR installs it into both
243 non-volatile and local memory.
244 7. At some point the authority updates the NERD and increments the
245 database version counter. At the same time it generates a list
246 of changes, which it also signs, as it does with the original
247 database.
248 8. Periodically ITRs will poll from their list of servers to
249 determine if a new version of the database exists. When a new
250 version is found, an ITR will attempt to retrieve a change file,
251 using its list of preconfigured servers.
252 9. The ITR validates a change file just as it does the original
253 database. Assuming the change file passes validation, the ITR
254 installs new entries, overwrites existing ones, and removes empty
255 entries, based on the content of the change file.
257 As time goes on it is quite possible that an ITR may probe a list of
258 configured neighbors for a database or change file copy. It is
259 equally possible that neighbors might advertise to each other the
260 version number of their database. Such methods are not explored in
261 depth in this memo, but are mentioned for future consideration.
263 2.2. Communications between ITR and ETR
265 [1] describes the basic approach to what happens when a packet
266 arrives at an ITR, and what communications between ITR and ETR take
267 place. NERD provides an optimistic approach to establishing
268 communications with an ETR that is responsible for a given EID
269 prefix. State must be kept, however, on an ITR to determine whether
270 that ETR is in fact reachable. It is expected that this is a common
271 requirement across LISP mapping systems, and will be handled in the
272 core LISP architecture.
274 2.3. Who are database authorities?
276 This memo does not specify who the database authority is. That is
277 because there are several possible operational models. In each case
278 the number of database authorities is meant to be small so that ITRs
279 need only keep a small list of authorities, similar to the way a name
280 server might cache a list of root servers.
282 o A single database authority exists. In this case all entries in
283 the database are registered to a single entity, and that entity
284 distributes the database. Because the EID space is provider
285 independent address space, there is no architectural requirement
286 that address space be hierarchically distributed to anyone, as
287 there is with provider-assigned address space. Hence, there is a
288 natural affinity between the IANA function and the database
289 authority function.
290 o Each region runs a database authority. In this case, provider
291 independent address space is allocated to either Regional Internet
292 Registries (RIRs) or to affiliates of such organizations of
293 network operations guilds (NOGs). The benefit of this approach is
294 that there is no single organization that controls the database.
295 It allows one database authority to backup another. One could
296 envision as many as ten database authorities in this scenario.
297 One drawback to this approach, however, is that any reference to a
298 region imposes a notion of locality, thus potentially diminishing
299 the split between locator and identifier.
300 o Each country runs a database authority. This could occur should
301 countries decide to regulate this function. While limiting the
302 scope of any single database authority as the previous scenario
303 describes, this approach would introduce some overhead as the list
304 of database authorities would grow to as many as 200, and possibly
305 more if jurisdictions within countries attempted to regulate the
306 function. There are two drawbacks to this approach. First, as
307 distribution of EIDs is driven to more local jurisdictions, an EID
308 prefix is tied even tighter to a location. Second, a large number
309 of database authorities will demand some sort of discovery
310 mechanism.
311 o Independent operators manage database authorities. This has the
312 appeals of being location independent, and enabling competition
313 for good performance. This method has the drawback of potentially
314 requiring a discovery mechanism.
316 The latter two approaches are not mutually exclusive. While this
317 specification allows for multiple databases, discovery mechanisms are
318 left as future work.
320 3. NERD Format
322 The NERD consists of a header that contains a database version and a
323 signature that is generated by ignoring the signature field and
324 setting the authentication block length to 0 (NULL). The
325 authentication block itself consists of a signature and a certificate
326 whose private key counterpart was used to generate the signature.
328 Records are kept sorted in numeric order with AFI plus EID as primary
329 key and mask length as secondary. This is so that after a database
330 update it should be possible to reconstruct the database to verify
331 the digest signature, which may be retrieved separately from the
332 database for verification purposes.
334 0 1 2 3
335 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
336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
337 | Schema Vers=1 | DB Code | Database Name Size |
338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
339 | Database Version |
340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
341 | Old Database Version or 0 |
342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
343 | |
344 | Database Name |
345 | |
346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
347 | PKCS#7 Block Size | Reserved |
348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
349 | |
350 | PKCS#7 Block containing Certificate and Signature |
351 | |
352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354 Database Header
356 The DB Code indicates 0 if what follows is an entire database or 1 if
357 what follows is an update. The database file version is incremented
358 each time the complete database is generated by the authority. In
359 the case of an update, the database file version indicates the new
360 database file version, and the old database file version is indicated
361 in the "old DB version" field. The database file version is used by
362 routers to determine whether or not they have the most current
363 database.
365 The database name is a domain name. This is the name that will
366 appear in the Subject field of the certificate used to verify the
367 database. The purpose of the database name is to allow for more than
368 one database. Such databases would be merged by the router. It is
369 important that an EID/RLOC mapping be listed in no more than one
370 database, lest inconsistencies arise. However, it may be possible to
371 transition a mapping from one database to another. During the
372 transition period, the mappings MUST be identical. When they are
373 not, the resultant behavior will be undefined.
375 The PKCS#7 [4] authentication block contains a DER encoded [5]
376 signature and associated public key.
378 3.1. NERD Record Format
380 As distributed over the network, NERD records appear as follows:
382 0 1 2 3
383 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
384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
385 | Num. RLOCs | EID Mask Len | EID AFI |
386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
387 | End point identifier |
388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
389 | Priority 1 | Weight 1 | AFI 1 |
390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
391 | Routing Locator 1 |
392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
393 | Priority 2 | Weight 2 | AFI 2 |
394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
395 | Routing Locator 2 |
396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
397 | Priority 3 | Weight 3 | AFI 3 |
398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
399 | Routing Locator 3... |
400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
402 Priority N and Weight N, and AFI N are associated with Routing
403 Locator N. There will always be at least one routing locator. The
404 minimum record size for IPv4 is 16 bytes. Each additional IPv4 RLOC
405 increases the record size by 8 bytes. The purpose of this format is
406 to keep the database compact, but somewhat easily read. The meaning
407 of weight and priority are described in [1]. The format of the AFI
408 is specified by IANA as "Address Family Numbers", with the exception
409 of how IPv6 EID prefixes are stored.
411 In order to reduce storage and transmission amounts for IPv6, only
412 the necessary number of bytes as specified by the prefix length are
413 kept in the record, rounded to the nearest four byte (word) boundary.
414 For instance, if the prefix length is /49, the nearest four-byte word
415 boundary would require that eight bytes are stored. IPv6 RLOCs are
416 represented as normal 128-bit IPv6 addresses.
418 3.2. Database Update Format
420 A database update contains a set of changes to an existing database.
421 Each AFI/EID/mask-length tuple may have zero or more RLOCs associated
422 with it. In the case where there are no RLOCs, the EID entry is
423 removed from the database. Records that contain EIDs and mask
424 lengths that were not previously listed are simply added. Otherwise,
425 the old record for the EID and mask length is replaced by the more
426 current information. The record format used by the a database update
427 is the same as described in Section 3.1.
429 4. NERD Distribution Mechanism
431 4.1. Initial Bootstrap
433 Bootstrap occurs when a router needs to retrieve the entire database.
434 It knows it needs to retrieve the entire database because either it
435 has none or an update too substantial to process, as might be the
436 case if a router has been out of service for a substantially lengthy
437 period of time.
439 To bootstrap the ITR appends the database name plus "/current/
440 entiredb" to a Base Distribution URI and retrieves the file via HTTP.
441 For example, if the configured URI is
442 "http://www.example.com/eiddb/", and assuming a database name of
443 "nerd.arin.net", the ITR would request
444 "http://www.example.com/eiddb/current/nerd.arin.net/entiredb".
445 Routers MUST check the signature on the database prior to installing
446 it, and MUST check that the database schema matches a schema they
447 understand. Once a router has a valid database it MUST store that
448 database in some sort of non-volatile memory (e.g., disk, flash
449 memory, etc).
451 N.B., the host component for such URIs MUST NOT resolve to a LISP
452 EID, lest a circular dependency be created.
454 4.2. Retrieving Changes
456 In order to retrieve a set of database changes an ITR will have
457 previously retrieved the entire database. Hence it knows the current
458 version of the database it has. Its first step for retrieving
459 changes is to retrieve the current version of the database. It does
460 so by appending "current/version" to the base distribution URI and
461 retrieving the file. Its format is text and it contains the integer
462 value of the current database version.
464 Once an ITR has retrieved the current version it compares version of
465 its local copy. If there is no difference, then the router is up to
466 date and need take no further actions until it next checks.
468 If the versions differ, the router next sends a request for the
469 appropriate change file by appending "current/changes/" and the
470 textual representation of the version of its local copy of the
471 database to the base distribution URI. For example, if the current
472 version of the database is 1105503 and router's version is 1105500,
473 and the base URI and database name are the same as above, the router
474 would request
475 "http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500".
477 The server may not have that change file, either because there are
478 too many versions between what the router has and what is current, or
479 because no such change file was generated. If the server has changes
480 from the routers version to any later version, the server SHOULD
481 issue an HTTP redirect to that change file, and the router SHOULD
482 retrieve and process it. Once it has done so, the router should then
483 repeat the process until it has brought itself up to date. It is
484 thus important for servers to expire old change files in the order in
485 which they were generated.
487 By way of convention, it is suggested that the URIs issued in
488 redirects be of the following form:
490 {base dist. URI}/{dbname}/{more-recent-version}/changes/
491 {older-version}
493 where "base dist. URI" is the base distribution URI, "dbname" is the
494 name of the database, and each version is the textual representation
495 of the integer version value.
497 For example, if the current database version was 1105503 and a router
498 made a request for
499 "http://www.example.com/eiddb/nerd.arin.net/current/changes/1105400"
500 but there was no change file from 1105400 to 1105503, and the server
501 had a group of change files to make the router current, it would
502 issue a redirect to
503 "http://www.example.com/eiddb/nerd.arin.net/110450/changes/1105400"
504 that the router would then process. The router would then make a
505 request for
506 "http://www.example.com/eiddb/nerd.arin.net/current/changes/110450"
507 that the server would have.
509 While it is unlikely that database versions would wrap, as they
510 consists of 32 bit integers, should the event occur, ITRs MUST
511 attempt first to retrieve a change file when their current version
512 number is within 10,000 of 2^32 and they see a version available that
513 is less than 10,000. Barring the availability of a change file, the
514 ITR MUST still assume that the database version has wrapped and
515 retrieve a new copy.
517 5. Analysis
519 We will start our analysis by looking at how much data will be
520 transferred to a router during bootstrap conditions. We will then
521 look at the bandwidth required. Next we will turn our concerns to
522 servers. Finally we will ponder the effect of providing only
523 changes.
525 In the analysis below we treat the overhead of the database header as
526 insignificant (because it is). The analysis should be similar,
527 whether a single database or multiple databases are employed, as we
528 would assume that no entry would appear more than once.
530 5.1. Database Size
532 By its very nature the information to be transported is relatively
533 static and is specifically designed to be topologically insensitive.
534 That is, every ITR is intended to have the same set of RLOCs for a
535 given EID. While some processing power will be necessary to install
536 a table, the amount required should be far less than that of a
537 routing information database because the level of entropy is intended
538 to be lower.
540 For purposes of this analysis, we will assume that the world has
541 migrated to IPv6, as this increases the size of the database, which
542 would be our primary concern. However, to mitigate the size
543 increase, we have limited the size of the prefix transmitted. For
544 purposes of this analysis, we shall assume an average prefix length
545 of 64 bits.
547 Based on that assumption, Section 3.1 states that mapping information
548 for each EID/Prefix includes a group of RLOCs, each with an
549 associated priority and weight, and that a minimum record size with
550 IPv6 EIDs with at least one RLOC is 30 bytes uncompressed. Each
551 additional IPv6 RLOC costs 20 bytes.
553 +-----------+--------+--------+---------+
554 | 10^n EIDs | 2 RLOC | 4 RLOC | 8 RLOC |
555 +-----------+--------+--------+---------+
556 | 4 | 500 KB | 900 KB | 1.70 MB |
557 | 5 | 5.0 MB | 9.0 MB | 17.0 MB |
558 | 6 | 50 MB | 90 MB | 170 MB |
559 | 7 | 500 MB | 900 MB | 1.70 GB |
560 | 8 | 5.0 GB | 9.0 GB | 17.0 GB |
561 +-----------+--------+--------+---------+
563 Database size for IPv6 routes with average prefix length = 64 bits
565 Table 1
567 Entries in the above table are derived as follows:
569 E * (30 + 20 * (R - 1 ))
571 where E = number of EIDs (10^n), R = number of RLOCs per EID.
573 Our scaling target is to accommodate 10^8 multihomed systems, which
574 is one order magnitude greater than what is discussed in [8]. At
575 10^8 entries, a device could be expected to use between 5 and 17
576 gigabytes of RAM for the mapping. No matter the method of
577 distribution, any router that sits in the core of the Internet would
578 require near this amount of memory in order to perform the ITR
579 function. Large enterprise ETRs would be similarly strained, simply
580 due to the diversity of of sites that communicate with one another.
581 The good news is that this is not our starting point, but rather our
582 scaling target, a number that we intend to reach by the year 2050.
583 Our starting point is more likely in the neighborhood of 10^4 or 10^5
584 EIDs, thus requiring between 500KB and 17 MB.
586 5.2. Router Throughput Versus Time
588 +-------------------+---------+--------+---------+-------+
589 | Table Size (10^N) | 1mb/s | 10mb/s | 100mb/s | 1gb/s |
590 +-------------------+---------+--------+---------+-------+
591 | 6 | 8 | 0.8 | 0.08 | 0.008 |
592 | 7 | 80 | 8 | 0.8 | 0.08 |
593 | 8 | 800 | 80 | 8 | 0.8 |
594 | 9 | 8,000 | 800 | 80 | 8 |
595 | 10 | 80,000 | 8,000 | 800 | 80 |
596 | 11 | 800,000 | 80,000 | 8,000 | 800 |
597 +-------------------+---------+--------+---------+-------+
599 Number of seconds to process NERD
601 Table 2
603 The length of time it takes to process the database is significant in
604 models where the device acquires the entire table. During this
605 period of time, either the router will be unable to route packets
606 using LISP or it must use some sort of query mechanism for specific
607 EIDs as the rest it populates its table through the transfer.
608 Table 2 shows us that at our scaling target, the length of time it
609 would take for a router using 1 mb/s of bandwidth is about 80
610 seconds. We can measure the processing rate in small numbers of
611 hours for any transfer speed greater than that. The fastest
612 processing time shows us as taking 8 seconds to process an entire
613 table of 10^9 bytes and 80 seconds for 10^10 bytes.
615 5.3. Number of Servers Required
617 As easy as it may be for a router to retrieve, the aggregate
618 information may be difficult for servers to transmit, assuming the
619 information is transmitted in aggregate (we'll revisit that
620 assumption later).
622 +----------------+------------+-----------+------------+------------+
623 | # Simultaneous | 10 Servers | 100 | 1,000 | 10,000 |
624 | Requests | | Servers | Servers | Servers |
625 +----------------+------------+-----------+------------+------------+
626 | 100 | 720 | 72 | 72 | 72 |
627 | 1,000 | 7,200 | 720 | 72 | 72 |
628 | 10,000 | 72,000 | 7,200 | 720 | 72 |
629 | 100,000 | 720,000 | 72,000 | 7,200 | 720 |
630 | 1,000,000 | 7,200,000 | 720,000 | 72,000 | 7,200 |
631 | 10,000,000 | 72,000,000 | 7,200,000 | 720,000 | 72,000 |
632 +----------------+------------+-----------+------------+------------+
634 Retrieval time per number of servers in seconds. Assumes average
635 10^8 entries with 4 RLOCs per EID and that each server has access to
636 1gb/s and 100% efficient use of that bandwidth and no compression.
638 Table 3
640 Entries in the above table were generated using the following method:
642 For 10^8 entries with four RLOCs per EID, the table size is 9.0GB,
643 per our previous table. Assume 1 Gb/s transfer rates and 100%
644 utilization. Protocol overhead is ignored for this exercise. Hence
645 a single transfer X takes 48 seconds and can get no faster.
647 With this in mind, each entry is as follows:
649 max(1X,N*X/S)
651 where N=number of transfers, X = 72 seconds,
652 and S = number of servers.
654 If we have a distribution model which every device must retrieve the
655 mapping information upon start, Table 3 shows the length of time in
656 seconds it will take for a given number of servers to complete a
657 transfer to a given number of devices. This table says, as an
658 example, that it would take 72,000 seconds (20 hours) for one million
659 ITRs to simultaneously retrieve the database from one thousand
660 servers. Should a cold start scenario occur, this number should be
661 of some concern. Hence it is important to take some measures both to
662 avoid such a scenario, and to ease the load should it occur. The
663 primary defense should be for ITRs to first attempt to retrieve their
664 databases from their peers or upstream providers. Secondary defenses
665 could include data sanity checks within ITRs, with agreed norms for
666 how much the database should change in any given update or over any
667 given period of time. As we will see below, dissemination of changes
668 is considerably less volume.
670 +----------------+-------------+---------------+----------------+
671 | % Daily Change | 100 Servers | 1,000 Servers | 10,000 Servers |
672 +----------------+-------------+---------------+----------------+
673 | 0.1% | 300 | 30 | 3 |
674 | 0.5% | 1500 | 150 | 15 |
675 | 1% | 3000 | 300 | 30 |
676 | 5% | 15,000 | 1500 | 150 |
677 | 10% | 30,000 | 3000 | 300 |
678 +----------------+-------------+---------------+----------------+
680 Assuming 10 million routers and a database size of 9GB, resulting
681 hourly transfer times are shown in seconds, given number of servers
682 and daily rate of change.
684 Table 4
686 This table shows us that with 10,000 servers the average transfer
687 time with 1Gb/s links for 10,000,000 routers will be 300 seconds with
688 10% daily change spread over 24 hourly updates. For a 0.1% daily
689 change, that number is 3 seconds for a database of size 9.0GB.
691 The amount of change goes to the purpose of LISP. If its purpose is
692 to provide effective multihoming support to end customers, then we
693 might anticipate relatively few changes. If, on the other, service
694 providers attempt to make use of LISP to provide some form of traffic
695 engineering, we can expect the same data to change more often. We
696 can probably not conclude much in this regard without additional
697 operational experience. The one thing we can say is that different
698 applications of the LISP protocol may require new and different
699 distribution mechanisms. Such optimization is left for another day.
701 5.4. Security Considerations
703 Whichever the answer to our previous question, we must consider the
704 security of the information being transported. If an attacker can
705 forge an update or tamper with the database, he can in effect
706 redirect traffic to end sites. Hence, integrity and authenticity of
707 the NERD is critical. In addition, a means is required to determine
708 whether a source is authorized to modify a given database. No data
709 privacy is required. Quite to the contrary, this information will be
710 necessary for any ITR.
712 The first question one must ask is who to trust to provide the ITR a
713 mapping. Ultimately the owner of the EID prefix is most
714 authoritative for the mapping to RLOCs. However, were all owners to
715 sign all such mappings, ITRs would need to know which owner is
716 authorized to modify which mapping, creating a problem of O(N^2)
717 complexity.
719 We can reduce this problem substantially by investing some trust in a
720 small number of entities that are allowed to sign entries. If
721 authority manages EIDs much the same way a domain name registrar
722 handles domains, then the owner of the EID would choose a database
723 authority she or he trusts, and ITRs must trust each such authority
724 in order to map the EIDs listed by that authority to RLOCs. This
725 reduces the amount of management complexity on the ETR to retaining
726 knowledge of O(#authorities), but does require that each authority
727 establish procedures for authenticating the owner of an EID. Those
728 procedures needn't be the same.
730 There are two classic methods to ensure integrity of data:
732 o secure transport of the source of the data to the consumer, such
733 as Transport Layer Security (TLS) [7]; and
734 o provide object level security.
736 These methods are not mutually exclusive, although one can argue
737 about the need for the former, given the latter.
739 In the case of TLS, when it is properly implemented, the objects
740 being transported cannot easily be modified by interlopers or so-
741 called men in the middle. When data objects are distributed to
742 multiple servers, each of those servers must be trusted. As we have
743 seen above, we could have quite a large number of servers, thus
744 providing an attacker a large number of targets. We conclude that
745 some form of object level security is required.
747 Object level security involves an authority signing an object in a
748 way that can easily be verified by a consumer, in this case a router.
749 In this case, we would want the mapping table and any incremental
750 update to be signed by the originator of the update. This implies
751 that we cannot simply make use of a tool like CVS [9]. Instead, the
752 originator will want to generate diffs, sign them, and make them
753 available either directly or through some sort of content
754 distribution or peer to peer network.
756 5.4.1. Use of Public Key Infrastructures (PKIs)
758 X.509 provides a certificate hierarchy that has scaled to the size of
759 the Internet. The system is most manageable when there are few
760 certificates to manage. The model proposed in this memo makes use of
761 one current certificate per database authority. The three pieces of
762 information necessary to verify a signature, therefore, are as
763 follows:
765 o the certificate of the database authority, which can be provided
766 along with the database;
767 o the certificate authority's certificate; and
768 o A table of database names and distinguished names (DNs) that are
769 allowed to update them.
771 The latter two pieces of information must be very well known and must
772 be configured on each ITR. It is expected that both would change
773 very rarely, and it would not be unreasonable for such updates to
774 occur as part of a normal OS release process.
776 The tools for both signing and verifying are readily available.
777 OpenSSL [16] provides tools and libraries for both signing and
778 verifying. Other tools commonly exist.
780 Use of PKIs is not without implementation, operational complexity or
781 risk. The following risks and mitigations are identified with NERD's
782 use of PKIs:
784 If a NERD database authority private key is exposed:
786 In this case an attacker could sign a false database update,
787 either redirecting traffic, or otherwise causing havoc. In this
788 case, the NERD database administrator must revoke its existing key
789 and issue a new one. The certificate is added to a certificate
790 revocation list (CRL), which may be distributed with both this and
791 other databases, as well as through other channels. Because this
792 event is expected to be rare, and the number of database
793 authorities is expected to be small, a CRL will be small. When a
794 router receives a revocation, it checks it against its existing
795 databases, and attempts to update the one that is revoked. This
796 implies that prior to issuing the revocation, the database
797 authority MUST sign an update with the new key. Routers SHOULD
798 discard updates they have already received that were signed after
799 the revocation was generated. If a router cannot confirm that
800 whether the authority's certificate was revoked before or after a
801 particular update, it MUST retrieve a fresh new copy of the
802 database with a valid signature.
804 The private key associated with the CA that signed the Authority's
805 certificate is compromised:
807 In this case, it becomes possible for an attacker to masquerade as
808 the database authority. To ameliorate damage, the database
809 authority SHOULD revoke its certificate and get a new certificate
810 issued from a CA that is not compromised. Once it has done so,
811 the previous procedure is followed. The compromised certificate
812 can be removed during the normal operating system upgrade cycle.
814 An algorithm used if either the certificate or the signature is
815 cracked:
817 This is a catastrophic failure and the above forms of attack
818 become possible. The only mitigation is to make use of a new
819 algorithm. In theory this should be possible, but in practice has
820 proved very difficult. For this reason, additional work is
821 recommended to make alternative algorithms available.
823 The Database Authority loses its key or disappears:
825 In this case nobody can update the existing database. There are
826 few programmatic mitigations. If the database authority places
827 its private keys and suitable amounts of information escrow, under
828 agreed upon circumstances, such as no updates for three days, for
829 example, the escrow agent would release the information to a party
830 competent of generating a database update.
832 5.4.2. Other Risks
834 Because this specification does not require secure transport, if an
835 attacker prevents updates to an ITR for the purposes of having that
836 ITR continue to use a compromised ETR, the ITR could continue to use
837 an old version of the database without realizing a new version has
838 been made available. If one is worried about such an attack, a
839 secure channel such as SSL to a secure chain back to the database
840 authority should be used. It is possible that after some operational
841 experience, later versions of this format will contain additional
842 semantics to address this attack.
844 As discussed above, substantial risk would be a cold start scenario.
845 If an attacker found a bug in a common operating system that allowed
846 it to erase an ITR's database, and was able to disseminate that bug,
847 the collective ability of ITRs to retrieve new copies of the database
848 could be taxed by collective demand. The remedy to this is for
849 devices to share copies of the database with their neighbors, thus
850 making each potential requester a potential service.
852 6. Why not use XML?
854 Many objects these days are distributed as either XML pages or
855 something derived as XML [11], such as SOAP [12],[13]. Use of such
856 well known standards allows for high level tools and library reuse.
857 XML's strength is extensibility. Without a doubt XML would be more
858 extensible than a fixed field database. Why not, then, use these
859 standards in this case? There are two answers to this question.
860 First, the obvious concern is that XML is not known for efficiency of
861 data transport. Being based in text, an IPv4 address is expanded
862 from one octet to three octets, plus either an attribute and quotes
863 or element tags and end tags. Let us presume for the moment a very
864 simple schema that might cause a record to be represented as follows:
866
867
868
869 192.168.1.1
870
871
872
873
874 192.168.1.2
875
876
877
879 With white space removed the uncompressed XML represents 120 bytes
880 versus 20 bytes for the record specified in Section 3.1, representing
881 a five fold expansion. The expansion rate for IPv6 is a bit more
882 complex. Because the textual representation can be shortened, it's
883 hard to say exactly what length an IPv6 address would be.
885 The other concern about XML is that version 1.0 of the specification
886 is silent on the order of sibling elements. Specifications other
887 than the base specification state that order is significant. Order
888 is significant to LISP and NERD because once an update is applied to
889 the database it should be possible to verify the signature of the
890 entire database. Prior to applying the signature the XML generator
891 would need to ensure the order of information. That same sort would
892 be required of the router. This seems to add unnecessary fragility
893 to a critical system without much benefit. While there may indeed be
894 uses of an XML representation of the database, these uses are likely
895 to be outside of a router.
897 7. Perhaps use a hybrid model?
899 Perhaps it would be useful to use both a prepopulated database such
900 as NERD and a query mechanism (perhaps LISP+ALT, LISP-CONS [15], or
901 DNS) to determine an EID/RLOC mapping. One idea would be to receive
902 a subset of the mappings, say, by taking only the NERD for certain
903 regions. This alleviates the need to drop packets for some subset of
904 destinations under the assumption that one's business is localized to
905 a particular region. If one did not have a local entry for a
906 particular EID one would then make a query.
908 One approach to using DNS to query live would be to periodically walk
909 "interesting" portions of the network, in search of relevant records,
910 and caching them to non-volatile storage. While preventing resource
911 attacks, the walk itself could be viewed as an attack, if the
912 algorithm was not selective enough about what it thought was
913 interesting. A similar approach could be applied to LISP+ALT or
914 LISP-CONS by forcing a data-driven Map Reply for certain sites.
916 8. Deployment Issues
918 While LISP and NERD are intended as experiments at this point, it is
919 already obvious one must give serious consideration to circular
920 dependencies with regard to the protocols used and the elements
921 within them.
923 8.1. HTTP
925 In as much as HTTP depends on DNS, either due to the authority
926 section of a URI, or due to the configured base distribution URI,
927 these same concerns apply. In addition, any HTTP server that itself
928 makes use of provider independent addresses would be a poor choice to
929 distribute the database for these exact same reasons.
931 One issue with using HTTP is that it is possible that a middlebox of
932 some form, such as a cache, may intercept and process requests. In
933 some cases this might be a good thing. For instance, if a cache
934 correctly returns a database, some amount of bandwidth is conserved.
935 On the other hand, if the cache itself fails to function properly for
936 whatever reason, end to end connectivity could be impaired. For
937 example, if the cache itself depended on the mapping being in place
938 and functional, a cold start scenario might leave the cache
939 functioning improperly, in turn providing routers no means to update
940 their databases. Some care must be given to avoid such
941 circumstances.
943 9. Open Questions
945 Do we need to discuss reachability in more detail? This was clearly
946 an issue at the IST-RING workshop. There are two key issues. First,
947 what is the appropriate architectural separation between the data
948 plane and the control plane? Second, is there some specific way in
949 which NERD impacts the data plane?
951 Should we specify a (perhaps compressed) tarball that treads a middle
952 ground for the last question, where each update tarball contains both
953 a signature for the update and for the entire database, once the
954 update is applied.
956 Should we compress? In some initial testing of databases with 1, 5,
957 and 10 million IPv4 EIDs and a random distribution of IPv4 RLOCs, the
958 current format in this document compresses down by a factor of
959 between 35% and 36%, using Burrows-Wheeler block sorting text
960 compression algorithm (bzip2). The NERD used random EIDs with mask
961 lengths varying from 19-29, with probability weighted toward the
962 smaller masks. This only very roughly reflects reality. A better
963 test would be to start with the existing prefixes found in the DFZ.
965 10. Conclusions
967 This memo has specified a database format, an update format, a URI
968 convention, an update method, and a validation method for EID/RLOC
969 mappings. We have shown that beyond the predictions of 10^8 EID-
970 prefix entries, the aggregate database size would likely be at most
971 17GB. We have considered the amount of servers to distribute that
972 information and we have demonstrated the limitations of a simple
973 content distribution network and other well known mechanisms. The
974 effort required to retrieve a database change amounts to between 3
975 and 30 seconds of processing time per hour at at today's gigabit
976 speeds. We conclude that there is no need for an off box query
977 mechanism today, and that there are distinct disadvantages for having
978 such a mechanism in the control plane.
980 Beyond this we have examined alternatives that allow for hybrid
981 models that do use query mechanisms, should our operating assumptions
982 prove overly optimistic. Use of NERD today does not foreclose use of
983 such models in the future, and in fact both models can happily co-
984 exist.
986 We leave to future work how the list of databases is distributed, how
987 BGP can play a role in distributing knowledge of the databases, and
988 how DNS can play a role in aggregating information into these
989 databases.
991 We also leave to future work whether HTTP is the best protocol for
992 the job, and whether the scheme described in this document is the
993 most efficient. One could easily envision that when applied in high
994 delay or high loss environments, a broadcast or multicast method may
995 prove more effective.
997 11. IANA Considerations
999 This memo makes no requests of IANA.
1001 12. Acknowledgments
1003 Dino Farinacci, Patrik Faltstrom, Dave Meyer, Joel Halpern, Dave
1004 Thaler, Mohamed Boucadair, Robin Whittle, Max Pritikin, and Scott
1005 Brim were very helpful with their reviews of this work. Thanks also
1006 to the participants of the Routing Research Group and the IST-RING
1007 workshop held in Madrid in December of 2007 for their incisive
1008 comments. The astute will notice a lengthy References section. This
1009 work stands on the shoulders of many others' efforts.
1011 13. References
1013 13.1. Normative References
1015 [1] Farinacci, D., "Locator/ID Separation Protocol (LISP)",
1016 draft-farinacci-lisp-06 (work in progress), February 2008.
1018 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1019 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
1020 HTTP/1.1", RFC 2616, June 1999.
1022 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1023 Levels", BCP 14, RFC 2119, March 1997.
1025 [4] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1026 1.5", RFC 2315, March 1998.
1028 [5] International Telecommunications Union, "Information technology
1029 - Open Systems Interconnection - The Directory: Public-key and
1030 attribute certificate frameworks", ITU-T Recommendation X.509,
1031 ISO Standard 9594-8, March 2000.
1033 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1034 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
1035 January 2005.
1037 13.2. Informational References
1039 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
1040 Protocol Version 1.1", RFC 4346, April 2006.
1042 [8] Carpenter, B., "IETF Plenary Presentation: Routing and
1043 Addressing: Where we are today", March 2007.
1045 [9] Grune, R., Baalbergen, E., Waage, M., Berliner, B., and J.
1046 Polk, "CVS: Concurrent Versions System", November 1985.
1048 [10] International International Telephone and Telegraph
1049 Consultative Committee, "Information Technology - Open Systems
1050 Interconnection - The Directory: Authentication Framework",
1051 CCITT Recommendation X.509, November 1988.
1053 [11] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
1054 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
1055 October 2000, .
1057 [12] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
1058 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C
1059 Working Draft soap12-part1, June 2002,
1060 .
1062 [13] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H.
1063 Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", W3C Working
1064 Draft soap12-part2, June 2002,
1065 .
1067 [14] Farinacci, D., "LISP Alternative Topology (LISP-ALT)",
1068 draft-fuller-lisp-alt-01 (work in progress), November 2007.
1070 [15] Brim, S., "LISP-CONS: A Content distribution Overlay Network
1071 Service for LISP", draft-meyer-lisp-cons-03 (work in progress),
1072 November 2007.
1074 URIs
1076 [16]
1078 Appendix A. Generating and verifying the database signature with
1079 OpenSSL
1081 As previously mentioned, one goal of NERD was to use off-the-shelf
1082 tools to both generate and retrieve the database. To many, PKI is
1083 magic. This section is meant to provide at least some clarification
1084 as to both the generation and verification process, complete with
1085 command line examples. Not included is how you get the entries
1086 themselves. We'll assume they exist, and that you're just trying to
1087 sign the database.
1089 To sign the database, to start with, you need a database file that
1090 has a database header described in Section 3. Block size should be
1091 zero, and there should be no PKCS#7 block at this point. You also
1092 need a certificate and its private key with which you will sign the
1093 database.
1095 The OpenSSL "smime" command contains all the functions we need from
1096 this point forth. To sign the database, issue the following command:
1098 openssl smime -binary -sign -outform DER -signer yourcert.crt \
1099 -inkey yourcert.key -in database-file -out signature
1101 -binary states that no MIME canonicalization should be performed.
1102 -sign indicates that you are signing the file that was given as the
1103 argument to -in. The output format (-outform) is binary DER, and
1104 your public certificate is provided with -signer along with your key
1105 with -inkey. The signature itself is specified with -out.
1107 The resulting file "signature" is then copied into to PKCS#7 block in
1108 the database header, its size in bytes is recorded in the PKCS#7
1109 block size field, and the resulting file is ready for distribution to
1110 ITRs.
1112 To verify a database file, first retrieve the PKCS#7 block from the
1113 file by copying the appropriate number of bytes into another file,
1114 say "signature". Next, zero this field, and set the block size field
1115 to 0. Next use the "smime" command to verify the signature as
1116 follows:
1118 openssl smime -binary -verify -inform DER -content database-file
1119 -out /dev/null -in signature
1121 Openssl will return "Verification OK" if the signature is correct.
1122 OpenSSL provides sufficiently rich libraries to accomplish the above
1123 within the C programming language with a single pass.
1125 Appendix B. Changes
1127 This section to be removed prior to publication.
1129 o 04: Analysis change: IPv6 RLOCs are 128 bits. While they can be
1130 shortened to 64 bits, that involves substantial ETR changes and
1131 expenditure of IPv6 networks, which is probably unnecessary, and
1132 can be left as a later optimization. Added an option of
1133 independent operators. Processed all but two of Dino's comments.
1134 Addressed Scott's comments. Removed existing work analysis.
1135 Saving that for another day. Clarified OpenSSL Appendix.
1136 o 03: Change dbname to a domain name, indicate that is what is in
1137 the subject of the X.509 certificate, and list editorial changes,
1138 update acknowledgments.
1139 o 02: Incorporate some of Dave Thaler's comments. Add
1140 authentication block detail. Modify analysis to take IPv6 into
1141 account, along with a more realistic number of RLOCs per EID. Add
1142 some comments about potential risks of a cold start. Add S/MIME
1143 example as appendix A and take out old ToDo. Provide some amount
1144 of compression of IPv6 addresses by limiting their size to
1145 significant bytes rounded to a four byte word boundary.
1146 o 01: Massive spelling correction, URI example correction.
1147 o 00: Initial Revision.
1149 Author's Address
1151 Eliot Lear
1152 Cisco Systems GmbH
1153 Glatt-com
1154 Glattzentrum, ZH CH-8301
1155 Switzerland
1157 Phone: +41 44 878 7525
1158 Email: lear@cisco.com
1160 Full Copyright Statement
1162 Copyright (C) The IETF Trust (2008).
1164 This document is subject to the rights, licenses and restrictions
1165 contained in BCP 78, and except as set forth therein, the authors
1166 retain all their rights.
1168 This document and the information contained herein are provided on an
1169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1171 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1172 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1173 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1176 Intellectual Property
1178 The IETF takes no position regarding the validity or scope of any
1179 Intellectual Property Rights or other rights that might be claimed to
1180 pertain to the implementation or use of the technology described in
1181 this document or the extent to which any license under such rights
1182 might or might not be available; nor does it represent that it has
1183 made any independent effort to identify any such rights. Information
1184 on the procedures with respect to rights in RFC documents can be
1185 found in BCP 78 and BCP 79.
1187 Copies of IPR disclosures made to the IETF Secretariat and any
1188 assurances of licenses to be made available, or the result of an
1189 attempt made to obtain a general license or permission for the use of
1190 such proprietary rights by implementers or users of this
1191 specification can be obtained from the IETF on-line IPR repository at
1192 http://www.ietf.org/ipr.
1194 The IETF invites any interested party to bring to its attention any
1195 copyrights, patents or patent applications, or other proprietary
1196 rights that may cover technology that may be required to implement
1197 this standard. Please address the information to the IETF at
1198 ietf-ipr@ietf.org.