idnits 2.17.1 draft-ietf-opes-threats-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 160: '...n the data request/response flow SHALL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 114 has weird spacing: '... as the basis...' == Line 164 has weird spacing: '...dded as base ...' == Line 183 has weird spacing: '... on a high-...' == Line 185 has weird spacing: '...lls for speci...' == Line 218 has weird spacing: '...age and theft...' == (8 more instances...) -- 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 (December 8, 2003) is 7438 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. '1' ** Downref: Normative reference to an Informational draft: draft-ietf-opes-scenarios (ref. '2') == Outdated reference: A later version (-03) exists of draft-ietf-opes-authorization-00 ** Downref: Normative reference to an Informational draft: draft-ietf-opes-authorization (ref. '3') Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: June 7, 2004 O. Batuner 5 Independent consultant 6 B. Srinivas 7 Nokia 8 M. Hofmann 9 Bell Labs/Lucent Technologies 10 H. Orman 11 Purple Streak Development 12 December 8, 2003 14 Security Threats and Risks for OPES 15 draft-ietf-opes-threats-03 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 7, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 The document investigates the security threats associated with OPES. 46 The effects of security threats on the underlying architecture are 47 discussed. The main goal of this document is threat discovery and 48 analysis. The document does not specify or recommend any solutions. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. OPES Data Flow Threats . . . . . . . . . . . . . . . . . . 5 54 2.1 OPES Flow Network Level Threats . . . . . . . . . . . . . 6 55 2.1.1 Connection-Flow Denial-of-Service (DoS) . . . . . . . . . 6 56 2.1.2 Threats to network robustness . . . . . . . . . . . . . . 7 57 2.2 OPES Flow Application Level Threats . . . . . . . . . . . 7 58 2.2.1 Unauthorized OPES entities . . . . . . . . . . . . . . . . 7 59 2.2.2 Unauthorized actions of legitimate OPES entities . . . . . 7 60 2.2.3 Unwanted content transformations . . . . . . . . . . . . . 8 61 2.2.4 Corrupted content . . . . . . . . . . . . . . . . . . . . 8 62 2.2.5 Threats to message structure integrity . . . . . . . . . . 8 63 2.2.6 Granularity of protection . . . . . . . . . . . . . . . . 9 64 2.2.7 Risks of hop-by-hop protection . . . . . . . . . . . . . . 9 65 2.2.8 Threats to integrity of complex data . . . . . . . . . . . 9 66 2.2.9 Denial of Service (DoS) . . . . . . . . . . . . . . . . . 9 67 2.2.10 Tracing and notification information . . . . . . . . . . . 10 68 2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . . 10 69 3. Threats to out-of-band data . . . . . . . . . . . . . . . 11 70 3.1 Threats that endanger the OPES data flow . . . . . . . . . 11 71 3.2 Inaccurate Accounting Information . . . . . . . . . . . . 11 72 3.3 OPES service request repudiation . . . . . . . . . . . . . 12 73 3.4 Inconsistent privacy policy . . . . . . . . . . . . . . . 12 74 3.5 Exposure of privacy preferences . . . . . . . . . . . . . 12 75 3.6 Exposure of security settings . . . . . . . . . . . . . . 12 76 3.7 Improper enforcement of privacy and security policy . . . 13 77 3.8 DOS Attacks . . . . . . . . . . . . . . . . . . . . . . . 13 78 4. Security Considerations . . . . . . . . . . . . . . . . . 14 79 Normative References . . . . . . . . . . . . . . . . . . . 15 80 Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16 82 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18 83 Intellectual Property and Copyright Statements . . . . . . 19 85 1. Introduction 87 The Open Pluggable Edge Services (OPES) [1] architecture enables 88 cooperative application services (OPES services) between a data 89 provider, a data consumer, and zero or more OPES processors. The 90 application services under consideration analyze and possibly 91 transform application-level messages exchanged between the data 92 provider and the data consumer. The OPES processor can distribute 93 the responsibility of service execution by communicating and 94 collaborating with one or more remote callout servers. The details of 95 the OPES architecture can be found in [1]. 97 Security threats with respect to OPES can be viewed from different 98 angles. There are security risks that affect content consumer 99 applications, and those that affect the data provider applications. 100 These threats affect the quality and integrity of data that the 101 applications either produce or consume. On the other hand, the 102 security risks can also be categorized into trust within the system 103 (i.e. OPES service providers) and protection of the system from 104 threats imposed by outsiders such as hackers and attackers. Insiders 105 are those parties that are part of the OPES system. Outsiders are 106 those entities that are not participating in the OPES system. 108 It must be noted that not everyone in an OPES delivery path is 109 equally trusted. Each OPES administrative trust domain must protect 110 itself from all outsiders. Furthermore, it may have limited trust 111 relationship with another OPES administrative domain for certain 112 purposes. 114 OPES service provide must use authentication as the basis for 115 building trust relationships between administrative domains. 116 Insiders can intentionally or unintentionally inflict harm and damage 117 on the data consumer and data provider applications. This can be 118 through bad system configuration, execution of bad software or, if 119 their networks are compromised, by inside or outside hackers. 121 Depending on the deployment scenario, the trust within the OPES 122 system is based on a set of transitive trust relationships between 123 the data provider application, the OPES entities and the data 124 consumer application. Threats to OPES entities can be at the OPES 125 flow level and/or at the network level. 127 In considering threats to the OPES system, the document will follow a 128 threat analysis model that identifies the threats from the 129 perspective of how they will affect the data consumer and the data 130 provider applications. 132 The main goal of this document is threat discovery and analysis. The 133 document does not specify or recommend any solutions. 135 It is important to mention that the OPES architecture has many 136 similarities with other so called overlay networks, specifically web 137 caches and content delivery networks (CDN) (see [2] , [4] ). This 138 document focuses on threats that are introduced by the existence of 139 the OPES processor and callout servers. Security threats specific to 140 content services that do not use the OPES architecture are considered 141 out-of-scope of this document. However, this document can be used as 142 input when considering security implications for web caches and CDNs. 144 The document is organized as follows: Section 2 discusses threats to 145 OPES data flow on network and application level, section 3 discusses 146 threats to other parts of the system and section 4 discusses security 147 considerations. 149 2. OPES Data Flow Threats 151 Threats to OPES data flow can affect the data consumer and data 152 provider applications. At the OPES flow level, threats can occur at 153 Policy Enforcement Points and Policy Decision Points [3] and along 154 the OPES flow path where network elements are used to process the 155 data. 157 A serious problem is posed by the very fact that the OPES 158 architecture is based on widely adopted protocols (HTTP is used as an 159 example). The architecture document specifically requires that "the 160 presence of an OPES processor in the data request/response flow SHALL 161 NOT interfere with the operations of non-OPES aware clients and 162 servers". This greatly facilitates OPES deployment but on the other 163 hand a vast majority of clients (browsers) will not be able to 164 exploit any safeguards added as base protocol extensions. 166 For the usual data consumer, who might have questions such as (Where 167 does this content come from? Can I get it another way? What is the 168 difference? Is it legitimate?). Even if there are facilities and 169 technical expertise present to pursue these questions, such thorough 170 examination of each result is prohibitively expensive in terms of 171 time and effort. OPES-aware content providers may try to protect 172 themselves by adding verification scripts and special page 173 structures. OPES-aware end users may use special tools. In all other 174 cases (non-OPES aware clients and servers) protection will rely on 175 monitoring services and investigation of occasionally discovered 176 anomalies. 178 An OPES system poses a special danger as a possible base for 179 classical man-in-the-middle attacks. One of the reasons why such 180 attacks are relatively rare is the difficulty in finding an 181 appropriate base: a combination of a traffic interception point 182 controlling a large flow of data and an application codebase running 183 on a high-performance hardware with sufficient performance to 184 analyze and possible modify all passing data. An OPES processor meets 185 this definition. This calls for special attention to protection 186 measures at all levels of the system. 188 Any compromise of an OPES processor or remote callout server can have 189 a ripple effect on the integrity of the affected OPES services across 190 all service providers that use the service. To mitigate this threat 191 appropriate security procedures and tools (e.g., a firewall) should 192 be applied. 194 Specific threats can exist at the network level and at OPES data flow 195 level. 197 2.1 OPES Flow Network Level Threats 199 OPES processor and callout servers are susceptible to network level 200 attacks from outsiders or from the networks of other OPES service 201 providers (i.e. if the network of a contracted OPES service is 202 compromised). 204 The OPES architecture is based on common application protocols that 205 do not provide strong guarantees of privacy, authentication, or 206 integrity. The IAB considerations [4] require that the IP address of 207 an OPES processor be accessible to data consumer applications at the 208 IP addressing level. This requirement limit the ability of service 209 providers of positioning the OPES processor behind firewalls and may 210 exposes the OPES processor, including remote callout servers, to 211 network level attacks. For example, the use of TCP/IP as network 212 level protocol makes OPES processors subject to many known attacks, 213 such as IP spoofing and session stealing. 215 The OPES system is also susceptible to a number of security threats 216 that are commonly associated with network infrastructure. These 217 threats include snooping, denial of service, sabotage, vandalism, 218 industrial espionage and theft of service. 220 There are best practice solutions to mitigate network level threats. 221 It is recommended that the security of the OPES entities at the 222 network level be enhanced using known techniques and methods that 223 minimize the risks of IP spoofing, snooping, denial of service and 224 session stealing. 226 At the OPES Flow level, connection-level security between the OPES 227 processor and callout servers is an important consideration. For 228 example, it is possible to spoof the OPES processor or the remote 229 callout server. There are threats to data confidentiality between the 230 OPES processor and the remote callout server in an OPES flow. 232 The next subsections covers possible DOS attack on OPES processor, 233 remote callout server or data consumer application and network 234 robustness. 236 2.1.1 Connection-Flow Denial-of-Service (DoS) 238 OPES processors, or callout servers or data consumer applications can 239 be vulnerable to DOS attacks. DOS attacks can be of various types. 240 One example of DOS attacks is the overloading of OPES processors or 241 callout servers by spurious service requests issued by a malicious 242 node, which denies the legal data traffic the necessary resources to 243 render service. The resources include CPU cycles, memory, network 244 interfaces, etc. A Denial-of-Service attack can be selective, 245 generic or random in terms of which communication streams are 246 affected. 248 Distributed DoS is also possible when an attacker successfully 249 directs multiple nodes over the network to initiate spurious service 250 requests to an OPES processor(or callout server) simultaneously. 252 2.1.2 Threats to network robustness 254 If OPES implementation does violate end-to-end addressing principles, 255 it could endanger the Internet infrastructure by complicating routing 256 and connection management. If it does not use flow-control 257 principles for managing connections, or if it interferes with 258 end-to-end flow control of connections that it did not originate, 259 then it could cause Internet congestion. 261 An implementation that violates the IAB requirement of explicit IP 262 level addressing (for example by adding OPES functional capabilities 263 to an interception proxy) may defeat some of the protective 264 mechanisms and safeguards built into the OPES architecture. 266 2.2 OPES Flow Application Level Threats 268 At the content level, threats to the OPES system can come from 269 outsiders or insiders. The threat from outsiders is frequently 270 intentional. Threats from insiders can be intentional or due to 271 inappropriate implementations such as programming and configuration 272 errors that result in bad system behavior. 274 Application level problems and threats to the OPES systems are 275 discussed below: 277 2.2.1 Unauthorized OPES entities 279 Although one party authorization is mandated by the OPES 280 architecture, such authorization occurs out-of-band. Discovering the 281 presence of an OPES entity and verifying authorization requires 282 special actions and may present a problem. 284 Adding notification and authorization information to the data 285 messages (by using base protocol extensions) may help, especially if 286 the data consumer's software is aware of such extensions. 288 2.2.2 Unauthorized actions of legitimate OPES entities 290 According to the OPES architecture, the authorization is not tightly 291 coupled with specific rules and procedures triggered by the rules. 292 Even if a requirement to approve each particular rule and procedure 293 was set, it looks at least impractical if not impossible to request 294 such permission from the end user. The authorization is basically 295 given for the class of transformations. The actual rules and 296 triggered procedures may (maliciously or due to a programming error) 297 perform actions that they are not authorized for. 299 2.2.3 Unwanted content transformations 301 An authorized OPES service may perform actions that do not adhere to 302 the expectations of the party that gave the authorization for the 303 service. Examples may include ad flooding by a local ad insertion 304 service or use of inappropriate policy by a content filtering 305 service. 307 On the other hand an OPES entity acting on behalf of one party may 308 perform transformations that another party deems inappropriate. 309 Examples may include replacing ads initially inserted by the content 310 provider or applying filtering transformations that change the 311 meaning of the text. 313 2.2.4 Corrupted content 315 The OPES system may deliver outdated or otherwise distorted 316 information due to programming problems or as a result of malicious 317 attacks. For example, a compromised server, instead of performing 318 OPES service, may inject bogus content. Such an action may be an act 319 of cyber-vandalism (including virus injection) or intentional 320 distribution of misleading information (such as manipulations with 321 financial data). 323 A compromised OPES server or malicious entity in the data flow may 324 introduce changes specifically intended to cause improper actions in 325 the OPES server or callout server. These changes may be in the 326 message body, headers or both. This type of threat is discussed in 327 more detail below. 329 2.2.5 Threats to message structure integrity 331 An OPES server may add, remove or delete certain headers in a request 332 and/or response message (for example to implement additional privacy 333 protection or assist in content filtering). Such changes may violate 334 end-to-end integrity requirements or defeat services that use 335 information provided in such headers (for example some local 336 filtering services or reference-based services). 338 2.2.6 Granularity of protection 340 OPES services have implicit permission to modify content. However, 341 the permissions generally apply only to portions of the content, for 342 example, URL's between particular HTML tags, or text in headlines, or 343 URL's matching particular patterns. In order to express such 344 policies, one must be able to refer to portions of messages and to 345 detect modifications to message parts. 347 Because there is currently very little support for policies that are 348 expressed in terms of message parts, it will be difficult to 349 attribute any particular modification to a particular OPES processor, 350 or to automatically detect policy violations. 352 A fine-grained policy language should be devised, and it could be 353 enforced using digital signatures. This would avoid the problems 354 inherent in hop-by-hop data integrity measures (see next section). 356 2.2.7 Risks of hop-by-hop protection 358 OPES services cannot be applied to data protected with end-to-end 359 encryption methods because, by definition, the decryption key cannot 360 be shared with OPES processors. This means that if the endpoint 361 policies permit OPES services, the data must either be transmitted 362 without confidentiality protections or an alternative model to 363 end-to-end (hop-by-hop) encryption be developed. Extending the 364 end-to-end encryption model is out of scope of this work. In this 365 work security is end-to-end. OPES services cannot be performed if 366 endpoints need security. 368 2.2.8 Threats to integrity of complex data 370 The OPES system may violate data integrity by applying inconsistent 371 transformations to interrelated data objects or references within the 372 data object. Problems may range from a broken reference structure 373 (modified/missing targets, references to wrong locations or missing 374 documents) to deliberate replacement/deletion/insertion of links that 375 violate intentions of the content provider. 377 2.2.9 Denial of Service (DoS) 379 The data consumer application may not be able to access data if the 380 OPES system fails for any reason. 382 A malicious or malfunctioning node may be able to block all traffic. 383 The data traffic destined for the OPES processor (or callout server) 384 may not be able to use the services of the OPES device. The DoS may 385 be achieved by preventing the data traffic from reaching the 386 processor or the callout server. 388 2.2.10 Tracing and notification information 390 Inadequate or vulnerable implementation of the tracing and 391 notification mechanisms may defeat safeguards built into the OPES 392 architecture. 394 Tracing and notification facilities may become a target of malicious 395 attack. Such an attack may create problems in discovering and 396 stopping other attacks. 398 The absence of a standard for tracing and notification information 399 may present an additional problem. This information is produced and 400 consumed by the independent entities (OPES servers/user agents/ 401 content provider facilities). This calls for a set of standards 402 related to each base protocol in use. 404 2.2.11 Unauthenticated Communication in OPES Flow 406 There are risks and threats that could arise from unauthenticated 407 communication between the OPES server and callout servers. Lack of 408 use of strong authentication between OPES processors and callout 409 servers may open security holes whereby DOS and other types of 410 attacks (see sections [2 and 3]) can be performed. 412 3. Threats to out-of-band data 414 The OPES architecture separates a data flow from a control 415 information flow (loading rulesets, trust establishment, tracing, 416 policy propagation, etc.). There are certain requirements set for 417 the latter but no specific mechanism is prescribed. This gives more 418 flexibility for implementations but creates more burden for 419 implementers and potential customers to ensure that each specific 420 implementation meets all requirements for data security, entity 421 authentication and action authorization. 423 In addition to performing correct actions on the OPES data flow, any 424 OPES implementation has to provide an adequate mechanism to satisfy 425 requirements for out-of-band data and signaling information 426 integrity. 428 Whatever the specific mechanism may be, it inevitably becomes subject 429 to multiple security threats and possible attacks. The way the 430 threats and attacks may be realized depends on implementation 431 specifics but the resulting harm generally falls into two categories: 432 threats to OPES data flow and threats to data integrity. 434 The specific threats are: 436 3.1 Threats that endanger the OPES data flow 438 Any weakness in the implementation of a security, authentication, or 439 authorization mechanism may open the door to the attacks described in 440 section 2. 442 An OPES system implementation should address all these threats and 443 prove its robustness and ability to withstand malicious attacks or 444 networking and programming problems. 446 3.2 Inaccurate Accounting Information 448 Collecting and reporting accurate accounting data may be vital when 449 OPES servers are used to extend a business model of content provider, 450 service provider or as a basis for third party service. Ability to 451 collect and process accounting data is an important part of OPES 452 system functionality. This functionality may be challenged by 453 distortion or destruction of base accounting data (usually logs), 454 processed accounting data, accounting parameters and reporting 455 configuration. 457 As a result a data consumer may be inappropriately charged for 458 viewing content that was not successfully delivered, or a content 459 provider or independent OPES services provider may not be compensated 460 for the services performed. 462 OPES system may use accounting information to distribute resources 463 between different consumers or limit resource usage by a specific 464 consumer. In this case an attack on accounting system (by distortion 465 of data or issuing false configuration commands) may result in 466 incorrect resource management and DoS by artificial resource 467 starvation. 469 3.3 OPES service request repudiation 471 An entity (producer or consumer) makes an authorized request and 472 claim, later, that it did not make that request. As a result an OPES 473 entity may be held liable for unauthorized changes to the data flow, 474 or will be unable to receive compensation for a service. 476 There should be a clear request that this service is required and 477 there should be a clear course of action on the behalf of all 478 parties. This action should have a request, and should have an 479 action, and should have a means of repudiation of the request, and 480 should have a means to specify the effect of the action. 482 3.4 Inconsistent privacy policy 484 The OPES entities may have privacy policies that are not consistent 485 with the data consumer application or content provider application. 487 Privacy related problems may be further complicated if OPES entities, 488 content providers and end users belong to different jurisdictions 489 with different requirements and different levels of legal protection. 490 As a result the end user may not be aware that he or she does not 491 have the expected legal protection. The content provider may be 492 exposed to legal risks due to a failure to comply with regulation 493 which he is not even aware of. 495 3.5 Exposure of privacy preferences 497 The OPES system may inadvertently or maliciously expose end user 498 privacy settings and requirements. 500 3.6 Exposure of security settings 502 There are risks that the OPES system may expose end user security 503 settings when handling the request and responses. The user data must 504 be handled as sensitive system information and protected against 505 accidental and deliberate disclosure. 507 3.7 Improper enforcement of privacy and security policy 509 OPES entities are part of the content distribution system and as such 510 take on certain obligations to support security and privacy policies 511 mandated by content producer and/or end user. However there is a 512 danger that these policies are not properly implemented and enforced. 513 The data consumer application may not be aware that its protections 514 are no longer in effect. 516 There is also the possibility of security and privacy leaks due to 517 the accidental misconfiguration or, due to missunderstanding what 518 rules are in effect for a particular user or request. 520 Privacy and security related parts of the systems can be targeted by 521 malicious attacks and ability to withstand such attacks is of 522 paramount importance. 524 3.8 DOS Attacks 526 DOS attacks can be of various types. One type of DOS attacks can take 527 effect by overloading the client. For example, an intruder can direct 528 an OPES processor to issue numerous responses to a client. There is 529 also additional DOS risk from a rule misconfiguration that would have 530 the OPES processor ignore a data consumer application. 532 4. Security Considerations 534 This document discusses multiple security and privacy issues related 535 to the OPES services. 537 Normative References 539 [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge 540 Services (OPES)", Internet-Draft: http://www.ietf.org/ 541 internet-drafts/draft-ietf-opes-architecture-04.txt, Aug 2002. 543 [2] A. Barbir et. al, "OPES Use Cases and Deployment Scenarios", 544 Internet-Draft: http://www.ietf.org/ 545 draft-ietf-opes-scenarios-01, July 2002. 547 [3] A. Barbir et. al, "Requirements for Policy, Authorization and 548 Enforcement of OPES Services", Internet-Draft: http:// 549 www.ietf.org/internet- drafts/ 550 draft-ietf-opes-authorization-00.txt , October 2002. 552 Informative References 554 [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy 555 Considerations for Open Pluggable Edge Services", RFC 3238, 556 January 2002. 558 Authors' Addresses 560 Abbie Barbir 561 Nortel Networks 562 3500 Carling Avenue 563 Nepean, Ontario K2H 8E9 564 Canada 566 Phone: +1 613 763 5229 567 EMail: abbieb@nortelnetworks.com 569 Oskar Batuner 570 Independent consultant 572 EMail: batuner@attbi.com 574 Bindignavile Srinivas 575 Nokia 576 5 Wayside Road 577 Burlington, MA 01803 578 USA 580 EMail: bindignavile.srinivas@nokia.com 582 Markus Hofmann 583 Bell Labs/Lucent Technologies 584 Room 4F-513 585 101 Crawfords Corner Road 586 Holmdel, NJ 07733 587 US 589 Phone: +1 732 332 5983 590 EMail: hofmann@bell-labs.com 591 Hilarie Orman 592 Purple Streak Development 594 Phone: 595 EMail: ho@alum.mit.edu 597 Appendix A. Acknowledgements 599 Many thanks to T. Chan (Nokia) and A. Beck (Lucent) 601 Intellectual Property Statement 603 The IETF takes no position regarding the validity or scope of any 604 intellectual property or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; neither does it represent that it 608 has made any effort to identify any such rights. Information on the 609 IETF's procedures with respect to rights in standards-track and 610 standards-related documentation can be found in BCP-11. Copies of 611 claims of rights made available for publication and any assurances of 612 licenses to be made available, or the result of an attempt made to 613 obtain a general license or permission for the use of such 614 proprietary rights by implementors or users of this specification can 615 be obtained from the IETF Secretariat. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights which may cover technology that may be required to practice 620 this standard. Please address the information to the IETF Executive 621 Director. 623 Full Copyright Statement 625 Copyright (C) The Internet Society (2003). All Rights Reserved. 627 This document and translations of it may be copied and furnished to 628 others, and derivative works that comment on or otherwise explain it 629 or assist in its implementation may be prepared, copied, published 630 and distributed, in whole or in part, without restriction of any 631 kind, provided that the above copyright notice and this paragraph are 632 included on all such copies and derivative works. However, this 633 document itself may not be modified in any way, such as by removing 634 the copyright notice or references to the Internet Society or other 635 Internet organizations, except as needed for the purpose of 636 developing Internet standards in which case the procedures for 637 copyrights defined in the Internet Standards process must be 638 followed, or as required to translate it into languages other than 639 English. 641 The limited permissions granted above are perpetual and will not be 642 revoked by the Internet Society or its successors or assignees. 644 This document and the information contained herein is provided on an 645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 651 Acknowledgment 653 Funding for the RFC Editor function is currently provided by the 654 Internet Society.