文章目录
- 5. Control Plane
- 6. Link layer
- 7. Network Security
5. Control Plane
two network-layer functions:
- forwarding: move packets from router’s input port to appropriate output port (data plane)
- routing: determine route taken by packets from source to destination (control plane)
Two approaches to structuring network control plane:
- per-router control (traditional): Individual routing algorithm components in each and every router interact with each other in control plane to compute forwarding tables
- logically centralized control (software defined networking): A distinct (typically remote) controller interacts with local control agents (CAs) in routers to compute forwarding tables
Why a logically centralized control plane?
- Easier network management: avoid router misconfigurations, greater flexibility of traffic flows
- Table-based forwarding (recall OpenFlow API) allows “programming” routers
- Centralized “programming” easier: compute tables centrally and distribute
- Distributed “programming more difficult: compute tables as result of distributed algorithm (protocol) implemented in each and every router
- Open (non-proprietary) implementation of control plane
5.1 Routing protocols: Dijkstra
Routing protocol goal: determine “good” paths (equivalently, routes), from sending hosts to receiving host, through network of routers
- Path: sequence of routers packets will traverse in going from given initial source host to given final destination host
- “good”: least “cost”, “fastest”, “least congested”
- Routing: a “top-10” networking challenge!
使用 Dijkstra 算法来解决,把网络抽象为一张图,跑最短路。
5.2 Routing protocols: Distance vector algorithm
From time-to-time, each node sends its own distance vector estimate to neighbors When x receives new DV estimate from neighbor, it updates
its own DV using B-F equation (通过松弛更新当前节点的最短路)
Iterative, asynchronous: each local iteration caused by:
- Local link cost change
- DV update message from neighbor
Distributed: Each node notifies neighbors only when its DV changes, neighbors then notify their neighbors if necessary.
link cost changes
- Node detects local link cost change
- Updates routing info, recalculates distance vector
- If DV changes, notify neighbors
- good news travels fast but Bad news travels slow – “count to infinity”
5.3 Intra-AS routing in the Internet: OSPF
Making routing scalable
Our routing study thus far - idealized
- All routers identical
- Network “flat”
Scale: with billions of destinations:
- Can’t store all destinations in routing tables!
- Routing table exchange would swamp links!
Administrative autonomy
- Internet = network of networks
- Each network admin may want to control routing in its own network
5.3.1 Internet approach to scalable routing
Aggregate routers into regions known as “autonomous systems” (AS)
Intra-AS routing
- Routing among hosts, routers in same AS
- All routers in AS must run same intra-domain protocol
- Routers in different AS can run different intra-domain routing protocol
- Gateway router: at “edge” of its own AS, has link(s) to router(s) in other AS’es
Inter-AS routing
- Routing among AS’es
- Gateways perform inter-domain routing (as well as intra-domain routing)
Interconnected ASes
Forwarding table configured by both intra- and inter-AS routing algorithm
- Intra-AS routing determine entries for destinations within AS
- Inter-AS & intra-AS determine entries for external destinations
Inter-AS tasks
Suppose router in AS1 receives datagram destined outside of AS1:
- Router should forward packet to gateway router, but which one?
- AS1 must:
- Learn which dests are reachable through AS2, which through AS3
- Propagate this reachability info to all routers in AS1
Intra-AS Routing
Aka interior gateway protocols (IGP)
Most common intra-AS routing protocols:
- RIP: Routing Information Protocol
- OSPF: Open Shortest Path First (IS-IS* protocol essentially same as OSPF)
- IGRP: Interior Gateway Routing Protocol (Cisco proprietary for decades, until 2016)
5.4 Routing among the ISPs: BGP
BGP (Border Gateway Protocol): the de facto inter-domain routing protocol
BGP provides each AS router a means to:
- eBGP: obtain subnet prefix reachability information from neighboring ASes. Allows subnet to advertise its existence to rest of Internet: “I am here.”
- iBGP: propagate reachability information to all AS-internal routers, and determine “best” routes to other networks based on reachability information and policy
- BGP session: two BGP routers (“peers”) exchange BGP messages over semi-permanent TCP connection (using port 179). Advertising paths to different destination network prefixes (BGP is a “path vector” protocol)
- When AS3 gateway router 3a advertises path AS3,X to AS2 gateway router 2c: AS3 promises to AS2 it will forward datagrams towards X.
Path attributes and BGP routes
Advertised prefix includes BGP attributes: prefix + attributes = “route”
Two important attributes:
- AS-PATH: list of ASes through which prefix advertisement has passed.
- NEXT-HOP: indicates the IP address of the router interface that begins the AS-PATH.
- Policy-based routing:
- Gateway receiving route advertisement uses import policy to accept/decline path (e.g., never route through AS Y).
- AS policy also determines whether to advertise path to other neighboring ASes.
5.4.1 BGP messages
- BGP messages exchanged between peers over TCP connection
- BGP messages:
- OPEN: opens TCP connection to remote BGP peer and authenticates sending BGP peer
- UPDATE: advertises new path (or withdraws old)
- KEEPALIVE: keeps connection alive in absence of UPDATES; also ACKs OPEN request
- NOTIFICATION: reports errors in previous msg; also used to close connection
5.4.2 BGP route selection
Router may learn about more than one route to destination AS, selects route based on:
- local preference value attribute: policy decision
- shortest AS-PATH
- closest NEXT-HOP router: hot potato routing
- choose local gateway that has least intra-domain cost, don’t worry about inter-domain cost
- additional criteria
5.4.3 achieving policy via advertisements
Suppose an ISP only wants to route traffic to/from its customer networks (does not want to carry transit traffic between other ISPs)
A,B,C are provider networks, X,W,Y are customer (of provider networks), X is dual-homed: attached to two networks.
policy to enforce: X does not want to route from B to C via X, so X will not advertise to B a route to C
- A advertises path Aw to B and to C
- B chooses not to advertise BAw to C:
- B gets no “revenue” for routing CBAw, since none of C, A, w are B’s customers.
- C does not learn about CBAw path
- C will route through CAw (not using B) to get to w
Why different Intra-, Inter-AS routing?
Policy:
- inter-AS: admin wants control over how its traffic routed, who routes through its net.
- intra-AS: single admin, so no policy decisions needed
5.5 The SDN control plane
SDN: Software defined networking
- Internet network layer: historically has been implemented via distributed, per-router approach
- Monolithic router contains switching hardware, runs proprietary implementation of Internet standard protocols (IP, RIP, IS-IS, OSPF, BGP) in proprietary router OS (e.g., Cisco IOS)
- Different “middleboxes” for different network layer functions: firewalls, load balancers, NAT boxes,
- Renewed interest in rethinking network control plane
5.5.1 Key Characteristics of SDN Architecture
Data plane switches
- Fast, simple, commodity switches implementing generalized data-plane forwarding in hardware
- Switch flow table computed, installed by controller
- API for table-based switch control: defines what is controllable and what is not
- Protocol for communicating with controller
SDN controller (network OS)
- Maintains network state information
- Interacts with network control applications “above” via northbound API
- Interacts with network switches “below” via southbound API
- Implemented as distributed system for performance, scalability, fault-tolerance, robustness
Network-control apps
- “brains” of control: implement control functions using lower-level services, API provided by SND controller
- Open: can be provided by 3rd party: distinct from routing vendor, or SDN controller
Components of SDN controller
5.5.1 OpenFlow protocol
- Operates between controller, switch
- TCP used to exchange messages (optional encryption)
- Three classes of OpenFlow messages:
- controller-to-switch
- asynchronous (switch to controller)
- symmetric (misc)
controller-to-switch messages
- Features: controller queries switch features, switch replies
- Configure: controller queries/sets switch configuration parameters
- Modify-state: add, delete, modify flow entries in the OpenFlow tables
- Packet-out: controller can send this packet out of specific switch port
switch-to-controller messages
- Packet-in: transfer packet (and its control) to controller. See packet-out message from controller
- Flow-removed: flow table entry deleted at switch
- Port status: inform controller of a change on a port.
OpenDaylight (ODL) controller
- ODL Lithium controller
- Network apps may be contained within, or be external to SDN controller
- Service Abstraction Layer: interconnects internal, external applications and services
ONOS controller
- Control apps separate from controller
- Intent framework: high-level specification of service: what rather than how
- Considerable emphasis on distributed core: service reliability, replication performance scaling.
5.6 ICMP
ICMP: internet control message protocol
Used by hosts & routers to communicate network-level information
- error reporting: unreachable host, network, port, protocol
- echo request/reply (used by ping)
Network-layer “above” IP:
- ICMP msgs carried in IP datagrams
ICMP message: type, code plus first 8 bytes of IP datagram causing error.
Traceroute and ICMP
Source sends series of UDP segments to destination
- first set has TTL =1
- second set has TTL=2, etc.
- unlikely port number
When datagram in nth set arrives to nth router:
- router discards datagram and sends source ICMP message (type 11, code 0)
- ICMP message include name of router & IP address
When ICMP message arrives, source records RTTs.
Stopping criteria:
- UDP segment eventually arrives at destination host
- destination returns ICMP “port unreachable” message (type 3, code 3)
- source stops
5.6 SNMP
Network management includes the deployment, integration and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate, and control the network and element resources to meet the real-time, operational performance, and Quality of Service requirements at a reasonable cost. – Saydam 1996
Infrastructure for network management
Managed devices contain managed objects whose data is gathered into a Management Information Base (MIB)
5.6.1 SNMP protocol
Two ways to convey MIB info, commands:
message types
message formats
6. Link layer
Data-Link Layer has responsibility of
- transferring datagram
- from one node to physically adjacent node
- over a link
Node: Hosts and routers
Link:
- communication channel
- connection adjacent nodes
Layer-2 packet: frame. Encapsulates datagram
6.1 Services of link layer
Link layer services
- Framing
- Encapsulate datagram into frame: adding header, trailer
- Different formats for different protocols
- Link access
- Medium Access Control (MAC) protocol is used to transmit a frame
- Point to point link or broadcast link
- MAC addresses used in frame to identify source and destination
- Reliable delivery
- Low bit-error link (fiber, coax, some twisted pair): seldom used
- High error rates wireless links: often used
- Error detection and correction
- Caused by signal attenuation, noise
- Receiver detects error: retransmission or correction
- Correction: corrects the bit error without retransmission
Where is the link layer implemented?
In each and every host
Link layer implemented in “Adapter” or on a chip. Attached into host’s system buses
Adaptors communicating
- Sending side
- Encapsulates datagram in frame
- Adds error checking bits, rdt, flow control, etc.
- Receiving side
- Looks for errors, rdt, flow control, etc.
- Extracts datagram, passes to upper layer at receiving side
6.2 Error detection and correction
6.2.1 Error detection
D = Data protected by error checking, including header fields
EDC = Error Detection and Correction bits (redundancy)
Error detection not 100% reliable!
protocol may miss some errors, but rarely. larger EDC field (more sophisticated) yields better detection and correction.
6.2.2 Three techniques for detecting errors
- Parity Checks
- Single bit parity
- Even/Odd parity scheme: Add an additional bit. Total number of 1 (D+1) is even/odd.
- Detect single bit errors
- 2D parity
- Detect and correct single bit errors
- Two-dimensional even parity
- Single bit parity
- Checksum
- Goal: detect “errors” in transmitted segment
- Sender
- Treat segment contents, including header fields, as sequence of 16-bit integers
- Checksum: addition (one’s complement sum) of segment contents
- Sender puts checksum value into (e.g., UDP) checksum field
- Receiver
- Compute checksum of received segment
- Check if computed checksum equals checksum field value
- In the TCP and UDP protocols, the Internet checksum is computed over all fields (header and data fields included). In IP, the checksum is computed over the IP header (since the UDP or TCP segment has its own checksum).
- Cyclic Redundancy Checks (CRC)
- more powerful error-detection coding, widely used in practice
- all CRC calculations are done in modulo-2 arithmetic without carries in addition or borrows in subtraction.
- modulo-2 Arithmetic
- Addition
- Subtraction
- Bitwise exclusive-or
- steps
- view Data bits, D, as a binary number
- choose an r + 1 r+1 r+1 bit pattern (generator), G (G is given for both sender and receiver.)
- goal: find r CRC bits, (remainder), R, such that a d + r a~ d+r a d+r bit pattern <D, R> exactly divisible by G (modulo-2)
- receiver knows G, divides <D, R> by G.
- if non-zero remainder: error detected!
- can detect all burst errors less than r + 1 bits
6.3 Multiple access protocols
6.3.1 Multiple access links, protocols
Two types of links:
- P2P
- PPP for dial-up access
- PPPOE: Point to point protocol over Ethernet
- Broadcast: shared wire or medium
- Old-fashioned Ethernet
- Upstream HFC
- WLAN – 802.11
Multiple access protocols
- One single shared broadcast channel
- Two or more simultaneous transmissions by nodes: interference
- collision if node receives two or more signals at the same time.
- Multiple access protocol: Distributed algorithm that determines how nodes share channel, i.e., determine when node can transmit
- Communication about channel sharing must use channel itself! (No out-of-band channel for coordination)
An ideal multiple access protocol
given: broadcast channel of rate R bps
Desiderata (desirable characteristics):
- when one node wants to transmit, it can send at rate R.
- when M nodes want to transmit, each can send at average (and instantaneous) rate R/M.
- fully decentralized:
- no special node to coordinate transmissions
- no synchronization of clocks, slots
- Simple, inexpensive to implement.
6.3.2 MAC protocols: taxonomy
Three broad classes:
- Channel partitioning
- divide channel into smaller “pieces” (time slots, frequency, code)
- allocate piece to node for exclusive use
- TDMA: time division multiple access
- Access to channel in “rounds”
- Each station/node gets fixed length slot (length = packet transmission time) in each round
- Unused slots go idle
- FDMA: frequency division multiple access
- Channel spectrum divided into frequency bands
- Each station/node assigned fixed frequency band
- Unused transmission time in frequency bands go idle
- Random access
- allocate piece to node for exclusive use
- “recover” from collisions
- When node has packet to send
- transmit at full channel data rate R
- no a priori coordination among nodes
- Two or more transmitting nodes ➜ “collision”
- Random access MAC protocol specifies:
- how to detect collisions
- how to recover from collisions
- Examples: slotted ALOHA, ALOHA, CSMA, CSMA/CD, CSMA/CA
- CSMA: carrier sense multiple access
- listen before transmit
- if channel sensed idle: transmit entire frame
- if channel sensed busy, defer transmission
- Taking turns
- nodes take turns, but nodes with more to send can take longer turns
- Polling
- Master node “invites” slave nodes to transmit in turn
- Typically used with “dumb” slave devices
- Drawbacks:
- Polling overhead
- Single point of failure (master)
- Token passing
- Control token passed from one node to next sequentially.
- Token message
- Drawbacks
- Token overhead
- Node crashes/fails to release token
6.4 Addressing and ARP
6.4.1 MAC address
- IP address
- IPv4 (32 bits) and IPv6 (128 bits)
- Network-layer address
- Layer-3 forwarding
- MAC (LAN) address
- 48 bits
- Burned in NIC ROM
- Used “locally” get frame from one interface to another physically-connected interface
Each adapter on LAN has unique LAN address
MAC address allocation administered by IEEE. Manufacturer buys portion of MAC address space (to assure uniqueness)
MAC flat address: portability. Can move LAN card from one LAN to another.
IP hierarchical address not portable. IP hierarchical address not portable.
6.4.2 ARP: address resolution protocol
How to determine interface’s MAC address, if knowing its IP address?
ARP table: each IP node (host, router) on LAN has the table
- An IP/MAC address mappings for LAN nodes: < IP address; MAC address; TTL>
- A TTL (Time To Live): time after which address mapping will be forgotten (typically 20 min)
ARP protocol: same LAN
- A wants to send datagram to B (B’s MAC address not in A’s ARP table.)
- A broadcasts ARP query packet, containing B’s IP address
- A broadcasts ARP query packet, containing B’s IP address
- All nodes on LAN receive ARP query
- B receives ARP packet, replies to A with its (B’s) MAC address. Frame sent to A’s MAC address (unicast)
- A caches (saves) IP-to-MAC address pair in its ARP table.
- ARP is “plug-and-play”: Nodes create their ARP tables without intervention from net administrator.
Addressing: routing to another LAN
Walkthrough: send datagram from A to B via R
- Focus on addressing – at IP (datagram) and MAC layer (frame)
- Assume A knows B’s IP address
- Assume A knows IP address of first hop router, R
- Assume A knows R’s MAC address
6.5 Ethernet
“dominant” wired LAN technology,
Single chip, multiple speeds,
First widely used LAN technology,
Simpler, cheap
thernet: physical topology
- Bus: popular through mid 90s. All nodes in same collision domain (can collide with each other)
- Star: prevails today: Active switch in center. Each “spoke” runs a (separate) Ethernet protocol (nodes do not collide with each other)
Ethernet frame structure
Sending adapter encapsulates IP datagram (or other network layer protocol packet) in Ethernet frame
- preamble: 8-byte
- 7 bytes with pattern 10101010 followed by one byte with pattern 10101011
- used to synchronize receiver, sender clock rates
- Addresses: 6 byte source, destination MAC addresses
- If adapter receives frame with matching destination address, or with broadcast address (e.g. ARP packet), it passes data in frame to network layer protocol
- Otherwise, adapter discards frame
- Type: indicates higher layer protocol (mostly IP but others possible, e.g., Novell IPX, AppleTalk)
- CRC: cyclic redundancy check at receiver (Error detected: frame is dropped)
Connectionless: no handshaking between sending and receiving NICs
Unreliable: receiving NIC doesn’t send acks or nacks to sending NIC. Data in dropped frames recovered only if initial sender uses higher layer rdt (e.g., TCP), otherwise dropped data lost
Ethernet’s MAC protocol: unslotted CSMA/CD with binary backoff (using with sensing channel idle)
802.3 Ethernet standards: link & physical layers
Many different Ethernet standards
- Common MAC protocol and frame format
- Different speeds: 2 Mbps, 10 Mbps, 100 Mbps, 1Gbps, 10 Gbps, 40 Gbps
- Different physical layer media: fiber, cable
6.6 Switches
Link-layer device (2 layer device): takes an active role
- Store, forward Ethernet frames
- Examine incoming frame’s MAC address, selectively forward frame to one-or-more outgoing links when frame is to be forwarded on segment, uses CSMA/CD to access segment
Transparent: Hosts are unaware of presence of switches
Plug-and-play, self-learning: Switches do not need to be configured
multiple simultaneous transmissions
- Hosts have dedicated, direct connection to switch.
- Switches buffer packets
- Ethernet protocol used on each incoming link, but no collisions; full duplex
Self-learning
Switch learns which hosts can be reached through which interfaces.
- When frame received, switch “learns” location of sender: incoming LAN segment
- Records sender/location pair in switch table
** frame filtering/forwarding**
When frame received at switch:
- record incoming link, MAC address of sending host
- index switch table using MAC destination address
- if entry found for destination
- if destination on LAN segment from which frame arrived: drop frame
- else forward frame on interface indicated by entry
- else flood
Interconnecting switches
Self-learning switches can be connected together
Institutional network
Switches vs. routers
Both are store-and-forward:
- Routers: network-layer devices (examine network-layer headers)
- Switches: link-layer devices (examine link-layer headers)
Both have forwarding tables:
- Routers: compute tables using routing algorithms, IP addresses
- Switches: learn forwarding table using flooding, learning, MAC addresses
6.7 VLANs: Virtual Local Area Network
Motivation
single broadcast domain:
- all layer-2 broadcast traffic (ARP, DHCP, unknown location of destination MAC address) must cross entire LAN
- security/privacy, efficiency issues
Switch(es) supporting VLAN capabilities can be configured to define multiple virtual LANs over single physical LAN infrastructure.
Port-based VLAN
- traffic isolation: frames to/from ports 1-8 can only reach ports 1-8. can also define VLAN based on MAC addresses of endpoints, rather than switch port.
- dynamic membership: ports can be dynamically assigned among VLANs
- forwarding between VLANS: done via routing (just as with separate switches). In practice vendors sell combined VLAN switches plus routers (so the external router shown in the figure is not needed)
VLANS spanning multiple switches
Trunk port: carries frames between VLANS defined over multiple physical switches
- Frames forwarded within VLAN between switches can’t be vanilla 802.1 frames (must carry VLAN ID info)
- 802.1q protocol adds/removed additional header fields for frames forwarded between trunk ports
802.1Q VLAN frame format
6.8 Data center networking
Thousands of hosts, closely coupled
- Search engines, data mining
- E-Business
- SNS
- Content-servers
Challenges
- Multiple applications, each serving massive numbers of clients
- Managing/balancing load, avoiding processing, networking, data bottlenecks
Load balancer: application-layer routing:
- Receives external client requests
- Directs workload within data center
- Returns results to external client (hiding data center internals from client)
Rich interconnection among switches, racks:
- Increased throughput between racks (multiple routing paths possible)
- Increased reliability via redundancy
scenario: student attaches laptop to campus network, requests / receives www.google.com
- connecting laptop needs to get its own IP address, addr of first-hop router, addr of DNS server: use DHCP
- DHCP request encapsulated in UDP, encapsulated in IP, encapsulated in 802.3 Ethernet
- Ethernet frame broadcast (dest: FFFFFFFFFFFF) on LAN, received at router running DHCP server
- Ethernet demuxed to IP demuxed, UDP demuxed to DHCP
- DHCP server formulates DHCP ACK containing client’s IP address, IP address of first-hop router for client, name & IP address of DNS server
- encapsulation at DHCP server, frame forwarded (switch learning) through LAN, demultiplexing at client
- DHCP client receives DHCP ACK reply
- before sending HTTP request, need IP address of www.google.com: DNS
- DNS query created, encapsulated in UDP, encapsulated in IP, encapsulated in Eth. To send frame to router, need MAC address of router interface: ARP
- ARP query broadcast, received by router, which replies with ARP reply giving MAC address of router interface
- client now knows MAC address of first hop router, so can now send frame containing DNS query
- IP datagram containing DNS query forwarded via LAN switch from client to 1st hop router
- IP datagram forwarded from campus network into Comcast network, routed (tables created by RIP, OSPF, IS-IS and/or BGP routing protocols) to DNS server
- demuxed to DNS server
- DNS server replies to client with IP address of www.google.com
- to send HTTP request, client first opens TCP socket to web server
- TCP SYN segment (step 1 in 3-way handshake) inter-domain routed to web server
- web server responds with TCP SYNACK (step 2 in 3-way handshake)
- client responds with TCP ACK (step 3)
- TCP connection established!
- HTTP request sent into TCP socket
- IP datagram containing HTTP request routed to www.google.com
- web server responds with HTTP reply (containing web page)
- IP datagram containing HTTP reply routed back to client
7. Network Security
confidentiality: only sender, intended receiver should “understand” message contents
- sender encrypts message
- receiver decrypts message
authentication: sender, receiver want to confirm identity of each other
message integrity: sender, receiver want to ensure message not altered (in transit, or afterwards) without detection
access and availability: services must be accessible and available to users
7.1 Principles of cryptography
The language of cryptography
m
m
m: plaintext message
K
A
(
m
)
K_A(m)
KA(m): ciphertext, encrypted with key
K
A
K_A
KA
m
=
K
B
(
K
A
(
m
)
)
m=K_B(K_A(m))
m=KB(KA(m))
Breaking an encryption scheme
- cipher-text only attack: Trudy has ciphertext she can analyze
- two approaches:
- brute force: search through all keys
- statistical analysis
- two approaches:
- known-plaintext attack: Trudy has plaintext corresponding to ciphertext
- chosen-plaintext attack: Trudy can choose the plaintext message and obtain its corresponding ciphertext form
7.1.1 Symmetric key cryptography
Simple encryption scheme
substitution cipher: substituting one thing for another
A more sophisticated encryption approach
Symmetric key crypto: DES
- 56-bit symmetric key, 64-bit plaintext input
- block cipher with cipher block chaining
- how secure is DES?
- DES Challenge: 56-bit-key-encrypted phrase decrypted (brute force) in less than a day
- no known good analytic attack
- making DES more secure: 3DES: encrypt 3 times with 3 different keys
AES: Advanced Encryption Standard
- symmetric-key NIST standard, replaced DES (Nov 2001)
- processes data in 128 bit blocks
- 128, 192, or 256 bit keys
- a machine could brute force decryption (try each key) taking 1 sec on DES, takes 149 trillion years for AES
7.1.2 Public Key Cryptography
given public key
K
B
+
K^+_B
KB+, it should be impossible to compute private key
K
B
−
K^-_B
KB−
RSA: Rivest, Shamir, Adleman algorithm
- message: just a bit pattern
- bit pattern can be uniquely represented by an integer number
- thus, encrypting a message is equivalent to encrypting a number
- Creating public/private key pair
- choose two large prime numbers p , q p,q p,q.
- compute n = p q , z = ( p − 1 ) ( q − 1 ) n=pq,z=(p-1)(q-1) n=pq,z=(p−1)(q−1)
- choose e , e < n e,e<n e,e<n that has no common factors with z z z
- choose d d d such that e d − 1 ed-1 ed−1 is exactly divisible by z z z
- public key is ( n , e ) (n,e) (n,e), private key is ( n , d ) (n,d) (n,d)
- encryption
- to encrypt message m ( < n ) m (<n) m(<n), compute c = m e m o d n c=m^e\mod n c=memodn
- to decrypt received bit pattern c c c, compute m = c d m o d n m=c^d\mod n m=cdmodn
- The following property will be very useful later: K B − ( K B + ( m ) ) = K B + ( K B − ( m ) ) K^-_B(K^+_B(m))=K^+_B(K^-_B(m)) KB−(KB+(m))=KB+(KB−(m))
- Why is RSA secure?
- suppose you know Bob’s public key (n,e). How hard is it to determine d?
- essentially need to find factors of n without knowing the two factors p and q. Factoring a big number is hard.
session key, K S K_S KS
- Bob and Alice use RSA to exchange a symmetric key K S K_S KS.
- once both have K S K_S KS, they use symmetric key cryptography.
7.2 Message integrity, authentication
7.2.1 Authentication
- Protocol ap1.0: Alice says “I am Alice”
- Protocol ap2.0: Alice says “I am Alice” in an IP packet containing her source IP address
- Protocol ap3.0: Alice says “I am Alice” and sends her secret password to “prove” it.
- Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it.
- Protocol ap4.0: to prove Alice “live”, Bob sends Alice nonce, R (once-in-a-lifetime). Alice must return R, encrypted with shared secret key
- Protocol ap5.0: use nonce, public key cryptography
ap5.0: security hole
man (or woman) in the middle attack: Trudy poses as Alice (to Bob) and as Bob (to Alice)
difficult to detect:
- Bob receives everything that Alice sends, and vice versa.
- problem is that Trudy receives all messages as well
7.2.2 Message integrity
Digital signatures
cryptographic technique analogous to hand-written signatures:
- sender (Bob) digitally signs document, establishing he is document owner/creator.
- verifiable, nonforgeable: recipient (Alice) can prove to someone that Bob, and no one else (including Alice), must have signed document.
simple digital signature for message m m m:
- Bob signs m m m by encrypting with his private key K B − K^-_B KB−, creating “signed” message, K B − ( m ) K^-_B(m) KB−(m)
Message digests
computationally expensive to public-key-encrypt long messages. Apply hash function
H
H
H to
m
m
m, get fixed size message digest,
H
(
m
)
H(m)
H(m).
Hash function properties:
- many-to-1
- produces fixed-size msg digest (fingerprint)
- given message digest x x x, computationally infeasible to find m such that x = H ( m ) x = H(m) x=H(m)
Signed message digest
Hash function algorithms
- MD5 hash function widely used
- computes 128-bit message digest in 4-step process.
- arbitrary 128-bit string x, appears difficult to construct msg m whose MD5 hash is equal to x
- SHA-1 is also used
- US standard
- 160-bit message digest
Public-key certification
Certification authorities
certification authority (CA): binds public key to particular entity, E.
E (person, router) registers its public key with CA.
- E provides “proof of identity” to CA.
- CA creates certificate binding E to its public key.
- certificate containing E’s public key digitally signed by CA – CA says “this is E’s public key”
7.3 Securing e-mail
Alice wants to send confidential e-mail, m, to Bob
- generates random symmetric private key, K S K_S KS
- encrypts message with K S K_S KS (for efficiency)
- also encrypts K S K_S KS with Bob’s public key
- sends both K S ( m ) K_S(m) KS(m) and K B + ( K S ) K^+_B(K_S) KB+(KS) to Bob
For Bob:
- uses his private key to decrypt and recover K S K_S KS
- uses K S K_S KS to decrypt K S ( m ) K_S(m) KS(m) to recover m m m
Alice wants to provide sender authentication message integrity
- Alice digitally signs message
- sends both message (in the clear) and digital signature
Alice wants to provide secrecy, sender authentication, message integrity: Alice uses three keys: her private key, Bob’s public key, newly created symmetric key
7.4 Securing TCP connections: SSL
SSL: Secure Sockets Layer
SSL and TCP/IP
SSL provides application programming interface (API) to applications
Toy SSL: a simple secure channel
- handshake: Alice and Bob use their certificates, private keys to authenticate each other and exchange shared secret
- key derivation: Alice and Bob use shared secret to derive set of keys
- considered bad to use same key for more than one cryptographic operation. Use different keys for message authentication code (MAC) and encryption.
- four keys:
- K C = K_C= KC= encryption key for data sent from client to server
- M C = M_C= MC= MAC key for data sent from client to server
- K S = K_S= KS= encryption key for data sent from server to client
- M S = M_S= MS= MAC key for data sent from server to client
- keys derived from key derivation function (KDF): takes master secret and (possibly) some additional random data and creates the keys
- data transfer: data to be transferred is broken up into series of records
- break stream in series of records
- each record carries a MAC
- receiver can act on each record as it arrives
- issue: in record, receiver needs to distinguish MAC from data. Want to use variable-length records
- sequence numbers
- problem: attacker can capture and replay record or re-order records
- solution: put sequence number into MAC:
- MAC = H ( M X , s e q u e n c e ∣ ∣ d a t a ) =H(M_X,sequence ||data) =H(MX,sequence∣∣data)
- note: no sequence number field (in the record)
- problem: attacker could replay all records
- solution: use nonce
- break stream in series of records
- connection closure: special messages to securely close connection
- problem: truncation attack (MITM attacker):
- attacker forges TCP connection close segment (FIN)
- one or both sides thinks there is less data than there actually is.
- solution: record types, with one type for closure ( type 0 for data; type 1 for closure)
- MAC = H ( M X , s e q u e n c e ∣ ∣ t y p e ∣ ∣ d a t a ) =H(M_X,sequence||type||data) =H(MX,sequence∣∣type∣∣data)
- problem: truncation attack (MITM attacker):
SSL cipher suite
- cipher suite
- public-key algorithm
- symmetric encryption algorithm
- MAC algorithm
- SSL supports several cipher suites
- negotiation: client, server agree on cipher suite
- client offers choice
- server picks one
7.4.1 Real SSL: handshake
- client sends list of algorithms it supports, along with client nonce
- server chooses algorithms from list; sends back: choice + certificate + server nonce
- client verifies certificate, extracts server’s public key, generates
pre_master_secret
, encrypts with server’s public key, sends to server - client and server independently compute encryption and MAC keys from
pre_master_secret
and nonces - client sends a MAC of all the handshake messages
- server sends a MAC of all the handshake messages
last 2 steps protect handshake from tampering
client typically offers range of algorithms, some strong, some weak, man-in-the middle could delete stronger algorithms from list. Last 2 steps prevent this.
7.5 Network layer security: IPsec
What is network-layer confidentiality?
between two network entities:
- sending entity encrypts datagram payload, payload could be: TCP or UDP segment, ICMP message, OSPF message
- all data sent from one entity to other would be hidden from any third party (that might be sniffing the network): web pages, e-mail, P2P file transfers, TCP SYN packets
- blanket coverage
Virtual Private Networks (VPNs)
- institutions often want private networks for security
- institution could actually deploy a stand-alone physical network that is completely separate from the public Internet.
- costly: separate routers, links, DNS infrastructure.
- VPN: institution’s inter-office traffic is sent over public Internet instead
- encrypted before entering public Internet
- logically separate from other traffic
two protocols providing different service models:
- Authentication Header (AH)
- provides source authentication and data integrity but no confidentiality
- Encapsulation Security Payload (ESP)
- provides source authentication, data integrity, and confidentiality
- more widely used than AH
IPsec transport mode (host mode)
- IPsec datagram emitted and received by end-system
- protects upper level protocols
tunneling mode
Security associations (SAs)
- before sending data, “security association (SA)” established from sending to receiving entity. SAs are simplex: logical connection for only one direction
- ending, receiving entitles maintain state information about SA
- recall: TCP endpoints also maintain state info
- IP is connectionless; IPsec is connection-oriented
Security Association Database (SAD)
- endpoint holds SA state in security association database (SAD), where it can locate them during processing.
- with n salespersons, 2 + 2n SAs in R1’s SAD
- when sending IPsec datagram, R1 accesses SAD to determine how to process datagram.
- when IPsec datagram arrives to R2, R2 examines SPI in IPsec datagram, indexes SAD with SPI, and processes datagram accordingly.
IPsec datagram
focus for now on tunnel mode with ESP
- appends to back of original datagram (that includes original header fields!) an “ESP trailer” field.
- encrypts result using algorithm & key specified by SA.
- appends to front of this encrypted quantity the ESP header, creating “enchilada”.
- creates authentication MAC over the whole enchilada, using algorithm and key specified in SA.
- appends MAC to back of enchilada, forming payload.
- creates brand new IP header, with all the classic IPv4 header fields, which it appends before payload.
- ESP trailer: Padding for block ciphers
- ESP header:
- SPI, so receiving entity knows what to do
- Sequence number, to thwart replay attacks
- MAC in ESP auth field is created with shared secret key
Security Policy Database (SPD)
- policy: For a given datagram, sending entity needs to know if it should use IPsec or vanilla IP
- needs also to know which SA to use. may use: source and destination IP address; protocol number
- info in SPD indicates “what” to do with arriving datagram
- info in SAD indicates “how” to do it
IKE: Internet Key Exchange
use IPsec IKE (Internet Key Exchange) protocol, specified in RFC 5996.
7.6 Operational security: firewalls and IDS
7.6.1 Firewalls
isolates organization’s internal net from larger Internet, allowing some packets to pass, blocking others
- prevent denial of service attacks: SYN flooding: attacker establishes many bogus TCP connections, no resources left for “real” connections
- prevent illegal modification/access of internal data
- allow only authorized access to inside network: set of authenticated users/hosts
- three types of firewalls:
- stateless packet filters
- internal network connected to Internet via router firewall
- router filters packet-by-packet, decision to forward/drop packet based on:
- source IP address, destination IP address
- TCP/UDP source and destination port numbers
- ICMP message type
- TCP SYN and ACK bits
- ACL (Access Control Lists): table of rules, applied top to bottom to incoming packets: (action, condition) pairs: looks like OpenFlow forwarding table
- stateful packet filters
- stateless packet filter: heavy handed too. admits packets that “make no sense”
- stateful packet filter: track status of every TCP connection
- track connection setup (SYN), teardown (FIN): determine whether incoming, outgoing packets “makes sense”
- timeout inactive connections at firewall: no longer admit packets
- application gateways
- filter packets on application data as well as on IP/TCP/UDP fields.
- require all telnet users to telnet through gateway.
- for authorized users, gateway sets up telnet connection to dest host. Gateway relays data between 2 connections.
- router filter blocks all telnet connections not originating from gateway.
- stateless packet filters
Limitations of firewalls, gateways
- IP spoofing: router can’t know if data “really” comes from claimed source
- if multiple app’s. need special treatment, each has own app. gateway
- client software must know how to contact gateway.
- filters often use all or nothing policy for UDP
- tradeoff: degree of communication with outside world, level of security
- many highly protected sites still suffer from attacks
7.6.2 Intrusion detection systems
packet filtering:
- operates on TCP/IP headers only.
- no correlation check among sessions.
IDS: intrusion detection system
- deep packet inspection: look at packet contents (e.g., check character strings in packet against database of known virus, attack strings
- examine correlation among multiple packets
- port scanning
- network mapping
- DoS attack
multiple IDSs: different types of checking at different locations