multicast securityd2zmdbbm9feqrf.cloudfront.net/2013/eur/pdf/brkipm-2262.pdfof multicast security...

© 2013 Cisco and/or its affiliates. All rights reserved. BRKIPM-2262 Cisco Public

Multicast Security Toerless Eckert

BRKIPM-2262


Abstract / Session Goals

This session shows how the Cisco IOS set of command-line tools can be used to provide access and admission control to the network or router (for protocol security and prevention of attacks), as well as to multicast applications, and shows how to control their intended usage.

Explicit examples for common cases are presented. The session also gives an overview of the current and upcoming functions available for IP Multicast with IP Security, discusses ways to dynamically provision or control multicast application usage, and reviews multicast and firewalls.

This session covers requirements in both enterprise and service provider networks when using IP Multicast.

3 3 3


Agenda Introduction – Unicast/Multicast comparison

Control plane security

Data plane security

‒ Access control

‒ Admission control

Firewalls

‒ What more than PIM router with access control is needed ?

IPsec with Multicast

‒ For service/content and protocol authentication

‒ For service/content confidentiality (encryption)

Summary and best Practices

Not covered

‒ VPN/VRF isolation Yes–but covered in MVPN presentations, not here!

‒ AAA with multicast–policy framework

Authentication, Authorization, Accounting?

Moved to Appendix

‒ NAT – supported by Cisco routers but not ‘security’


Introduction


The Why? What? How? And Where? of Multicast Security

Access Permission/

Credential

Admission Resource availability

Policy

State

creation

Packet level policing, encryption

Device Control plane

Links

Network Data plane

Service Content

Local Router

switch

Hop-by-Hop Coordinated

VRF/VPN

Policy-Server AAA


Multicast/Unicast Security Comparison Network

‒Replication

‒Per application state

‒Receiver built trees

‒Scoped addresses

Application

‒Typical not “TCP like”

‒Unidirectional or multidirectional

Protocols

‒Similar

‒Common use of link scope multicast


Multicast vs. Unicast Per-Application State

Unicast:

‒State grows when network topology grows.

‒Router (control plane) CPU active on network topology changes.

No impact by user activity (traffic sending)

Scale routers/links by size of topology, amount of bandwidth

Multicast:

‒State grows when user starts application

‒CPU active when application state changes

Scale routers by number of application/sources

‒Also inherits all of unicast

Topology changes cause reconvergence of trees

Large number of trees (applications) == lots of CPU activity


Multicast vs. Unicast State and Replication in Routers and Switches

“ingress” state

per application/sender

“egress” state

per receiver branch

HW limits: 5000 … >100,000

SW limits: >> 100,000

Throughput limits

Unicast: Ingress Packet Rate

Multicast: Egress Packet Rate

ROUTERS AND SWITCHES

…

S2,G2 S1,G1

Multicast

Lookup/ingress states

Multicast

Egress/Replication

states


Ether SW

Multicast vs. Unicast Replication in Routers and Switches

Example: Deny traffic from Source to receiver A

Unicast: can filter anywhere on path

Multicast: filter after last replication

Receivers are not implied by packets destination address – but by router/interface where filtering is applies

General model ‒ Source Filtering: Deny source to send to group

Filter on ingres before first replication

‒ Receiver filtering: Deny receiver to get packets from source and/or to group

Filter on egres after last replication

L3 router or L2 switch – same principle

Multicast

Unicast

R1

S1 R2

A B

C

Source


Multicast vs. Unicast Receiver Side Explicit Join Based Traffic Forwarding (1)

Attacks from sources to hosts:

Unicast: No implicit protection.

Multicast: implicit protection

ASM:

Sources can attack groups

No independent host attacks

Better: SSM:

No attacks by unwanted sources

Traffic stops at first-hop router

Un

ica

st

AS

M

RP

SS

M

First

Hop

router



Attacks from sources to network:

Even without receivers

PIM-SM: ‒ (S,G) and (*,G) on FHR and RP

‒ State attack!

Bidir-PIM: ‒ No state attack–just traffic! RP as attackable as unicast

‒ (*,G/M) towards RP

‒ Note: Pre-IOS 15 IPv4 multicast still creates (*,G) state due to legacy implementation (except cat6k/c7600)

Asm

/

Bid

ir

Ouch

AS

M

/PIM

-SM

RP

First

Hop

router

Ouch! (Ouch?)



Attacks from receivers!

Receivers create state

No equivalent in unicast

1.Attack against content: receive content unauthorized

2.Attack against bandwidth: Overload network bandwidth. Shared bandwidth: attack against other receivers

3.Attack against routers/switches: Overload state tables, Increase convergence times

RP

Source(s)

Jo

in S

1,G

1

Jo

in G

2

Jo

in S

2,G

2

1.

2.

State

State

State

State 3.



Unicast/Multicast

Filter packets

ip access-group <acl>

Traffic stops where filter is configured

Multicast

Per tree filter at control plane

Traffic stops where filtered branch hits tree

Filter at receiver–stop traffic at source

ip multicast boundary …

Unicast

Per prefix route-filters

Ineffective with aggregation (default-route)

R1

A

Source

e0

R2

R3

R4

IGM

P

me

mb

ers

hip

PIM

Jo

in

PIM

Jo

in

PIM

Jo

in

R1

A

Source

e0

R2

R3

R4

IGM

P

me

mb

ers

hip

e0

Filtering: Data-plane only vs. Control Plane


Multicast vs. Unicast Summary

Unicast:

MUST protect hosts AND network nodes against sender attackers

Often using Transport (UDP/TCP) ports or DPI

Multicast

Protect routers/switches against too much state (from receiver/sources)

Security: DoS attacks against router/link resources

QoS: Guarantee lossless delivery (see backup slides)

Per flow admission control

ASM: MUST protect applications against unwanted sources.

PIM-SM may require additional RP protection

Can control application participation and traffic flow at network layer with (*,G), (S,G) access and admission control


Control Plane Security


Control Plane Security Covered Here

IGMP/MLD/PIM (RP/DR)/MSDP/AutoRP/SAP

Control plane filtering

Primarily to protect against spoofing

‒ Spoof function (RP, DR, BSR, MA, MSDP-peer)

‒ DoS network, participants

IGMP/PIM

‒ Understand different packet types used by protocols

‒ Understand type of attacks possible

‒ Explain protocol specific filtering available

Filtering for other protocols

MSDP authentication


Control Plane Security Covered Elsewhere

Overload router CPU with packets–brute force DoS

‒ See backup section:

MQC for control packets: CoPP/Interface

Authenticate PIM control plane messages with IPsec

‒ Covered in IPsec section

Create non-permitted state

‒ Covered in access-control section:

Scope boundaries

Generic state access-control

Memory (SW) and hardware (state) overload

‒ Covered in admission-control section


Filter for Control Plane Packets Non-Multicast Specific

ip receive access-list <ext-acl>

Filter applied to “received” packets

‒Unicast to router interface addresses

‒ IP Broadcast

‒Packets with router alert option

‒Packets for joined IP multicast traffic

Link local scope groups (“show ip int”).

Groups with “L” flag set

CLI too simple – only available in IOS 12.0 S

‒ replace with per-interface ACL or CPL CoPP in IOS 12.2/15.x!


MQC—Modular QoS CLI Three Ways to apply MQC

Explicit service policies on interfaces ‒ standard case

Microflow-policing ‒ Automatic creation of service policies for individual flows

CoPP–Control Plane Policing ‒ Apply to control plane packets (policing only)

‒ Same packet processing rules as for ip receive acl

control-plane

service-policy input copp-policy ! Virtual interface for all control plane traffic ! Allows only limited config ! MQC for policing/filtering of packets


MQC for Control Packets CoPP and Interface Example class-map match-all class-access-if-control

match access-group acl-access-if-control ! Eg: IGMP+DCHP but not PIM+OSPF

class-map match-any class-all-control

match access-group acl-access-if-control ! As above

match access-group acl-core-if-control ! Eg: OSPF, BGP, PIM

! CoPP – Control plane policing

policy-map control-plane-policy

class class-all-control

police rate 800000 bps … burst …

control-plane ! The virtual control-plane IF

service-policy input control-plane-policy

! Interface level policing / dropping

policy-map access-if-policy

class class-core-if-control ! How to drop class traffic:

police rate 1000 bps … burst 1000 … ! Arbitrary sizes!

… conform-action drop exceed-action drop drop ! Drop either way !

class class-access-if-control ! Rate limit control traffic

police rate 8000 bps … burst 80000 … ! from user – DoS does not

… conform-action transmit … exceed-action drop ! Impact other users !!!

Interface ethernet 0 ! User facing access interface

service-policy input access-if-policy ! No class-core-if-control in


MQC for Control Packets

