Network Security: Broadcast and Multicast,

Mobile IPv6

Tuomas Aura

2

Outline

Broadcast and multicast

Receiver access control (i.e. data confidentiality)

Multicast authentication

DoS protection

Mobile IPv6

Spoofed bindings, bombing attack

Return routability test

Broadcast and multicast

4

Broadcast and multicast

Unicast = send to one receiver

Traditional IP routing

TCP, HTTP, video and audio streaming

Server sends a separate copy to each receiver

Broadcast = send to everyone

Terrestrial radio and television, satellite

Link-layer broadcast on Ethernet or WLAN, flood-fill through an overlay network

Multicast = send to a group of receivers

IP multicast, overlay streaming , IPTV

Can save bandwidth by routing through a tree

5

IP unicast

6

Satellite broadcast

7

IP multicast protocols

8

IP multicast

Internet group management protocol (IGMP) in IPv4 and Multicast listener discovery (MLD) in IPv6 between clients and the gateway router

Clients use to connect to a local multicast router

Protocol-independent multicast (PIM) within larger networksPIM sparse mode (PIM-SM) or dense mode (PIM-DM) used closed routing domains

Inter-domain protocols: Multicast Source Discovery Protocol (MSDP) and MBGP

Still experimental

The multicast routing protocols do not provide security in themselves

9

Future of multicast and broadcast?

Multicast tree vs. P2P overlay multicast protocols

Youtube and unicast

10

Security goals

Applications: satellite and cable TV, Internet TV, peer-to-peer content distribution, GPS/Galileo, teleconference

Access control to multicast and broadcast data

Data authentication

DoS protection — access control for senders

Privacy — confidentiality of subscriber identities (which channel is my neighbor watching?)

Receiver access control

11

Access control to data

Goal: allow only authorized access to data

Encrypt data, distribute keys to authorized recipients (= multicast group)

Key distribution issues:

Revocation speed

Amount of communication and computation per joining or leaving node

Scalability (teleconference vs. satellite TV broadcast)

Possible packet loss when session keys are replaced

Sharing keys to unauthorized parties is easier than sharing data

13

Group key distribution

Various efficient protocols for distributing keys to a multicast group

Typical solution: unicast key distribution to individual subscribers

Ok for small groups (e.g. teleconference) or slow updates (e.g. IPTV subscription)

Can piggyback individual key updates on multicast data

Does not require separate unicast channel

Ok for slow updates (e.g. satellite TV)

Advanced protocols

Typically log(N) communication to revoke one receiver out of N

Multicast and broadcast authentication

15

Multicast data authentication

Security goals:Integrity, data-origin authentication

Sometimes non-repudiation

Early dropping of spoofed data

Other constraints:Loss tolerance vs. reliable transmission

Real-time requirements

Small groups could use a shared key and MACsEvery member can spoof data

Won’t work for large or mutually distrusting groups

Asymmetric crypto seems the right toolOne sender and many receivers

16

Hash chainingForward chaining

Amortize the cost of a signature over many data packets

Sender can send in real time

Receiver should buffer data and consume only after signature received

Received vulnerable to DoS from spoofed packets

Backward chaining

Received can authenticate and consume data immediately

Sender must buffer data before sending and signing

Sign(H1) H2data H4data dataH3dataH1

n=4

H1 data H3 datadata H2 data

hash

Sign(H4)H4

n=4

17

Loss tolerant chaining

Redundant hash chains

Efficient multi-chained stream signature (EMSS)E.g. 1-3-7 chaining sequence tolerates bursty losses of up to 7 packets:

Redundant signatures costly

Random chaining sequence shown to be efficient

Alternative: forward error correction code

18

Guy Fawkes protocol (1)

Delayed authentication [Ross Anderson 1997]

Initially, receiver knows Y = hash(X)

To authenticate message M:

1. Sender publishes Z = MACX(M)

2. Sender reveals M, X

Z is a commitment that binds the message M and the secret X. Revealing X later authenticates M

Critical detail:

The commitment Z must be received before X is revealed

In the Guy Fawkes protocol, Z is published in a news paper = broadcast medium with guaranteed latest delivery time

19

Guy Fawkes protocol (2)

Out-of-band initialization:Sender selects a random X0 and computes Y0 = hash(X0)

Sender publishes Y0 via an authenticate channel

Protocol round i=1,2,3,…:1. Sender selects a random Xi and computes Yi = hash(Xi)

