Transcript Presentation16

COMP1321
Digital Infrastructures
Richard Henson
February 2016
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
Getting the message across…
• Humans:
 waving flags
 smoke & fire signals
 more recently: morse code
• Each has a set of rules… a protocol
Communication between
Multiple Digital Devices
• If a network is involved
the protocol involves navigation of packets
and a routing algorithm
needs to work!
NEEDS TO BE TRUSTWORTHY!!!
TSK-100-2
Concepts of Trustworthy
Software
Generic BSc Courseware
DRAFT v0.B
2012-12-07]
© Copyright TSI 2003-2012
5
Trusted Software Initiative T$I)
• A new government-sponsored body with
responsibility for coordinating principles for
developing trustworthy software
• 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)
6
[TSI/2012/183]
© Copyright 2003-2012
Why Trustworthy Software?
•
•
•
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
Undesirable consequences of current - untrustworthy
- software has major impact on organisations, and
countries, from political, economic, financial and
security perspectives
Yet – until now – little consensus on what constitutes
trustworthy software, and how to achieve it!
TSI & TSF
•
Minister for the Cabinet Office Francis Maude,
“Future Plans for UK’s Cyber Security Strategy”:
“We support and fund the Trustworthy Software Initiative
(TSI), which aims to improve cyber security by making
software more secure, dependable and reliable, and to
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
• Needs point-point transmission protocol
• Two further issues immediately arise when
there are two or more possible receivers for
the data:
 1. identifying the receiver
 2. navigating a route between sender and receiver
• Software duly developed and very thoroughly
tested…
Types of Software
currently being used
Supply
Wetware
Software
Hardware
e.g. VDHL
Chain
[TSI/2013/306 | Draft 0.B | 2014-02-10]
TSI
Logo
e.g. ECU
Software Supply Chain
(reuse of code…?)
e.g. Refinery
Sensor
e.g. SMSC
e.g. DBMS
[TSI/2013/306 | Draft 0.B | 2014-02-10]
e.g. WebApp
TSI
Logo
Prerequisites
for Trustworthiness
Trustworthy
Software
Trustworthy
Practitioners
Trustworthy
Trustworthy
Organisations Components
[TSI/2013/306 | Draft 0.B | 2014-02-10]
“Appropriate Conduct”
(for developers?)
• Nothing new…
•
Babylonian Code of Hammurabi (~1780BCE)
•
Hippocrates lays out the Oath (late 5th Century
BCE)
 earliest known example of code of conduct for
craftsmen, engineers and builders
 a moral framework for the conduct of doctors and other
healthcare professionals
13
[TSI/2012/183]
© Copyright 2003-2012
Do People Learn?
• Old knowledge, New context…
•
apparently they don’t!
e.g. Tay Railway Bridge (1880s)…
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
TSI
Logo
Prerequisites
for Trustworthiness
Trustworthy
Software
Trustworthy
Practitioners
Trustworthy
Trustworthy
Organisations Components
[TSI/2013/306 | Draft 0.B | 2014-02-10]
Context
Trustworthiness
TSI
Logo
Trustworthiness
Safety
The ability of the
system to
operate without
harmful states
Resilience
Reliability
Availability
The ability of the
system to deliver
services as
specified
The ability of the
system to deliver
services when
requested
The ability of the
system to
transform,
renew, and
recover in timely
response to
events
[TSI/2013/306 | Draft 0.B | 2014-02-10]
Security
The ability of the
system to remain
protected against
accidental or
deliberate
attacks
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
17
[TSI/2012/183]
© Copyright 2003-2012
Software & Engineering
• Creativity v Practicality
• Bridges & software… look good?
also need to be trustworthy:
 safe
 reliable
 available
 resilient
 secure…
Software problems:
Incident Impact (1)
• High cost to economy…
 US Government National Institute of Standards &
Technology (NIST) ~$60 billion/year to US alone
19
[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 /
McKinsey 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”
 (GovCERT-UK, 2012-09)
ICT & Adversity
 Few practitioners
treat Adversity
holistically
 Information Security
community model
has problems
handling Known,
Unknown and
Unknowable (KuU)
factors, and often
ignores Hazards
 System Reliability /
Source: UK TSI / US DOD (2012)
Safety community
model usually ignores
Threat
21
[TSI/2012/183]
© Copyright 2003-2012
Software Fault Case Study (1)
•
Availability…
NatWest bank
systems failure, 2012
22
[TSI/2012/183]
© Copyright 2003-2012
Software Fault Case Study (2)
•
Safety…
National Cancer
Institute, Panama
City (2000)
23
[TSI/2012/183]
© Copyright 2003-2012
Software Fault Case Study (3)
•
Security... (hacked!)
North East US
power blackout
(2003)
24
[TSI/2012/183]
© Copyright 2003-2012
Routing protocols
(also see previous lecture)
• Two routing methods…
connection-oriented (circuit switching)
• all data goes the same way
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 1980s, managed reliably by TCP/IP protocol
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”?
• 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)
 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)
• Payload contains… data
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
Resolving 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
Resolving 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
A Packet Switching protocol
(OSI layers 3 & 4)
• Assumptions:
the network infrastrucure (layers 1 & 2) is
operating normally & the establishment
and management of open channels is
managed separately by a further protocol
(known as CSMA/CD - 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…)
Who managed TCP/IP
development?
• Design of all Internet software “de jure”:
via RFC (Request for Comments)
• 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? What if it was rushed?
(e.g. fixed/tighter deadline?)
After class…
• What other protocols were available for
digital communication besides TCP/IP?
• Why did TCP/IP become so successful?