CoPP first line of defense always use if available) ‒ Not incoming interface specific!

‒ Single interface attack affects other interfaces

Interface level MQC / interface level filtering ‒Per interface (type) policies–eg: access, core, …

‒More powerful … and cumbersome

‒ Isolate attack domains to single interface

‒Use-Case: aggregation router connecting to multiple customers

Easier: per-vrf limits (PE router)


Filter for Control Plane Packets Non-Multicast Specific

Filter using interface filter or CoPP filtering:

Usage guideline/examples:

‒ Positive list of required control plane packets

Most secure: Permit only explicitly understood control plane packets

Protects against all unknown protocols – which may be enabled by default

‒ Negative list of unwanted protocols.

Most easy: Deny explicitly known insecure defaults/protocol options:

Unicast PIM packets

Recommended on all on RP / non-candidate-BSR routers!

Unicast IGMP packets

Recommended on all routers as long as UDLR is not used.

If you do not know what UDLR is, you do not use it!

TCP packets to port 639 (MSDP) from non-MSDP peer sources

If you do same type of filtering for other TCP ports too - Not necessary if MSDP is not used


Multicast Hardware Based

CPU Rate Limiters on 6500/7600 Sup720 The 6500/7600 has hardware based CPU rate limiters

specifically for IP Multicast

mls rate-limit multicast ipv4 partial

mls rate-limit multicast ipv4 fib-miss

mls rate-limit multicast ipv4 ip-options

mls rate-limit multicast ipv4 igmp

mls rate-limit all ttl-failure

mls rate-limit multicast ipv4 pim

PIM rate limiter requires 12.2(33)SXH

The actual limits will need to be designed with knowledge of the traffic characterizations in each environment.


IGMP/MLD Packets IPv6: MLD uses ICMPv6 protocol type packets

IPv4: IGMP is an IP protocol type:

‒PIMv1, IGMPv1,v2,v3, mrinfo, DVMRP, mtrace

‒ IOS: all these protocols enabled (if multicast is)

Bad?!!:

PIMv1–legacy protocol behavior

mrinfo–eavesdropping (use SNMP)

DVMRP–flood and prune

Good:

mtrace–multicast equivalent of traceroute


IGMP/MLD Protocol Packets

Bad: Unicast IGMP packets–for IGMP/UDLR

Good: “Normal” = Multicast IGMP packets:

‒Attacks must originate on the same subnet

‒Link local multicast, not routed!

Forged IGMP/MLD query packets

‒Lower version: inhibit SSM, leave-latency

‒Bursts: response storms

Forged (multicast) IGMP/MLD membership reports

‒Not a problem!? .. The router can solve


IGMP/MLD Protocol Packets The L3 vs. L2 Problem

Forged queries:

‒ Need to inhibit that other hosts receive them (DoS)!

Forget membership reports

‒ Forge IP address of other host

‒ Router can not validate identity of hosts!

L2 - per-port control required for these

Per-LAN vs. per port access/admission control

Multicast IGMP/MLD

Control Packets L2 switch

Geek - o - meterGeek - o - meter


ip access-list extended control-packets …

deny igmp any any pim ! No PIMv1

deny igmp any any dvmrp ! No DVMRP packets

deny igmp any any host-query ! Do not use with redundant routers !

permit igmp any host 224.0.0.22 ! IGMPv3 membership reports

permit igmp any any 14 ! Mtrace responses

permit igmp any any 15 ! Mtrace queries

permit igmp any 224.0.0.0 15.255.255.255 host-query ! IVMPv1/v2/v3 queries

permit igmp any 224.0.0.0 15.255.255.255 host-report ! IGMPv1/v2 reports

permit igmp any 224.0.0.0 15.255.255.255 7 ! IGMPv2 leave messages

deny igmp any any ! Implicitly deny unicast IGMP here!

…

permit ip any any ! Likely deny any on control plane!

ip receive access-list control-packets

interface ethernet 0

ip access-group control-packets in ! Could put filter here too

IGMP Packets Example Extended ACL for Various IGMP Packets

http://www.iana.org/assignments/igmp-type-numbers

Numeric ‘port’ <n> = IGMP type number 0x1<n>








PIM Packets—Multicast

Multicast PIM Control Packets :

‒Hello, Join/Prune, Assert, Bootstrap, DF-elect

‒All are link local multicast (TTL=1)

‒All are multicast to All-PIM-Routers (224.0.0.13)

Attacks must originate on the same subnet

‒Forged Join/Prune, Hello, Assert packet.

Multicast

PIM Control Packets


PIM Packets—Unicast

Unicast PIM Control Packets :

‒Register: Unicast from DR to RP.

‒Register-Stop: Unicast from RP to DR.

‒C-RP-Advertisement: Unicast from C-RP to BSR.

Attacks can originate from anywhere!

RP DR

Unicast

PIM Control Packets

PIM-SM Domain


PIM Packets—Auto-RP IOS: AutoRP/BSR always enabled, non-configurable

Auto-RP PIM Control Packets :

‒C-RP-Announce: Multicast (224.0.1.39) to all MA’s.

‒Discovery: Multicast (224.0.1.40) to all Routers.

‒Normally Dense mode flooded (IOS)!

Attacks can originate

from anywhere!

MA C-RP

Multicast

C-RP Announce Packets

PIM-SM Domain

Multicast

Discovery Packets


PIM Neighbor Control

Must receive Hellos to establish PIM neighbor

‒ For DR election/failover and to Accept/Send PIM Join/Prune/Assert

Use ip pim neighbor filter to inhibit neighbors

‒ Filters effectively all PIM packets from non-allowed sources: Hellos, J/P, BSR, … !

Not spoofing-proof

PIM Hellos

rtr-a rtr-b

10.0.0.2 10.0.0.1

ip multicast-routing

ip pim sparse-mode


access-list 1 permit 10.0.0.2

Access-list 1 deny any

Interface e0

ip pim sparse-mode

ip pim neighbor-filter 1 PIM Hellos


AutoRP Control RP Announce Filter

ip pim rp-announce-filter

‒Configure on MA which router (IP-addr) is accepted as C-RP

for which group ranges/group-mode

C-RP 10.0.0.1

C-RP

10.0.0.2

D

MA# show ip pim rp mapping

This system is an RP-mapping agent

Group(s) 224.0.0.0/4,

uptime: 00:00:15, expires: 00:02:45

RP 10.0.0.1 (Rtr-C), PIMv1

Info source: 10.0.0.1 (Rtr-C)

C

MA

A

ip pim rp-announce-filter rp-list 1

group-list 2




15.255.255.255


Auto-RP Control Constrain Auto-RP Messages

AutoRP packets:

‒ 224.0.1.39 (RP-announce), 224.0.1.40 (RP-discovery)

PIM Domain

Neighboring

PIM Domain

Border

Router Border

Router

Neighboring

PIM Domain

RP Discover RP Announce

MA S0 S0

Need to Block All

Auto-RP Message

from Entering or

Leaving Network

Need to Block All

Auto RP Message from

Entering/Leaving

Network

interface s0

ip multicast boundary 1

access-list 1 deny 224.0.1.39


A B

interface s0

ip multicast boundary 1




BSR Control Constrain BSR Messages

ip pim bsr-border

‒ Filters messages (multicast) from BSR - no ACL possible (hop by hop forwarded)

PIM Domain

Neighboring

PIM Domain

Border

Router

Border

Router

Neighboring

PIM Domain

BSR Msgs BSR Msgs

BSR S0 S0

Need to Block All

BSR Message from

Entering/Leaving

Network

Need to Block All

BSR Message from

Entering/Leaving

Network

Interface S0

ip pim bsr-border

B A

Interface S0

ip pim bsr-border


PIM-SM Register Tunnel Control

PIM register messages are process-level switched

‒ Sent only until RP sends register stop,

performance impact proportional to rate of source (per (S,G) flow)

‒ Consider impact of IPTV source-server sending 500 * 8 Mbps TV

Recommendations (in order of preference).

‒ Use SSM (or Bidir-PIM)–no punted packets from connected source

‒ Configure DR to also be RP (Add MSDP towards ‘real’ RP if necessary)

‒ Use ip pim register-rate-limit

Source

PIM-SM register

messages

RP S0

ip pim register-rate-limit 2

DR

PIM-SM register

stop messages


Access Networks Protection Against Attacks

Attacks by hosts (multicast)

‒PIM Hellos–become DR–no traffic forwarded to LAN

Same applies to DF-election packets for Bidir-PIM

‒PIM joins–receive traffic (should use IGMP / filtered)

‒AutoRP RP-discovery or BSR bootstrap

Announce fake RP, bring down SM/Bidir service

Attacks by hosts (unicast)

‒Send register/register-stop

