- Slides: 64
COMP 1321 Digital Infrastructures Richard Henson February 2018
Session 16: Communications Protocols • By the end of this session, you should be able to: Ø explain how/why protocols should be designed and built according to proven engineering principles and the catastrophic effect of not doing so Ø explain the communications issues that need resolving when data could be sent through multiple paths Ø explain how TCP/IP guarantees packet delivery
Communication between Multiple Digital Devices • If a network is involved, requires… Ønavigation of packets Øa routing algorithm Øreliability (needs to work!) ØNEEDS TO BE TRUSTWORTHY!!!
Writing the best software… • TCP/IP is amazing! • How was this achieved? • Why isn’t all software this good? • All about design… (!) Øand the time/money to implement it correctly
Trusted Software Initiative (TSI) • Software was getting worse… Ø more and more vulnerabilities identified • 2012… government-sponsored body with responsibility for coordinating principles for developing trustworthy software 5 [TSI/2012/183] © Copyright 2003 -2012
Trustworthy Software Foundation • The UK’s leading professional bodies for ICT are supporting the provision of course material for all relevant UK University courses… • • British Computer Society (BCS) Institute of Engineering & Technology (IET) Royal Academy of Engineering (RAEng) Engineering Council (EC)
Why now? • • The growth and prosperity of economies around the world are driven by ICT… Ø organisations and individuals need to have trust in the systems they use and the software that runs on them to benefit from the all that ICT and the Internet have to offer Consequences of untrustworthy software… Ø major impact on organisations and countries, from political, economic, financial and security perspectives • Until recently, little consensus on Ø what constitutes trustworthy software Ø how to achieve it!
Aims of TSF • Originally based on UK cyber security intentions… Ø improve cyber security Ø software more secure, dependable and reliable Ø educate on why trustworthy software is important • Trustworthy Software Framework (TSF) provides means for anyone to quickly find the information and advice they need to build, procure or work with trustworthy software
Protocol for sending data across a Network https: //www. ietf. org • Any software for the Internet submitted to IETF (Internet Engineering Task Force) Ø people have 6 months to comment Ø Becomes a Draft RFC (request for comments) Ø if all OK, can be developed into Internet software (perhaps minor modifications)
Development of TCP and IP • Final TCP and IP designs submitted as RFCs (1974, 1980, 1981) Øhttp: //www. rfc-base. org/txt/rfc-675. txt Øhttp: //www. rfc-base. org/txt/rfc-760. txt Øhttp: //www. rfc-base. org/txt/rfc-791. txt Øhttp: //www. rfc-base. org/txt/rfc-793. txt ØAuthors: • John Postel “Father of the Internet” (died 1998) • Vint Cerf, Bob Kahn… ideas on packet switching Øhttps: //en. wikipedia. org/wiki/Jon_Postel ØApproved, numbered (760 replaced by 793)
Implementation of Program Design • TCP and IP both implemented in “C” by Postel & friends Øtested and passed to IETF Øfurther tested by IETF people Øonce all was OK, installed on Internet Obituary to John Postel: https: //tools. ietf. org/html/rfc 2468
20 years on: Types of Software used in real world Wetware Software Hardware e. g. VDHL [TSI/2013/306 | Draft 0. B | 2014 -02 -10]
Reuse of Code • Takes a long time to write programs Øif good, and shared… • • • goes into “libraries” used to make new programs can be unexpected consequences…
Software Supply Chain (reuse of code…? ) e. g. ECU e. g. Refinery Sensor e. g. SMSC e. g. DBMS e. g. Web. App
“Appropriate Conduct” (for software developers? ) • Guidelines go back a long way… • Babylonian Code of Hammurabi (~1780 BCE) Ø earliest known example of code of conduct for craftsmen, engineers and builders • Hippocrates: “Oath” (5 th Century BCE) Ø a moral framework for the conduct of doctors and other healthcare professionals 15 [TSI/2012/183] © Copyright 2003 -2012
Prerequisites for Trustworthiness Trustworthy Software Trustworthy Practitioners Trustworthy Organisations Components
Do People Remember and Learn? • Old knowledge, New context… Øapparently they don’t! • e. g. Tay Railway Bridge (1880 s)… ØThe Court of Inquiry report concluded that, "The fall of the bridge was occasioned by the insufficiency of the cross bracing and its fastenings to sustain the force of the gale. ” http: //taybridgedisaster. co. uk
When is software Trustworthy? Trustworthy when it is all of these things!
Engineering Principles • Royal Academy of Engineering & Engineering • Council: Statement of Ethical Principles Includes: Ø acting in a reliable and trustworthy manner Ø Giving due weight to all relevant facts and published guidance, and the wider public interest Ø Identifying, evaluating, and quantifying risks Ø Being alert to ways in which work might affect others, holding health and safety paramount 19 [TSI/2012/183] © Copyright 2003 -2012
Software as Engineering • Not everyone agrees… • Bridges & software… ØCreativity v Practicality Øboth need to look good Øbut both need to be trustworthy… (!) ØOtherwise… DISASTER!
Software problems: Incident Impact (1) • High cost to economy… Ø US Government National Institute of Standards & Technology (NIST) ~$60 billion/year to US alone 21 [TSI/2012/183] © Copyright 2003 -2012
Software: Incident Impact (2) • Software a major source of IT project failure: Ø University of Oxford Saïd Business School / Mc. Kinsey 2011 Ø ESSU (European Services Strategy Unit) 2007 Ø Tata Consultancy 2007 Ø Standish Chaos Reports 2004 onwards Ø Rand 2004 • Software bugs “source of 90% of ICT Incidents” Ø (Gov. CERT-UK, 2012 -09)
ICT & Adversity § Few practitioners treat Adversity holistically § Information Security community model has problems handling Known, Unknown and Unknowable (Ku. U) factors, and often ignores Hazards § System Reliability / Source: UK TSI / US DOD (2012) Safety community model usually ignores Threat 23 [TSI/2012/183] © Copyright 2003 -2012
Software Fault Case Study (1) • Availability… Nat. West bank systems failure, 2012 24 [TSI/2012/183] © Copyright 2003 -2012
Software Fault Case Study (2) • Safety… National Cancer Institute, Panama City (2000) 25 [TSI/2012/183] © Copyright 2003 -2012
Software Fault Case Study (3) • Security. . . (hacked!) North East US power blackout (2003) 26 [TSI/2012/183] © Copyright 2003 -2012
More software: Routing Protocols • Two basic routing methods… Øconnection-oriented (circuit switching) • route calculated • all data follows that route Øconnectionless (packet switching) • • • data chopped up into “packets” each packet finds its own way… routers provide direction signs…
Analogy: Circuit Switching and Packet Switching • Group of students need to get from City Campus to Riverside for a lecture… Øcircuit switching: all go together on the bus • everyone goes the same way… Øpacket switching: just agree to meet at the destination address • everyone goes their own sweet way…
Why Circuit Switching? • Used for very many years by analogue telephone networks (CCITT standard!): Ø system of relays and wires Ø when the required number is dialed, a series of electrical switches are opened Ø result… direct communication channel between sender and receiver • As with point-point, communication channel created by the sender
Circuit-Switching & computer networks • Protocol (on sender)… 1. Data input: a) name/address of receiver b) map of the network 2. networking software on sender navigates a route through the network with the aid of a routing algorithm (e. g. Dijkstra’s Routing Algorithm)
Circuit-Switching & computer networks • Continued… 4. further software tests the route to receiver for carrying data 5. network “channel” opened 6. data all transmitted along same route, using point-point protocol 7. channel closes!
Packet Switching • Devised by British and French research scientists in the early days of computer networking Ø each packet also contained a header, with “source” and “destination” addresses and TTL information • First practical use of packet-switching to route data around the ARPAnet, back in Dec 1969. . . Ø by 1980 s, managed reliably by TCP/IP • Postel’s protocols!
Packet v Circuit switching • No need for relaying devices! Øprobably be too slow, in any case • Each node “intelligent” Øcan participate dynamically in the routing • All nodes… (not just sender) Øneed to access an up-to-date record of network addresses for routing purposes • Adv: Much greater max. network traffic
Problem with Small Packets • Original TCP/IP: Ø IP packet was 53 bytes (48 data + 5 header) • For sending longer messages, this becomes inefficient Ø header information makes up a significant portion of the data sent • Possible solution: Ø string several packets together (multiplexing) Ø take them apart again at the receiving end (demultiplexing) • Perfected TCP/IP typically uses 768 bytes
What is a “Packet”? header payload (data) • Each header contains: Ø destination IP address (so it can be routed to the right node Ø source IP address (in case it gets lost, and so that the receiver knows where it came from) Ø TCP port number (type of application it belongs to) Ø message “chunk” number, so packets that are part of a message can be reassembled into the correct order as they arrive at the receiver Ø A TTL (Time To Live, e. g. 5 days)
Mechanism of Packet switching • Packets go to an adjacent node Øreceiver node uses packet header information to route to next node (closer to destination node) Øif the intended receiver becomes inactive “en route”… ØThen source address used to “return to sender” • c. f. letter that has been incorrectly addressed
Mechanism of Packet switching • Eventually (less than a second, or up to • several days…) the packets should all arrive at the destination node Problem – packets may well be navigated along different routes, and the order of delivery may be quite different from the order of sending… Ø packet numbering, found in “header data” Ø software to re-organise packets into the correct order
Issues with Connectionless Communication (1) • No prior “hand shaking”… (unlike connection-orientated communication) Øso receiver doesn’t necessarily expect the packet Øneeds to include a mechanism for acknowledging safe receipt of each packet
Issues with Connectionless Communication (2) • If If the packet doesn’t find its destination, it • • could wander around for a long time… Sender will not know if that packet is “lost” The packet is taking up valuable bandwidth on the network So each packet has a TTL (time to live) After this time has elapsed, no further routing will take place and the receiving node will delete (“kill”) it
Issues (3): Identifying the receiver ~ network addressing • Sending data not a non-existent node Ø could be sending to any one of thousands (on a large network) of potential receiver nodes Ø all nodes must have a unique identifier, generally known as a network address – analogous to a telephone number Ø all nodes must also have access to a database of network nodes, so that it can be quickly established whether or not the receiving node actually exists
Postel’s Protocol (OSI layers 3 & 4) • Assumptions: Ønetwork infrastructure layers (1 & 2) operating normally • establishment and management of open channels managed separately by CSMA/CD protocol - more on this later) Øall channels are “open” for communication Øpackets are numbered, so they can be correctly assembled at the receiving end
Stage 1 • When the first packet of the message leaves the sender, it is picked up by a “network names” database, which is dynamically updated Ø may well be held on the network “host“ or server computer • Server uses the database to “ping” the destination address to check it is “active” (i. e. has an open communications channel) Ø information sent back to the senders IP address
Stage 2 • If the sender receives a positive response: Ø the routing algorithm will calculate a route round the network, taking account of the network topology Ø the first packet, complete with error checking information, will be sent out to the address of the first “hop” • This in turn should route the packet to the next address, and so on, until the packet reaches its destination
Stage 3 • Subsequent packets can follow immediately, whether or not the first packet has arrived at its destination Ø routing algorithm may chart a different route through the network • When a packet arrives at its destination, it is processed for errors, and an appropriate message routed back to the sender: Ø either an acknowledgement of safe delivery Ø or a resend request in the event of errors being detected)
Stage 4 • All packets received? Then… Ø they are sorted into the correct order using packet numbers Ø a message is sent back to the receiver indicating that the whole message has been satisfactorily sent • What if a packet is “lost” on the network? Ø a “timeout” signal from the router that fails to pass it on will trigger a request to resend that packet
Other Protocols and packet switching • IBM was the biggest player in computer networks Ø when OSI (and later TCP/IP) became accepted as an International standard… Ø came up with their own proprietary implementation Ø whole new operating system based on Unix: • known as AIX
More about TCP/IP • Protocol suite? Ø family of (communication) protocols that work together in a consistent fashion • Or protocol “stack”? Ø 7 stacked up software layers that make it compliant with the ISO/OSI open systems model Ø TCP makes up level 4 (transport) Ø IP makes up level 3 (network) • Designed to deal with all issues that may arise during network communication, so unlikely to fail (engineering, trustworthiness…)
RIP (Routing Information Protocol) • Protocol to navigate packets round the Internet so as to avoid congested channels • Again proposed as an RFC (1058): Øhttp: //www. rfc-base. org/txt/rfc-1058. txt Øproposed by Hendrik, Rutgers University Øaccepted in 1988
Theory of Routing • Uses IP address (OSI level 3) ØCompare: MAC addresses used at level 2 for Ethernet • Each router reads the IP destination address of each packet Øthen decides what to do with the packet Øwhich router to forward the packet on to?
‘Store and Forward’ (1) • Packets arriving at a router may come from several different connections • May not arrive regularly Øarrivals may be ‘bursty’ • Router may not be able to process all packets immediately on arrival Øe. g. 2 packets arriving almost simultaneously on different connections
‘Store and Forward’ (2) • Packets arrive at the router, added to a “buffer” Øarea of memory where packets are stored temporarily until they can be processed • Packets processed in order of arrival Ø‘first in, first out’ (FIFO) stack • Note: if the buffer gets full, further packets are discarded and lost
Routing decisions • Router uses the destination IP address in the packet IP header to decide what to do with the packet Øsend to a local network to which the router is connected? • router must know the IP addresses relevant to its own local network(s) Øor forward on to another router? • But which one?
Routing tables • Each router: database of IP addresses (or parts of IP addresses) Øfor each destination IP address… Ørouting table has a link that a packet for that IP address should be forwarded on • Router reads the destination IP address, consults the routing table, and forwards the packet on the appropriate link
Routing table from http: //www. answers. com/topic/routing-protocol 1? cat=technology
Construction of routing tables • Routing tables can be set up when the router is first booted • But network conditions may change Øa route that was once optimal may become congested Øa link or router may malfunction or be removed Øa new link may be added to the network • Dynamic updates needed
Updating routing tables • Routers send each other information about network conditions ØBroken links ØNew links ØRouters going off-line ØCongestion problems • Each router updates its routing tables accordingly
Normal route of message Router B Recipient Router C Router A Sender
Disaster strikes: link is broken Router B Recipient Router C Router A Message cannot be delivered Sender
What happens • Router A finds out about the broken link ØNo traffic received from router B ØRegular updates from router B don’t arrive • Router A knows enough about the local network topology to use an alternative route • Routing table adjusted accordingly
Solution: a new route is found Router B Recipient Router C Router A Sender
Decisions between multiple possible routes • Factors to be considered by the router: ØTotal number of ‘hops’ in the path ØTraffic loading on each hop ØFinancial costs of using certain hops • Algorithms for finding best routes: ØBellman-Ford (distance-vector algorithm) ØDijkstra (link-state algorithm)
Border Gateway Protocol (alternative to RIP) • Application layer protocol ØTCP port 179 • First defined in RFC 1105 (June 1989) Øupdated to version 4 in RFC 1774 (March 1995) Ølatest update to version 4: RFC 4271 (January 2008)
Who managed TCP/IP development? • All changes Overseen by IETF (Internet Engineering Task Force) http: //www. ietf. org Ømade sure implementation followed best engineering principles • Over budget, late, and very expensive… who paid? Was it worth it?
After class… • What other protocols were available for digital communication besides TCP/IP? • Why did TCP/IP become so successful? • What other routing protocols are available besides RIP