2. Sender publishes in a newspaper Zi = MACXi-1 (Mi, Yi)

3. Sender reveals Mi, hash(Xi), Xi-1

Zi is a commitment that binds the message Mi and the secret Xi-1. Revealing Xi-1 later authenticates Mi

The next key Yi is authenticated together with Mi

Critical: Each Zi must be received before Xi-1 revealed

20

Lamport hash chain

[Leslie Lamport 1981]

One-time passwords for client-server authentication

Initialization: Random number X0

Hash chain Xi = h(Xi-1), i=1…n

Server stores Xn

Client reveals hashes in reverse order: Xn–1, Xn-2,…

Protects against password sniffingCannot be replayed like a normal password

Better than real random passwords> takes less storage space and the serve password database (/etc/password) can be public

Entity authentication only; no key exchange

21

TESLA (1)Time efficient stream loss-tolerant authentication [Perrig et al. 2000][RFC 4082]After initialization, secret-key crypto (cryptographic hash and MACs) onlyDelayed authentication: broadcast sender commits to MAC keys and reveals them after a fixed delay

Authentication delay at least one round-trip time (RTT)MAC keys come from a hash chain

Requires loose clock synchronizationAuthentication delay must be set to > maximum clock skew

No buffering of data at sender; buffering for a fixed period at the receiverTolerates packet lossScales to any number of receiversNo non-repudiation

22

TESLA (2)

Initialization:

Sender commits to the key chain and release schedule by signing: k0, start time T1, interval duration Tint, disclosure delay d∙Tint

Time periods start at T1, others Ti+1=Ti+Tint

MAC keys k’1, k’2, k’3,…

Used for message authentication in periods starting from T1, T2, T3…

ki revealed d periods later (revealing ki reveals all kj, j≤i)

Sender and receiver must have loosely synchronized clocks

k0 k1 k2

k’t

kt = random? ? ?h hhhh

h’

k’1 k’2 k’t-1

kt-1

? ? ?

h’ h’ h’

k3h

k’3

h’

MAC keys:

23

TESLA (3)

Packets received in period i will be authenticated in period i+dIf a packet that belongs to the period [Ti ,Ti+1] is received after Ti+1, it cannot be authenticatedOk to have silent periods but dummy packets may be needed to avoid long authentication delaysNext key chain can be initialized by sending the new k0 in the last packets of the previous chain (cf. Guy Fawkes)

k0 k1 k2

k’N

kN = random? ? ?h hhhh

h’

k’1 k’2 k’N-1

kN-1

? ? ?

h’ h’ h’

k3h

k’3

h’

MAC keys:

? ? ?

T1 TNT4T3T2 TN-1

Packets:

Contain k1 Contain kN-3 Contain kN-1 Contain kNContain kN-2

? ? ?

Setup: Sign(k0,Y1,Tint,d=2,N) Contain k2

h

k’4

h’

k4

DoS protection

Access control for sendersMulticast is a mechanism for traffic amplification → can be used for DoS attacks to consume bandwidthOne-root solution: the root node of the multicast tree authenticates senders and checks for authorization

Ok for satellite broadcast No such root in IP multicast in the Internet, in many-to-many communication, or in peer-to-peer content distribution Authentication of data at each router needed to avoid insertion of false data → maybe too expensive

Reverse path forwarding: each router checks the routing table for the source address and decides whether the packet came from the right direction

Prevents some spoofing attacksNeeded to prevent routing loops anyway

26

Non-crypto access control for receivers

A multicast receiver could subscribe to a large number of multicast streams

Packet flood to the location of the receiver

Either free, unencrypted streams or streams of encrypted packets it cannot decrypt

Need some way of limiting subscriptions at the receiver end

27

Exercises

Combine backward and forward chaining to divide the buffering requirement between sender and receiver

How could a criminal organization use cryptography to make a series of anonymous but plausible threats? (Hint: Guy Fawkes was a 17th century terrorist)

If the receiver has no capability for public-key operations, how would you initialize TESLA?

Mobile IPv6

29

Mobile IPv6Network-layer mobility protocol

Developed since 1991; now standardized by the Internet Engineering Task Force (IETF)

Mobile IP(v4) [RFC 3344], IPv6 [RFC 3775]

History:

Mobile IPv6 standardization halted in 2000 because of security concerns

Security protocol proposed by us in 2001 became a part of the standard. Major security problems fixed

Next, we'll go through the threat analysis and security protocol design step by step

30

Mobile IPv6 and addresses