Inject fake traffic

BSR announce packets–announce fake RP

Hosts should never do PIM!


L3/L2 redundant Access Networks (1) Protection Against Attacks

Most complex to secure:

‒ R1 and R2 need to exchange PIM-Hello, IGMP-query across access LAN

Result:

‒ Need to filter most control plane packets (unwanted sent from hosts),

but still allow PIM Hellos, IGMP queries

PIM Hellos

L2 switch

In wiring

closet

R1 R2

S1

Access

LAN



access-list 2 permit <R2>

interface e0

ip pim sparse-mode

ip pim neighbor-filter 2 ! Only allow R2

ip pim bsr-border ! No BSR

ip multicast boundary 1 ! No autorp

e0 e0


L3/L2 redundant Access Networks (2) Protection Against Attacks

PIM Hellos

L2 switch

In wiring

closet

R1 R2

S1

Access

LAN



access-list 2 permit <R2>

interface e0

ip pim sparse-mode

ip pim neighbor-filter 2 ! Only allow R2

ip pim bsr-border ! No BSR

ip multicast boundary 1 ! No autorp

e0 e0

Hosts can still spoof PIM packets “from” R1/R2

‒ PIM neighbor filter still useful: avoids host become DR (blackhole)

No simple or cross platform solution

‒ for IPsec for PIM (later in presentation)

‒ L2 switch PIM/IGMP-query filtering from host ports

“ip host-guard” (L2 switch specific)


L3 Wiring Closet Access Networks Protection Against Attacks

Same physical reliability/ redundancy as standard L2

wiring closet

But security design easier:

‒ Access-LAN has now only one router (S1)

‒ Definitely know that on this (non-redundant) access-LAN no router-to-

router control plane traffic is needed (all of which could be subject to

spoofing from hosts)!

‒ No PIM packets

‒ No IGMP queries (only S1 to send them)

‒ No DVMRP

‒ No BSR

‒ No unicast routing protocols

Eg: catalyst 3k/4k as S1

PIM Hellos

L3 switch

In wiring

closet

R1 R2

S1

Access

LAN

e0 e0


Non-Redundant Access-Networks Protection Against Attacks

Single L3 router on access-LAN

‒ L3 wiring closet (previous slide)

‒ No wiring closet at all

Big datacenter router/switch directly connected to hosts

Many wireless Access-Point attachments

‒ All broadband services access interfaces

DSL–p2p “PPPoX” interface between BBRAS and PC or Home-Router

or shared LAN to multiple homes

Cable: CMTS to home-LAN

Can still have internal or box redundancy within BBRAS/CMTS

transparent to routing

Can filter all PIM protocol packets from LAN!

L3 switch/router

In datecenter, Eg: cat6k / VSS

R1

BBRAS

DSLAM

Home

Gateway

DSL line PPPoX

tunnel

va1234 Virtual

Access

Interface


Non-Redundant Access-Networks Protection Against Attacks

IOS permits fine-grained filtering

Difficult – lots of expert knowledge requried ‒ If new control protocols are invented …

No filtering of SENT packets (PIM Hello,DF-election)–unneeded on access-LAN (can not filter with access-group!)

L3 switch/router

In datecenter, Eg: cat6k

R1

BBRAS

DSLAM

Home

Gateway

DSL line PPPoX

tunnel

va1234 Virtual

Access

Interface

ip access-list extended no-control-plane

permit igmp any 224.0.0.13 ! IGMPv3 reports

permit igmp any any 6 ! IGMPv2 reports

permit igmp any any 7 ! IGMPv2 leave

permit igmp any any 14 ! mtrace

permit igmp any any 15 ! mtrace

deny igmp any any ! Queries, PIMv1, DVMRP, …

deny pim any any ! Hello, Join/Prune, BSR

deny ip any 224.0.0.39 ! AutoRP

deny ip any 224.0.0.40 ! AutoRP

… ! BSR

permit ip any any

interface e0

ip pim sparse-mode

ip igmp version 3

ip access-group no-control-plane-in

interface virtual-template 0


Non-Redundant Access-Networks Simplify Your Life: PIM Passive

ip pim passive

‒ Configure on non-redundant access LAN instead of ip pim *-mode.

‒ Same as ip pim sparse-mode plus all the filtering you ever needed!

‒ ..Cisco can update filtering in IOS releases if protocol packets change..

Inbound filtering

‒ All (current) PIM (including BSR and AutoRP) multicast packets: Router does not joins to 224.0.0.13 (see show ip interface).

‒ WILL STILL PASS THROUGH PIM UNICAST PACKETS (need to protect RP).

‒ DVMRP packets, IGMP queries

Outbound filtering:

‒ No PIM Hellos, DF-election sent on interface (also not any AutoRP nor BSR)

R1

interface e0

ip pim passive

ip igmp version 3


MSDP MD5 Password Authentication

Protect MSDP peering against spoofed packets

‒ Protects against spoofed sourced packets

‒ Partial protect against man-in-middle

Uses RFC2385 TCP authentication header

‒ Defined for BGP

‒ Actually independent of BGP

MSDP MD5 Peering

Passwd “cisco”

10.0.0.2

10.0.0.1

ip msdp peer 10.0.0.2

ip msdp password peer 10.0.0.2 0 cisco R1

R2

Spoofed MSDP Peering

Attempt to bring down

Existing peering

“DoS”

ip msdp peer 10.0.0.2

ip msdp password peer 10.0.0.2 0 cisco

10.0.0.1


Other

ip sap listen

‒ Receive SAP/SDP messages

“Just” for show ip sap output

Not used / required by router otherwise

except legacy ip multicast rate-limit function

‒ DoS against router CPU / memory

‒ Recommendation

Do not enable!

unless considered important to troubleshoot

If enabled, use CoPP to rate-limit

ip multicast mrinfo-filter <std-acl>

‒ Limit mrinfo answers to specific requesters



Access Control Includes Scoping


Access Control Overview Control which ASM groups and SSM channels systems endpoint can send to or receive from

Packet level filter (ASM/SSM) : ip access-group

ipv6 traffic-filter

PIM-SM filter which sources can send to which group:

ip pim accept-register

ipv6 pim pim accept-register

ASM/SSM which group/channel can be received on interface:

ip igmp access-group

ipv6 mld access-group

Which ASM/SSM groups are useable overall: ip multicast group-range

ipv6 multicast group-range

ASM/SSM control plane scoping and flexible filtering:

ip multicast boundary

ipv6 multicast boundary


ip access-list extended source

permit ip 10.0.0.0 0.255.255.255 239.0.0.0 0.127.255.255

deny ip any 224.0.0.0 15.255.255.255 ! Log ?

permit ip any any

interface ethernet0

ip address 10.1.1.1 255.255.255.0

ip access-group source in

We’ll just allow

IPmc traffic from a

well known address range

and to a well known group

range

Network

Engineer

DA = 239.244.244.1

SA = 10.0.1.1

DA = 239.10.244.1

SA = 10.0.0.1

E0

ip access-group [in|out]

ipv6 traffic-filter [in|out]

Packet Filter Based Access Control

HW installed on most platforms–(costs HW filter)

Filters before multicast routing–no state creation

Best for ingress filtering


Host Receiver Side Access Control

Filter group/channels in IGMP/MLD membership reports ‒ Controls entries into IGMP/MLD cache

‒ Extended ACL semantics like multicast boundary

‒ Deny only effective if protocol = ip

‒ IGMPv2/MLDv1 reports:

source = 0.0.0.0 / 0::0

ip access-list extended allowed-multicast

permit ip any host 225.2.2.2 ! Like simple ACL

permit ip 10.0.0.0 0.255.255.255 232.0.0.0

0.255.255.255

deny ip any any


ip igmp access-group allowed-multicast

ip igmp access-group

ipv6 mld access-group H2 224.1.1.1

Report

225.2.2.2

Report

H2


PIM-SM Source Control

RP-based (central) access control for (S,G) in PIM-SM

Extended-Acl: which source can send to which group

Imperfect:

‒ (S,G) state on FHR still created

‒ (S,G) traffic still to local and downstream rcvrs

ip pim accept-register list 10


RP

Unwanted Sender

Source Traffic

Reg

iste

r

Reg

iste

r-Sto

p

First-hop

• Unwanted source traffic

hits first-hop router

• First-hop router creates

(S,G) state and

sends Register

• RP rejects Register,

sends back a

Register-Stop

ip pim accept-register

ipv6 pim accept-register


Disabling Multicast Groups

ip/ipv6 multicast group-range <std-acl>

Futures (partial released for IPv6)

Disable all operations for groups denied by <acl>

‒Drop / ignore group in control packets: PIM, IGMP/MLD, MSDP

‒No IGMP/MLD (cache), PIM, MRIB/MFIB state

