idnits 2.17.1 draft-ietf-dtn-bibect-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2019) is 1720 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BP' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track August 4, 2019 4 Expires: February 5, 2020 6 Bundle-in-Bundle Encapsulation 7 draft-ietf-dtn-bibect-02.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on February 5, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 50 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence 51 layer" protocol that tunnels BP "bundles" through encapsulating 52 bundles. The services provided by the BIBE convergence-layer 53 protocol adapter encapsulate an outbound BP "bundle" in a BIBE 54 convergence-layer protocol data unit for transmission as the payload 55 of a bundle. Security measures applied to the encapsulating bundle 56 may augment those applied to the encapsulated bundle. The protocol 57 includes a mechanism for recovery from loss of an encapsulating 58 bundle, called "custody transfer". This mechanism is adapted from 59 the custody transfer procedures described in the experimental Bundle 60 Protocol specification developed by the Delay-Tolerant Networking 61 Research group of the Internet Research Task Force and documented in 62 RFC 5050. 64 Table of Contents 66 1. Introduction...................................................2 67 2. Conventions used in this document..............................4 68 3. BIBE Design Elements...........................................4 69 3.1. BIBE Endpoints............................................4 70 3.2. BIBE Protocol Data Units..................................4 71 3.3. Custody Signals...........................................6 72 3.4. Custody Transfer Status Reports...........................7 73 4. BIBE Procedures................................................8 74 4.1. BPDU Transmission.........................................8 75 4.2. BPDU Reception............................................8 76 4.3. Retransmission Timer Expiration..........................10 77 4.4. Custody Signal Reception.................................10 78 5. Security Considerations.......................................11 79 6. IANA Considerations...........................................11 80 7. References....................................................11 81 7.1. Normative References.....................................11 82 7.2. Informative References...................................11 83 8. Acknowledgments...............................................11 84 Appendix A. For More Information.................................13 85 Appendix B. CDDL expression......................................14 87 1. Introduction 89 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 90 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [BP] 91 "convergence layer" protocol that tunnels BP "bundles" through 92 encapsulating bundles. 94 Conformance to the bundle-in-bundle encapsulation (BIBE) 95 specification is OPTIONAL for BP nodes. Each BP node that conforms 96 to the BIBE specification provides a BIBE convergence-layer adapter 97 (CLA) that is implemented within the administrative element of the 98 BP node's application agent. Like any convergence-layer adapter, 99 the BIBE CLA provides: 101 . A transmission service that sends an outbound bundle (from the 102 bundle protocol agent) to a peer CLA. In the case of BIBE, the 103 sending CLA and receiving peer CLA are both BP nodes. 104 . A reception service that delivers to the bundle protocol agent 105 an inbound bundle that was sent by a peer CLA (itself a BP 106 node) via the BIBE convergence layer protocol. 108 The BIBE CLA performs these services by: 110 . Encapsulating outbound bundles in BIBE protocol data units, 111 which take the form of Bundle Protocol administrative records 112 as described later. 113 . Requesting that the bundle protocol agent transmit bundles 114 whose payloads are BIBE protocol data units. 115 . Taking delivery of BIBE protocol data units that are the 116 payloads of bundles received by the bundle protocol agent. 117 . Delivering to the bundle protocol agent the bundles that are 118 encapsulated in delivered BIBE protocol data units. 120 Bundle-in-bundle encapsulation may have broad utility, but the 121 principal motivating use case is the deployment of "cross domain 122 solutions" in secure communications. Under some circumstances a 123 bundle may arrive at a node that is on the frontier of a sector of 124 network topology in which augmented security is required, from which 125 the bundle must egress at some other designated node. In that case, 126 the bundle may be encapsulated within a bundle to which the 127 requisite additional BP Security (BPSEC) [bpsec] extension block(s) 128 can be attached, whose source is the point of entry into the 129 insecure region (the "security source") and whose destination is the 130 point of egress from the insecure region (the "security 131 destination"). 133 Note that: 135 . If the payload of the encapsulating bundle is protected by a 136 Bundle Confidentiality Block (BCB), then the source and 137 destination of the encapsulated bundle are encrypted, providing 138 defense against traffic analysis that BPSEC alone cannot offer. 139 . Bundles whose payloads are BIBE protocol data units may 140 themselves be forwarded via a BIBE convergence-layer adapter, 141 enabling nested bundle encapsulation to arbitrary depth as 142 required by security policy. 143 . Moreover, in the event that no single point of egress from an 144 insecure region of network topology can be determined at the 145 moment a bundle is to be encapsulated, multiple copies of the 146 bundle may be encapsulated individually and forwarded to all 147 candidate points of egress. 149 The protocol includes a mechanism for recovery from loss of an 150 encapsulating bundle, called "custody transfer". This mechanism is 151 adapted from the custody transfer procedures described in the 152 experimental Bundle Protocol specification developed by the Delay- 153 Tolerant Networking Research group of the Internet Research Task 154 Force and documented in RFC 5050 [RFC5050]. Custody transfer is a 155 convention by which the loss or corruption of BIBE encapsulating 156 bundles can be mitigated by the exchange of other bundles, which are 157 termed "custody signals". 159 2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC-2119 [RFC2119]. 165 In this document, these words will appear with that interpretation 166 only when in ALL CAPS. Lower case uses of these words are not to be 167 interpreted as carrying RFC-2119 significance. 169 3. BIBE Design Elements 171 3.1. BIBE Endpoints 173 BIBE convergence-layer protocol endpoints, also known as BIBE 174 convergence-layer adapters (BCLAs), are the Administrative Elements 175 of Bundle Protocol nodes that conform to the BIBE protocol 176 specification. The node of which a given BCLA is one component is 177 termed the BCLA's "local node". 179 3.2. BIBE Protocol Data Units 181 Notionally, a BCLA is assumed to implement in some way, for each 182 custodial node to which the local node issues BIBE Protocol Data 183 Units (BPDUs), the following two data resources: 185 1. A "custodial transmission count" (CTC). A CTC is a 186 monotonically increasing integer indicating the number of 187 "custodial" BPDUs - that is, BPDUs for which custody transfer 188 was requested - that have been issued to the custodial node by 189 the local node since instantiation of the local node. 190 2. A "custodial transmission database" (CTDB), a notional array of 191 "custodial transmission items" (CTIs). The CTDB contains one 192 CTI for each custodial BPDU issued to the custodial node, by 193 the local node, for which (a) no custody disposition has yet 194 been received in any custody signal (as discussed later) and 195 (b) the bundle encapsulated in that BPDU has not yet been 196 destroyed due to, e.g., time-to-live expiration. Each CTI 197 notionally contains: 198 a. A reference to the bundle encapsulated in the 199 corresponding BPDU. 200 b. The "transmission ID" of the corresponding BPDU, as 201 discussed below. 202 c. A "retransmission time" indicating the time by which 203 custody disposition for the corresponding BDPU is 204 expected. 206 A BIBE protocol data unit is a Bundle Protocol administrative record 207 whose record type code is 3 (i.e., bit pattern 0011), constructed as 208 follows. 210 Each BPDU SHALL be represented as a CBOR array. The number of 211 elements in the array SHALL be 3. 213 The first item of the BPDU array SHALL be the "transmission ID" for 214 the BPDU, represented as a CBOR unsigned integer. The transmission 215 ID for a BPDU for which custody transfer is NOT requested SHALL be 216 zero. The transmission ID for a BPDU for which custody transfer IS 217 requested SHALL be the current value of the local node's custodial 218 transmission count, plus 1. 220 The second item of the BPDU array SHALL be the BPDU's retransmission 221 time (i.e., the time by which custody disposition for this BPDU is 222 expected), represented as a CBOR unsigned integer. Retransmission 223 time for a BPDU for which custody transfer is NOT requested SHALL be 224 zero. Retransmission time for a BPDU for which custody transfer IS 225 requested SHALL take the form of a "DTN Time" as defined in the 226 Bundle Protocol specification; determination of the value of 227 retransmission time is an implementation matter that is beyond the 228 scope of this specification and may be dynamically responsive to 229 changes in connectivity. 231 The third item of the BPDU array SHALL be a single BP bundle, termed 232 the "encapsulated bundle", represented as a CBOR byte string of 233 definite length. 235 3.3. Custody Signals 237 A "custody signal" is a Bundle Protocol administrative record whose 238 record type code is 4 (i.e., bit pattern 0100) and whose content is 239 constructed as follows. 241 The content of each custody signal SHALL be represented as a CBOR 242 array. The number of elements in the array SHALL be 2. 244 The first item of the custody signal content array SHALL be a 245 disposition code represented as a CBOR unsigned integer. Valid 246 disposition codes are defined as follows: 248 +---------+--------------------------------------------+ 250 | Value | Meaning | 252 +=========+============================================+ 254 | 0 | Custody accepted. | 256 +---------+--------------------------------------------+ 258 | 1 | No further information. | 260 +---------+--------------------------------------------+ 262 | 2 | Reserved for future use. | 264 +---------+--------------------------------------------+ 266 | 3 | Redundant (reception by a node that | 268 | | already has a copy of this bundle). | 270 +---------+--------------------------------------------+ 272 | 4 | Depleted storage. | 274 +---------+--------------------------------------------+ 276 | 5 | Destination endpoint ID unintelligible. | 278 +---------+--------------------------------------------+ 280 | 6 | No known route destination from here. | 281 +---------+--------------------------------------------+ 283 | 7 | No timely contact with next node on route. | 285 +---------+--------------------------------------------+ 287 | 8 | Block unintelligible. | 289 +---------+--------------------------------------------+ 291 | (other) | Reserved for future use. | 293 +---------+--------------------------------------------+ 295 Figure 1: Disposition Codes 297 The second item of the custody signal content array SHALL be a 298 "disposition scope report", represented as a CBOR indefinite-length 299 array. Each item of the disposition scope report array SHALL be a 300 "disposition scope sequence", represented as a CBOR array of two 301 elements. The first element of each disposition scope sequence 302 array SHALL be the first transmission ID in a sequence of 1 or more 303 consecutive transmission IDs corresponding to BPDUs to which the 304 custody signal's disposition is declared to apply; the second 305 element of each disposition scope sequence array SHALL be the number 306 of transmission IDs in that sequence. Both are represented as CBOR 307 unsigned integers. 309 A custody signal constitutes an assertion by the source of that 310 administrative bundle that the indicated disposition code applies to 311 all BPDUs identified by the transmission IDs enumerated in the 312 custody signal's disposition scope report. If the disposition code 313 is zero, then the source of the custody signal has accepted custody 314 of all bundles that were encapsulated in the indicated BPDUs. 315 Otherwise the source of the custody signal has refused custody of 316 all bundles that were encapsulated in the indicated BPDUs, for the 317 indicated reason. 319 3.4. Custody Transfer Status Reports 321 A "custody transfer status report" is a bundle status report with 322 the "reporting node attempted custody transfer" flag set to 1. 324 4. BIBE Procedures 326 4.1. BPDU Transmission 328 When a BCLA is requested by the bundle protocol agent to send a 329 bundle to the peer BCLA(s) included in the BP endpoint identified by 330 a specified BP endpoint ID: 332 . The BCLA SHALL generate, as defined in Section 6.2 of the 333 Bundle Protocol specification (a work in progress), a BPDU for 334 which the third element of the content array is the bundle that 335 is to be transmitted. The destination of the bundle whose 336 payload is the BPDU (termed the "encapsulating bundle") SHALL 337 be the specified BP endpoint. Selection of the values of the 338 parameters governing the forwarding of the encapsulating 339 bundle, other than the destination endpoint ID, is an 340 implementation matter. The parameter values governing the 341 forwarding of the BPDU's encapsulated bundle MAY be consulted 342 for this purpose. 343 . Note that any transmission request presented to a BCLA MAY 344 request that the transmission be subject to Custody Transfer, 345 provided that the destination EID of the request identifies a 346 singleton endpoint. 347 . If Custody Transfer is requested: 348 o The first element of the BPDU's content array MUST be the 349 BPDU's transmission ID, which SHALL be 1 more than the 350 current value of the BCLA's CTC for the node that is the 351 sole occupant of the BPDU's destination endpoint. 352 o The second element of the BPDU's content array MUST be the 353 BPDU's retransmission time as discussed in 3.2 above. 354 o The bundle protocol agent MUST add the retention constraint 355 "Custody accepted" to the encapsulated bundle. 356 o The BCLA MAY establish a retransmission timer for the 357 encapsulated bundle. If a retransmission timer is 358 established, it MUST be set to expire at the BPDU's 359 retransmission time. 360 . Otherwise, the first two elements of the BPDU's content array 361 MUST both be zero. 363 Note that the custody transfer retransmission timer mechanism 364 provides a means of recovering from loss of an encapsulating bundle 365 as indicated by non-arrival of a responding custody signal. 367 4.2. BPDU Reception 369 When a BCLA receives a BPDU from the bundle protocol agent (that is, 370 upon delivery of the payload of an encapsulating bundle): 372 . If Custody Transfer was requested for this BPDU (as indicated 373 by a non-zero value of transmission ID): 374 o If the encapsulated bundle has the same source node ID, 375 creation timestamp, and (if that bundle is a fragment) 376 fragment offset and payload length as another bundle that 377 is currently retained at the BCLA's local node, then 378 custody transfer redundancy MUST be handled as follows: 379 . The BCLA SHALL add the BPDU's transmission ID to the 380 disposition scope report of a pending outbound 381 custody signal, destined for the node that was the 382 source of the encapsulating bundle, whose disposition 383 is the reason code from Figure 1 for "Redundant 384 reception". 385 o Otherwise, if the BCLA determines that its local node can 386 neither deliver nor forward the encapsulated bundle for 387 any of the reasons listed in Figure 1, then custody 388 transfer has failed. Custody transfer failure SHALL be 389 handled as follows: 390 . The BCLA SHALL add the BPDU's transmission ID to the 391 disposition scope report of a pending outbound 392 custody signal, destined for the node that was the 393 source of the encapsulating bundle, whose disposition 394 is the reason code from Figure 2 that indicates the 395 reason for the custody transfer failure. 396 o Otherwise, custody transfer has succeeded: 397 . The BCLA SHALL add the BPDU's transmission ID to the 398 disposition scope report of a pending outbound 399 custody signal, destined for the node that was the 400 source of the encapsulating bundle, whose disposition 401 is zero (indicating that custody was accepted). 402 o In each of these three cases: 403 . The pending outbound custody signal MAY then be 404 issued immediately, but alternatively it MAY be 405 issued at some time in the future, possibly enabling 406 additional BPDUs' transmission IDs to be added to the 407 same disposition scope report. 408 . If the "request reporting of custody transfer 409 attempted" flag in the encapsulating bundle's status 410 report request field is set to 1, and status 411 reporting is enabled, a custody transfer status 412 report whose reason code is the same as the pending 413 outbound custody signal's disposition SHOULD be 414 generated, destined for the report-to endpoint of the 415 encapsulating bundle. 416 . If Custody Transfer was NOT requested for this BPDU, or if 417 Custody Transfer was requested for this BPDU and custody 418 transfer succeeded, then the encapsulated bundle SHALL be 419 delivered from the convergence layer adapter to the bundle 420 protocol agent, whereupon bundle reception SHALL be performed 421 as defined in section 5.6 of the Bundle Protocol specification 422 (a work in progress) as usual: the encapsulated bundle may be 423 forwarded, delivered, etc. 425 Note that the manner in which pending outbound custody signals are 426 managed, disposition scope reports are aggregated, and custody 427 signal transmission is initiated is an implementation matter that 428 is beyond the scope of this specification. Note, however, that 429 failure to deliver a custody signal prior to the earliest value of 430 retransmission time among all BPDUs enumerated in the custody 431 signal's disposition scope report may result in unnecessary 432 retransmission of one or more BPDUs. 434 4.3. Retransmission Timer Expiration 436 Upon expiration of a retransmission timer, the BCLA SHOULD remove 437 the corresponding CTI from the CTDB (destroying the associated 438 retransmission timer, if any) and notify the bundle protocol agent 439 that custodial transmission of the indicated bundle failed. This 440 notification may cause the indicated bundle to be re-forwarded 441 (possibly on a different route). 443 4.4. Custody Signal Reception 445 When a BCLA receives a custody signal from the bundle protocol agent 446 (that is, upon delivery of the payload of a custody-signal-bearing 447 bundle): 449 . If the custody signal's disposition is 0 (custody acceptance), 450 then for each transmission ID in the custody signal's 451 disposition scope report: 452 o The bundle protocol agent MUST remove the retention 453 constraint "Custody accepted" on the bundle referenced by 454 the corresponding CTI. 455 o The corresponding CTI MUST be removed from the CTDB 456 (destroying the associated retransmission timer, if any). 457 . Otherwise (custody refusal), for each transmission ID in the 458 custody signal's disposition scope report: 459 o The corresponding CTI MUST be removed from the CTDB 460 (destroying the associated retransmission timer, if any). 461 o Any further action taken by the BCLA is implementation- 462 specific and may depend on the reason code cited for the 463 refusal. For example, if the custody signal's reason code 464 was "Depleted storage", the BCLA might choose to notify 465 the bundle protocol agent that custodial transmission of 466 the indicated bundle failed. If the reason code was 467 "Redundant reception", on the other hand, this might cause 468 the BCLA simply to instruct the bundle protocol agent to 469 remove the retention constraint "Custody accepted" on the 470 bundle referenced by the corresponding CTI and to revise 471 its algorithm for computing retransmission time. 473 5. Security Considerations 475 An adversary on a DTN-based network that can delete bundles could 476 delete a BIBE custody signal in transit. This could result in 477 unnecessary custodial retransmission, degrading network performance. 479 Alternatively, an adversary on a DTN-based network that can reorder 480 bundles could cause bundles to be delivered to a BCLA in an order 481 that complicates the efficient construction of disposition scope 482 reports in pending outbound custody signals. This could result in 483 inefficient custody transfer communications, again degrading network 484 performance. 486 Custody transfer in BIBE may be contraindicated in environments 487 characterized by such attacks. 489 6. IANA Considerations 491 The BIBE specification requires IANA registration of the new BIBE 492 administrative records (type codes 3 and 4) defined above. 494 7. References 496 7.1. Normative References 498 [BP] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 499 Version 7", Work In Progress, August 2019. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 7.2. Informative References 506 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 507 Specification", RFC 5050, November 2007. 509 8. Acknowledgments 511 This work is freely adapted from [RFC5050], which was an effort of 512 the Delay Tolerant Networking Research Group. The following DTNRG 513 participants contributed significant technical material and/or 514 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 515 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 516 Michael Demmer of the University of California at Berkeley, Robert 517 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 518 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 519 College Dublin, Peter Lovell and Howard Weiss of SPARTA, Inc., and 520 Manikantan Ramadas of Ohio University. 522 The custody transfer procedures defined in this specification are 523 adapted from the Aggregate Custody Signals draft specification 524 authored in 2010-2012 by Sebastian Kuzminsky and Andrew Jenkins, 525 then of the University of Colorado at Boulder. 527 Although the BIBE specification diverges in some ways from the 528 original Bundle-in-Bundle Encapsulation Internet Draft authored by 529 Susan Symington, Bob Durst, and Keith Scott of The MITRE Corporation 530 (draft-irtf-dtnrg-bundle-encapsulation-06, 2009), the influence of 531 that earlier document is gratefully acknowledged. 533 This document was prepared using 2-Word-v2.0.template.dot. 535 Appendix A. For More Information 537 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 538 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 540 Copyright (c) 2019 IETF Trust and the persons identified as authors 541 of the code. All rights reserved. 543 Redistribution and use in source and binary forms, with or without 544 modification, is permitted pursuant to, and subject to the license 545 terms contained in, the Simplified BSD License set forth in Section 546 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 547 (http://trustee.ietf.org/license-info). 549 Appendix B. CDDL expression 551 For informational purposes, Carsten Bormann has kindly provided an 552 expression of the Bundle Protocol specification in the CBOR Data 553 Definition Language (CDDL). Portions of CDDL expression that bear 554 on the custody transfer extension are presented below, somewhat 555 edited by the authors. Note that wherever the CDDL expression is in 556 disagreement with the textual representation of the BP specification 557 presented in the earlier sections of this document, the textual 558 representation rules. 560 admin-record-choice /= BIBE-PDU 562 BIBE-PDU = [3, [transmission-ID: uint, 564 retransmission-time: uint, 566 encapsulated-bundle: bytes, 568 admin-common]] 570 admin-record-choice /= custody-signal 572 custody-signal = [4, [disposition-code: uint, 574 disposition-scope-report, 576 admin-common]] 578 disposition-scope-report = *disposition-scope-sequence 580 disposition-scope-sequence = [first-transmission-ID: uint, 582 number-of-transmission-IDs: uint] 584 Authors' Address 586 Scott Burleigh 587 Jet Propulsion Laboratory, California Institute of Technology 588 4800 Oak Grove Dr. 589 Pasadena, CA 91109-8099 590 US 591 Phone: +1 818 393 3353 592 Email: Scott.Burleigh@jpl.nasa.gov