Network Security: Broadcast and Multicast, Mobile IPv6

Network Security: Broadcast and Multicast,

Mobile IPv6Tuomas Aura

2

OutlineBroadcast and multicast

Receiver access control (i.e. data confidentiality)Multicast authenticationDoS protection

Mobile IPv6Spoofed bindings, bombing attackReturn routability test

Broadcast and multicast

4

Broadcast and multicastUnicast = send to one receiver

Traditional IP routingTCP, HTTP, video and audio streamingServer sends a separate copy to each receiver

Broadcast = send to everyoneTerrestrial radio and television, satelliteLink-layer broadcast on Ethernet or WLAN, flood-fill through an overlay network

Multicast = send to a group of receiversIP multicast, overlay streaming , IPTVCan save bandwidth by routing through a tree

5

IP unicast

Client

Client

Client

Client

Server

6

Satellite broadcast

Client

Server

Client

Client

Client

7

IP multicast protocols

Client

Server

Client

Client

Client

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

Server Client

Single domainLAN

PIM IGMP

9

Future of multicast and broadcast?Multicast tree vs. P2P overlay multicast protocolsYoutube and unicast

10

Security goalsApplications: satellite and cable TV, Internet TV, peer-to-peer content distribution, GPS/Galileo, teleconferenceAccess control to multicast and broadcast dataData authenticationDoS protection — access control for sendersPrivacy — confidentiality of subscriber identities (which channel is my neighbor watching?)

Receiver access control

11

Access control to dataGoal: allow only authorized access to dataEncrypt data, distribute keys to authorized recipients (= multicast group)Key distribution issues:

Revocation speedAmount of communication and computation per joining or leaving nodeScalability (teleconference vs. satellite TV broadcast)Possible packet loss when session keys are replacedSharing keys to unauthorized parties is easier than sharing data

13

Group key distributionVarious efficient protocols for distributing keys to a multicast groupTypical 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 dataDoes not require separate unicast channelOk for slow updates (e.g. satellite TV)

Advanced protocolsTypically log(N) communication to revoke one receiver out of N

Multicast and broadcast authentication

15

Multicast data authenticationSecurity goals:

Integrity, data-origin authentication Sometimes non-repudiationEarly dropping of spoofed data

Other constraints:Loss tolerance vs. reliable transmissionReal-time requirements

Small groups could use a shared key and MACsEvery member can spoof dataWon’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 packetsSender can send in real timeReceiver should buffer data and consume only after signature receivedReceived vulnerable to DoS from spoofed packets

Backward chainingReceived can authenticate and consume data immediatelySender 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 chainingRedundant hash chainsEfficient multi-chained stream signature (EMSS)

E.g. 1-3-7 chaining sequence tolerates bursty losses of up to 7 packets:

Redundant signatures costlyRandom 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 MCritical detail:

The commitment Z must be received before X is revealedIn 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 authenticationInitialization:

Random number X0

Hash chain Xi = h(Xi-1), i=1…nServer stores Xn

Client reveals hashes in reverse order: Xn–1, Xn-2,…Protects against password sniffing

Cannot be replayed like a normal passwordBetter 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 T∙ int

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 receiversA multicast receiver could subscribe to a large number of multicast streams

Packet flood to the location of the receiverEither free, unencrypted streams or streams of encrypted packets it cannot decrypt

Need some way of limiting subscriptions at the receiver end

27

ExercisesCombine backward and forward chaining to divide the buffering requirement between sender and receiverHow 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 protocolDeveloped 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 concernsSecurity 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 addressesThe mobile node (MN) has two IPv6 addressesHome address (HoA):

Subnet prefix of the home networkUsed as address when MN is at home. Used as node identifier when MN is roaming in a foreign networkHome network may be virtual – MN never at home.

Care-of address (CoA):MN’s current point of attachment to the InternetSubnet 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 NetworkCorrespondent node (CN)

Mobile node (MN)

Home address(HoA)

Care-of address (CoA)

32

Mobile IPv6 goalsMobility goals:

MN is always reachable at HoA as long as it is connected to the Internet at some CoAConnections 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 requirementsMobile 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 mobileMN always reachable at HoA

source = HAdestination = CoA

CN

MN at CoA

tunnel

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

tunnel

36

Route-optimized packets on the wirePacket 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 optimizationImportant optimization:

Normally, only the first packet sent via home agent (HA). Binding udpate (BU) triggered when MN receives a tunneled packet. All following packets optimizedBut, 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 timeIn principle, IP layer is stateless and does not know whether there was previous communication

38

Binding updateOriginally, a 2-message protocol:

Binding update (BU) from CoA to CNBinding acknowledgement (BA) from CN to MN

Now a much more complex protocol, for security reasons that we'll soon explainCN 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 locationCN 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 correspondentAny IPv6 address can become mobile, even though most never doBy 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

Stolen data

Attacker

A B

C

42

Spoofed data

Connection hijacking

source = Cdestination = BThis is AI'm at C

False BU

Stolen data

Attacker

source = C destination = BFrom A

Attacker could highjack old connections or open newA, B and C can be any Internet nodes

A B

C

43

Man-in-the-middle attack

False BU

Attacker

False BUThis is BI'm at C

This is AI'm at C

A B

C

44

If no security measures addedAttacker anywhere on the Internet can hijack connection between any two Internet nodes, or spoof such a connectionAttacker must know the IPv6 addresses of the target nodes, though

45

BU authenticationMN and HA trust each other and can have a secure tunnel between them. Authenticating BUs to CN is the problemThe 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 neededSome IP-layer infrastructure is available:

IPv6 addressesRouting 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

securetunnel

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

securetunnel

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 trueAlmost 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

securetunnel

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 issueIP trace-back cannot find the attacker

securetunnel

2a. K0

1. 2b. K1

DDoS Attacker

B

MNat CoA

HAat 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

securetunnel

1a. BU

MNat CoA

HAat HoA

CN

57

4. BA

The Mobile IPv6 Standard Protocol

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

2a. HoT

1b. CoTIESP tunnel

1a. HoTI

MNat CoA

HAat HoA CN

3. BU

2b. CoT

58

ExercisesBased 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 availableHow 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