‒Drop all data packets: HW-discarding platform dependent

Consider as additional level of defense against other mis-configs

TBD: Filter BSR/AutoRP announcements?


Interface/Protocol Level Access Control Overview IPv4: per-interface either or all of A, B ,C (one each)

‒A: ip multicast boundary <std-acl> [ filter-autorp ]

Group scope boundaries

Payload filtering of AutoRP messages

‒B: ip multicast boundary <ext-acl> in

‒C: ip multicast-boundary <ext-acl> out

Extended form for access-control, SSM scopes

IPv6: per-interface one config of A

‒A: ipv6 multicast boundary scope <n>

Scoping simple due to IPv6 architecture

No B, C options (yet)


Interface/Protocol Level Access Control IPv4 Scope Boundaries

Configure on interfaces passing the (imaginary)

scope boundary line

Protocol filtering for

denied groups

‒ IGMP/PIM

On inside and outside routers

Use filter-autorp option when using AutoRP

‒ No equivalent for BSR (yet)

SITE scope:

239.192.0/16 R2

R1

R3

R4

R5

REGION zone:

239.193.0/16

access-list 10 deny 239.192.0.0 0.0.255.255

access-list 10 permit any

Interface ethernet 0

ip multicast boundary 10 [ filter-autorp ]

e0


Interface/Protocol Level Access Control IPv6 Scope Boundaries

SITE scope: 5

R2

R1

R3

R4

R5


ipv6 multicast boundary scope 7

e1

ipv6 access-group standard scope7filter

permit ff02::00 00f0::00 ! Always permitted

deny ff03::00 00f0::00 ! Deny up to and

… ! Including scope 7

deny ff07::00 00f0::00 !

permit ff08::00 00f0::00 ! Permit higher

… ! scopes

permit ff0f:000 00f0::00 !

REGION zone: 7

Scope addresses fixed by architecture

‒ No need/way to define your own scoping ranges

Larger scope may not cut through smaller scope

‒ Boundary for scope <n> always

filters scope 2..<n-1> addresses

ACL for scope implicitly defined:



Interface/Protocol Level Access Control Separate In/Out Filtering

ip multicast boundary <ext-acl> in

‒ Applies to incoming interface. Inhibits traffic received on the interface

ip multicast boundary <ext-acl> out

‒ Applies to outgoing interface. Inhibit replication to the interface

Extended ACL

‒ Can filter each (*,G) and (S,G) state differently

‒ Support SSM per-channel filtering.

Inbound traffic must be permitted by both ip multicast boundary acl and

ip multicast boundary ext-acl in

Outbound traffic must be permitted by both ip multicast boundary acl and

ip multicast boundary ext-acl out



Interface/Protocol Level Access Control Filtering Rules (1)

OIF (“out”) check:

‒ Router receives IGMP or PIM join on interface where boundary is configured

‒ Multicast boundary (“out”) checks G or (S,G) of this ‘join’

‒ If permitted, normal processing continues

‒ If denied: ‘join’ is ignored.

No state created in PIM / mroute tables

IGMP/MLD/PIM

Join/membership G

OIF check


ip multicast boundary deny-groups ! either

ip multicast boundary deny-states out ! or



IIF (“in”) check (1):

‒ Router receives a ‘join’ (PIM/IGMP)on an interface

‒ “in” Multicast boundary in the receiving interface passed the ‘join’

‒ State (*,G) and/or (S,G) is created if not already existing

‒ PIM selects RPF-interface for the state

