7 Network Working Group B. Aboba
8 Request for Comments: 2607 Microsoft Corporation
9 Category: Informational J. Vollbrecht
14 Proxy Chaining and Policy Implementation in Roaming
18 This memo provides information for the Internet community. It does
19 not specify an Internet standard of any kind. Distribution of this
24 Copyright (C) The Internet Society (1999). All Rights Reserved.
28 This document describes how proxy chaining and policy implementation
29 can be supported in roaming systems. The mechanisms described in this
30 document are in current use.
32 However, as noted in the security considerations section, the
33 techniques outlined in this document are vulnerable to attack from
34 external parties as well as susceptible to fraud perpetrated by the
35 roaming partners themselves. As a result, such methods are not
36 suitable for wide-scale deployment on the Internet.
40 This document frequently uses the following terms:
43 The Network Access Server (NAS) is the device that clients contact
44 in order to get access to the network.
47 This is a server which provides for authentication/authorization
48 via the protocol described in [3], and for accounting as described
58 Aboba & Vollbrecht Informational [Page 1]
60 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
64 In order to provide for the routing of RADIUS authentication and
65 accounting requests, a RADIUS proxy can be employed. To the NAS,
66 the RADIUS proxy appears to act as a RADIUS server, and to the
67 RADIUS server, the proxy appears to act as a RADIUS client.
69 Network Access Identifier
70 In order to provide for the routing of RADIUS authentication and
71 accounting requests, the userID field used in PPP (known as the
72 Network Access Identifier or NAI) and in the subsequent RADIUS
73 authentication and accounting requests, can contain structure.
74 This structure provides a means by which the RADIUS proxy will
75 locate the RADIUS server that is to receive the request. The NAI
79 Roaming relationships include relationships between companies and
80 ISPs, relationships among peer ISPs within a roaming association,
81 and relationships between an ISP and a roaming consortia.
82 Together, the set of relationships forming a path between a local
83 ISP's authentication proxy and the home authentication server is
84 known as the roaming relationship path.
86 3. Requirements language
88 In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
89 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
94 Today, as described in [1], proxy chaining is widely deployed for the
95 purposes of providing roaming services. In such systems,
96 authentication/authorization and accounting packets are routed
97 between a NAS device and a home server through a series of proxies.
98 Consultation of the home server is required for password-based
99 authentication, since the home server maintains the password database
100 and thus it is necessary for the NAS to communicate with the home
101 authentication server in order to verify the user's identity.
114 Aboba & Vollbrecht Informational [Page 2]
116 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
119 4.1. Advantages of proxy chaining
121 Proxies serve a number of functions in roaming, including:
123 Scalability improvement
124 Authentication forwarding
125 Capabilities adjustment
126 Policy implementation
127 Accounting reliability improvement
130 Scalability improvement
131 In large scale roaming systems, it is necessary to provide for
132 scalable management of keys used for integrity protection and
135 Proxy chaining enables implementation of hierarchical
136 forwarding within roaming systems, which improves scalability
137 in roaming consortia based on authentication protocols without
138 automated key management. Since RADIUS as described in [3]
139 requires a shared secret for each client-server pair, a
140 consortium of 100 roaming partners would require 4950 shared
141 secrets if each partner were to contact each other directly,
142 one for each partner pair. However, were the partners to
143 route authentication requests through a central proxy, only
144 100 shared secrets would be needed, one for each partner. The
145 reduction in the number of partner pairs also brings with it
146 other benefits, such as a reduction in the number of bilateral
147 agreements and accounting and auditing overhead. Thus,
148 hierarchical routing might be desirable even if an
149 authentiation protocol supporting automated key exchange were
152 Capabilities adjustment
153 As part of the authentication exchange with the home server,
154 the NAS receives authorization parameters describing the
155 service to be provided to the roaming user. Since RADIUS,
156 described in [3], does not support capabilities negotiation,
157 it is possible that the authorization parameters sent by the
158 home server will not match those required by the NAS. For
159 example, a static IP address could be specified that would not
160 be routable by the NAS. As a result, capbilities adjustment is
161 performed by proxies in order to enable communication between
162 NASes and home servers with very different feature sets.
170 Aboba & Vollbrecht Informational [Page 3]
172 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
175 As part of capabilities adjustment, proxies can edit
176 attributes within the Access-Accept in order to ensure
177 compatibility with the NAS. Such editing may include
178 addition, deletion, or modification of attributes. In
179 addition, in some cases it may be desirable for a proxy to
180 edit attributes within an Access-Request in order to clean up
181 or even hide information destined for the home server. Note
182 that if the proxy edits attributes within the Access-Accept,
183 then it is possible that the service provided to the user may
184 not be the same as that requested by the home server. This
185 creates the possibility of disputes arising from inappropriate
186 capabilities adjustment.
188 Note that were roaming to be implemented based on an
189 authentication/authorization protocol with built-in capability
190 negotiation, proxy-based capabilities adjustment would
191 probably not be necessary.
193 Authentication forwarding
194 Since roaming associations frequently implement hierarchical
195 forwarding in order to improve scalability, in order for a NAS
196 and home server to communicate, authentication and accounting
197 packets are forwarded by one or more proxies. The path
198 travelled by these packets, known as the roaming relationship
199 path, is determined from the Network Access Identifier (NAI),
200 described in [6]. Since most NAS devices do not implement
201 forwarding logic, a proxy is needed to enable forwarding of
202 authentication and accounting packets. For reasons that are
203 described in the security section, in proxy systems it is
204 desirable for accounting and authentication packets to follow
207 Note: The way a proxy learns the mapping between NAI and the
208 home server is beyond the scope of this document. This
209 mapping can be accomplished by static configuration in the
210 proxy, or by some currently undefined protocol that provides
211 for dynamic mapping. For the purposes of this document, it is
212 assumed that such a mapping capability exists in the proxy.
214 Policy implementation
215 In roaming systems it is often desirable to be able to
216 implement policy. For example, a given partner may only be
217 entitled to use of a given NAS during certain times of the
218 day. In order to implement such policies, proxies may be
219 implemented at the interface between administrative domains
220 and programmed to modify authentication/authorization packets
221 forwarded between the NAS and the home server. As a result,
222 from a security point of view, a proxy implementing policy
226 Aboba & Vollbrecht Informational [Page 4]
228 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
231 operates as a "man in the middle."
233 Accounting reliability improvement
234 In roaming systems based on proxy chaining, it is necessary
235 for accounting information to be forwarded between the NAS and
236 the home server. Thus roaming is inherently an interdomain
239 This represents a problem since the RADIUS accounting
240 protocol, described in [4] is not designed for use on an
241 Internet scale. Given that in roaming accounting packets
242 travel between administrative domains, packets will often pass
243 through network access points (NAPs) where packet loss may be
244 substantial. This can result in unacceptable rates of
245 accounting data loss.
247 For example, in a proxy chaining system involving four
248 systems, a one percent failure rate on each hop can result in
249 loss of 3.9 percent of all accounting transactions. Placement
250 of an accounting proxy near the NAS may improve reliability by
251 enabling enabling persistent storage of accounting records and
255 In order to ensure consistency among all parties required to
256 process accounting data, it can be desirable to assure that
257 transmission of accounting data is handled as an atomic
258 operation. This implies that all parties on the roaming
259 relationship path will receive and acknowledge the receipt of
260 the accounting data for the operation to complete. Proxies can
261 be used to ensure atomic delivery of accounting data by
262 arranging for delivery of the accounting data in a serial
263 fashion, as discussed in section 5.2.
267 An example of a proxy chaining system is shown below.
269 (request) (request) (request)
270 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
271 (reply) (reply) (reply) Server
272 <--------- <--------- <---------
274 In the above diagram, the NAS generates a request and sends it to
275 Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards
276 the request to the Home Server. The Home Server generates a reply
277 and sends it to Proxy2. Proxy2 receives the reply, matches it with
278 the request it had sent, and forwards a reply to Proxy1. Proxy1
282 Aboba & Vollbrecht Informational [Page 5]
284 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
287 matches the reply with the request it sent earlier and forwards a
288 reply to the NAS. This model applies to all requests, including
289 Access Requests and Accounting Requests.
291 Except for the two cases described below, a proxy server such as
292 Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1
293 without first having received a Reply packet initiated by the Home
294 Server. The two exceptions are when the proxy is enforcing policy as
295 described in section 5.1 and when the proxy is acting as an
296 accounting store (as in store and forward), as described in section
299 The RADIUS protocol described in [3] does not provide for end-to-end
300 security services, including integrity or replay protection,
301 authentication or confidentiality. As noted in the security
302 considerations section, this omission results in several security
303 problems within proxy chaining systems.
305 5.1. Policy implementation
307 Proxies are frequently used to implement policy in roaming
308 situations. Proxies implementing policy MAY reply directly to
309 Access-Requests without forwarding the request. When replying
310 directly to an Access-Request, the proxy MUST reply either with an
311 Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply
312 directly with an Access-Accept. An example of this would be when the
313 proxy refuses all connections from a particular realm during prime
314 time. In this case the home server will never receive th Access-
315 Request. This situation is shown below:
318 NAS ----------> Proxy1 ----------> Proxy2 Home
319 (reply) (reply) Server
320 <--------- <---------
322 A proxy MAY also decide to Reject a Request that has been accepted by
323 the home server. This could be based on the set of attributes
324 returned by the home server. In this case the Proxy SHOULD send an
325 Access-Reject to the NAS and an Accounting-Request with Acct-Status-
326 Type=Proxy-Stop (6) to the home server. This lets the home server
327 know that the session it approved has been denied downstream by the
328 proxy. However, a proxy MUST NOT send an Access-Accept after
329 receiving an Access-Reject from a proxy or from the home server.
338 Aboba & Vollbrecht Informational [Page 6]
340 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
343 (Access-Req) (Access-Req) (Access-Req)
344 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
345 (Access-Reject) (Access-Accept) (Access-Accept) Server
346 <--------- <--------- <---------
347 (AcctPxStop) (AcctPxStop)
348 ----------> ---------->
350 5.2. Accounting behavior
352 As described above, a proxy MUST NOT reply directly with an Access-
353 Accept, and MUST NOT reply with an Access-Accept when it has received
354 an Access-Reject from another proxy or Home Server. As a result, in
355 all cases where an accounting record is to be generated (accepted
356 sessions), no direct replies have occurred, and the Access-Request
357 and Access-Accept have passed through the same set of systems.
359 In order to allow proxies to match incoming Accounting-Requests with
360 previously handled Access-Requests and Access-Accepts, a proxy SHOULD
361 route the Accounting-Request along the same realm path travelled in
362 authentication/authorization. Note that this does not imply that
363 accounting packets will necessarily travel the identical path,
364 machine by machine, as did authentication/authorization packets.
365 This is because it is conceivable that a proxy may have gone down,
366 and as a result the Accounting-request may need to be forwarded to an
367 alternate server. It is also conceivable that
368 authentication/authorization and accounting may be handled by
369 different servers within a realm.
371 The Class attribute can be used to match Accounting Requests with
372 prior Access Requests. It can also be used to match session log
373 records between the home Server, proxies, and NAS. This matching can
374 be accomplished either in real-time (in the case that authentication
375 and accounting packets follow the same path, machine by machine), or
378 Home servers SHOULD insert a unique session identifier in the Class
379 attribute in an Access-Accept and Access-Challenge. Proxies and
380 NASes MUST forward the unmodified Class attribute. The NAS MUST
381 include the Class attribute in subsequent requests, in particular for
382 Accounting-Requests. The sequence of events is shown below:
394 Aboba & Vollbrecht Informational [Page 7]
396 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
399 Authentication/Authorization
401 --------> --------> --------->
402 NAS Proxy1 Proxy2 Home (add class)
403 <-class-- <-class- <-class--
408 (Accounting-req) (Accounting-req) (Accounting-req)
409 w/class w/class w/class
410 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
411 (Accounting-reply) (Accounting-reply)(Accounting-reply) Server
412 <--------- <--------- <---------
414 Since there is no need to implement policy in accounting, a proxy
415 MUST forward all Accounting Requests to the next server on the path.
416 The proxy MUST guarantee that the Accounting Request is received by
417 the End Server and all intermediate servers. The proxy may do this
418 either by: 1) forwarding the Accounting Request and not sending a
419 Reply until it receives the matching Reply from the upstream server,
420 or 2) acting as a store point which takes responsibility for
421 reforwarding the Accounting Request until it receives a Reply.
423 Note that when the proxy does not send a reply until it receives a
424 matching reply, this ensures that Accounting Start and Stop messages
425 are received and can be logged by all servers along the roaming
426 relationship path. If one of the servers is not available, then the
427 operation will fail. As a result the entire accounting transaction
428 will either succeed or fail as a unit, and thus can be said to be
431 Where store and forward is implemented, it is possible that one or
432 more servers along the roaming relationship path will not receive the
433 accounting data while others will. The accounting operation will not
434 succeed or fail as a unit, and is therefore not atomic. As a result,
435 it may not be possible for the roaming partners to reconcile their
436 audit logs, opening new opportunities for fraud. Where store and
437 forward is implemented, forwarding of Accounting Requests SHOULD be
438 done as they are received so the downstream servers will receive them
441 Note that there are cases where a proxy will need to forward an
442 Accounting packet to more than one system. For example, in order to
443 allow for proper accounting in the case of a NAS that is shutting
444 down, the proxy can send an Accounting-Request with Acct-Status-
445 Type=Accounting-Off (8) to all realms that it forwards to. In turn,
446 these proxies will also flood the packet to their connected realms.
450 Aboba & Vollbrecht Informational [Page 8]
452 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
457 [1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
458 Roaming Implementations", RFC 2194, September 1997.
460 [2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
461 Protocols", RFC 2477, January 1999.
463 [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
464 Authentication Dial In User Service (RADIUS)", RFC 2138, April
467 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
469 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
470 Levels", BCP 14, RFC 2119, March 1997.
472 [6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
475 7. Security Considerations
477 The RADIUS protocol described in [3] was designed for intra-domain
478 use, where the NAS, proxy, and home server exist within a single
479 administrative domain, and proxies may be considered a trusted
480 component. However, in roaming the NAS, proxies, and home server will
481 typically be managed by different administrative entities. As a
482 result, roaming is inherently an inter-domain application, and
483 proxies cannot necessarily be trusted. This results in a number of
484 security threats, including:
489 Theft and modification of accounting data
492 Fraudulent accounting
496 Through the use of shared secrets it is possible for proxies
497 operating in different domains to establish a trust relationship.
498 However, if only hop-by-hop security is available then untrusted
499 proxies are capable of perpetrating a number of man-in-the-middle
500 attacks. These include modification of messages.
506 Aboba & Vollbrecht Informational [Page 9]
508 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
511 For example, an Access-Accept could be substituted for an Access-
512 Reject, and without end-to-end integrity protection, there is no way
513 for the NAS to detect this. On the home server, this will result in
514 an accounting log entry for a session that was not authorized.
515 However, if the proxy does not forward accounting packets or session
516 records to the home server, then the home server will not be able to
517 detect the discrepancy until a bill is received and audited.
519 Note that a proxy can also send an Access-Reject to the NAS after
520 receiving an Access-Accept from the home server. This will result in
521 an authentication log entry without a corresponding accounting log
522 entry. Without the proxy sending an Accounting-Request with Acct-
523 Status-Type=Proxy-Stop (6) to the home server, then there will be no
524 way for the home server to determine whether the discrepancy is due
525 to policy implementation or loss of accounting packets. Thus the use
526 of Acct-Status-Type=Proxy-Stop can be of value in debugging roaming
529 It should be noted that even if end-to-end security were to be
530 available, a number of sticky questions would remain. While the end-
531 points would be able to detect that the message from the home server
532 had been modified by an intermediary, the question arises as to what
533 action should be taken. While the modified packet could be silently
534 discarded, this could affect the ability of the home server to .
535 accept an Acct-Status-Type=Proxy-Stop message from an intermediate
536 proxy. Since this message would not be signed by the NAS, it may need
537 to be dropped by the home server.
539 This is similar to the problem that IPSEC-capable systems face in
540 making use of ICMP messages from systems with whom they do not have a
541 security association. The problem is more difficult here, since in
542 RADIUS retransmission is driven by the NAS. Therefore the home
543 server does not receive acknowledgement for Access-Accepts and thus
544 would have no way of knowing that its response has not been honored.
546 7.2. Attribute editing
548 RADIUS as defined in [3] does not provide for end-to-end security or
549 capabilities negotiation. As a result there is no way for a home
550 server to securely negotiate a mutually acceptable configuration with
551 the NAS or proxies. As a result, a number of attribute editing
552 attacks are possible.
554 For example, EAP attributes might be removed or modified so as to
555 cause a client to authenticate with EAP MD5 or PAP, instead of a
556 stronger authentication method. Alternatively, tunnel attributes
557 might be removed or modified so as to remove encryption, redirect the
558 tunnel to a rogue tunnel server, or otherwise lessen the security
562 Aboba & Vollbrecht Informational [Page 10]
564 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
567 provided to the client. The mismatch between requested and received
568 services may only be detectable after the fact by comparing the
569 Access-Accept attributes against the attributes included in the
570 Accounting-Request. However, without end-to-end security services, it
571 is possible for a rogue proxy to cover its tracks.
573 Due to the complexity of proxy configuration, such attacks need not
574 involve malice, but can occur due to mis-configuration or
575 implementation deficiencies. Today several proxy implementations
576 remove attributes that they do not understand, or can be set up to
577 replace attribute sets sent in the Access-Accept with sets of
578 attributes appropriate for a particular NAS.
580 In practice, it is not possible to define a set of guidelines for
581 attribute editing, since the requirements are very often
582 implementation-specific. At the same time, protection against
583 inappropriate attribute editing is necessary to guard against attacks
584 and provide assurance that users are provisioned as directed by the
587 Since it is not possible to determine beforehand whether a given
588 attribute is editable or not, a mechanism needs to be provided to
589 allow senders to indicate which attributes are editable and which are
590 not, and for the receivers to detect modifications of "non-editable"
591 attributes. Through implementation of end-to-end security it may be
592 possible to detect unauthorized addition, deletion, or modification
593 of integrity-protected attributes. However, it would still possible
594 for a rogue proxy to add, delete or modify attributes that are not
595 integrity-protected. If such attributes influence subsequent charges,
596 then the possibility of fraud would remain.
598 7.3. Theft of passwords
600 RADIUS as defined in [3] does not provide for end-to-end
601 confidentiality. As a result, where clients authenticate using PAP,
602 each proxy along the path between the local NAS and the home server
603 will have access to the cleartext password. In many circumstances,
604 this represents an unacceptable security risk.
606 7.4. Theft and modification of accounting data
608 Typically in roaming systems, accounting packets are provided to all
609 the participants along the roaming relationship path, in order to
610 allow them to audit subsequent invoices. RADIUS as described in [3]
611 does not provide for end-to-end security services, including
612 integrity protection or confidentiality. Without end-to-end integrity
613 protection, it is possible for proxies to modify accounting packets
614 or session records. Without end-to-end confidentiality, accounting
618 Aboba & Vollbrecht Informational [Page 11]
620 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
623 data will be accessible to proxies. However, if the objective is
624 merely to prevent snooping of accounting data on the wire, then IPSEC
629 In this attack, a man in the middle or rogue proxy collects CHAP-
630 Challenge and CHAP-Response attributes, and later replays them. If
631 this attack is performed in collaboration with an unscrupulous ISP,
632 it can be used to subsequently submit fraudulent accounting records
633 for payment. The system performing the replay need not necessarily
634 be the one that initially captured the CHAP Challenge/Response pair.
636 While RADIUS as described in [3] is vulnerable to replay attacks,
637 without roaming the threat is restricted to proxies operating in the
638 home server's domain. With roaming, such an attack can be mounted by
639 any proxy capable of reaching the home server.
641 7.6. Connection hijacking
643 In this form of attack, the attacker attempts to inject packets into
644 the conversation between the NAS and the home server. RADIUS as
645 described in [3] is vulnerable to such attacks since only Access-
646 Reply and Access-Challenge packets are authenticated.
648 7.7. Fraudulent accounting
650 In this form of attack, a local proxy transmits fraudulent accounting
651 packets or session records in an effort to collect fees to which they
652 are not entitled. This includes submission of packets or session
653 records for non-existent sessions. Since in RADIUS as described in
654 [3], there is no end-to-end security, a rogue proxy may insert or
655 edit packets without fear of detection.
657 In order to detect submissions of accounting packets or session
658 records for non-existent sessions, parties receiving accounting
659 packets or session records would be prudent to reconcile them with
660 the authentication logs. Such reconciliation is only typically
661 possible when the party acts as an authentication proxy for all
662 sessions for which an accounting record will subsequently be
665 In order to make reconciliation easier, home servers involved in
666 roaming include a Class attribute in the Access-Accept. The Class
667 attribute uniquely identifies a session, so as to allow an
668 authentication log entry to be matched with a corresponding
669 accounting packet or session record.
674 Aboba & Vollbrecht Informational [Page 12]
676 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
679 If reconciliation is put in place and all accounting log entries
680 without a corresponding authentication are rejected, then the
681 attacker will need to have obtained a valid user password prior to
682 submitting accounting packets or session records on non-existent
683 sessions. While use of end-to-end security can defeat unauthorized
684 injection or editing of accounting or authentication packets by
685 intermediate proxies, other attacks remain feasible. For example,
686 unless replay protection is put in place, it is still feasible for an
687 intermediate proxy to resubmit authentication or accounting packets
688 or session records. In addition, end-to-end security does not provide
689 protection against attacks by the local proxy, since this is
690 typically where end-to-end security will be initiated. To detect such
691 attacks, other measures need to be put in place, such as systems for
692 detecting unusual activity of ISP or user accounts, or for
693 determining whether a user or ISP account is within their credit
696 Note that implementation of the store and forward approach to proxy
697 accounting makes it possible for some systems in the roaming
698 relationship path to receive accounting records that other systems do
699 not get. This can result in audit discrepancies. About the best that
700 is achievable in such cases is to verify that the accounting data is
701 missing by checking against the authentication logs.
705 Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of
706 CompuServe, Aydin Edguer of Morningstar, Bill Bulley of Merit, and
707 Steven P. Crain of Shore.Net for useful discussions of this problem
730 Aboba & Vollbrecht Informational [Page 13]
732 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
735 9. Authors' Addresses
738 Microsoft Corporation
743 EMail: bernarda@microsoft.com
749 Ann Arbor, MI 48105-2785
786 Aboba & Vollbrecht Informational [Page 14]
788 RFC 2607 Proxy Chaining and Policy in Roaming June 1999
791 10. Full Copyright Statement
793 Copyright (C) The Internet Society (1999). All Rights Reserved.
795 This document and translations of it may be copied and furnished to
796 others, and derivative works that comment on or otherwise explain it
797 or assist in its implementation may be prepared, copied, published
798 and distributed, in whole or in part, without restriction of any
799 kind, provided that the above copyright notice and this paragraph are
800 included on all such copies and derivative works. However, this
801 document itself may not be modified in any way, such as by removing
802 the copyright notice or references to the Internet Society or other
803 Internet organizations, except as needed for the purpose of
804 developing Internet standards in which case the procedures for
805 copyrights defined in the Internet Standards process must be
806 followed, or as required to translate it into languages other than
809 The limited permissions granted above are perpetual and will not be
810 revoked by the Internet Society or its successors or assigns.
812 This document and the information contained herein is provided on an
813 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
814 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
815 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
816 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
817 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
821 Funding for the RFC Editor function is currently provided by the
842 Aboba & Vollbrecht Informational [Page 15]