Distributed Systems . . .

1. Distributed Systems . . . . . . Risks and how to tackle them

2. Slides by Peter Thanisch & Jyrki Nummenmaa ‘

3. Internet Commerce -Distributed Application Example Area To exemplify the potential risks in safety and credibility of distributed systems, we will discuss an example application area. Internet commerce is a good example area, because it deals with money and there is a lot of interest in application development.

4. Internet Commerce defined The use of the global Internet for purchase and sale of goods and services, including service and support after the sale.

5. Internet Commerce: our focus • Advertising • Browsing • Purchasing • Billing • Payments

6. Customer Financial Adviser Mortgage Lenders Life Insurers Electronic Commerce: the old way

7. PC Web browser Exhibitor Exhibition Hall’s Web site Brokerage service stands computers communications furniture Internet Commerce Example: Exhibition Hall Rental Companies’ Web Sites

8. Electronic commerce Fixed set of participating companies Proprietary, special-purpose protocols. Specialist agent drives the dialogue, with special-purpose software Internet commerce Transient sets of companies, maybe with brokers. Protocols are Internet standards The customer drives the dialogue from a general-purpose Web browser. So what is changing?

9. The state of the market • Projections about the growth of Internet commerce have been wildly optimistic. • Not many retailers have been making big bucks. • Market for Internet commerce software is not hugely profitable either.

10. Internet Commerce • A person, running a web browser on a desktop computer, electronically purchases a set of goods or services from several vendors at different web sites. • This person wants either the complete set of purchases to go through, or none of them.

11. Technical Problems with Internet Commerce • Security • Failure • Multiple sites • Protocol problems • Server product limitations • Response time

12. Security

13. Security: the end user’s view • Confidentiality: Preventing sniffing on your communication. • Identification: Verifying that the sender truly is who it is stated to be. • Authentication: Verifying that the message has not be altered. • Non-repudiation: Ensuring that the sender cannot deny sending the message.

14. Web site of company selling the product you want to buy Your Internet Service Provider Internet Backbone A sniffer Your PC Confidentiality

15. Web site of company selling the product you want to buy Your Internet Service Provider Internet Backbone XYZ ABC Identification and Authentication Your PC XYZ XYZ ABC

17. Security: some solutions • Confidentiality: Encryption. • Authentication: Certification. • Integrity: Digitally signed message digest codes. • Non-repudiation: Receipts containing a digital signature. • You can do these through SSL/TLS or using the Java APIs.

18. Failure

19. Failures: single computer • Hardware failure • Software crash • User switched off the PC • Active attack

20. Failure: Additional Problems for Multiple Sites • Network failure • Or is it just congestion? • Or has the remote computer crashed? • Or is it just running slowly? • Message loss? • Denial-of-service attack? • Typically, these failures are partial.

21. Distributed Transaction • Changes two or moreautonomous databases from one consistent state to another consistent state. • Server Autonomy - any server can unilaterally decide to abort the transaction. • Changes must be durable: information is preserved despite system failures. • System failures are typically partial.

22. Traditional data processing transaction: set of read and update operations collectively transform the database from one consistent state to another. Internet Commerce transaction: set of read and update operations collectively provide the user with his/her required package Subtle Difference: transaction

23. Protocol Problems

24. TIP: Transaction Internet Protocol • Proposed as an Internet Standard. • Backed by Microsoft and Tandem. • Heterogeneous Transaction Managers can implement TIP to communicate with each other.

25. Site A Site B Application Program Application Program TIP API TIP API TIP txn manager TIP txn manager TIP: Two-pipe model Pipe 1 Pipe 2 TIP commit protocol

26. User’s Web Browser Server A Server C Server B A Browsing Transaction (1) Initiate txn (2) txn URL (4) txn URL (3) PUSH txn (5) PULL txn

27. A C D B PUSH ‘txn1a’ PUSH ‘txn1a’ PUSH ‘txn1b’ PUSH ‘txn1c’ Multiple inclusions of a site

28. TIP vulnerability • Communication is pairwise point-to-point. • Vulnerable to single link failures.

29. The Commit Protocol:Ensuring Atomicity • Once the pushing and pulling is over, a coordinator must ensure that all sites can complete their work, writing their results into their databases. • The method used to achieve this is called a Commit Protocol. • The Commit Protocol must behave sensibly even when there are failures.

30. Coordinator VOTE-REQUEST Participants COMMIT or ABORT votes Multicast decision Transaction Commit (no failures!)

31. C P1 P2 COMMIT COMMIT Two-Phase Commit Blocks (2) C crashes (1)COMMIT sent (4) P2 is blocked (3) P1 crashes

32. TIP Security • Requires Secure-HTTP/SSL/TLS with • encryption and • end-to-end authentication. • Operator intervention is needed when the commit protocol fouls up. • How will this work on the Internet?

33. Internet Transaction Security • Big value transactions will not be conducted in this way. • Thus any scams will take the form of having a small effect on a large number of transactions. (Salami scams.)

34. SSL/TLS does NOT solve all of the problems • TIP with TLS does not ensure non-repudiation. • Various Denial-of-Service attacks are possible. • A rogue participant could block progress by refusing to commit.

35. Denial-of-Service • PULL-based: • A rogue company that knows the transaction ID sends a PULL to a site then closes the connection. • PUSH-based • Flood a sites with PUSHes so that it cannot service legitimate requests.

36. Broken connection • If a site loses its connection to its superior, the rogue sites sends it a RECONNECT command and tells it the wrong result of the commit.

37. Repudiation • General point about how to repudiate: • The site that wants to repudiate a transaction can always cause itself to crash and then recover, meanwhile losing all information that was in vulnerable storage.

38. Repudiation • Interaction of 2PC and authenticated protocol messages • The semantics of the authenticated messages only apply if the txn is committed.

39. Repudiation • If a message from A to B is part of a 2PC protocol, then B’s possession of the digital signature proves nothing. • A can claim: Yes, that was sent, but the action was rolled back. • B must prove that the action was committed. B must also prove that the message was part of that txn.

40. Implications for Internet Commerce • Existing protocols are inappropriate for the way people expect to be able to do business on the Internet. • The TIP approach looks promising, but ... • For particular business sectors, a detailed analysis of likely transaction behaviour will be needed. • Market opportunities for brokerage companies.

41. Conclusions • Security: techniques exist, but you have to know when to use them and how • Failure: Protocols exist, but they have several shortcomings, some more and some less serious • We did not discuss performance this time, but performance can be strongly related to failure (and perhaps to an extent to security).