‒ Multicast boundary on RPF interface examines (G or (S,G) of state

‒ If permitted–normal processing continues

‒ If denied:

OIF entry for join is NOT CREATED – result: NO OIF entries for this state are created

Result: router will never send PIM join for this state (OIF empty)

IGMP/MLD/PIM

Join/membership G

E.g.: to RP

IIF check (1)



ip multicast boundary deny-states in ! or



IIF (“in”) check (2):

‒ Router receives multicast (S,G) packet on RPF interface

‒ State ( (*,G) and/or (S,G) is created if not already existing

‒ Same check of multicast boundary on RPF interface as last slide!

‒ … multicast state gets forced empty OIF list

‒ If state is PIM-SM, no registering is done for it!

‒ Because state exists in HW, future packets are not punted but HW-dropped

‒ Cat6: No state created! Instead received packets dropped in HW

Multicast boundary on Cat6k ALSO behaves like “ip access-group … in”

IIF check (2)

IGMP/MLD/PIM

Join/membership G

Multicast (S,G) packet Interface ethernet 0


ip multicast boundary deny-states in ! or


Interface/Protocol Level Access Control Filtering Rules Summary

OIF (“out”) check:

‒ Inhibit unwanted traffic “out” that interface

Inhibits propagation of any ‘join’s for such state

‒ Performed by ‘multicast boundary’ and ‘multicast-boundary … out’

IIF (“in”) checks:

‒ Inhibits unwanted traffic “into” an interface. Fast drops further traffic. Inhibits

propagation of any ‘join’ for such state or registering

‒ Performed by ‘multicast boundary’ and ‘multicast boundary … in’

IGMP/MLD/PIM

Join/membership G

IGMP/MLD/PIM

Join/membership G

E.g.: to RP

OIF check IIF check (1) IIF check (2)

IGMP/MLD/PIM

Join/membership G

Multicast (S,G) packet


Interface/Protocol Level Access Control AutoRP Filtering

Domain Boundary

Scope boundary–use filter-autorp

Group ranges intersecting denied ranges in ACL are removed from RP-Discovery/Announce messages at boundary

INTERNET

COMPANY

REGION

SITE 239.192/

16

SITE 239.192/

16

SITE 239.192/

16

239.193/16

239.194/16

224.0.1.0 –

238.255.255.255

Access-list standard internet-boundary

deny host 224.0.1.39

deny host 224.0.1.40

deny 239.0.0.0 0.255.255.255


ip multicast boundary internet-boundary

Access-list standard region

deny 239.193.0.0 0.255.255.255


ip multicast boundary region filter-autorp

RP


Interface/Protocol Level Access Control Semantics of Extended ACLs

INCORRECT: Ineffective for ip multicast boundary

‒ [1], [2] Deny only effective with protocol “ip” (all packets of a (S,G)/(*,G)

‒ [3] Can filter only routable groups!

GOOD: Reuse ACL with ip access-group, consistent result

SPECIAL TRICK: [4] Src = 0.0.0.0 = *

‒ deny (*,G) joins / IGMPv2 memberships, but permit (S,G)

Ip access-list extended ext-acl

deny udp any 239.0.0.0 0.255.255.255 ! [1]

deny pim any host 224.0.0.13 ! [2]

deny ip any host 224.0.0.13 ! [3]

deny ip host 0.0.0.0 any ! [4]

deny ip any 239.0.0.0 0.255.255.255 ! [5]



ip access-group ext-acl out



Interface/Protocol Level Access Control Example: Interdomain (*,G) Filter

Example: PIM-SM transit provider:

‒ MSDP peering only

‒ (S,G), but no (*,G) on border

‒ Inhibit (*,G) joins !

‒ Example: Also inhibit admin-scope addresses

Not useable in Internet transit.

MSDP

RP/

MSDP

Enterprise

ISP1

MSDP

…

ISP1

ip access-list extended interdomain-sm-edge

deny ip host 0.0.0.0 any

deny ip any 239.0.0.0 0.255.255.255

permit ip any any


ip multicast boundary interdomain-sm-edge out

ip multicast boundary interdomain-sm-edge in



Interface/Protocol Level Access Control Example: Subscriber Interfaces


supersedes ip igmp access-group ext-acl

Use ip multicast boundary in/out

independent of host or router subscriber

Consider ip access-group ext-acl in because ingres packet filtering most secure

Rule of thumb:

‒ Output: State based control

‒ Input: State {+ packet} control

H1

Subscriber 1

H1

Subscriber 2

H1

PIM

Provider

Edge Router

IGMP

Sourced

Packets


Admission Control


Admission Control Goals

Protect router from control plane overload

‒State (HW, memory), CPU

‒DoS not to affect non-multicast services

Resource allocation

‒Per subscriber (VRF, interface)

‒DoS not to affect multicast to other subs.

‒Limit subscriber resources to SLA

Call admission control

‒Protect bandwidth resources (interfaces, subnets) from congestion

‒Content/Subscriber based policies


Admission Control MSDP Control Plane

ip msdp sa-limit <peer> <limit>

Limit #SA states accepted from MSDP peer

Simple recommendations ISP router:

‒ Small limit from stub-neighbor (customer)

‒ Large limit (max #SA in Internet) from transit customer

If you are transit ISP yourself

Enterprise MSDP speaker

‒ Max #SA (large limit) should not overload router

Tra

nsit

all S

A

Enterprise

Customer1

ISP

Enterprise

Customer2

ISP2

ISP

Peer2

ISP

Peer2

Large #SA Large #SA

Small #SA

MSDP peerings

Small #SA



Admission Control Global/per-VRF Route Limits

No state created beyond <limit>

‒ State triggering packets still punted, but discarded

Syslog warnings created beyond <threshold>

PIM Join

rtr-a

rtr-b

ip multicast route-limit 1500 1460

%MROUTE-4-ROUTELIMITWARNING :

multicast route-limit warning 1461 threshold 1460

%MROUTE-4-ROUTELIMIT :

1501 routes exceeded multicast route-limit of 1500

rtr-a> show ip mroute count

IP Multicast Statistics

1460 routes using 471528 bytes of memory

404 groups, 2.61 average sources per group

ip multicast route-limit <limit> [ <threshold> ]



Admission Control IGMP/MLD Admission Control

ip igmp limit <n> [ except <ext-acl> ]

ipv6 mld limit <n> [ except <ext-acl> ]

Always per interface

Global command sets per-interface default

Counts entries in IGMP/MLD (per-interface) table

ip access-list extended channel-guides

permit ip any host 239.255.255.254 ! SDR announcements

deny ip any any

ip igmp limit 1 except channel-guides


ip igmp limit 2 except channel-guides


Admission Control per-interface mroute limits

ip multicast limit

[ rpf |out|connected ] <ext-acl> <max>

Per interface mroute state for PIM and IGMP

Output: Out

‒ Supersedes IGMP limit

Input: Rpf

‒ connected = Input from directly connected source

Multiple limits configurable per interface

‒ Sequential matching:

‒ Flow limited against first limiter with <ext-acl> permitting the

flow

S1,G1

Multicast

Lookup/ingress states

Accounted against s0

Ingress (rpf/connected)

Multicast

Egress/Replication

states, accounted

Against s1, s2 egress (out)

s2 s1

s0


Admission Control How to Use It

Protection against DoS attacks by creating too many trees

‒First level of defense:

Global/per-vrf mroute-limits–sufficiently larger than expected

‒Second level of defense

Global IGMP/MLD limit default–applies per interface.

Isolates attacks between interfaces

‒Third level of defense

On PE, connecting to (internet) CEs

Per-interface mroute-limit, input and output

Like igmp limits but for sourced and received trees, IGMP and PIM


Bandwidth Based CAC via CLI Overview

Default–count trees as ‘1’

‒Effectively just count number of trees

Add global config to define how to count each tree:

ip multicast limit cost <ext-acl> <count>

‒Multiple configs possible, first acl match determines tree cost

Usage:

‒Decide on unit for <count> and <max>, eg: Mbps

‒Set up address plan – allow easy adding of flows later

‒239.1.X.Y -> X = bandwidth in Mbps (2..20), Y flow-number

‒Configure one global multicast limit cost CLI line for each X

(without having to know which Y is going to be used)


3. Requested Policy: Fair sharing of bandwidth between CPs

Bandwidth Based CAC via CLI Example

4. 250 Mbps for each CP 250 Mbps Internet/etc

1. Three Content Provides

2. Four bandwidth flows: - MPEG2 SDTV: 4 Mbps - MPEG2 HDTV: 18 Mbps - MPEG4 SDTV: 1.6 Mbps - MPEG4 HDTV: 6 Mbps

5. Simply add global costs

1GE

250-500 users per DLAM

DSLAM

DSLAM

DSLAM

Cisco 7600

10GE

Content Provider 1

Content Provider 2

Content Provider 3

Content Providers

Service Provider

Paying Customers

MPEG4 SDTV

MPEG2 SDTV

MPEG4 SDTV MPEG2 HDTV

MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


PE


3. Requested Policy: Fair sharing of bandwidth between CPs

Bandwidth Based CAC via CLI Example

4. 250 Mbps for each CP 250 Mbps Internet/etc

1. Three Content Provides

2. Four bandwidth flows: - MPEG2 SDTV: 4 Mbps - MPEG2 HDTV: 18 Mbps - MPEG4 SDTV: 1.6 Mbps - MPEG4 HDTV: 6 Mbps

5. Simply add global costs

1GE


DSLAM

DSLAM

DSLAM

Cisco 7600

10GE

Content Provider 1

Content Provider 2

Content Provider 3

Content Providers

Service Provider

Paying Customers

MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


PE

! Global

ip multicast limit cost acl-MP2SD-channels 4000 ! from any provider

ip multicast limit cost acl-MP2HD-channels 18000 ! from any provider



!

interface Gig0/0

description --- Interface towards DSLAM ---

...

! CAC

ip multicast limit out 250000 acl-CP1-channels



…


Bandwidth Based CAC via CLI Example: Input CAC

What difference does Input vs. output

limit make?

Consider same example slightly

changed:

‒ Non-Cisco PE

‒ Cisco IOS routers (FTTH)

instead of DSLAM

Same config, same result just

configure input (rpf) limit instead of out

limits!

1GE

250-500 users per FTTH switch

DSLAM

DSLAM

DSLAM

Non Cisco PE

10GE

Content Provider 1

Content Provider 2

Content Provider 3

Content Providers

Service Provider

Paying Customers

MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


PE

IOS-Rtr

IOS-Rtr

IOS-Rtr


Bandwidth Based CAC via CLI Example: Input CAC

What difference does Input vs. output

limit make?

Consider same example slightly

changed:

‒ Non-Cisco PE

‒ Cisco IOS routers (FTTH)

instead of DSLAM

Same config, same result just

configure input (rpf) limit instead of out

limits!

1GE

250-500 users per FTTH switch

DSLAM

DSLAM

DSLAM

Non Cisco PE

10GE

Content Provider 1

Content Provider 2

Content Provider 3

Content Providers

Service Provider

Paying Customers

MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


MPEG4 SDTV

MPEG2 SDTV


PE

IOS-Rtr

IOS-Rtr

IOS-Rtr

! Global





!

interface Gig0/0

description --- Interface towards PE ---

...

! CAC

ip multicast limit rpf 250000 acl-CP1-channels



…


ASM: only match (/count) (*,G) = (0.0.0.0,G) states:

SSM: count each (S,G) state

ip access-list extended acl-MP2SD-channels

permit ip host 0.0.0.0 239.0.4.0 0.255.0.255

ip access-list extended acl-MP2HD-channels

permit ip host 0.0.0.0 239.0.18.0 0.255.0.255

...

ip access-list extended acl-CP1-channels

permit ip host 0.0.0.0 239.1.0.0 0.0.255.255


permit ip host 0.0.0.0 239.2.0.0 0.0.255.255

Bandwidth Based CAC ACL Details

ip access-list extended acl-MP2SD-channels

permit ip any 232.0.4.0 0.255.0.255

ip access-list extended acl-MP2HD-channels

permit ip any 232.0.18.0 0.255.0.255

...


permit ip any 232.1.0.0 0.0.255.255


permit ip any 232.2.0.0 0.0.255.255


RSVP based IP multicast CAC

RSVP + IP multicast supported for long time in IOS

‒ But not enforced in network so far

‒ Required “collaborative receivers”

‒ If link was overloaded, receivers who got “RSVP RESV rejected” had to stop their IGMP join immediately.

RSVP IP multicast filtering 2011/2012

‒ For SSM and egres CAC

‒ Compared to CLI based CAC:

No configuration necessary: “which (S,G)flow requires which bandwidth”.

Bandwidth dynamically signaled by RSVP.

All (unicast) RSVP policies supported to determine which flows are to be admitted. Includes priorities. Eg: Later high priority flow can preempt existing low-priority flows.

Makes multicast CAC more applicable to non IPTV networks

‒ Simplicity/no need to know bandwidths

‒ Eg: enterprise networks


Firewalls


Firewalls and Multicast Overview

Firewall function is not NAT

‒Firewall and NAT often collocated

‒ IOS: Source NAT and limited src/grp NAT

IOS Firewall: specific firewall feature set

‒No multicast support requirements identified

‒Coexistence good enough!

Firewall devices/appliances: (ASA, FWSM ..)

‒Add IP multicast routing to device

‒And similar access control as IOS


Cisco IOS Firewall Unicast

‒Mostly to avoid unwanted “receiving”/”external connections”

‒ Identify TCP/UDP/RTP/.. Flows by examining control plane flows (TCP, RTSP, FTP, HTML, ..)

‒Dynamic permitting flows based on policies

‒Passes multicast traffic

Multicast

‒Use multicast access-control to permit multicast applications:

ip multicast boundary, …

‒Safe because (you should know this now):

Multicast flows stateful, explicit join

Full control of flows with existing control mechanisms


ASA/(PIX) Firewalls Overview

PIX Firewall pre v7.0

‒ IGMPv2 proxy routing only (for edge PIX). Still supported.

Current: v8.x

‒515, 525, 535 and ASA platforms

‒PIX is full IGMP/PIM router

Full features (ported from IOS)

Not all functions tested yet/supported

Obsoletes solutions like

GRE tunnels through PIX

Third-party DVMRP-only firewall


ASA/FWSM Multicast Features ASA

‒ IGMP Support Stub multicast routing–IGMP Proxy Agent

IGMPv2, access group, limits

‒PIM Support PIM Sparse Mode, Bidirectional, SSM

DR Priority

Accept Register Filter

Multicast Source NAT

‒Multicast Boundary with autorp filter

‒PIM Neighbor filters with Bidir-support

FWSM >= 3.1 ‒Almost all ASA/(PIX) features

‒Missing multicast boundary

‒But supports Multicast Destination NAT


IPsec and Multicast


Multicast and IPsec Concepts IPsec p2p tunnel interfaces (12.3(14)T/12.3(2)T)

‒Permits to encrypt IP multicast traffic

avoids RPF issues with crypto-map based IPsec

“Secure Multicast” / GETvpn (12.4(6)T)

‒Transparent “tunnel mode” en/decryption

Inhibits need for overlay network

IPsec to both multicast data traffic

and control plane security

‒GDOI—Key distribution mechanism (RFC3547)

Manual keying still available


GRE tunnels and DMVPN IPsec to encrypt unicast GRE packets

P2P IKE security associations (hub to spoke)

P2P GRE tunnel (hub to spoke)

‒ IPsec encryption applied only to unicast GRE packets

DMVPN adds

‒ Scalability: single ‘multipoint’ tunnel interface on hub and spokes

‒ NHRP: create on-demand shortcut tunnel/sec-assoc between spokes

Rtr 1

Rtr 2 Rcvr1

Rcvr2

Traffic flow Rtr 3

Rtr 4

Encrypt crypto-map Decrypt crypto-map

Rtr1/Rtr3 SA

Rtr2/Rtr3 SA


P2P IPsec Tunnel Interface GRE free solution

IPsec tunnel interface

‒ looks like GRE tunnel interface to IP multicast

Interoperability with 3rd party IPsec equipment

‒ Router and clients

‒ Multicast to clients only possible with this IPsec tunnel interface solution

Does not replace DMVPN/GRE solution

‒ No multpoint interfaces, NHRP shortcuts

Rtr 1

Rtr 2 Rcvr1

Rcvr2

Traffic flow Rtr 3

Rtr 4


Rtr1/Rtr3 SA

Rtr2/Rtr3 SA


Secure Multicast How to Use Multicast in Core?

IPsec “Tunnel mode”: changes (S,G)

creates multicast overlay problem -> requires MVPN signaling or similar

‒ IPsec Header preservation mode can avoid this

Need SA for multicast packets between source/receiver routers

(share key between “group of nodes”)

‒ Manual keying group membership/scaling issues -> GDoI !

Rtr 1

Rtr 2 Rcvr1

Rcvr2

Traffic flow Rtr 3


?


IP header

(S,G) IP Payload

Original IP Packet

IPsec Tunnel Mode IP Header Preservation

Preservation copies/maintains Source, Destination, options, DSCP, … Not maintained: IP header protocol type (obviously!–now ESP/AH)

(classic/unicast) IPSec Tunnel Mode – no multicast

New IP header:

Tunnel src/dest

IP Header Preservation Mode

IPSec

packet

ESP or AH

header IP header

(S,G) IP Payload

Original

IP header

(S,G)

ESP or AH

header IP header

(S,G) IP Payload


Dynamic Group SA Keying GDOI

Single/manual configured key between all encrypting/decrypting

routers

‒How to manage keys, membership? Re-keying?

GDOI: Dynamic Group-SA protocol (RFC3547)

‒Group-key equivalent to PKI (p2p SA)

‒Client-Server protocol:

Encrypting/decrypting nodes (routers/host) = clients

Server: Key server, managing members

IOS implements both client and server side

‒Scalable/dynamic re-keying: Can use multicast to distribute updated keys!


Secure Multicast / GETvpn Encrypt with Multicast across Core

In IOS images with “Secure Multicast” feature support,

multicast packets receive “Header Preservation” in tunnel mode

Can now successfully use crypto-maps (no tunnel interfaces required) to pass multicast

encrypted across core

Use with:

‒ MVPN: en/decrypt on PE or CE routers!

‒ Non-MVPN: E.g.: Enterprise, unsecure backbone links, …

Rtr 1

Rtr 2 Rcvr1

Rcvr2

Traffic flow Rtr 3


Group SA

Rtr1/Rtr2/Rtr3


Secure PIM Control Traffic with IPSec Strategy/Example

Encrypt/Authenticate PIM Packets

‒ Crypto map for 224.0.0.13 (PIM Control Messages)

‒ Hop-by-hop encryption/decryption of PIM msgs

Does not include PIM-SM registering! (would require unicast IPsec setup)

‒ Use either IPSec options

Hash Functions: MD5, SHA1

Security Protocols: Authentication Header(AH), Encapsulating Security Payload (ESP)

Encryption Algorithms: DES, 3DES, AES

NOT ALL COMBINATIONS WORK

Recommended IPSec Mode: Transport

Recommended Key method: Manual?

IPSec AH recommended in PIM IETF RFC5601

LAN

Encrypt/ Decrypt

crypto-map

Encrypt/ Decrypt

crypto-map


access-list 106 permit ip 0.0.0.0 255.255.255.255 host 224.0.0.13

crypto ipsec transform-set pimts ah-sha-hmac

mode transport

crypto map pim-crypto 10 ipsec-manual

set peer 224.0.0.13

set session-key inbound ah 404 bcbcbcbcbcbcaaaa

set session-key outbound ah 404 bcbcbcbcbcbcaaaa

set transform-set pimts

match address 106

Secure PIM Control Plane Global config (once)

Per interface config

interface Ethernet0/0

crypto map pim-crypto


Secure PIM Control Plane Discussion

Basic security (previous slide)

‒ Uses AH as recommended by PIM (RFC4601)

‒ Same security as RIP/OSPF built-in security:

No replay protection

Manual keys

Authorization only

No encryption

Best security!?

‒ Replay protection: require dynamic keying (GDoI)

‒ In IOS:

Requires ESP (for validating IP header)

Uses Cisco proprietary time-based replay protection (no standard available)

‒ Optional: Add encryption of packet (also requires ESP)

No IPsec support in PIM-snooping!

No benefit? for encryption without PIM-snooping in LAN

‒ Spoofer can always see from actual multicast traffic what was in PIM-Join messages



Summary and

Best Practices


Summary Multicast and Security

Multicast is different from unicast!

‒Why? Remember? … states, replication, joins, unidirectional..

Rich framework of IOS CLI commands for control

‒Controlling protocol operations

‒Control multicast state

‒Policing packets (MQC, CoPP,–same as unicast)

‒Can provide “protected” service/SLA

ASA with “full”(PIM) IP multicast routing

Emerging solutions with multicast

‒ IPsec (protect PIM or multicast data)


Security by Simplicity SSM No attack points in network

‒ PIM-SM RP, DR (punting, tunnel), RP-mapping protocols (AutoRP/BSR), MSDP

Assume best effort–no business critical application running

Secure–protect to be ~comparable to unicast

Simple config global mroute/igmp limits!


ip pim ssm default

no ip dm-fallback

ip multicast route-limit 1000 900

ip igmp limit 100

interface ethernet 0 ! All backbone

ip pim sparse-mode

Interface vlan 1 ! All (non-redundant) access

ip pim passive

ip igmp version 3


Adding ASM Service And Harden It

Static-RP config with override safer than relying on AutoRP or

BSR

‒AutoRP/BSR of course more flexible! If wanted:

‒Need to inhibit users to send AutoRP/BSR messages–see section

on redundant access networks.

Intradomain ASM: Bidir-PIM “safer” than PIM-SM

‒No RP or DR (tunnel) that can be attacked

PIM-SM

‒Protect register tunnel, consider filtering unicast PIM on edge

(attacks at RP), consider CoPP on DR/RP.


Manage IP multicast SLA Access and Admission Control

If you only care about a stable network,.. But not the applications

‒ Per-interface igmp/mroute limits

protect against state attack from individual ports/users.

If you also need to provide constraints for applications, protect content, …

‒ Define scoped address ranges if access to applications/content can be defined by

geography

‒ Separate input/output multicast boundary filtering to differentiate between

permitted senders and receivers

‒ Effective filtering on first-hop best should use packet-filter

Multicast boundary only sufficient on platforms where it includes packet filtering – cat6k, …


Exercises for Your Own Time! Administrative Edge Security

Many choices

Most secure solution–static:

‒ Just statically forward traffic “ip igmp static-group G source S” (from the voice of a security person, not a multicast person !)

With PIM used

‒ Prefer standard PIM-SSM and PIM-SM/MSDP (IPv4)

Filter (*,G) on edge, only (S,G) needed

‒ Consider Embedded-RP (IPv6)

‒ Always filter AutoRP, BSR and all appropriate scopes, denied group-ranges on edge interface

Avoid “sharing” RPs with ‘customers’ (eg: enterprise customer)

‒ If really necessary:

Have RP be used statically, avoid using AutoRP/BSR across interdomain border

If AutoRP/BSR must be used toward “customers” be very careful in filtering RP/group range mappings!


Q and A


Recommended Reading


References & Further Reading White Paper: “The Multicast Security Toolkit”

‒http://www.cisco.com/web/about/security/intelligence/multicast_toolkit.html

Cisco IP Multicast Security

‒http://www.cisco.com/en/US/products/ps6593/products_ios_protocol_group_home.html

PIM-SM Protocol Specification

‒RFC 4601, extensive security section!

IETF Msec Working Group

‒http://www.ietf.org/html.charters/msec-charter.html

http://www.securemulticast.org/

“Multicast Security: A Taxonomy and Some Efficient Constructions”, Ran Canetti et al.,

1999

‒http://www.ieee-infocom.org/1999/papers/05d_03.pdf

Various papers on Multicast Security

‒http://www.cisco.com/en/US/products/ps6593/prod_white_papers_list.html

For Your Reference

http://www.cisco.com/web/about/security/intelligence/multicast_toolkit.html

http://www.cisco.com/en/US/products/ps6593/products_ios_protocol_group_home.html

http://www.ietf.org/html.charters/msec-charter.html



http://www.securemulticast.org/

http://www.ieee-infocom.org/1999/papers/05d_03.pdf



http://www.cisco.com/en/US/products/ps6593/prod_white_papers_list.html

© 2012 Cisco and/or its affiliates. All rights reserved. BRKIPM-2262 Cisco Public 112

Feedback

• Give us your feedback and you could win fabulous

prizes. Winners announced daily.

‒ Receive 20 Passport points for each session evaluation

you complete

‒ Complete your session evaluation online now

(open a browser through

our wireless network to access our portal) or visit one of

the Internet stations throughout the Convention Center.

• Don’t forget to activate your Cisco Live Virtual

account for access to all session material,

communities, and on-demand and live

activities throughout the year.

Activate your account at the Cisco booth in the

World of Solutions or visit www.ciscolive.com.

http://www.ciscolive.com/


Backup Slides … More Details …


Introduction


Multicast vs. Unicast Application Side Difference—Unicast/TCP

“Admission” control–unicast

‒ Relies on congestion control

Up to 30 times oversubscription

Works!

‒ Time-statistical multiplexing

‒ 95% TCP (or like TCP)!

Reliability by retransmission

Sender rate adaption

WRED, DPI, … in network

Non-real-time/best-effort service

…

… …

622 Mbps

155 Mbps

“6 Mbps”

x 100

ATM

LAC/LNS/BRAS

x 30


… x 30

Multicast vs. Unicast Application Side Difference—Multicast/PGM

PGM

‒ Multicast equivalent of TCP

‒ FEC/NAK retransmission

‒ PGM-CC (congestion control)

Match sender rate to slowest

receiver.

WRED/TCP compatible

Multicast problem

‒ Penalization by slowest receiver!

‒ Fate sharing between receivers

… Ignore too slow receivers

Best with enterprise apps?

… …

6

Mbps x 100

Multicast

6 Mbps

Unicast

2 Mbps


Multicast vs. Unicast Application Side Difference—Multicast/Large-Block-FEC

ALC with large-block FEC (Tornado/Raptor/..) codec

Sustain arbitrary packet loss and still decode content

Just discard packets at every hop under congestion

‒ Use even less-than-best-effort class (scavenger)

FEC encode Orig File

Send 2^32 different packets

Received File FEC decode

Receive arbitrary packets

Tra

nsm

itte

r R

eceiv

er

Network with (arbitrary) packet loss …

4 Mbps

x 100

Multicast

6 Mbps

Unicast

2 Mbps

6 Mbps 6 Mbps

Police=

Discard

packets


Multicast vs. Unicast Application Side Difference—Real-Time Traffic

Congestion and real-time traffic

‒Small % of today’s unicast traffic

‒Large % of today’s multicast traffic !!!

Temporary “congestion”/BER caused packet loss

‒ (short-block) FEC (MPEG)

‒ retransmissions (TCP, PGM)

Longer term “congestion”/oversubscription:

‒Over-provisioning/Diffserv bandwidth allocation.

‒Sender codec rate adaptation

‒Per-flow admission control (Intserv)


Oversubscription with Real-Time Traffic

Consider link filled with real-time traffic

‒ E.g.: 100Mbps link, 4Mbps TV

Can fit up to 25 Flows

What happens when 26th flow is put onto link ?

‒ All 26 flows become useless

Problem for unicast (VOD) and

multicast (broadcast)

‒ But solutions can differ

…

… …


Multicast vs. Unicast Sender codec-rate Adaption

Unicast Audio/Video:

‒ Sender (encoder/transcoder):

Reduce bit rate/lower quality due to congestion

‒ Used with “Internet AV” streaming.

Multicast/“Simulcast” Audio/Video:

‒ No third-party receiver penalizing:

‒ Send different BW encodings

‒ Receivers choose BW/encoding by joining to specific

group/channel

‒ Less-granular than unicast

…

… …

Multicast

HD: 6 Mbps

Unicast

2 Mbps

receives

2 Mbps

Receives

6 Mbps

Receives

6 Mbps

Multicast

SD: 2 Mbps


Multicast vs. Unicast Application Side Difference–Intserv Admission Control

Intserv:

‒ per flow (admission) control

Unicast:

‒ Source side enforcement!

‒ No need for network enforcement

Multicast:

‒ Network enforcement!

‒ Block forwarding at replication points!

Mechanisms:

‒ RSVP (unicast), CLI (mcast)

TV Server

…

A B C D

R1

R2

R3


Multicast vs. Unicast Scoped Addresses

Unicast:

‒ rfc1918 addresses

‒ Reuse of host addresses

‒ “privacy” for hosts

Multicast:

‒ IPv4: 239.0.0.0 / 8 addresses

‒ IPv6: 16 scopes in architecture

‒ Geographic form of access control

for applications

‒ No per source/receiver control

‒ Reuse of ASM group addresses

INTERNET

COMPANY

REGION

SITE 239.192/16

SITE 239.192/16

SITE 239.192/16

239.193/16

239.194/16

224.0.1.0 –

238.255.255.255

Example scoped

Address architecture

with IPv4 multicast


Access Control Includes Scoping


Interface/Protocol Level Access Control Example: Alternative SSM Scopes [ (S/M, G/M) ]

IPv6: 16 scopes for both ASM and SSM!

IPv4: Only global scope SSM (232.0.0.0/8).

Cisco recommendation, add ranges:

‒ 239.232.0.0/16–admin scoped SSM

‒ Not supported by all vendors

SSM (S/M, G/M) scopes:

‒ A/M = loopback of MVPN-PE

‒ 232.x.0.0 = MVPN Default & Data-MDTs

‒ Use (S/M,G/M) scope filter on P links facing Internet-PE (non-MVPN)

‒ Result:

Full Internet SSM transit

Protected MVPN service

P-Core

Internet

Bcast-Video

PE

Internet

Bcast-Video

PE

MVPN

PE

MVPN

PE

Deny ip A/M 232.x.0.0/16

SS

M w

ith

23

2.0

.0.0

/8


Admission Control


State/Call Admission Control Terminology

1 Call =

1 (TV/radio/market) program/flow

1 State ~= 1 Call ?

‒SSM: 1 (S,G) state = 1 call

‒ASM/PIM-SM: 1 call = (*,G) + 1 or more some (S,G)

Limit state = DoS protection

Limit calls = service management

Admission:

‒hop by hop–permit/deny call for whole branch of the tree

(RP)


Example Usage of igmp Limit Admission Control on Agg-DSLAM Link

1. 300 SDTV

channels

2. 4Mbps each

3. Gbps link to DSLAM

500 Mbps for TV

rest for Internet etc.

4. 500Mbps/4Mbps = 125 IGMP

states

IGMP/MLD =

Receiver side only No PIM

PE

10GE


1GE

DSLAM

DSLAM

DSLAM

Cat7600

PE

300 channels x 4Mbps = 1.2Gbps > 1GE

300 SDTV channels

interface Gig0/0

description Interface towards DSLAM

ip igmp limit 125


Example Use of per Interface mroute limits Admission Control on Agg-DSLAM Link

Superceeded by multicast-limits

300 SD channels with4 Mbps each

Basic, Extended, Premium bundles 100 channels ea.

Want to allow:

‒ 60%/300Mbps Basic 20%/100Mbps Extended 20%/100Mbps Premium

Need to limit:

‒ Basic 75 states Premium 25 states Gold 25 states

10GE


1GE

DSLAM

DSLAM

DSLAM

Cat7600

Generic interface multicast route limit feature with

support for Ingress, egress, PIM/IGMP, ASM/SSM.

300 channels offered

300 channels x 4Mbps = 1.2Gbps

Gig0/0

PE

Basic (100 channels)

Premium (100 channels)

Gold (100 channels)

interface Gig0/0

description Interface towards DSLAM

ip multicast limit out 75 acl-basic

ip multicast limit out 25 acl-ext

ip multicast limit out 25 acl-premium


Admission Control What different features achieve

Router global control plane (CoPP)

Per VRF, interface, neighbor control plane Mroute-limits, MQC rate limiters, MSDP limits (PIM-SM only)

Per interface state limits igmp / mld / multicast(pim)

Per interface limits with costs

RSVP for bandwidth limits

GOALS

Protect router from control plane overload

Fair/SLA based router resource allocation

Bandwidth based Call admission control

Features

–Yes, W–Workaround , F–Future

W W


1 Authentication, Authorization, Accounting

AAA1 Integration

for IP Multicast


Service Edge and Multicast AAA Integration

Subscriber and Content Provider Edge interfaces

Access/admission-control CLI is authorization

AAA integration:

‒ Add authentication driven authorization and accounting

Last Hop Router/Switches Connects to receiver

IP Multicast Delivery Network

SP/enter edge router

Access Router (DSL, Cable, …)

L2 Access Device switch, DSLAM,..

AAA Server e.g.: Radius

TV with STB

Desktop PC

Customer Edge Router

PIM

MLD IGMP

Video source (e.g.: Camera with MPEG encoder)

First Hop SP Edge Router Connects to Source directly or indirectly


Service Edge Without AAA Support

Assume single subscriber per interface

Configure discussed CLI commands, like:

‒ ip access-group / ipv6 traffic-filter

‒ ip igmp access-group / ipv6 mld access-group

‒ ip multicast boundary [in | out]

‒ ip pim neighbor filter

‒ ip igmp limit / ipv6 mld limit

‒ ip multicast limit [ rpf | out]

… to provide subscriber based access and admission control


AAA Models for IP Multicast Authentication

‒ By interface

‒ By subscriber (PPP links)

Authorization

‒ Manual (previous slide)

‒ Radius/Tacacs provisioning

‒ Join/Membership authorization

Accounting

‒ Dynamic accounting via Radius

‒ Netflow support for IP multicast

‒ Polling of MIB counter

‒ Application level (e.g.: STB)

Not usually considered to be part of AAA


AAA Models Radius/Tacacs Provisioning Consider manual global CLI configs

! Basic Service ip access-list standard basic-service

permit 239.192.1.0 0.0.0.255 ! Basic service channels

!Premium Service ip access-list standard premium-service


permit 239.192.2.0 0.0.0.255 ! Premium service channels

! Premium Plus Service ip access-list standard premium-plus-service


permit 239.192.2.0 0.0.0.255 ! Premium service channels

permit 239.192.3.0 0.0.0.255 ! Premium Plus service channels

! Just all multicast groups Ip access-list standard all-groups

permit 224.0.0.0 15.255.255.255


AAA Models Radius/Tacacs Provisioning

PPPoX interface support with AAA

‒User-ID based authentication. Not specific to multicast

‒Radius server dependent: reuse profiles

Multicast AAA

‒aaa authorization multicast default [method3 | method4]

‒Trigger Radius authentication after first IGMP/MLD join

‒Authenticates user via interface name

! On Radius/Tacacs Server Username / interface: !(PPP) / non-PPP links Cisco:Cisco-avpair = “{lcp}:interface-config = ip igmp limit 3, ip igmp access-group basic-service”


AAA Models Authentication with Radius Provisioning

User Access Router AAA Server

PPPoX

connection

interface Fa0/1

ipv6 mld limit 3 ! Three STB’s

ipv6 mld access-group premium-service

ipv6 multicast aaa accounting receive <acctacl> delay 10

Non PPP

connection



Accept Deny

Accept Deny Change in profile

AAA Models Changing User Profiles from Radius/Tacacs Provisioning


AAA Models FUTURE Per Join/Membership Authorization

Allows dynamic AAA server based policies

‒ More flexible and expensive than provisioning based

‒ Frequently changing policies (PPV,…)

‒ Admission control: With tracking of existing memberships

‒ Scalability via cache-timeout in AAA server replies

Potential to combine models:

‒ Whitelist: AAA provisioning permits always allowed services

‒ Greylist: per join/membership authorization only invoked for requests not

permitted by whitelist

E.g.: PPV, ..

‒ Maximizes scalability


AAA Models NOT DEVELOPED Per Join/Membership Authorization


Accept Deny

Accept Deny


AAA Receiver Accounting

aaa accounting multicast default [start-stop | stop-only]

[broadcast] [method1] [method2] [method3] [method4]

‒ Set global parameters for accounting

ipv6 multicast aaa account receive access-list

[throttle seconds]

‒ Enable accounting on interface

Generate Radius acct. records for multicast flows

‒ When first joined on an interface (START)

‒ When stopped being forwarded on interface (STOP)

‒ FUTURE: Periodically, with counters

Avoid many accounting record during zapping

‒ Send START record only throttle-seconds after join


AAA Receiver Accounting


With possible configurable delay as a throttling mechanism in the face of channel surfing


IPsec and Multicast


Router 1

Router 4

Subnet 1

Subnet 2

Subnet 3

Subnet 4

Router 2

Router 3

Key Server

• Each router Registers with the Key Server. The Key Server authenticates the router,

performs an authorization check, and downloads the policy and keys to the router.

Public Network

Rekey Keys and Policy

IPsec Keys and Policy

Rekey SA

IPSec SAs

Rekey SA

IPSec SAs

Rekey SA

IPSec SAs

Rekey SA

IPSec SAs

GDOI Registration

Each VPN CPE

• Registers to the GDOI key server to “receive” IPsec SAs

• Encrypts/Decrypts packets matching the SA

• Receives re-key messages, either to refresh the IPsec SAs or eject a member

GetVPN IPsec Unicast (and Multicast) with GDoI


Application Scenario Integration of GDOI with DMVPN

1. DMVPN Hub and spokes are configured as

Group Member (GM)

2. All Group members register with the Key

Server (KS)

3. A spoke to hub tunnel is established using

NHRP

4. Spoke sends a NHRP resolution request to

the Hub for any spoke-spoke Communication

5. Upon receiving NHRP resolution reply from

the hub, the spoke sends traffic directly to

other spokes with group key encryption

DMVPN HUB

Key Server

Spoke1

Spoke2

Spoke3

ISP

2

2

2

2

1

1

1

1

3

3

3

Benefit: Using Secure Multicast / GDOI functionality in DMVPN network, the delay from IPSec negotiation is eliminated

Note : Multicast traffic will be still forwarded to Hub for any spoke to

spoke even with this deployment.

DMVPN Hub

Key Server


Secure Multicast Summary Key Application Scenarios

Key Use Case Customer Features

Encryption of IP

packets sent over

Satellite Links

Organizations who wish to secure

video communications through use

of BB satellite

Hardware Acceleration support

Native Multicast Encryption

Secured Multicast

VPN

MPLS VPN Service Provider

customer who wish to have multicast

services between multiple sites of a

customer VPN

Security for mVPN packets

DoS protection for mVPN PE

CE-CE protection for Multicast

Reduce delays in

Spoke-Spoke

DMVPN network

DMVPN Enterprise customers who

are deploying voice and wish to

reduce the delays in setting up voice

calls between spokes

GDOI with DMVPN

Instant spoke-spoke connectivity

Secure PIM Control

Traffic

Enterprise financial customers who

wish to secure PIM control traffic in

their network

PIM control packets encryption


Call to Action

• Visit the Cisco Campus at the World of Solutions to experience Cisco innovations in action

• Get hands-on experience attending one of the Walk-in Labs

• Schedule face to face meeting with one of Cisco’s engineers

at the Meet the Engineer center

• Discuss your project’s challenges at the Technical Solutions Clinics

147

multicast securityd2zmdbbm9feqrf.cloudfront.net/2013/eur/pdf/brkipm-2262.pdfof multicast security...

Documents