idnits 2.17.1 draft-tbruijnzeels-sidr-repo-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2013) is 4091 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft O. Muravskiy 4 Intended status: Informational RIPE NCC 5 Expires: August 15, 2013 B. Weber 6 Cobenian 7 February 11, 2013 9 RPKI Repository Analysis and Requirements 10 draft-tbruijnzeels-sidr-repo-analysis-00 12 Abstract 14 The current RPKI Resource Certificate Repository Structure (RFC6480 & 15 RFC6481) uses rsync as both a delta and transfer protocol. Concerns 16 have been raised about the scalability of this repository and the 17 reliance on rsync. This document provides an analysis of these 18 concerns and formulates requirements for future work. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 15, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Concerns With current repository . . . . . . . . . . . . . . 3 57 3.1. Scalability of rsync(d) deltas . . . . . . . . . . . . . 3 58 3.2. Update frequency and propagation times . . . . . . . . . 3 59 3.2.1. Migrating to another ASN . . . . . . . . . . . . . . 4 60 3.2.2. Error in ROA . . . . . . . . . . . . . . . . . . . . 4 61 3.2.3. BGPSec . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Lack of rsync standard and implementations . . . . . . . 4 63 3.4. Inconsistent Responses . . . . . . . . . . . . . . . . . 5 64 3.5. Single publication point per CA . . . . . . . . . . . . . 6 65 3.6. Scalability through hierarchical fetching . . . . . . . . 6 66 4. Delta Protocol Requirements and Recommendations . . . . . . . 7 67 4.1. Transport Agnostic . . . . . . . . . . . . . . . . . . . 7 68 4.2. Support Publication Sets . . . . . . . . . . . . . . . . 7 69 4.3. Support non-hierarchical repository lay-out . . . . . . . 7 70 4.4. Expected factors affecting repository load . . . . . . . 7 71 4.4.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . 7 72 4.4.2. Size aspects of the global RPKI . . . . . . . . . . . 7 73 4.4.3. Churn . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4.4. Number of Relying Parties . . . . . . . . . . . . . . 10 75 4.4.5. Fetch frequency of Relying Parties . . . . . . . . . 11 76 4.5. Expected RPKI Repository Requirements . . . . . . . . . . 11 77 4.5.1. Objects and Relying Parties . . . . . . . . . . . . . 11 78 4.5.2. Update related throughput . . . . . . . . . . . . . . 12 79 4.5.3. Update related concurrency . . . . . . . . . . . . . 12 80 4.5.4. Update related traffic volume . . . . . . . . . . . . 12 81 4.6. Reduce Load on Central Repositories . . . . . . . . . . . 13 82 4.7. Update notifications . . . . . . . . . . . . . . . . . . 13 83 4.8. Reduce Churn . . . . . . . . . . . . . . . . . . . . . . 13 84 4.9. Signed Deltas . . . . . . . . . . . . . . . . . . . . . . 13 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 7. Normative References . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119] . 96 2. Introduction 98 The current RPKI Resource Certificate Repository Structure (RFC6480 & 99 RFC6481) uses rsync as both a delta and transfer protocol and 100 recommends that repositories be set up in a hierarchical way such 101 that relying parties (validation tools) can fetch all updates in a 102 single repository efficiently while performing top-down validation. 104 This structure has its benefits. In particular it has allowed for 105 early deployment of RPKI without the need to re-invent a delta 106 protocol, and this has allowed early adopters of RPKI to build up 107 operational experience more quickly. The delta protocol also has 108 benefits for relying party tools, allowing them to quickly retrieve 109 what's new in a repository limiting fetch time and bandwidth usage. 111 Having said this, operational experience, as well as lab testing, 112 have shown that there are concerns with regards to the current 113 infrastructure that justify that the WG thinks about improvements in 114 this space. 116 3. Concerns With current repository 118 3.1. Scalability of rsync(d) deltas 120 Rsync is a very efficient tool when used 1:1 between a client and 121 server. The problem is that in a globally deployed RPKI we can 122 expect in the order of 40k clients, roughly corresponding to the 123 number of ASNs, to connect regularly to a repository server. 125 When the rsync built-in delta protocol is used (recursive fetching), 126 the server is computationally involved in calculating the delta for 127 each connected client. Performance measurements in a lab have shown 128 that the maximum number of clients that can be processed per second 129 (throughput), and the maximum number of concurrent clients are both 130 linearly dependent on the repository size. The throughput is limited 131 by server CPU. Concurrency is limited by server memory. 133 As a result a sufficiently large repository has to invest heavily in 134 running multiple rsyncd instances to cope with the expected regular 135 load of a large number of clients, and to counter the risks of DDoS 136 attacks. 138 3.2. Update frequency and propagation times 139 The retrieval of signed objects is described in RFC6480 (section 6). 140 There are no formal limits imposed by this informational RFC on the 141 update frequency, but to prevent the overloading of repository 142 servers as described above, the typical update interval of current 143 tools is between 1-24 hours. 145 In previous discussions in the WG it was suggested that human scale 146 propagation times (i.e. up to 24 hours) are good enough for the 147 problem that we are trying to solve. There are however good reasons 148 why much faster retrieval of newly signed objects is desirable. 150 3.2.1. Migrating to another ASN 152 In this scenario, a ROA exists for a prefix and ASN, but the prefix 153 needs to be announced from another ASN. 155 In many cases the RP can foresee this and create an appropriate ROA 156 well in advance, but there are also failure cases possible where this 157 is not foreseeable. 159 3.2.2. Error in ROA 161 The CA operator made a mistake when it created a ROA. The ROA causes 162 announcements that should be considered VALID to appear as INVALID, 163 or vice versa. The CA would like to take appropriate action and 164 revoke the ROA or issue additional ROAs. However, RPs that have 165 received the mistaken ROA may not see these updates for some time. 167 3.2.3. BGPSec 169 The BGPSec protocol is still being discussed. However there are 170 indications that it would be desirable if propagation times for new 171 router certificates and CRLs could be reduced. In particular in the 172 context of: 174 o Planned router key roll-overs 176 o Unplanned roll-out of new router hardware with new keys 178 o Replay protection strategies that rely on having shorter cycles & 179 propagation times for router certs and keys 181 3.3. Lack of rsync standard and implementations 183 There is only one known implementation of rsync and the standard is 184 not described by any RFC. The implementation is non-modular, making 185 it impossible to use the code as a library even when coding in the 186 same language. 188 As a result all current implementations of relying party tooling have 189 had no option but to use rsync as a pre-installed external process. 191 This has several major draw backs for the quality of implementations: 193 o RP tools require that rsync is installed on a system, and they can 194 not assume which version is installed. 196 o Because there is only one implementation all RPKI repositories can 197 be affected by a single bug or exploit in rsync. 199 o Calling an external process is expensive limiting the benefits 200 that can be gained from parallel processing. 202 o Parsing downloaded objects is inefficient -- objects have to be 203 downloaded to disk first before they can be read and parsed. 205 o Dealing with errors is complicated -- exit codes are not always 206 clear, stderr may have to be parsed. Exit codes and messages are 207 not guaranteed to be the same across rsync versions. 209 3.4. Inconsistent Responses 211 An 'inconsistent' set of objects is a set of retrieved objects for a 212 CA Certificate where there differences between the objects retrieved 213 and the objects mentioned on the corresponding manifest. If any 214 objects are missing, or if additional objects not mentioned on the 215 manifest are found, or if any of the objects does not match the 216 sha256 hash mentioned on the manifest, then the set as a whole is 217 considered inconsistent. RFC6486 has text advising RPs on possible 218 ways to treat each of these cases. However, there is a large degree 219 of uncertainty as to how different RP tools, and operators, will deal 220 with these corner cases because most decisions are left to local 221 policy. This can lead to inconsistent and possibly surprising 222 differences in the validation of RPKI data. 224 Missing ROA objects can be particularly problematic because other 225 ROAs, that can be found and validated, may invalidate announcements 226 that would have been marked as valid by these missing ROAS. 227 Additional ROA objects are confusing because to the RP it's not clear 228 whether this ROA was intentional and the MFT is out of date, or not. 230 The use of rsync as a delta protocol is problematic in this context, 231 because rsync is non-transactional. As a result an RP may get 232 partially updated CA repository objects if it happens to fetch while 233 the objects on disk are being updated. This is confusing to the RP 234 who can not tell the difference between this and a persistent error 235 on the publisher side, or an attack involving partial replay or 236 withholding of objects. 238 All of this adds up to a repository infrastructure and corresponding 239 validation rules that leave a high degree of uncertainty in case of 240 corner cases. The authors believe that it would be better to (1) 241 improve the standards so that these corner cases are less likely to 242 occur, and (2) formulate much stricter validation rules so that the 243 uncertainty with regards to how RPs may deal with corner cases is 244 further reduced. 246 3.5. Single publication point per CA 248 In the current design only publication point per CA is envisioned. 250 Even though such a publication point may employ various techniques to 251 achieve high-availability, this leaves concerns with regards to: 253 o Attacks on DNS for the publication point 255 o A contractual tie-in between CA and publication server, with no 256 way for planned migration (while staying up to date) 258 o Failure of the publication server 260 o (Legal) attacks on the publication server 262 3.6. Scalability through hierarchical fetching 264 The notion that child CAs can publish in a sub-directory of their 265 parent CA publication point has been suggested as mitigation strategy 266 for scalability of fetching RPKI data using rsync. 268 There are a number of reasons why this hierarchical model may not be 269 advisable or even possible: 271 o The parent CA may not wish to imply responsibility over objects 272 issued by its child 274 o Recursive rsync fetches on sufficiently large repositories are 275 expensive. The parent CA may have no choice but to disallow 276 recursive fetching to mitigate its DDoS vulnerabilities 278 o CAs may wish to publish their own content, or they may wish to 279 publish their content in a repository that is provided by an 280 organisation other than their parent CA. 282 4. Delta Protocol Requirements and Recommendations 284 4.1. Transport Agnostic 286 A future delta protocol should be transport agnostic, allowing 287 agility in future transport protocols between RPs and repositories, 288 and sharing of deltas between RPs. 290 4.2. Support Publication Sets 292 A future delta protocol should enable CAs to publish new objects as a 293 set so that errors in evaluating route origin validity as a result of 294 incomplete information may be avoided as much as possible. 296 4.3. Support non-hierarchical repository lay-out 298 The scalability of a future delta protocol should not depend on a 299 hierarchical repository lay-out. This is particularly important if 300 one considers the possibility of third party publication servers and/ 301 or the possible use of mirror repositories. In both cases the CAs 302 for which objects are published can most likely not be considered 303 children of the publication server, or each other. 305 4.4. Expected factors affecting repository load 307 4.4.1. Disclaimer 309 The numbers cited below reflect our best current estimates based on 310 relevant statistics currently at our disposal. They are intended to 311 provide context for load testing proposed solutions. 313 We are of course open any suggestions and real world statistics that 314 can improve these estimates. 316 4.4.2. Size aspects of the global RPKI 318 4.4.2.1. Mirroring 320 For the purpose of scalability it would be prudent to assume that 321 mirroring should be supported in the RPKI to the point where one 322 publication server can, in principle, mirror the complete global 323 RPKI. In reality this may not happen to this extent, but any design 324 that can support this should be adequate to support smaller numbers. 326 4.4.2.2. Number of CAs in the global RPKI 328 Assuming that only current RIR member organisations that are holding 329 IPv4, IPv6 and/or ASN resources would act as Certificate Authorities 330 (CA), the expected number of CAs in the global RPKI is expected to be 331 around 50.000. However, if one also considers holders of Provider 332 Independent (PI) resources this number may be larger. For reference: 333 the RIPE NCC has roughly 25.000 PI prefixes registered, vs just 334 roughly 9000 regular members. If these numbers are similar for all 335 regions, and we assume the 'worst case' where all PI holders have 336 their own CAs, then we are looking at number that is roughly four 337 times larger: i.e. 200.000 CAs. 339 Note that each organisation will most likely find all their resources 340 on one certificate, however in case an organisation holds resources 341 from multiple parent sources more than certificate may be needed. 342 For the moment we will assume that the number of CA certificates per 343 organisation will be close to 1. 345 For each CA certificate 4 objects will be published in the global 346 RPKI: the CA certificate itself (by the parent CA), one manifest, one 347 CRL and one ghostbuster record. 349 4.4.2.3. Number of ROAs in the global RPKI 351 The number of ROAs in the global RPKI does not depend on the number 352 of CAs. A small organisation may have only 1 ROA, while a large 353 organisation will need many. Instead it is expected that the number 354 of ROAs is related to the number of intended announcements that are 355 seen in the global BGP. The current routing table has roughly 356 500.000 such announcements, but the size of the table has been 357 growing steadily. 359 It should be noted that ROAs can be used to authorise more than one 360 announcement, but there are restrictions: 362 o The ASN must be the same. 364 o The prefixes must all be held by the CA. 366 o Furthermore the prefixes must occur on the same parent 367 certificate. In other words: if an organisation has signed 368 resources from more than one source they can not be aggregated on 369 the same ROA. 371 Statistics for the RIPE region indicate that an aggregation factor of 372 3 announcements per ROA is reasonable. This would put the expected 373 number of ROAs in the order of 200.000. 375 4.4.2.4. Number of router certificates in the global RPKI 377 The number of router certificates depends on the number of keys that 378 will be used by BGPSec speaking routers. 380 At a specific ASN, different physical BGPSec speaking routers MAY use 381 the same key, and therefore may require only one certificate for that 382 key. On the other hand to support BGPSec roll-overs it may be 383 advisable to publish not one, but two keys at the same time. Plus 384 some operators may choose to use unique keys per physical router. 386 All in all it is not entirely clear to the authors how many certified 387 keys may be, but on list numbers as high as 2.000.000 have been 388 mentioned. 390 4.4.2.5. Total number of objects in the global RPKI 392 Using the number of objects cited in the previous sections, we can 393 describe the total number of objects in the RPKI with the formula: 395 Ototal = #CAorganisations * #Avg_CAcert_per_organisation * 4 + #ROAs 396 + #Router Certs 398 Ototal = 200k * ~1 * 4 + 200k + 2M = 3M 400 4.4.2.6. Total size of objects in the global RPKI 402 Based on the current repositories deployed by the RIRs we find these 403 average sizes for different object types: 405 +---------------------+-------------------------------+-------------+ 406 | type | size (bytes) | size in | 407 | | | model | 408 +---------------------+-------------------------------+-------------+ 409 | CA certificate | 1416 | 1.5 kB | 410 | Manifest | 1951 | 2 kB | 411 | CRL | 692 | 0.7 kB | 412 | ROA | 1846 | 2 kB | 413 | Ghostbuster record | unknown, expect similar to | 1.5 kB | 414 | | ROA | | 415 | Router certificate | unknown, expect similar to CA | 2 kB | 416 | | certificate | | 417 +---------------------+-------------------------------+-------------+ 419 We use rounded off decimal numbers for our calculations for 420 simplicity, and because our predictions are intended to give an idea 421 of the expected order of magnitude of the repository size only. 423 Using these numbers we can predict a global repository size with the 424 formula: 426 Stotal = #CAorganisations * ( CA_certificate_size + MFT_size + 427 CRL_size + GB_size) + #ROAs * ROA_size + #Router Certs * 428 Router_Cert_size 430 Stotal = 200k * ( 1.5k + 2k + 0.7k + 2k) + 200k * 2k + 2M * 2k 432 Stotal = 4.6G 434 4.4.3. Churn 436 The daily churn in the RPKI, i.e. the amount of new objects we're 437 expected to see, per 24 hours is another important factor to consider 438 in the context of scalability 440 The current RIR managed RPKI services typically update MFT and CRLs 441 for each CA every 8 hours, accounting for a churn of 200k * 2 * (24 442 hours / 8 hours) = 1.2 M objects per 24 hour (833 per minute). The 443 volume of this churn is expected to amount to 200k * (2kB + 0.7kB) * 444 (24 hours / 8 hours) = 1.6 GB per 24 hour = 1.1 MB per minute. 446 The expected churn in ROAs and router certificates are expected to 447 depend on: 449 o The amount of new planned announcements in BGP 451 o The average number of routers requiring new keys being rolled-out 452 daily. 454 o BGP Sec key roll-overs 456 We have no clear idea about these numbers at this time, but we expect 457 this number to be relatively small compared to the churn rate caused 458 by republishing MFTs and CRLs. 460 4.4.4. Number of Relying Parties 462 It seems plausible that in a full deployment scenario each ASN will 463 run at least two RP tool instance (one back-up). 465 There are currently around 40.000 ASNs in the global BGP, so this 466 would suggest a number of 80.000 distinct client RPs accessing 467 repositories. 469 Others have suggested that RPs can use (file) sharing techniques to 470 reduce their dependency on central repository servers. If this 471 approach would be deployed this could reduce the number of RPs that 472 central repository servers have to serve. We expect though that this 473 sharing will be mostly used to ensure redundancy with an ASN, and 474 much less between ASNs. 476 4.4.5. Fetch frequency of Relying Parties 478 The repository servers have little control of the fetch frequencies 479 used by Relying Parties. As mentioned in section 3.2 Relying Parties 480 have an interest in fetching new information much more frequently 481 than they do currently. It's not clear right now what frequency will 482 be most common in a full deployment scenario. We expect though that 483 the desired update frequency will be in the order of every ten 484 minutes. This seems to be in-line with operator time scale changes 485 that would have to be made in BGP and the RPKI. 487 4.5. Expected RPKI Repository Requirements 489 4.5.1. Objects and Relying Parties 491 It should be noted that repository servers have no control over 492 relying parties. RPs are responsible for their own infrastructure 493 and keeping up to date. Well functioning RPs will try to stay up to 494 date at all times, while avoiding to overload the server(s). Badly 495 configured RPs may however fail to retrieve updates, or they may 496 insist on checking for updates at a well-above average rate and cause 497 additional server load. 499 Having said that we believe that we can stipulate some ball park 500 parameters that large repositories should be prepared to deal with 501 based on the estimates mentioned in the previous section. 503 The numbers below all assume averages of well behaved RPs. In 504 reality repositories will have to deal with peak loads that may 505 result from a number of different factors, like: 507 o A large number of updates is available 509 o The number of RP connections is not evenly distributed 511 o There is an attack on the server 512 Defining these factors in formulas is however fairly complicated. 513 The authors believe that it is a more pragmatic and useful strategy 514 to take the naive estimates defined below as a starting point and 515 require that new protocols are load tested to a degree where we can 516 be confident that new implementations will be able to meet the normal 517 load requirements easily, as well as peak load conditions that may 518 exceed normal load by factors of 5-10. 520 4.5.2. Update related throughput 522 We define "throughput" as the total number of RP connections that the 523 repository can server per minute. Note that this does not imply 524 anything about the time each connection takes. 526 By definition the server has to be able to process a number of 527 connections per time unit that is at least equal, and preferably 528 comfortably bigger, than the number of new connections that are 529 expected over that time unit. Failure to meet this number will 530 inevitably lead to a build-up of client connections to the point 531 where the server will no longer be able to accept new connections 533 Based on 80k RP tools fetching updates every 10 minutes we may assume 534 that a throughput number of 8k connections / min. is the bare 535 minimum that needs to be supported. 537 4.5.3. Update related concurrency 539 Another interesting load factor is given by the number of expected 540 concurrent connections. A naive formula for this number is given by: 542 #Concurrent connections = #New Connections (conn / minute) * # Avg 543 processing time (min / conn) 545 E.g. if it would take 30 seconds to process the average connection, 546 we would need to support: 548 8k conn/min * 0.5 min/conn = 4k concurrent RPs 550 4.5.4. Update related traffic volume 552 Based un RPs getting deltas alone we expect that the volume of data 553 that the repository server has to serve per minute can be determined 554 by the formula: 556 Vol_min = Churn_vol_min * #RPs 558 Vol_min = 1.1 M/min * 80k = 88 GB/min 560 4.6. Reduce Load on Central Repositories 562 In a full deployment scenario a large number of RPs are expected to 563 approach a single repository server regularly. Estimates of how 564 large this number of RPs is, and how regularly they will fetch 565 updates, vary. However as a starting point one might expect one RP 566 tool for each ASN, currently 40k, to fetch updates every five 567 minutes. Whatever the real numbers may be it should be noted that 568 the repository server has very little control over these numbers. 570 Because of this it makes sense to look into a delta protocol where 571 the number of clients and frequency of fetching, has the least 572 possible effect on the central repository server. E.g by enabling 573 pre-computing of updates and offloading to caches or CDNs. 575 Although this may result in a protocol that causes the Relying Party 576 to do more work, the trade-off of offloading CPU cycles to a large 577 number of frequently polling RPs as opposed to spending CPU on the 578 server is expected to scale much better. 580 4.7. Update notifications 582 Higher update frequencies and shorter propagation times are desired. 583 On the other hand it would also be good if unnecessary 584 synchronisation attempts were prevented to reduce load. For this 585 reason a delta protocol would do well to support update notifications 586 to RPs. Both push and poll based strategies may be used for this 587 purpose. 589 4.8. Reduce Churn 591 A large part of the churn in the RPKI is caused by the regular 592 republishing of Manifests and CRLs. If this frequency could be 593 reduced without compromising security, such as an RP's sensitivity to 594 replay attacks, then the total load on repository servers could be 595 reduced significantly. 597 4.9. Signed Deltas 599 It should be noted that although RPs retrieve objects from untrusted 600 sources, these objects are cryptographically validated. In other 601 words a publisher, or monkey-in-the-middle, can not mislead the RP 602 and generate valid objects without having access to the associated 603 private keys. Having said that, this still leaves RPs vulnerable to 604 attacks where information is withheld or replayed. RPs can notice 605 such attacks if they rely on manifests to inform them about: 607 o which objects should be expected 608 o when the next update is expected at the latest 610 If deltas were signed it would be possible for RPs to detect attacks 611 or transport errors sooner. However, signing deltas comes at a cost 612 of complexity. In particular it will be difficult to communicate 613 keys used for signing in a secure and dynamic (allow rolls) way. The 614 benefit seems too limited to warrant this. 616 5. Security Considerations 618 TBD 620 6. Acknowledgements 622 TBD 624 7. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 Authors' Addresses 631 Tim Bruijnzeels 632 RIPE NCC 634 Email: tim@ripe.net 636 Oleg Muravskiy 637 RIPE NCC 639 Email: oleg@ripe.net 641 Bryan Weber 642 Cobenian 644 Email: bryan@cobenian.com