idnits 2.17.1 draft-ietf-btns-core-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 521. 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 Copyright Line does not match the current year == Line 223 has weird spacing: '... addr addr ...' == Line 293 has weird spacing: '... addr addr ...' == Line 326 has weird spacing: '... addr addr ...' -- 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 (July 26, 2007) is 6090 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) == Missing Reference: 'Q' is mentioned on line 358, but not defined == Missing Reference: 'R' is mentioned on line 248, but not defined == Missing Reference: 'A' is mentioned on line 345, but not defined == Missing Reference: 'B' is mentioned on line 345, but not defined == Missing Reference: 'C' is mentioned on line 359, but not defined == Missing Reference: 'D' is mentioned on line 185, but not defined == Missing Reference: 'SG-A' is mentioned on line 354, but not defined == Missing Reference: 'SG-B' is mentioned on line 308, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-00 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-03 == Outdated reference: A later version (-04) exists of draft-williams-on-channel-binding-00 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track M. Richardson 5 Expires: January 27, 2008 SSW 6 July 26, 2007 8 Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec 9 draft-ietf-btns-core-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies how to use the Internet Key Exchange (IKE) 43 protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" 44 security associations (SAs) for use with the IPsec Encapsulating 45 Security Payload (ESP) and the IPsec Authentication Header (AH). No 46 changes to IKEv2 bits-on-the-wire are required, but Peer 47 Authorization Database (PAD) and Security Policy Database (SPD) 48 extensions are specified. Unauthenticated IPsec is herein referred 49 to by its popular acronym, "BTNS" (Better Than Nothing Security). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . . 3 55 2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Example #1: A security gateway . . . . . . . . . . . . . . . 6 58 3.2. Example #2: A mixed end-system . . . . . . . . . . . . . . . 8 59 3.3. Example #3: A BTNS-only system . . . . . . . . . . . . . . . 9 60 3.4. Miscellaneous comments . . . . . . . . . . . . . . . . . . . 10 61 4. Security Considerations . . . . . . . . . . . . . . . . . . 11 62 4.1. Connection-Latching and Channel Binding . . . . . . . . . . 11 63 4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 14 68 7.2. Informative References . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 70 Intellectual Property and Copyright Statements . . . . . . . 16 72 1. Introduction 74 Here we describe how to establish unauthenticated IPsec SAs using 75 IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire 76 protocol elements are added to IKEv2. 78 The [RFC4301] processing model is assumed. 80 This document does not define an opportunistic BTNS mode of IPsec 81 whereby nodes may fallback to unprotected IP when their peers do not 82 support IKEv2, nor does it describe "leap-of-faith" modes, or 83 "connection latching." 85 See [I-D.ietf-btns-prob-and-applic] for the applicability and uses of 86 BTNS and definitions of these terms. 88 This document describes BTNS in terms of IKEv2 and [RFC4301]'s 89 concepts. There is no reason why the same methods cannot be used 90 with IKEv1 [RFC2408] [RFC2409] and [RFC2401], however, those 91 specifications do not include the PAD concepts, and therefore it may 92 not be possible to implement BTNS on all compliant RFC2401 93 implementations. 95 1.1. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. BTNS 103 The IPsec processing model is hereby modified as follows: 105 o A new ID type is added, 'PUBLICKEY'; IDs of this type have public 106 keys as values. This ID type is not used on the wire. 108 o A BTNS-specific PAD entry. This entry MUST be the last entry in 109 the PAD when BTNS is enabled. A peer that matches no other PAD 110 entries is to be "authenticated" by verifying that the signature 111 in its AUTH payload in the IKEv2 exchange with the public key from 112 the peer's CERT payload. The peer's ID MUST then be coerced to be 113 of 'PUBLICKEY' type with the peer's public key as its value. 115 o To accomplish the above, search the PAD as normal, with the ID 116 provided by the peer. If it matches do normal processing. If the 117 ID asserted by a peer does not match any PAD entry, then a BTNS- 118 enabled IPsec implementation replaces the ID with into the new ID 119 of type "PUBLICKEY" that is created by extracting the public key 120 from the IKE CERT payload. 122 o The PAD is searched again, using this new ID type and value. If 123 there is a match, the associated PAD entry (which will be a BTNS 124 entry) is used to control the SPD search. 126 o If there is no match, the IKE SA is rejected 128 o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that 129 match the BTNS PAD entry will match only SPD entries that have the 130 BTNS_OK flag set. The SPD may be searched by address or by ID (of 131 type PUBLICKEY, for BTNS peers), as per the IPsec processing model 132 [RFC4301]; searching by ID in this case requires creation of SPD 133 entries that are bound to public key values (this could be used to 134 build "leap-of-faith" [I-D.ietf-btns-prob-and-applic] Section 4.2 135 behaviour, for example). 137 Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD 138 entries but fail to authenticate properly. 140 Nodes wishing to be treated as BTNS nodes by their peers MUST include 141 bare RSA key CERT payloads. Nodes MAY also include any number of 142 certificates that bind the same public key. These certificates need 143 not to have been pre-shared with their peers (e.g., because ephermal, 144 self-signed). RSA keys for use in BTNS may be generated at any time, 145 but "connection latching" [I-D.ietf-btns-connection-latching] 146 requires that they remain constant between IKEv2 exchanges that are 147 used to establish SAs for latched connections. 149 To preserve standard IPsec access control semantics the BTNS PAD 150 entry MUST be last (lowest priority), and it MUST have ID constraints 151 that do not overlap those of other PAD entries. 153 This can easily be implemented by searching the PAD twice. Once when 154 BTNS peers authenticate and a second time when BTNS peers negotiate 155 child SAs. In the first pass the PAD is searched for a matching PAD 156 entry as usual, and in the second it is searched to make sure that 157 BTNS peers' asserted child SA traffic selectors do not conflict with 158 non-BTNS PAD entries. 160 3. Usage Scenarios 162 In order to explain the above rules a number of scenarios will be 163 examined. The goal here is to persuade the reader that the above 164 rules are both sufficient and necessary. 166 To explain the scenarios a reference diagram describing an example 167 network will be used. It is as follows: 169 [Q] [R] 170 AS1 . . AS2 171 [A]----+----[SG-A].......+....+.......[SG-B]-------[B] 172 ...... \ 173 ..PI.. ----[btns-B] 174 ...... 175 [btns-C].....+....+.......[btns-D] 177 Figure 1: Reference Network Diagram 179 In this diagram, there are six end-nodes: A, B, C and D. Two of the 180 systems are security gateways: SG-A, SG-B, protecting networks on 181 which [A] and [B] reside. There is a node [Q] which is IPsec and 182 BTNS capable, and node [R] is a simple node, with no IPsec or BTNS 183 capability. Nodes [C] and [D] are BTNS capable. 185 Nodes [C] and [Q] have fixed addresses. Node [D] has a non-fixed 186 address. 188 We will examine how these various nodes communicate with node SG-A, 189 and/or how SG-A rejects communications with some such nodes. In the 190 first example, we examine SG-A's point of view. In the second 191 example we look at Q's point of view. In the third example we look 192 at C's point of view. 194 PI is the Public Internet ("The Wild"). 196 3.1. Example #1: A security gateway 198 The machine that we will care in this example is [SG-A], a firewall 199 device of some kind which we wish to configure to respond to BTNS 200 connections from [C]. 202 SG-A has the following PAD and SPD entries: 204 Child SA 205 Rule Remote ID IDs allowed SPD Search by 206 ---- --------- ----------- ------------- 207 1 by-IP 208 2 by-IP 209 3 PUBLICKEY:any ANY by-IP 211 The last entry is the BTNS entry. 213 Figure 2: SG-A PAD table 215 Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry: 216 the BTNS catch-all PAD entry as the last entry, as described in 217 Section 2. 219 and are from [RFC4301] section 220 4.4.3 222 Rule Local Remote Next Layer BTNS Action 223 addr addr Protocol ok 224 ---- ----- ------ ---------- ---- ----------------------- 225 1 [A] [R] ANY N/A BYPASS 226 2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES, 227 SHA256) 228 3 [A] B-net ANY no PROTECT(ESP,tunnel,AES, 229 SHA256) 230 4 [A] ANY ANY yes PROTECT(ESP,transport, 231 integr+conf) 233 Figure 3: [SG-A] SPD table 235 The processing by [SG-A] of SA establishment attempts by various 236 peers is as follows: 238 o [Q] does not match PAD entry #1, but does match PAD entry #2; PAD 239 processing stops, then the SPD is searched by [Q]'s ID to find 240 entry #2; CHILD SAs are then allowed that have [SG-A]'s and [Q]'s 241 addresses as the end-point addresses. 243 o [SG-B] matches PAD entry #1; PAD processing stops, then the SPD is 244 searched by [SG-B]'s ID to find SPD entry #3; CHILD SAs are then 245 allowed that have [SG-A]'s address and any addresses from B's 246 network as the end-point addresses. 248 o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed 249 by SPD entry #1. 251 o [C] does not match PAD entries #1 or #2, but does match entry #3, 252 the BTNS wildcard PAD entry; the SPD is searched by [C]'s address 253 and SPD entry #4 is matched. CHILD SAs are then allowed that have 255 [SG-A]'s address and [C]'s address as the end-point addresses 256 provided that [C]'s address is neither [Q]'s nor any of [B]'s (see 257 Section 2). 259 o A rogue BTNS node attempting to assert [Q]'s or [B]'s addresses 260 will either match the PAD entries for [Q] or [B] and fail to 261 authenticate as [Q] or [B], in which case they are rejected, or 262 they will match PAD entry #3 but will not be allowed to create 263 CHILD SAs with [Q]'s or [B]'s addresses as traffic selectors. 265 o A rogue BTNS nodes attempting to assert [C]'s address will 266 succeed. Protection for [C] requires additional bindings of [C]'s 267 specific BTNS ID (that is, its public key) to its traffic flows 268 through connection-latching and channel binding, or leap-of-faith, 269 none of which are described here. 271 3.2. Example #2: A mixed end-system 273 [Q] is an NFSv4 server. 275 [Q] is a native IPsec implementation, and it's NFSv4 implementation 276 is IPsec-aware. 278 [Q] wants to protect all traffic with [A]. [Q] also wants to protect 279 NFSv4 traffice with all peers. It's PAD and SPD are configured as 280 follows: 282 Child SA 283 Rule Remote ID IDs allowed SPD Search by 284 ---- --------- ----------- ------------- 285 1 <[A]'s ID> <[A]'s address> by-IP 286 2 PUBLICKEY:any ANY by-IP 288 The last entry is the BTNS entry. 290 Figure 4: [Q] PAD table 292 Rule Local Remote Next Layer BTNS Action 293 addr addr Protocol ok 294 ---- ----- ------ ---------- ---- ----------------------- 295 1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES, 296 SHA256) 297 2 [Q] ANY ANY yes PROTECT(ESP,transport, 298 with integr+conf) 299 port 2049 300 Figure 5: [Q] SPD table 302 The same analysis shown above in Section 3.1 applies here with 303 respect to [SG-A], [C] and rogue peers. The second SPD entry permits 304 any BTNS capable node to negotiate a port-specific SA to port 2049, 305 the port on which NFSv4 runs. Additionally [SG-B] is treated as a 306 BTNS peer as it is not known to [Q], and therefore any host behind 307 [SG-B] can access the NFSv4 service on [Q]. As [Q] has no formal 308 relationship with [SG-B], rogues can impersonate [B] (i.e., assert 309 [B]'s addresses). 311 3.3. Example #3: A BTNS-only system 313 [C] supports only BTNS and wants to use BTNS to protect NFSv4 314 traffic. It's PAD and SPD are configured as follows: 316 Child SA 317 Rule Remote ID IDs allowed SPD Search by 318 ---- --------- ----------- ------------- 319 1 PUBLICKEY:any ANY by-IP 321 The last (and only) entry is the BTNS entry. 323 Figure 6: Q PAD table 325 Rule Local Remote Next Layer BTNS Action 326 addr addr Protocol ok 327 ---- ----- ------ ---------- ---- ----------------------- 328 1 [C] ANY ANY yes PROTECT(ESP,transport, 329 with integr+conf) 330 port 331 2049 333 2 [C] ANY ANY N/A BYPASS 335 Figure 7: SG-A SPD table 337 The analysis from Section 3.1 applies as follows: 339 o Communication with [Q] on port 2049 matches SPD entry number 1. 340 This causes [C] to initiate an IKEv2 exchange with [Q]. The PAD 341 entry on [C] causes it to not care what identity [Q] asserts. 342 Further authentication (and channel binding) could occur within 343 the NFSv4 protocol. 345 o Communication with [A], [B] or any other internet machine 346 (including [Q]), occurs in the clear, so long as it is not on port 347 2049. 349 o All analysis about rogue BTNS nodes applies, but they can only 350 assert SAs for port 2049. 352 3.4. Miscellaneous comments 354 If [SG-A] were not BTNS-capable then it would not have PAD and SPD 355 entries #3 and #4, respectively in example #1. Then [C] would be 356 rejected as usual under the standard IPsec model [RFC4301]. 358 Similarly, if [Q] were not BTNS-capable then it would not have PAD 359 and SPD entries #2 in example #2. Then [C] would be rejected as 360 usual under the standard IPsec model [RFC4301]. 362 4. Security Considerations 364 Unauthenticated security association negotiation is subject to MITM 365 attacks and should be used with care. Where security infrastructures 366 are lacking this may indeed be better than nothing. 368 Use with applications that bind authentication at higher network 369 layers to secure channels at lower layers may provide one secure way 370 to use unauthenticated IPsec, but this is not specified herein. 372 The BTNS PAD entry must be last and its child SA ID constraints must 373 be non-overlapping with any other PAD entry, as described in section 374 2, in order to ensure that no BTNS peer can impersonate another IPsec 375 non-BTNS peer. 377 4.1. Connection-Latching and Channel Binding 379 BTNS is subject to MITM attacks. One way to protect against MITM 380 attacks subsequent to initial communications is to use "connection 381 latching" [I-D.ietf-btns-connection-latching]. In connection 382 latching, ULPs cooperate with IPsec to bind discrete packet flows to 383 sequences of similar SAs. Connection latching requires native IPsec 384 implementations. 386 MITMs can be detected by using application-layer authentication 387 frameworks and/or mechanisms, such as the GSS-API [RFC2743], with 388 channel binding [I-D.williams-on-channel-binding]. IPsec "channels" 389 are nothing other than latched connnections. 391 4.2. Leap-of-Faith (LoF) for BTNS 393 "Leap of faith" is the term generally used when a user accepts the 394 assertion that a given key identifies a peer on the first 395 communication, despite a lack of strong evidence for that assertion, 396 and then remembers this association for future communications. 397 Specifically this is a common mode of operation for Secure Shell 398 [RFC4251] client. When a server is encountered for the first time 399 the Secure Shell client may ask the user whether to accept the 400 server's public key. If so, records the server's name (as given by 401 the user) and public key in a database. 403 Leap of faith can work in a similar way for BTNS nodes, but it is 404 currently still being designed and specified by the IETF BTNS WG. 406 5. IANA Considerations 408 This document has no IANA considerations, neither seeking to create 409 new registrations nor new registries. (The new ID type is not used 410 on the wire, therefore it need not be assigned a number from the IANA 411 IKEv2 Identification Payload ID Types registry.) 413 6. Acknowledgements 415 Thanks for the following reviewers: Stephen Kent 417 7. References 419 7.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 425 Internet Protocol", RFC 4301, December 2005. 427 7.2. Informative References 429 [I-D.ietf-btns-connection-latching] 430 Williams, N., "IPsec Channels: Connection Latching", 431 draft-ietf-btns-connection-latching-00 (work in progress), 432 February 2006. 434 [I-D.ietf-btns-prob-and-applic] 435 Touch, J., "Problem and Applicability Statement for Better 436 Than Nothing Security (BTNS)", 437 draft-ietf-btns-prob-and-applic-03 (work in progress), 438 June 2006. 440 [I-D.williams-on-channel-binding] 441 Williams, N., "On the Use of Channel Bindings to Secure 442 Channels", draft-williams-on-channel-binding-00 (work in 443 progress), August 2006. 445 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 446 Internet Protocol", RFC 2401, November 1998. 448 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 449 Security Association and Key Management Protocol 450 (ISAKMP)", RFC 2408, November 1998. 452 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 453 (IKE)", RFC 2409, November 1998. 455 [RFC2743] Linn, J., "Generic Security Service Application Program 456 Interface Version 2, Update 1", RFC 2743, January 2000. 458 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 459 Protocol Architecture", RFC 4251, January 2006. 461 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 462 RFC 4306, December 2005. 464 Authors' Addresses 466 Nicolas Williams 467 Sun Microsystems 468 5300 Riata Trace Ct 469 Austin, TX 78727 470 US 472 Email: Nicolas.Williams@sun.com 474 Michael C. Richardson 475 Sandelman Software Works 476 470 Dawson Avenue 477 Ottawa, ON K1Z 5V7 478 CA 480 Email: mcr@sandelman.ottawa.on.ca 481 URI: http://www.sandelman.ottawa.on.ca/ 483 Full Copyright Statement 485 Copyright (C) The IETF Trust (2007). 487 This document is subject to the rights, licenses and restrictions 488 contained in BCP 78, and except as set forth therein, the authors 489 retain all their rights. 491 This document and the information contained herein are provided on an 492 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 493 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 494 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 495 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 496 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 499 Intellectual Property 501 The IETF takes no position regarding the validity or scope of any 502 Intellectual Property Rights or other rights that might be claimed to 503 pertain to the implementation or use of the technology described in 504 this document or the extent to which any license under such rights 505 might or might not be available; nor does it represent that it has 506 made any independent effort to identify any such rights. Information 507 on the procedures with respect to rights in RFC documents can be 508 found in BCP 78 and BCP 79. 510 Copies of IPR disclosures made to the IETF Secretariat and any 511 assurances of licenses to be made available, or the result of an 512 attempt made to obtain a general license or permission for the use of 513 such proprietary rights by implementers or users of this 514 specification can be obtained from the IETF on-line IPR repository at 515 http://www.ietf.org/ipr. 517 The IETF invites any interested party to bring to its attention any 518 copyrights, patents or patent applications, or other proprietary 519 rights that may cover technology that may be required to implement 520 this standard. Please address the information to the IETF at 521 ietf-ipr@ietf.org. 523 Acknowledgment 525 Funding for the RFC Editor function is provided by the IETF 526 Administrative Support Activity (IASA).