The mobile node (MN) has two IPv6 addresses

Home address (HoA):

Subnet prefix of the home network

Used as address when MN is at home. Used as node identifier when MN is roaming in a foreign network

Home network may be virtual – MN never at home.

Care-of address (CoA):

MN’s current point of attachment to the Internet

Subnet prefix of the foreign network

Correspondent node (CN) can be any Internet host

(Note: MN and CN are hosts, not routers.)

31

Mobility

How to communicate after MN leaves its home network and is roaming in a foreign network?

(HoA, CN and CoA are IPv6 addresses)

Foreign Network

Home Network

Correspondent node (CN)

Mobile node (MN)

Home address(HoA)

Care-of address (CoA)

32

Mobile IPv6 goals

Mobility goals:

MN is always reachable at HoA as long as it is connected to the Internet at some CoA

Connections don’t break when CoA changes

Performance goals (different levels):

Roaming (transparent access to VPN, email and web while away from home) has low QoS requirements

Mobile multimedia (real-time voice and sound while constantly moving) requires delays < 200 ms

Security goals:

As secure as the current Internet without mobility

33

Mobile IPv6 tunnelling

Home agent (HA) is a router at the home network that forwards packets to and from the mobile

MN always reachable at HoA

source = HAdestination = CoA

CN

MN at CoA

source = CNdestination = HoAHome agent HA

at HoA

Home Network

Encapsulatedpacket source = CN

destination = HoA

34

Tunneled packets on the wireIPsec ESP tunnel between HA and MN

HA uses its own IPv6 address as the tunnel endpointMN uses the CoA as the tunnel endpoint → both SPD and SAD must be updated at HA when the mobile moves

Packet from CN to HoA:IP[CN,HoA] | Payload (intercepted by HA)Forward tunnel from HA to CoA:IP[HA,CoA] | ESP | IP[CN,HoA] | PayloadReverse tunnel from MN to HA:IP[CoA,HA] | ESP | IP[HoA,CN] | PayloadPacket forwarded from HA to CN:IP[HoA,CN] | PayloadNote: no problems with ingress filtering because all source addresses are topologically correct

35

Route optimization (RO)

HA at HoA

MN at CoA

source = CNdestination = CoAFor HoA

Routing header (RH)

source = CoAdestination = CNThis is HoAI'm at CoA

2. Binding Update (BU)3. Followingpackets

1. First packet

source = CoAdestination = CNFrom HoA

Home addressoption (HAO)

CN

36

Route-optimized packets on the wire

Packet from CN to MN:IP[CN,CoA] | RH[HoA] | Payload(RH = Routing header Type 1, “for HoA”)

Packet from MN to CN:IP[CoA,CN] | HAO[HoA] | Payload(HAO = Home address option, “from HoA”)

Again, all source addresses are topologically correct

37

Route optimization

Important optimization:

Normally, only the first packet sent via home agent (HA). Binding udpate (BU) triggered when MN receives a tunneled packet. All following packets optimized

But, if CN does not support BU or decides to ignore them, then all packets are tunneled via HA

MN may send the BU at any time

In principle, IP layer is stateless and does not know whether there was previous communication

38

Binding update

Originally, a 2-message protocol:

Binding update (BU) from CoA to CN

Binding acknowledgement (BA) from CN to MN

Now a much more complex protocol, for security reasons that we'll soon explain

CN caches the HoA–CoA binding in its binding cache for a few minutes

MN may send a new BU to refresh the cache or to update its location

CN may send a binding request (BR) to MN to ask for a cache refresh

39

Who are MN, CN?

Any IPv6 host may be the correspondent

Any IPv6 address can become mobile, even though most never do

By looking at the address, CN cannot know whether home address (HoA) belongs to a mobile node

→ Security flaws in Mobile IPv6 may be used to attack any Internet node

Threats and protectionmechanismsAll weaknesses shown here have been addresses in the RFC

40

41

Attack 1: false binding updates

A, B and C can be any IPv6 nodes (i.e. addresses) on the Internet

source = Cdestination = BThis is AI'm at C

False BU

Attacker

A B

C

42

Connection hijacking

source = Cdestination = BThis is AI'm at C

False BU

Attacker

source = C destination = BFrom A

Attacker could highjack old connections or open new

A, B and C can be any Internet nodes

A B

C

43

Man-in-the-middle attack

False BU

Attacker

False BU

This is BI'm at C

This is AI'm at C

A B

C

44

If no security measures added

