COMP 1321 Digital Infrastructures Richard Henson February 2018

  • Slides: 64
Download presentation
COMP 1321 Digital Infrastructures Richard Henson February 2018

COMP 1321 Digital Infrastructures Richard Henson February 2018

Session 16: Communications Protocols • By the end of this session, you should be

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

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? •

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

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

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

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

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

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

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

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.

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

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

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… •

“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

Prerequisites for Trustworthiness Trustworthy Software Trustworthy Practitioners Trustworthy Organisations Components

Do People Remember and Learn? • Old knowledge, New context… Øapparently they don’t! •

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!

When is software Trustworthy? Trustworthy when it is all of these things!

Engineering Principles • Royal Academy of Engineering & Engineering • Council: Statement of Ethical

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

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

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: Ø

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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 •

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

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,

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

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 &

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

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

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

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

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

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

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

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

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

‘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”

‘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

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)

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

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

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

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

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

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

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

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

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 •

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)

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? •

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