TermPaperDraft1.doc
Upcoming SlideShare
Loading in...5
×
 

TermPaperDraft1.doc

on

  • 396 views

 

Statistics

Views

Total Views
396
Views on SlideShare
396
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

TermPaperDraft1.doc TermPaperDraft1.doc Document Transcript

  • TCSS 559 Web Services Network Security Options for Service-Oriented Architectures Term Paper Draft Wednesday, February 15, 2006 By Robert Bunge, Team #5, Engineer B Abstract Service-Oriented Architectures (SOA) enjoy growing research attention, development effort and vendor support. SOAs promise improved interoperability, flexibility, speed of deployment, and support for business process composition. Yet with any such advance in the ease of information flows between distributed endpoints come concerns for network capacity and network security. Will existing networks scale to consume a growing array of distributed services? Do Web Services and other SOA data frameworks make efficient use of network capacity? And most importantly, will the current arsenal of network security defenses successfully ward off a new generation of malicious attacks slipping through firewalls in the guise of useful services? A growing body of research notes network performance concerns in relation to Web Services. The XML-based data formats common to Web Services and other SOAs have been engineered for human readability and systems interoperability, not for optimum transfer speed over a wire. For this reason, many researchers point to one compression scheme or another as possible improvements for SOA network performance. Yet how will such approaches interact with firewalls and other standard network defense measures such as, virtual private networks and secure web servers? How will firewalls be able to distinguish desired traffic when port-based security settings give way to XML-based methods? To what extent will emerging standards at the SOA level (e.g. WS-Security, WS-Trust, WS-Authorization) provide solutions upon which network managers can rely? Although SOAs promise an impressive list of solutions to outstanding issues in application development, they also raise an entirely new set of questions for network management and network security. This paper will survey the incipient literature on SOA data transmission techniques to identify promising approaches to network configuration for SOA performance and security.
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge Technical Proposal 1 Motivation Web Services enjoy a growing market share. Network security is also a growing concern. This leads to a need for a deeper understanding of the impact of Web Services deployments on network security requirements. 2 Purpose The purpose of this paper is to identify significant new issues in network security occasioned by the growing trend towards Web Services deployment. The paper will note the conclusions of existing research on this topic and it will identify areas most in need additional research. 3 Approach The approach taken will include a survey of the literature from leading academic journals. As appropriate, technical references from other publications will also be included. 4 Expected Results Traditional approaches (VPN, SSL) should be combined with WS-Security to get the best results. IPsec and SSL by themselves are not optimized for Web services. WS-Security by itself is not mature and puts too much overhead onto the network. PWSSec is a good recommendation, but it needs to be defined in more operational terms. 5 Expected Contribution Goal is to find or create detailed data regarding performance outcomes under different SOA security mechanisms. This will advance understanding of SOA deployment options and issues. Page 2 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge Related Work 1 Previous Work 1.1 Overview of SOA Security Issues [GUT] Growth of Web Services. [ALB] Security issues may limit SOAP usefulness [LI] Computer security versus communication security [TRE] Will Web services security be too complex for adoption? [DAM] Standards issues must be resolved 1.2 XML-based Security Methods for Software [NAE] XML DSib, AML Enc, SAML, XACML, XeML, XKMS, WS-Security [TAR] XML labels define authorized readers and writers [LI] Ontology-based approach. simpleWeb Services Security Language (sWSSL) [GUT] Software engineering approach. Process for Web Services Security (PWSSec). 1. 3 XML-based Network Solutions [HEA] XML Firewalls [CRE] Integrated WS-Security -Firewall model [ALC] Integrating Web Services with VPNs Page 3 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge 1.4 Problems of Performance [WER] Transport protocols introduce overhead. Bandwidth and Latency improved by XML compression [TIA] Mobile clients require compression for Web Services consumption [HAU] “Compression after encryption is silly. If an encryption algorithm is good, it will produce output which is statistically indistinguishable from random numbers and no compression algorithm will considerably compress random numbers” Problem statement: What is the performance penalty for each form of encryption in an SOA? Tentative hypotheses: • VPN cost Δ = VPN header + process to encrypt/decrypt. Also, set-up and tear-down of VPN. Not compatible with NAT. • SSL cost Δ = HTTPS cost + additional burden on web server to firewall XML content (port 80 transport avoids port-based firewalls) • WS-Security cost Δ = design overhead (PWSSec) + XML overhead. XML firewall also required (how will the network know the service is trusted?) • Other approaches require definition and/or test environment to consider performance and cost implications (label checking, sWSSL, integrated WS-VPN) Page 4 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge 2 Related Technologies 2.1 Port-based firewalls [BER] discussion of port-based security 2.2 Secure Sockets Layer (SSL) 2.3 Virtual Private Networks 2.3.1 IPsec 2.3.2 Transport versus tunnel 2.3.3 AH versus ESP Page 5 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge References [ALB] Conan C. Albrecht. How Clean is SOAP? Communications of the ACM 47(2), 2004. 66-68. [ALC] Lina Alchaal, Vincent Roca, Michel Habert. Managing and Securing Web Services with VPNs. International Conference on Web Services (2004) [BER] Hal Berghel and David Hoelzer. Pernicious ports. Communications of the ACM, 48(12), 2005. [CRE] M. Cremoni, E. Damiani, S. Vimercati, P. Samarati. An XML-based Approach to Combine Firewalls and Web Services Security Specifications. ACM Workshop on XML Security. (2003) 69-78. [DAM] E.Damiani, S. Vimercati, P. Samarati. Towards Security XML Web Services. ACM Workshop on XML Security (2002). 90-96. [GUT] Carlos Gutiérrez, Eduardo Fernández-Medina, Mario Piattini. Web services enterprise security architecture: a case study, (2005), Proceedings of the 2005 Workshop on Secure Web Services. (10-19) [HAU] A. Hauter, M.V. Chacko, R. Ramanathan. Compression and Encryption. December 1995. Retrieved February 3, 2006 from http://www.science.gmu.edu/~mchacko/csi801/proj-ckv.html [HEA] Jessica Heasley. Securing XML Data. InfoSecCD Conference’04. 112-114. [LI] C. Li and C. Pahl. Security in the Web Services Framework. International Symposium on Information and Communications Technologies ISICT’03, Dublin, Ireland. September 2003. [NAE] Martin Naedele. Standards for XML and Web Services Security. IEEE Computer, 4/2003 (96-98) [TAR] Zahir Tari, Peter Bertok, Dusan Simic. A Dynamic Label Checking Approach for Information Flow Control in Web Services. International Journal of Web Services Research (JWSR), 1-28, January 2006 Page 6 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge [TIA] Min Tian, Thiemo Voigt, Tomasz Naumowicz, Hartmut Ritter and Jochen Schiller. Performance Considerations for Mobile Web Services. Workshop on Applications and Services in Wireless Networks, Bern, Switzerland, July 2003. [TRE] Win Treese. XML, Web Services, and XML. netWorker. 6(3) 2002. 9-12 [WER] Carsten Buschmann, Tobias Jäcker, Stefan Fischer. Christian Werner. (2006). Bandwidth and Latency Considerations for Efficient SOAP Messaging. International Journal of Web Services Research Vol. 3, No. 1. pp. 49 -67. Appendix Conan C. Albrecht [ALB] traces the relationship between SOAP and port-based firewalls. He points out that every organization must balance the need for security and the desire for remote user access. SOAP tries to improve access by tunneling its activity over the generally accepted protocol HTTP. This, however, may limit the future of SOAP and Web services because of concerns over the exposure of private data through such a public channel. Although some may see SOAP as a solution to the balance between security and functionality, the underlying goals of firewall security are circumvented by SOAP. Network security administrators therefore may see SOAP as an “end run” around security. Typically, the transfer from network to application layers is facilitated by TCP or UDP port numbers. Because SOAP piggybacks onto the HTTP port 80, a different mechanism is needed in this case. SOAP transmits messages by placing a routing engine behind the Web server. Requests are sent through the Web server to to the processor, where they are routed to the appropriate application. Responses are sent back through the Web server to the remote client. Although most SOAP is currently deployed for custom internal applications (and thus benefits from security by obscurity), this may not always be the case. As external SOAP applications grow, SOAP will start to attract security attention much like email has. Just as perimeter security now strips email attachments and checks for harmful content, so SOAP may come under scrutiny. More firewalls can be configured to monitor SOAP traffic based on its unique content type (text/xml-SOAP). The switching point thus is moving behind ports and firewalls to the scripting area of Web servers. Lina Alchaal et al [ALL] propose securing Web services with dynamically composed Virtual Private Networks (VPNs). They introduce a VPN service provider architecture that enables dynamic building of IPSec VPNs between sites or hosts. The approach is centralized around an Virtual Network Operations Center (VNOC). A VNOC is a dedicated host that distributes policy configurations to Edge Devices (Eds) at each site. Eds can send join requests to the VNOC over SSL. The VNOC responds by establishing an IPSec VPN to the ED. The authors compare IPSec to SSL. IPSec operates at the OSI network layer. SSL operates at the application layer. IPSec secures all TCP and UDP communications. SSL requires the use of Page 7 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge HTTP. Both IPSec and SSL are used in VPNs. The proposed VNOC would support both types of VPN protocol. Next, Web services are analyzed from a security point of view. The first phase of Web services (based on XML, SOAP, UDDI, and WSDL) is now rather mature. This gives rise to a second phase of WS standards focused on security and stability. Such standards include XML Digital Signatures, SML Encryption, HTTP-R, SAML, and XACML. A third phase of Web services standards, addressing provisioning, monitoring, and system management, is in very early development. Web services face management challenges such as client identification, authorization, monitoring, and configuration deployment. The authors note that existing WS- Security languages focus on how to secure XML data, not on how to secure a Web service. For this reason, they propose dynamically composed VPNs with IPSec and/or SSL. Hal Berghel and and David Hoelzer [BER] survey the many threats addressed by port-based firewalls. The challenge of firewall management arises from the enormous threat space occasioned by 131,072 available ports (65,536 each for TCP and UDP). For this reason, firewall management is more of an art than a science. IANA has divided ports into three groups: well-known, registered, and dynamic. However, there is little control over the actual use of a port once it is registered. Port 1999 is registered to Cisco, yet this port was used by the SubSeven backdoor and Trojan. SubSeven also used registered port 2773, unassigned ports 7215 and 27374 and dynamic/private port 54283. The relevance of IANA registration has declined over time as vendors have wandered off on their own. Threats exist to both Windows and Unix ports. Ports 135, 137-130 and 445 are problematic for Windows. This are used by legacy NetBios and SMB. Other vulnerable Windows services include: Remote Procedure Call (port 135), WINS (port 42), and Windows Remote Desktop Protocol (port 3389). Vulnerable Unix services include SMTP (port 25), Windows interoperation (ports 135-139), Rlogin (port 513), and LDAP (port 389). Other threats exist to services such as telnet, FTP, and SNMP. Even the SSH port 22 has become subject to attack. Proxy servers are sometimes used to improve security, but proxies themselves can come under attack and turned against their own networks. Because of the wide array of potential threats, continuous oversight of firewalls and routers is required. [CRE] Cremoni et all differentiate between the security of end-to-end services and the security of the network. An example of what they term “Service-Oriented security” would be SOAP messages encrypted at each end point and passing without inspection through firewalls at the network perimeter. Although this might seem desirable for producers and consumer of XML services, many organizations prefer to enforce security policies at the edge of their internal network. The authors define this posture as “Network-Oriented Security.” Service- and Network- Oriented Security do not necessarily mesh will togther. Indeed, they may at times seem to contradict each other. This study proposes a framework to facilitate an integrated service- and network-oriented security model within an Service-Oriented Architecture. The proposed framework features four part authorization rules. The parts are: subject, object, condition, and sign. The subject field refers to the parties in a service exchange. The object field refers to the services. The condition field refers to additional restrictions or conditions for service Page 8 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge access. The condition field is the feature within the framework allowing for the melding of Network-Oriented Security to the service transaction. The condition field can refer by URI to network-specific elements such as routers, switches, subnets, VLANS, MAC addresses and so forth. The sign field of the proposed integrated framework can be set to “plus” for permitted or “minus” for denied. In this manner, service requests via SOAP can be made conditional upon network access permissions granted to particular subjects for specific network segments. The article also discusses some specific threats to the network that may arise from SOAP. One of these is stateful SOAP exchanges. Port-based firewalls typically deny TCP messages from the outside without an ACK bit set. This prevents outsiders from initiating TCP sessions. Similar firewall functionality for WS-ReliableMessaging, for example, would require an XML-aware firewall. The article concludes by suggesting approaches to this issue as well as other potential threats such as spoofing and denial of service. [DAM] Damiani et al compare a variety of approaches to securing Web services. One idea is to use the existing HTTP security model of SSL. This, however, features at least one significant drawback with respect to an SOA. Namely, if encryption is to be provided via SSL, then an HTTP transport binding is required for the service. Ideally, services should be free to bind to other protocols in the TCP/IP stack. Thus, a security model at the Web services layer, encapsulated within this layer itself, becomes desirable. The study points to the possible role of SOAP headers in supporting a Web services security model. One proposal by the authors features a custom SOAP head for the “subject” of the service request, with child elements including “user”, “location”, and “role”. User in turn can contain “userid” and “passwdhash”. In this manner, the SOAP header can be extended to include these and other elements related to authenticating the requestor of a service. The authors also discuss the use of security languages such as SAML and XACML. SAML uses assertions to characterize the authentication status of a request for service. In this manner, SAML plays a role similar to that proposed for custom SOAP security headers. XACML provides a standardized approach to access control for XML documents. XACML can map to SAML for the purpose of determining if access is justified based on the security credentials presented. The authors conclude by inviting discussion of the many unsolved problems in XML security. [GUT] Carlos Gutiérrez et al approach Web services security from a software engineering standpoint. They describe a complex process known as Process for Web Services Security (PWSSec). Unlike many approaches in the Web services security domain, PWSSec does not begin with an XML specification. Rather, it describes more of a business or engineering process for the development of secure Web services software. As a by-product, PWSSec is then also shown to generate security policies in XML format. The fundamental problem addressed is the typical lack of communication between development teams and security teams. The authors attempt to remedy this by specifying a formal link Page 9 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge between development and security at each phase of the software development cycle. Stage one is requirements. The acronym for this is WSSecReq. At this stage business requirements, including security requirements, are gathered and modeled. Stage two is architectural, and this is described as WSSecArch. At this stage architectural patterns are identified as are specifications, tests, and security mechanisms. The final stage is implementation, labeled WSSecTech. Resulting from this stage will be a Security Standards Identification and a Deployment Security Policies Definition. All of the phases above are highly structured, with stereotypical documents created at each stage. Indeed, such documents are intended to be reflected formally in XML. Several examples of such XML security documents are shown. Also generated through PWSSec are internal tables that constitute a sort of data dictionary or schema of the various security policies and relationships. In conclusion, the authors link PWSSec to ongoing research in WS-* approaches to SOA security. Jessica Heasley [HEA] surveys the current status of XML firewalls. There are generally two approaches to XML firewalls. One is hardware-based. The other is software-based. Hardware XML firewalls are generally faster and have more manageability than software-based firewalls. They generally cost more as well. XML firewalls are a subset of XML proxies, which provide other services in addition to security, such as XML transformation or acceleration. For this reason, XML firewall protection often comes as part of an XML proxy server. Products reviewed for this study include those of Forum Systems and DataPower. Other vendors (such as Vordel, Flamenco Networks, Westbridge Technology, Check Point Software and Cisco) are either in this market or are likely to enter it soon. Forum’s XML security appliance resides in front of servers and encrypts XML in real time. The appliance inspects XML on a tag by tag basis and only encrypts selected fields. A newer product by the same vendors adds features such as embedded messaging, content-based routing, interoperability, service negotiation, and QoS. This product combines SSL encryption with XML Intrusion Prevention (XIP). DataPower offers a product that creates a virtual firewall for every service exposed to the outside world. Each virtual firewall is configured with a custom policy of actions on each XML message passing through the firewall. Policy actions are implemented through XSL stylesheets. Such policies include filtering, digital signatures, signature verification, schema validation, encryption, decryption, transformation and routing. Proprietary hardware is used for this solution which increases performance by a factor of ten over software-based approaches. [LI] Li and Pahl approach the problem of Web services security from the point of view of the Semantic Web. Their concern is to determine a structure for “security objects” to be deployed in a Semantic Web framework. They offer examples of such objects and show how they can be constructed from related specifications for XML Web services languages. The authors describe their overarching framework as the Web Services Framework (WSF), a Web-based middleware platform. At the core of WSF are the familiar Web services standards: SOAP, WSDL, UDDI. Security goals for Web services listed by the authors include: confidentiality, integrity, availability, authentication, and accountability. The aim to ensure these Page 10 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge goals through security policies expressed in security rules. In this scheme, security rules are each composed of triples (S,A,O) consisting of subject, activity, object. The security goals can be attributes of the subject, activity, object, or some combination. For example, the authentication may pertain to the subject, while availability might pertain to the union of the activity and the object. This three-fold syntax maps well to RDF, which in turn points in the direction of Semantic Web approaches such as DAML+OIL and more resent iterations of such languages. Each security triple describes a security object, which can then be invoked within other XML elements. In summary, the authors describe this approach as simple Web Services Security Language (sWSSL). This language will be used to map security descriptions to Web services PortTypes (interfaces), much as current firewalls map security policies to TCP and UDP ports. Martin Naedele [NAE] provides an overview of Web services security standards. This field features many acronyms, yet most of these simply implement one common security service or another in XML format. The author notes that XML schemas on their own provide no security mechanism. The various WS-Security standards aim to address this problem. XML signatures (XML DSig) prove a document’s integrity. They also implement nonrepudiatable evidence of who created a document. XML DSig allows for only selected parts of the XML document tree to be signed (if desired). This is more flexible than alternative protocols such as PGP, which digitally sign entire documents. XML encryption (XML Enc) defines XML syntax for processing encrypted document wholes or parts. Security Assertion Markup Language (SAML) is an XML-based framework for request/response exchanges of authentication and authorization information. SAML can be used to ralize single sign-on between platforms such as Windows and Java. SAML statements are XML constructs called assertions. Extensible Access Control Markup Language (XACML) is an XML specification for expressing fine-grained information access policies. EACML defines ways to encode rules, bundle rules with policies, and define rules for combining multiple policies. Extensible Rights Markup Language (XrML) focuses on digital rights management. It overlaps with XACML, which is more comprehensive. XML Key Management Specification (XKMS) defines a Web service interface for public key management. XKMS can manage keys for other protocols such as XML DSig and XML Enc. XKMS contains two subprotocols: XML Key Information Service Specification (X-KISS) and XML Key Registration Service Specification (X-KRSS). In addition to all of these XML-based standards, WS-Security also supports existing security mechanisms such as X.509 and Kerberos. Zahir Tari et al [TAR] address the issue of declassification, or information leak, under Web services. Declassification occurs when confidentiality or privacy are breached. The proposed approach is Information Flow Control (IFC). Information flow control is a method of enforcing confidentiality through a procedural approach. Labels are attached to objects upon access from a resource. These labels are to be checked to prevent declassification. The proposed model starts with the idea that every information system can be divided into two primitive sets, subjects and objects. The subject is an active user or process. The object is a Page 11 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge resource. For Web services, the subject is a service running on behalf of a user. The object represents data in the form of XML. This may be an entire XML document, an element of a document, or a collection of documents. Labels contain flow control-specific information for detecting illegal flow. They are attached to and carried along with objects. The model further defines owners and readers of objects. The article presents an extensive symbolic calculus illustrating the relationship between readers, owners, labels, and objects. Checking of labels for permissions and policies can occur either dynamically or statically. Dynamic checking is at run time. Static checking is at compile time. The authors claim their model extends a decentralized label model in support of collective classification, change and preserving inter-owner trust. They also propose label-joining rules to aid the development of rules derived from labels. Min Tian et al [TIA] shows that compression can improve the transmission speed of web services to mobile clients with limited CPU power. Over time, web sites have moved from static HTML to dynamic scripting and now to Web services. With the additional functionality of Web services comes increased overhead for XML formats. This is a special problem for mobile clients. Such mobile clients, with smaller CPUs, limited memory, and embedded operating systems, may become the most common consumers of Web services. XML compression can help to reduce network overhead and improve Web services performance for mobile clients. A drawback to Web services compression, however, is increased load on the server because of the need to compress on that side of the connection. If the server is too busy, Web services performance could diminish. The authors propose one possible optimization for this situation: server side caching of compressed server responses to be served on demand during peak traffic loads. The idea is that clients could request compression if they need it to speed up their consumption of a Web service. If load conditions are light enough, the server would comply. Under heavy loads, however, the server would decline compression requests in order to keep average response times down. Instead of compressing under high loads, the server would offer cached, compressed responses. The authors designed and conducted experiments showing that clients with poor network connections benefited from this approach. Win Treese [TRE] points out some of the basic security issues for SOAP and Web services. He begins by reviewing the essential ideas of Web services, including the use of SOAP and XML. SOAP is designed to be carried over HTTP, in part, so that it can pass more easily through firewalls. However, HTTP was not intended to support Web services functionality such as remote procedure calls, so vendors are improving the ability of firewalls to inspect HTTP and to check for malicious code in the form of SOAP. There is a significant performance penalty, however, for this deeper inspection of HTTP. Some primary problems in communications security include the following: confidentiality, authentication, integrity, nonrepudiation, authentication, and key management. SOAP does not address any of these. One approach, then, is to rely on underlying network protocols such as SSL/TLS or VPNs to provide for Web services security. Such approaches encrypt entire SOAP messages or transactions. A more granular approach is available through WS-Security standards. Page 12 of 13
  • TCSS 559 Team #5, Engineer B Term Paper Robert Bunge Such standards are being defined by the W3C, OASIS, and the IETF. WS-Security standards include XML Encryption, XML Digital Signature, Security Assertion Markup Language, and XML Key Management. These protocols work together, and they allow selected elements of XML documents to receive differentiated security treatment. The author expresses concerns over whether developers will truly utilized WS-Security services, given that similar security practices in the past have often been overlooked. He sums up by noting that “complexity itself is often the enemy of good security”. Christian Werner at al [WER] take up the issue of transport level optimization for Web services. These authors note that TCP/IP protocols such as UDP, TCP, HTTP, FTP, and SMTP vary greatly with respect to header length per packet, thereby affecting the bandwidth and latency for network connections transporting SOAP. In a head-to-head experimental comparison of SOAP bound directly to each of the protocols above, UDP far outperformed the others. Compression of the SOAP messages prior to transmission improved performance for all protocols, but UDP remained the fastest due to its far smaller header size in relation to data payload. UDP is not the ideal transport binding for all applications, however. UDP is unreliable. It lacks a mechanism for retransmission of lost packets and it has no way to guarantee proper sequencing. These features are available through TCP and higher level protocols, but at a cost of increased header size per packet. The authors attempt to combine the speed of UDP with reliability features by introducing an experimental application layer protocol: PURE. PURE employs SOAP extensions for endpoint addressing and transport reliability. These extensions are consistent with the WS-Addressing and WS-ReliableMessaging specifications. The rational for replicating functionality normally found at the TCP level up at the top of the application stack is to be able to bind the application to UDP at the transport level. PRUE accomplishes is SOAP- centric reliability mission with a forty bit (five byte) header at the application layer. This is a 63 percent increase in header size over the normal sixty-four bit (eight byte) UDP header. However, PURE over UDP features a total header size of 104 bits (thirteen bytes), which is smaller than the 160 bit TCP header. Also, a number of TCP features (such as the Urgent Pointer field) may be superfluous for web services. To test the PURE approach, the authors developed a PURE implementation on .NET and tested it against the other protocols. In general, PURE equaled UDP in lightweight messaging, while adding a number of desirable reliability features. Page 13 of 13