Attacker anywhere on the Internet can hijack connection between any two Internet nodes, or spoof such a connection

Attacker must know the IPv6 addresses of the target nodes, though

45

BU authentication

MN and HA trust each other and can have a secure tunnel between them. Authenticating BUs to CN is the problem

The obvious solution is strong cryptographic authentication of BUs

Problem: there is no global system for authenticating any Internet node

46

Authentication without infrastructure?

How authenticate messages between any two IPv6 nodes, without introducing new security infrastructure?

Set requirements to the right level: Internet with Mobile IPv6 deployed must be as secure as before it → no general-purpose strong authentication needed

Some IP-layer infrastructure is available:

IPv6 addresses

Routing infrastructure

Surprisingly, both can be used for BU authentication:

Cryptographically generated addresses (CGA)

Routing-based “weak” authentication, called return routability

47

BU Authentication – v.1

CN sends a key in plaintext to HoA

MNat CoA

HAat HoA

2. K

1. BU

3. BU, MACK(BU)

accept BU

CN

48

Is that good enough?“Weak”, routing-based authentication, but it meets the stated requirementAttacker has to be on the path between CN and HA to break the authentication and hijack connections

This is true even if the MN never leaves home, so mobility does not make the Internet less secureNot possible for any Internet node to hijack any connection → significantly reduced risk

K is not a general-purpose session key! Only for authenticating BUs from MN to CNAnything else?

The weak authentication, CAM, and other protocols discourage lying about who you areStill possible to lie about where you are!

49

Attack 2: bombing attack

Attacker can flood the target by redirecting data streams

source = Cdestination = BThis is AI'm at C

False BU

Unwanted video stream

Target

bbc.co.ukVideo streamAttacker

A B

C

50

Bombing attack - ACKs

Attacker participated in the transport-layer handshake → can spoof TCP ACKs or similar acknowledgementsAttacker only needs to spoof one ACK per sender window to keep the stream goingTarget will not even send a TCP Reset!

False BU

Unwanted video stream

Target

bbc.comAttacker

source = Cdestination = BThis is AACK

Falseacknowledgments

AB

C

A

51

BU Authentication – v.2

CN sends a message to CoA to ask whether someone there wants the packetsCommon misconception: the purpose is not to send K0 and K1 along two independent paths!

MNat CoA

HAat HoA

2a. K0

1. BU

3. BU, MACK(BU)K=h(K0,K1)

accept BU

2b. K1

CN

52

Is that good enough?

Not possible to lie about identity or location; all information in BUs is true

Almost ready, but we still need to consider standard denial of service attacks against the BU protocol

53

Attack 3: Exhausting state storage

Correspondent will generate and store K0, K1Attacker can flood CN with false BUs → CN has to remember thousands of K0s and K1s

Attacker

2a. K0

1. BU

2b. K1

lost

lost

source = Ddestination = BThis is EI'm at D

C

B

54

BU authentication – v.3

We can make the correspondent stateless

2a. K0 = h (N, HoA)

1. BU

3. BU, MACK(BU) K=h(K0,K1)

accept BU

N

periodically changing

random value

MNat CoA

HAat HoA

CN

2b. K1 = h (N, CoA)

55

Attack 4: reflection and amplification

Two DDoS packets become one — minor issue

IP trace-back cannot find the attacker

2a. K0

1. 2b. K1

DDoS

Attacker

B

MN

at CoA

HA

at HoA

56

BU Authentication – v.4

Balanced message flows prevent amplification

2a. K0

1b. BU

3. BU, MACK(BU)K=h(K0,K1)

accept BU

2b. K1

1a. BU

MNat CoA

HAat HoA

CN

4. BA

57

The Mobile IPv6 Standard Protocol

Return routability (RR) test for HoA and CoASimilar mechanisms, completely different purpose

2a. HoT

1b. CoTI

1a. HoTI

MNat CoA

HAat HoA CN

3. BU

2b. CoT

58

Exercises

Based on the historical flaws in Mobile IPv6, are there any potential security problems in dynamic DNS? Does Secure DNS solve these problems?

Design a more efficient binding-update protocol for Mobile IPv6 assuming a global PKI is available

How could the return-routability test for the care-of address (CoA RR) be optimized if the mobile is opening a TCP connection? What are the advantages and disadvantages?

Find out about credit-based authorization for Mobile IPv6. How does it reduce latency? Is it secure?

What problems arise if mobile node can automatically pick a home agent in any network