IP Multicast Security - cisco.com · Receiver Side Explicit Join Based Traffic Forwarding (4) •...

1© 2006 Cisco Systems, Inc. All rights reserved. Cisco PublicRST-226212696_05_2006_X2

IP Multicast Security

RST-2262


Objectives

• Not a cookbook of recipes!

• Learn what makes multicast different from unicast

• Learn about tools (router functions) availableMeans and goal,

Tools developed for unicast

Multicast specific tools

With example stubs


Agenda

• Introduction

• Control Plane Security

• Access Control

• Admission Control

• AAA

• Firewalls

• IPsec


Introduction


Security Goals …(Why We Want “Security”)

• Keep network running underMis-configuration, Malfunction, Attacks

• Manage resources

• Control multicast application/serviceSender / Receiver

Authorization / Subscription

• Account for Resource utilization, service participation

No simple 1:1 mapping between goals and means. Wide range of tools in products.


… and MeansWhat “Tools” Provide Security

• Service Control and Enforcement

• AAAAuthentication, Authorization and Accounting

• “Privacy”Closed user groups (scopes), VPN / VRF

• NAT ? not security!

Just collocated in firewalls


Multicast Control and Enforcement

AccessPermission/Credential

AdmissionResource availability

Policy

Statecreation

Packet levelpolicing, encryption

Why: Control type

How: Method

What: Target

DeviceControl plane

LinksNetworkData plane

ServiceContent

Where: Location

LocalRouterswitch

Hop-by-HopCoordinated

Policy-ServerAAA


Multicast / Unicast Security Comparison

• NetworkReplicationPer application stateReceiver built treesScoped addresses

• ApplicationTypical not “TCP like”Unidirectional or multidirectional

• ProtocolsSimilar Common use of link scope multicast


Multicast / Unicast Security Comparison

Think Multicast !!!… if you want multicast

security…

CAN DO MORE / MUST DO MORE


Multicast vs. UnicastPer-Application State

• Unicast:State grows when network topology grows. CPU is active when network topology changes.

No impact by user activityDesign network (only) for bandwidthTopology change triggered activity

• Multicast:All of unicastState grows when user starts applicationCPU active when application state changes

Design for number of application/sources


Multicast vs. UnicastState and Replication in Routers and Switches

• “ingress” stateper application/sender

• “egress” state per receiver branch

• HW limits: 5000 … >100,000• SW limits: >> 100,000• Throughput limits

Unicast: Ingress Packet RateMulticast: Egress Packet Rate

• ROUTERS AND SWITCHES

…

S2,G2S1,G1

MulticastLookup/ingress states

MulticastEgress/Replication

states


Ether SW

Multicast vs. UnicastReplication in Routers and Switches

• Example: Inhibit Source -> A traffic

• Unicast: can filter anywhere on path

• MulticastSwitch or router

Receiver:

MUST filter after last replication

Egress filtering!

Sources:

MUST filter before first replication

Ingress filtering!

Multicast

Unicast

R1

S1R2

A B

C

Source


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

• Attacks from sources to hosts:• Unicast: No implicit protection.

Main reason for Firewalls.

• Multicast: implicit protection• ASM:

Sources can attack groupsNo independent host attacks

• SSM:No attacks by unwanted sourcesTraffic stops at first-hop router

Uni

cast

Ouch

ASM

Join G

RP

SSM

FirstHop

router

Ouch?



• Attacks from sources to network:• Even without receivers• PIM-SM:

(S,G) and (*,G) on FHR and RPState attack!

• Bidir-PIM:No state attack – just traffic !

RP as attackable as unicast(*,G/M) towards RP.Note: IOS IPv4 multicast still creates (*,G) state due to legacyimplementation (except cat6k/c7600).

Asm

/B

idir

Ouch

ASM

/PIM

-SM

RP

FirstHop

router

Ouch!(Ouch?)



• Attacks from receivers!Receivers create stateNo 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 tablesIncrease convergence times

RP

Source(s)

Join

S1,

G1

Join

G2

Join

S2,

G2

1.

2.

State

State

State

State3.



• UnicastCan only (well) filter packets

“ip access-group <acl>”

• MulticastCan stop traffic forwarding by filtering at control plan

Receiver side filtering stops traffic at source

“ip multicast boundary” …

R1

A

Source

e0

R2

R3

R4

IGM

Pm

embe

rshi

pPI

M J

oin

PIM

Joi

nPI

M J

oin

R1

A

Source

e0

R2

R3

R4

IGM

Pm

embe

rshi

p

e0

Filtering:Data-plane only vs. Control Plane


Multicast vs. UnicastScoped Addresses

• Unicast: rfc1918 addressesReuse of host addresses“privacy” for hosts

• Multicast:IPv4: 239.0.0.0 / 8 addressesIPv6: 16 scopes in architectureGeographic form of access control for applications. No per source/receiver controlReuse of ASM group addresses

INTERNETCOMPANY

REGIONSITE

239.192/16SITE

239.192/16

SITE239.192/16

239.193/16

239.194/16224.0.1.0 –

238.255.255.255

Example scopedAddress architecturewith IPv4 multicast


Multicast vs. UnicastApplication Side Difference- Unicast/TCP

• “Admission” control – unicastRelies on congestion control

• Up to 30 times oversubscription

• Works!Time-statistical multiplexing

95% TCP (or like TCP)!

Reliability by retransmission

Sender rate adoption

WRED, DPI, … in network

• Non-real-time / best-effort service

…

……

622 Mbps

155 Mbps

“6 Mbps”x 100

ATM

x 30

LAC/LNS/BRAS


…x 30

Multicast vs. UnicastApplication Side Difference – Multicast/PGM

• PGMMulticast equivalent of TCP

FEC/NAK retransmission

PGM-CC (congestion control)

Match sender rate to slowest receiver. WRED/TCP compatible

• Multicast problemPenalization by slowest receiver!

Fate sharing between receivers

… Ignore too slow receivers

Best with enterprise apps ?

……

6Mbps

x 100

Multicast6 Mbps

Unicast2 Mbps

slowpenalized

penalized


Multicast vs. UnicastApplication 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

Send2^32 different packets

Received FileFEC decode

Receive arbitrary packets

Tran

smitt

erR

ecei

ver

Network with (arbitrary) packet loss…

4 Mbps

x 100

Multicast6 Mbps

Unicast2 Mbps

6 Mbps 6 Mbps

Police=Discardpackets


Multicast vs. UnicastApplication Side Difference- Real-Time Traffic

• Congestion and real-time trafficSmall % 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 trafficE.g.: 100Mbps link, 4Mbps TV

• Can fit up to 25 Flows

• What happens when 26th flow isput onto link ?

All 26 flows become useless

• Problem for unicast (VOD) and multicast (broadcast)

But solutions can differ

…

……


Multicast vs. UnicastSender codec-rate Adoption

• 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

…

……

MulticastHD: 6 Mbps

Unicast2 Mbps

receives2 Mbps

Receives6 Mbps

Receives6 Mbps

MulticastSD: 2 Mbps


Multicast vs. UnicastApplication 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 ServerTV Server

…

A B C D

R1

R2

R3


Multicast vs. UnicastSummary

• Unicast:MUST protect hosts AND network nodes against attackers sending traffic

• MulticastProtect routers/switches against too much state

ASM: MUST protect applications against unwanted sources.

PIM-SM add. control plane protection (DR/RP)

Per flow admission control

Can control application participation and traffic flow due to explicit (*,G), (S,G) easier


Control Plane Security


Control Plane Security

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

• Spoof function (RP, DR, BSR, MA, MSDP-peer)DoS network, participants

• Create administrative boundaries

• Overload router (control plane) CPU

• Create non-permitted stateCovered in access-control section

• Memory (SW) and hardware (state) overloadCovered in admission-control section


Filter for Control Plane PacketsNon-Multicast Specific

• ip receive access-list <ext-acl>

• Filter applied to “received” packetsUnicast 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

• If not available – replace with per-interface ACL!


Filter for Control Plane PacketsNon-Multicast Specific

• Not incoming interface specific!Can not filter per-subscriber or user vs. backbone interfaces

• Usage guideline / examples: Positive list of required control plane packets

Protects against unknown stuff the router may accept without the admin knowing

Negative list of unwanted protocols. E.g.:Unicast PIM packets (not RP / candidate-BSR)!Unicast IGMP packets (non UDLR use)TCP packets to port 639 (MSDP) from non-MSDP peer sources (if MSDP running)


MQC – Modular QoS CLIPolicing (Rate-Limiting) and Shaping of Packets

• MQC: IPv4/IPv6 infrastructure in IOSnot multicast specific – multi purpose

• Police received multicast control plane packets Protection against DoS attacks by large amounts of control plane packets

• Police received data packetsEnforce SLA bandwidth (e.g.: video flows)For aggregate multicast traffic or individual flows

• Not security related:Queue outbound multicast data packets according to diffserv classesShape outbound multicast data packets to control burstynessTag packets with DSCP bits according to application->Diffserv policies


ip access-group extended mc-control-aclpermit ip any 224.0.0.0 0.0.0.255

class-map match-all mc-control-classmatch access-group mc-control-acl

policy-map mc-control-policyclass mc-control-class

police rate 4000000 bpsburst 2500000

conform-action transmit exceed-action drop

!interface Serial0ip address 192.168.2.2 255.255.255.0service-policy input mc-control-policy

ip access-group extended mc-control-aclpermit ip any 224.0.0.0 0.0.0.255

class-map match-all mc-control-classmatch access-group mc-control-acl

policy-map mc-control-policyclass mc-control-class

police rate 4000000 bpsburst 2500000


!interface Serial0ip address 192.168.2.2 255.255.255.0service-policy input mc-control-policy

• As requiredDefine ACLs for reqd. objects

1. Traffic classificationidentify traffic andassign to classes

2. Define the Diffserv policyAssign classes to a policyDefine the Diffserv treatment for each class

3. Attach the Diffserv policy to a logical/physical interface

The point of application of a QOS policy

MQC – Modular QoS CLIThree Tier CLI Hierarchy

• Example: Rate-limit aggregate of all multicast control packet into router to 4 Mbps (~5000 packets/sec @ 100 byte packets) – 5 sec burst.


MQC – Modular QoS CLIThree Ways to Use MQC

• Explicit service policies on interfacesstandard case

• Microflow-policingAutomatic creation of service policies for individual flows

• CoPP - Control Plane PolicingApply to control plane packets (policing only)

Same rules as for ip receive acl

Control-Plane

Establishes context like “Interface”, but allows only MQC commands afterwards


Interface Filtering and Rate-Limitingon Control Packets

• Full throttle paranoia: HW-filter unwanted control packets, and HW-rate limit required ones (e.g.: DHCP, IGMP). Limit IGMP state.

Per-interface filter because of backbone interfaces

Per-interface rate-limiting to isolate amongst multiple users

ip access-list extended no-control-indeny pim any any ! Protect CPU against unwanted protocolsdeny ospf any any ! Run on router !permit igmp any host 224.0.0.22 ! Only IGMPv3deny igmp any anypermit ip any any

access-list 101 permit any host 255.255.255.255 ! E.g.: DHCP requestsaccess-list 101 permit any 224.0.0.0 0.0.0.255 ! E.g.: IGMP membershipsAccess-list 101 permit any host 192.189.1.1 ! Interface addr of router

Interface ethernet 0 ! User facingip access-group no-control-in in

ip igmp version 3ip igmp limit 2 ! Allow 2 STBsrate-limit input access-group control-packets 8000 1500 200


ip access-list extended no-control-indeny pim any any ! Protect CPU against unwanted protocolsdeny ospf any any ! Run on router !permit igmp any host 224.0.0.22 ! Only IGMPv3deny igmp any anypermit ip any any

access-list 101 permit any host 255.255.255.255 ! E.g.: DHCP requestsaccess-list 101 permit any 224.0.0.0 0.0.0.255 ! E.g.: IGMP membershipsAccess-list 101 permit any host 192.189.1.1 ! Interface addr of router

Interface ethernet 0 ! User facingip access-group no-control-in in

ip igmp version 3ip igmp limit 2 ! Allow 2 STBsrate-limit input access-group control-packets 8000 1500 200



IGMP/MLD Packets

• IPv6: MLD uses ICMPv6 protocol type packets

• IPv4: IGMP is a 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 & prune

Good:

mtrace – multicast equiv. 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!

Memberships: Only with IGMPv3

• Forged query packetsLower version: inhibit SSM, leave-latency

Bursts: response storms

• Forged (multicast) membership reportsNot a problem !?


IGMP/MLD Protocol PacketsThe L3 vs. L2 Problem

• Forged queries:Need inhibit that other hosts receive it!

• Forget membership reportsForge IP address of other hostRouter can not validate identity of hosts !

• L2 - per-port control required for these• Per-LAN vs. per port access/admission control

Multicast IGMP/MLDControl Packets L2 switch


IGMP PacketsExample Extended ACL for Various IGMP Packets

• http://www.iana.org/assignments/igmp-type-numbers• Numeric ‘port’ <n> = IGMP type number 0x1<n>

ip access-list extended control-packets…deny igmp any any pim ! No PIMv1deny igmp any any dvmrp ! No DVMRP packetsdeny igmp any any host-query ! Do not use with redundant routers !

permit igmp any host 224.0.0.22 ! IGMPv3 membership reportspermit igmp any any 14 ! Mtrace responsespermit igmp any any 15 ! Mtrace queries permit igmp any 224.0.0.0 15.255.255.255 host-query ! IVMPv1/v2/v3 queriespermit igmp any 224.0.0.0 15.255.255.255 host-report ! IGMPv1/v2 reportspermit igmp any 224.0.0.0 15.255.255.255 7 ! IGMPv2 leave messagesdeny 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 0ip access-group control-packets in ! Could put filter here too

ip access-list extended control-packets…deny igmp any any pim ! No PIMv1deny igmp any any dvmrp ! No DVMRP packetsdeny igmp any any host-query ! Do not use with redundant routers !

permit igmp any host 224.0.0.22 ! IGMPv3 membership reportspermit igmp any any 14 ! Mtrace responsespermit igmp any any 15 ! Mtrace queries permit igmp any 224.0.0.0 15.255.255.255 host-query ! IVMPv1/v2/v3 queriespermit igmp any 224.0.0.0 15.255.255.255 host-report ! IGMPv1/v2 reportspermit igmp any 224.0.0.0 15.255.255.255 7 ! IGMPv2 leave messagesdeny 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 0ip access-group control-packets in ! Could put filter here too

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


PIM Packets – Multicast

• Multicast PIM Control Packets : Hello, Join/Prune, Assert, Bootstrap, DF-electAll are link local multicast (TTL=1)All are multicast to All-PIM-Routers (224.0.0.13)

• Attacks must originate on the same subnetForged Join/Prune, Hello, Assert packet.

MulticastPIM 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!

RPDR

UnicastPIM 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!

• Attacks can originate from anywhere!

MAC-RP

MulticastC-RP Announce Packets

PIM-SM Domain

MulticastDiscovery Packets


PIM Neighbor Control

• Must receive Hellos to establish PIM neighborDR election, failover

Accept / Send PIM Join/Prune/Assert

• Use ip pim neighbor filter to inhibit neighborsFilters all PIM packets from non-allowed sources

Hellos, J/P, BSR, … !

PIM Hellos

rtr-a rtr-b

10.0.0.210.0.0.1

ip multicast-routingip pim sparse-modeip multicast-routing

access-list 1 permit 10.0.0.2Access-list 1 deny any

Interface e0ip pim sparse-modeip pim neighbor-filter 1

ip multicast-routingip pim sparse-modeip multicast-routing

access-list 1 permit 10.0.0.2Access-list 1 deny any

Interface e0ip pim sparse-modeip pim neighbor-filter 1

PIM Hellos


AutoRP ControlRP 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-RP10.0.0.2

D

MA# show ip pim rp mappingThis 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), PIMv1Info source: 10.0.0.1 (Rtr-C)

MA# show ip pim rp mappingThis 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), PIMv1Info source: 10.0.0.1 (Rtr-C)

C

MA

A

Announce

RP = 10.0.

0.1

Group-Ran

ge = 22

4.0.0.

0/4

Holdtime =

180 s

ec

ip pim rp-announce-filter rp-list 1 group-list 2

access-list 1 permit 10.0.0.1access-list 1 permit 10.0.0.2access-list 2 permit 224.0.0.0

15.255.255.255

ip pim rp-announce-filter rp-list 1 group-list 2

access-list 1 permit 10.0.0.1access-list 1 permit 10.0.0.2access-list 2 permit 224.0.0.0

15.255.255.255


Auto-RP ControlConstrain Auto-RP Messages

• AutoRP packets:224.0.1.39 (RP-announce), 224.0.1.40 (RP-discover)

PIMDomain

PIMDomain

NeighboringPIM Domain

BorderRouter

BorderRouter


RP Discover RP Announce

MAS0 S0

Need to Block AllAuto-RP Messagefrom Entering or Leaving Network

Need to Block AllAuto RP Message fromEntering/Leaving Network

interface s0ip multicast boundary 1

access-list 1 deny 224.0.1.39access-list 1 deny 224.0.1.40



A B






BSR ControlConstrain BSR Messages

• ip pim bsr-borderFilters messages (multicast) from BSR

no ACL possible (hop by hop forwarded)

PIMDomain

PIMDomain


BorderRouter

BorderRouter


BSR Msgs BSR MsgsBSRS0 S0

Need to Block AllBSR Message fromEntering/Leaving Network

Need to Block AllBSR Message fromEntering/Leaving Network

Interface S0ip pim bsr-border


BA




Protection Against Attackson Access Networks

• Attacks by hosts (multicast)PIM Hellos – become DR – no traffic forwarded to LAN

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 !


Protection Against Attackson Access Networks

• ip pim multicast boundary - filter AutoRP (not PIM) –

• ip pim rp-address override - not using AutoRP / BSR

• Non-redundant access-networkip pim announce-filter acl-noneMulticast only: need to add filtering on RP/BSR

ip access-group acl-deny-all-pim in

• Redundant access-networksAllow PIM from redundant neighbor.Need L2 mechanisms to inhibit forged packets !

Add ip pim bsr-border - group-mapping attacks


PIM Control PlaneMissing Simplifications / Improvements

• Disable AutoRP operations on router

• Disable BSR operations on router

• Disable RP operations on routerFunctions not running can not be attacked

• And/Or:

• Authentication for PIM / AutoRP messagesDifferentiate PIM / AutoRP messages from forged

Without knowledge of IP addresses of legal peers

Possible with IPsec for multicast (later slides)

Not easy to configure yet though


MSDP MD5 Password Authentication

• Protect MSDP peering against spoofed packetsProtects against spoofed sourced packetsPartial protect against man-in-middle

• Uses RFC2385 TCP authentication headerDefined for BGPActually independent of BGP

MSDP MD5 PeeringPasswd “cisco”

10.0.0.2

10.0.0.1

ip msdp peer 10.0.0.2ip msdp password peer 10.0.0.2 0 cisco

ip msdp peer 10.0.0.2ip msdp password peer 10.0.0.2 0 cisco R1

R2Spoofed MSDP PeeringAttempt to bring down

Existing peering

“DoS”



10.0.0.1


SAP / SDP / SDR

• 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

• RecommendationDo no enable!

unless considered important to troubleshoot

If enabled, use CoPP to rate-limit


Other Control Plane Security Features

• ip multicast mrinfo-filter <std-acl>Limit mrinfo answers to specific requesters


Access ControlIncludes Scoping


Access ControlOverview

• Control which ASM groups and SSM channels systems (hosts or subscribers) can send and/or receive traffic for

• ip access-group / ipv6 traffic-filter

• ip pim accept-register / ipv6 pim pim accept-register

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

• Ip multicast group-range / ipv6 multicast group-range

• ip multicast boundary / ipv6 multicast boundary


ip access-list extended sourcepermit ip host 10.0.0.0 0.255.255.255 239.0.0.0 0.127.255.255deny ip any 224.0.0.0 15.255.255.255 logdeny ip any any log

interface ethernet0ip address 10.1.1.1 255.255.255.0 ip access-group source in

ip access-list extended sourcepermit ip host 10.0.0.0 0.255.255.255 239.0.0.0 0.127.255.255deny ip any 224.0.0.0 15.255.255.255 logdeny ip any any log

interface ethernet0ip 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 rangeand to a well known group

range

NetworkEngineer

DA = 239.244.244.1SA = 10.0.1.1

DA = 239.10.244.1SA = 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 – egress filtering best at multicast routing


Host Receiver Side Access Control

• Filter group/channels inIGMP/MLD membership reports

Controls entries into IGMP/MLD cacheExtended ACL semanticslike multicast boundaryDeny only effective if protocol = ipIGMPv2/MLDv1 reports:

source = 0.0.0.0 / 0::0

H2224.1.1.1

Report

225.2.2.2

Report

H2

ip access-list extended allowed-multicastpermit ip any host 225.2.2.2 ! Like simple ACLpermit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255deny ip any any

interface ethernet 0ip igmp access-group allowed-multicast

ip access-list extended allowed-multicastpermit ip any host 225.2.2.2 ! Like simple ACLpermit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255deny ip any any

interface ethernet 0ip igmp access-group allowed-multicast

ip igmp access-group / ipv6 mld access-group


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 10access-list 10 permit 192.16.1.1

ip pim accept-register list 10access-list 10 permit 192.16.1.1 RP

Unwanted Sender

Source TrafficR

egis

ter

Register-Stop

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 multicast group-range <std-acl> (future)

• ipv6 multicast group-range <std-acl> (12.4T)

• Disable all operations for groups denied by <acl>Drop / ignore group in all control packets.

PIM, IGMP, MLD, MSDP.

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

Drop all data packets.

HW-discarding platform dependent


Interface / Protocol Level Access ControlOverview

• IPv4: per-interface either or all of A, B ,C (one each)A: ip multicast boundary <std-acl> [ filter-autorp ]

Group scope boundaries Semantic filtering of AutoRP messages

B: ip multicast boundary <ext-acl> inC: ip multicast-boundary <ext-acl> out

Extended form for access-control, SSM scopes

• IPv6: per-interface one config of AA: ipv6 multicast boundary scope <n>

Scoping simple due to IPv6 architectureNo B, C options (yet)


Interface / Protocol Level Access ControlIPv4 Scope Boundaries

• Configure on interfaces passing the (imaginary) scope boundary line

• Protocol filtering for denied groupsIGMP / PIM

• On inside and outside routers

• Use filter-autorp option when using AutoRP

No equivalent for BSR (yet)

SITE scope:239.192.0/16R2

R1

R3

R4

R5

REGION zone:239.193.0/16

access-list 10 deny 239.192.0.0 0.0.255.255access-list 10 permit any

Interface ethernet 0ip multicast boundary 10 [ filter-autorp ]

access-list 10 deny 239.192.0.0 0.0.255.255access-list 10 permit any

Interface ethernet 0ip multicast boundary 10 [ filter-autorp ]

e0


Interface / Protocol Level Access ControlIPv6 Scope Boundaries

• Scope addresses fixed by architecture

• Boundary for scope <n> always also filters scope 2..<n-1> addresses.

Larger scope may not cut through smaller scope.

• ACL for scope implicitly defined:

SITE scope: 5R2

R1

R3

R4

R5

REGION zone: 7

Interface ethernet 1ipv6 multicast boundary scope 7

Interface ethernet 1ipv6 multicast boundary scope 7

e1

ipv6 access-group standard scope7filterpermit ff02::00 00f0::00 ! Always permitteddeny ff03::00 00f0::00 ! Deny up to and… ! Including scope 7deny ff07::00 00f0::00 ! permit ff08::00 00f0::00 ! Permit higher… ! scopespermit ff0f:000 00f0::00 !

ipv6 access-group standard scope7filterpermit ff02::00 00f0::00 ! Always permitteddeny ff03::00 00f0::00 ! Deny up to and… ! Including scope 7deny ff07::00 00f0::00 ! permit ff08::00 00f0::00 ! Permit higher… ! scopespermit ff0f:000 00f0::00 !


Interface / Protocol Level Access Control Shape and Structure of Scopes

• Scopes must be convex. Traffic between source/receivers must not cross scope boundary.Property of topology AND metric

• Scopes contained in larger scopes?Only mandatory in IPv6 archScope expanding ring searchSmaller scopes subset of larger scopes(IPv4, historical)

• Recommendations IPv4Define IPv4 scopes as non-overlapping ranges.

R1

R2

R3

R5

R4

Picture:Non-convex scope


R1Src1

Src2 Rcv

RcvScope5 zone 1

Scope 5zone 2

RP1

RP2(zone2,*,G)

• IPv6 arch: scope boundaries cut through router !draft-ietf-ipngwg-addr-arch-v3-11.txt

• IOS / IOS-XR:ALWAYS for link-local scopeNEVER for larger scopes

Scope boundaries only cut through links!

NOT SUPPORTED

(zone1,*,G)

Interface / Protocol Level Access Control Location of Scope Boundaries

R1

Scope 1 (link scope)“zone 1” (serial0)

Scope 1 (link scope)“zone 2” (ethernet0)

s0

e0

SUPPORTED


Interface / Protocol Level Access Control Filtering Rules (1)

• Filter IGMP/PIM messages and create filtered state

• OIF (“out”) case: Discard IGMP/PIM “join” for egress denied (*,G)/(S,G) state. Do not create state.

• IIF (“in”) cases:(1) Force OIF of mroute state to NULL if state denied on RPF-interface. No joins sent on RPF-interface

(2) Directly connected traffic: discarded state with NULL OF list. Also inhibits PIM-SM registering.

IGMP/MLD/PIMJoin/membership G

IGMP/MLD/PIMJoin/membership G

E.g.: to RP

OIF case IIF case (1)

Multicast (S,G) packet

IGMP/MLD/PIM join

IIF case (2)


Interface / Protocol Level Access Control Filtering Rules (2)

• PIM-DM: Do not flood on egress boundary. Send prune on ingress boundary

• PIM-SM/SSM/DM: State creation by directly connected sources.

Not Catalyst-6500/Cisco-7600 (IPv4). Boundary-acl also filters packets.

• Bidir-PIM: May not inhibit upstream traffic with multicast boundary

For Bidir-PIM groups, use “ip multicast boundary” AND “ip access group”.

R1

RP

Picture:Boundaries

and Bidir problem


Interface / Protocol Level Access Control AutoRP Filtering

Scope boundary – use filter-autorp• Group ranges intersecting denied ranges in

ACL are removed from RP-Discovery/Announce messages at boundary

INTERNET

COMPANY

REGION

SITE239.192/

16

SITE239.192/

16

SITE239.192/

16

239.193/16

239.194/16

224.0.1.0 –238.255.255.255

Access-list standard internet-boundarydeny host 224.0.1.39deny host 224.0.1.40deny 239.0.0.0 0.255.255.255

Interface ethernet 0ip multicast boundary internet-boundary

Access-list standard internet-boundarydeny host 224.0.1.39deny host 224.0.1.40deny 239.0.0.0 0.255.255.255

Interface ethernet 0ip multicast boundary internet-boundary

• Domain Boundary

Access-list standard regiondeny 239.193.0.0 0.255.255.255

Interface ethernet 0ip multicast boundary region filter-autorp

Access-list standard regiondeny 239.193.0.0 0.255.255.255

Interface ethernet 0ip multicast boundary region filter-autorp

RP


Interface / Protocol Level Access Control Separate In/Out Filtering

• ip multicast boundary <ext-acl> inIIF only - To inhibit traffic received on the interface

• ip multicast boundary <ext-acl> outOIF only – Inhibit replication to the interface

• Extended ACLCan filter each (*,G) and (S,G) state differentlySupport SSM per-channel filtering.

• Inbound traffic must be permitted by bothip multicast boundary acl andip multicast boundary ext-acl in

• Outbound traffic must be permitted by both ip multicast boundary acl andip multicast boundary ext-acl out


Interface / Protocol Level Access Control Semantics of Extended ACLs

• 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!

• Reuse ACL with ip access-group• [4] Src = 0.0.0.0 = *

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

Ip access-list extended ext-acldeny 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]

Interface ethernet 0ip multicast boundary ext-acl outip access-group ext-acl out

Ip access-list extended ext-acldeny 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]

Interface ethernet 0ip multicast boundary ext-acl outip 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 !

Also inhibit admin-scope addrs.

MSDP

RP/MSDP

Enterprise

ISP1

MSDP

…

ISP1

ip access-list extended interdomain-sm-edgedeny ip host 0.0.0.0 anydeny ip any 239.0.0.0 0.255.255.255 permit ip any any

Interface ethernet 0ip multicast boundary interdomain-sm-edge outip multicast boundary interdomain-sm-edge in

ip access-list extended interdomain-sm-edgedeny ip host 0.0.0.0 anydeny ip any 239.0.0.0 0.255.255.255 permit ip any any

Interface ethernet 0ip multicast boundary interdomain-sm-edge outip multicast boundary interdomain-sm-edge in


Interface / Protocol Level Access Control Example: Subscriber Interfaces

• ip multicast boundary ext-acl outsupersedes 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

• Rule of thumb: Output: State based control

Input: State {+ packet} control

H1

Subscriber 1

H1

Subscriber 2

H1

PIM

Provider

Edge Router

IGMP

SourcedPackets


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 SSMNot supported by all vendors

• SSM (S/M, G/M) scopes: A/M = loopback of MVPN-PE232.x.0.0 = MVPN Default & Data-MDTsUse (S/M,G/M) scope filter on P links facing Internet-PE (non-MVPN)Result:

Full Internet SSM transitProtected MVPN service

P-Core

InternetBcast-Video

PE

InternetBcast-Video

PE

MVPNPE

MVPNPE

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

M w

ith 2

32.0

.0.0

/8


Access ControlRecommended Interdomain MSDP SA Filter

http://www.cisco.com/warp/public/105/49.html

! domain-local applicationsaccess-list 111 deny ip any host 224.0.2.2 ! access-list 111 deny ip any host 224.0.1.3 ! Rwhodaccess-list 111 deny ip any host 224.0.1.24 ! Microsoft-ds access-list 111 deny ip any host 224.0.1.22 ! SVRLOCaccess-list 111 deny ip any host 224.0.1.2 ! SGI-Dogfightaccess-list 111 deny ip any host 224.0.1.35 ! SVRLOC-DAaccess-list 111 deny ip any host 224.0.1.60 ! hp-device-disc!-- auto-rp groupsaccess-list 111 deny ip any host 224.0.1.39 access-list 111 deny ip any host 224.0.1.40!-- scoped groupsaccess-list 111 deny ip any 239.0.0.0 0.255.255.255!-- loopback, private addresses (RFC 1918)access-list 111 deny ip 10.0.0.0 0.255.255.255 anyaccess-list 111 deny ip 127.0.0.0 0.255.255.255 anyaccess-list 111 deny ip 172.16.0.0 0.15.255.255 anyaccess-list 111 deny ip 192.168.0.0 0.0.255.255 anyaccess-list 111 permit ip any any!-- Default SSM-range. Do not do MSDP in this rangeaccess-list 111 deny ip any 232.0.0.0 0.255.255.255access-list 111 permit ip any any

! domain-local applicationsaccess-list 111 deny ip any host 224.0.2.2 ! access-list 111 deny ip any host 224.0.1.3 ! Rwhodaccess-list 111 deny ip any host 224.0.1.24 ! Microsoft-ds access-list 111 deny ip any host 224.0.1.22 ! SVRLOCaccess-list 111 deny ip any host 224.0.1.2 ! SGI-Dogfightaccess-list 111 deny ip any host 224.0.1.35 ! SVRLOC-DAaccess-list 111 deny ip any host 224.0.1.60 ! hp-device-disc!-- auto-rp groupsaccess-list 111 deny ip any host 224.0.1.39 access-list 111 deny ip any host 224.0.1.40!-- scoped groupsaccess-list 111 deny ip any 239.0.0.0 0.255.255.255!-- loopback, private addresses (RFC 1918)access-list 111 deny ip 10.0.0.0 0.255.255.255 anyaccess-list 111 deny ip 127.0.0.0 0.255.255.255 anyaccess-list 111 deny ip 172.16.0.0 0.15.255.255 anyaccess-list 111 deny ip 192.168.0.0 0.0.255.255 anyaccess-list 111 permit ip any any!-- Default SSM-range. Do not do MSDP in this rangeaccess-list 111 deny ip any 232.0.0.0 0.255.255.255access-list 111 permit ip any any


Admission Control


Admission ControlGoals

• Protect router from control plane overloadState (HW, memory), CPU

DoS not to affect non-multicast services

• Resource allocationPer subscriber (VRF, interface)

DoS not to affect multicast to other subs.

Limit subscriber resources to SLA

• Call admission controlProtect bandwidth resources (interfaces, subnets) from congestion

Content / Subscriber based policies


Admission ControlGoals and Means (Tools)

Router global control plane CoPP

Per VRF, interface, neighbor control planeMroute-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

GOALSProtect router from control plane overloadFair/SLA based router resource allocationBandwidth based Call admission control

MEANSF

- Yes, W – Workaround , F - Future

W W


Admission ControlGlobal / 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 1460ip 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

%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 countIP Multicast Statistics1460 routes using 471528 bytes of memory404 groups, 2.61 average sources per group

rtr-a> show ip mroute countIP Multicast Statistics1460 routes using 471528 bytes of memory404 groups, 2.61 average sources per group

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


Admission ControlMSDP Control Plane

• ip msdp sa-limit <peer> <limit>

• Limit #SA states accepted from MSDP peer

• Simple recommendations: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 that won’t overload router

Tran

sit a

ll SA

ISP

EnterpriseCustomer1

EnterpriseCustomer2

ISP2

ISPPeer2

ISPPeer2

Large #SA Large #SA

Small #SA

MSDP peerings

Small #SA


State / Call Admission ControlTerminology

• 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 forwhole branch of the tree

(RP)


Admission ControlHost Receiver Side 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 cache

ip access-list extended channel-guidespermit ip any host 239.255.255.254 ! SDR announcementsdeny ip any any

ip igmp limit 1 except channel-guides

interface ethernet 0ip igmp limit 2 except channel-guides

ip access-list extended channel-guidespermit ip any host 239.255.255.254 ! SDR announcementsdeny ip any any

ip igmp limit 1 except channel-guides

interface ethernet 0ip igmp limit 2 except channel-guides


Example Usage of igmp LimitAdmission Control on Agg-DSLAM Link

PE

10GE

1GE

250-500 users per DLAM

1GE

DSLAM

DSLAM

DSLAM

Cat7600

4. 500Mbps/4Mbps = 125 IGMP states

IGMP/MLD =Receiver side only

No PIM

3. Gbps link to DSLAM500 Mbps for TVrest for Internet etc.

Multicast V

ideo (50%)

Voice, Internet &

VoD (50%)

PE

2. 4Mbps each

300 channels x 4Mbps = 1.2Gbps > 1GE

1. 300 SDTV channels

300 SDTV channels1GE

interface Gig0/0description Interface towards DSLAMip igmp limit 125

interface Gig0/0description Interface towards DSLAMip igmp limit 125


Per Interface mroute Limits

• ip multicast limit [ rpf | out | connected ] <ext-acl> <max>

• Per interface mroute state (PIM/IGMP)

• Input: Rpf,connected = (S,G) with S connected

• Output: Out

• Multiple limits allowed per interface

• Each establishes one limiter

• Input / Output state accounted against first limiter permitting state in <ext-acl>

S1,G1

MulticastLookup/ingress statesAccounted against s0

Ingress (rpf/connected)

MulticastEgress/Replicationstates, accounted

Against s1, s2 egress (out)

s2s1

s0


Per Interface mroute Limits

• Control plane similar to ip multicast boundarySame IIF,OIF PIM, IGMP filtering if flow denied

• Denied input multicast boundary creates OIF=0 flow stateProtect best against unwanted packets

• Denied input multicast limit does not create stateProtect against state creation!

Use CoPP to protect against unwanted packets

• Limits state, not calls (*,G) and (S,G) counted !• Emulate boundary with multicast limit!

ip multicast boundary <ext-acl> outip multicast limit out <not-ext-acl> 0

Need to invert <ext-acl>


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

10GE

1GE

1GE

DSLAM

DSLAM

DSLAM

Cat7600

Generic interface multicast routelimit feature with support for

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

1. 300 SD channels

250-500 users per DLAM

300 channels offered

2. 4 Mbps

300 channels x 4Mbps = 1.2Gbps

Gig0/0

6. Basic 75 statesPremium 25 statesGold 25 states

1GE

4. 500 Mbps for TVMultic

ast Video (5

0%)

Voice, Internet &

VoD (50%)

5. 60%/300Mbps Basic 20%/100Mbps Extended20%/100Mbps Premium

PE

3. Basic, Extended, Prem.bundles 100 channels ea

Basic (100 channels)

Premium (100 channels)

Gold (100 channels)

interface Gig0/0description Interface towards DSLAMip multicast limit out 75 acl-basic ip multicast limit out 25 acl-extip multicast limit out 25 acl-premium

interface Gig0/0description Interface towards DSLAMip multicast limit out 75 acl-basic ip multicast limit out 25 acl-extip multicast limit out 25 acl-premium


Bandwidth Based CAC

• ip multicast limit cost <ext-acl> <multiplier>

• Cost (<multiplier>) of states in ip multicast limit

• Global configuration, multiple possible

• Use first limit cost with <ext-acl> permitting state

• UsageSet multipliers to Mbps/kbps of flows

Set up address plan to include bandwidth

Allow to add flows later without changing config

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

PIM-SM: count only (*,G): (multiplier=0 for S,G…)


3. Fair sharing of bandwidth

1GE

Multicast Call Admission Control :Cost Factor for per-interface Mroute State Limits

1GE

1GE

250-500 usersper DLAM

DSLAM

DSLAM

DSLAM

Cat7600

Example CAC use:

4. 250 Mbps for each CP250 Mbps Internet/etc

1. Three CPs

10GE

10GE

10GE

ContentProvider 1

ContentProvider 2

ContentProvider 3

ContentProviders

ServiceProvider

PayingCustomers

2. Different BW:

- MPEG2 SDTV: 4 Mbps - MPEG2 HDTV: 18 Mbps - MPEG4 SDTV: 1.6 Mbps - MPEG4 HDTV: 6 Mbps

MPEG4 SDTV

MPEG2 SDTVMPEG4 SDTV

MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

CP-1 (250Mbps)

CP-2 (250Mbps)

CP-3 (250Mbps)

Voice/Int/V

oD (250Mbps)

5. Simply add global costs

PE

! Global ip multicast limit cost acl-MP2SD-channels 4000 ! from any providerip multicast limit cost acl-MP2HD-channels 18000 ! from any providerip multicast limit cost acl-MP4SD-channels 1600 ! from any providerip multicast limit cost acl-MP4HD-channels 6000 ! from any provider!interface Gig0/0description --- Interface towards DSLAM ---... ! CACip multicast limit out 250000 acl-CP1-channelsip multicast limit out 250000 acl-CP2-channelsip multicast limit out 250000 acl-CP3-channels …

! Global ip multicast limit cost acl-MP2SD-channels 4000 ! from any providerip multicast limit cost acl-MP2HD-channels 18000 ! from any providerip multicast limit cost acl-MP4SD-channels 1600 ! from any providerip multicast limit cost acl-MP4HD-channels 6000 ! from any provider!interface Gig0/0description --- Interface towards DSLAM ---... ! CACip multicast limit out 250000 acl-CP1-channelsip multicast limit out 250000 acl-CP2-channelsip multicast limit out 250000 acl-CP3-channels …


Most Simple Recipe forRunning IP Multicast ?


Secure Best-Effort SSM Multicast

• Best effort – no business critical application running

• Secure – protect to be ~comparable to unicast

• Simple config – run without monitoring ?!

ip multicast-routingip pim ssm defaultno ip dm-fallbackip multicast route-limit 1000 900ip igmp limit 100

! All interfacesinterface ethernet 0ip pim sparse-mode

ip multicast-routingip pim ssm defaultno ip dm-fallbackip multicast route-limit 1000 900ip igmp limit 100

! All interfacesinterface ethernet 0ip pim sparse-mode


AAA1 Integrationfor IP Multicast

1 Authentication, Authorization, Accounting


Service Edgeand 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/SwitchesConnects to receiver

IP MulticastDelivery Network

SP/enter edge router

Access Router(DSL, Cable, …)

L2 AccessDevice

switch, DSLAM,..

AAA Servere.g.: Radius

TV with STB

Desktop PC

Customer EdgeRouter

PIM

MLDIGMP

Video source(e.g.: Camera with

MPEG encoder)

First Hop SP Edge RouterConnects to Source directly or indirectly


Service EdgeWithout 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 modelsfor IP Multicast

• AuthenticationBy interfaceBy subscriber (PPP links)

• AuthorizationManual (previous slide)Radius/Tacacs provisioningJoin/Membership authorization (FUTURE)

• AccountingDynamic accounting via RadiusNetflow support for IP multicastPolling of MIB counterApplication level (e.g.: STB)

Not usually considered to be part of AAA


AAA ModelsRadius/Tacacs Provisioning

! Basic Serviceip access-list standard basic-servicepermit 239.192.1.0 0.0.0.255 ! Basic service channels

!Premium Serviceip access-list standard premium-servicepermit 239.192.1.0 0.0.0.255 ! Basic service channelspermit 239.192.2.0 0.0.0.255 ! Premium service channels

! Premium Plus Serviceip access-list standard premium-plus-servicepermit 239.192.1.0 0.0.0.255 ! Basic service channelspermit 239.192.2.0 0.0.0.255 ! Premium service channelspermit 239.192.3.0 0.0.0.255 ! Premium Plus service channels

! Just all multicast groupsIp access-list standard all-groupspermit 224.0.0.0 15.255.255.255

! Basic Serviceip access-list standard basic-servicepermit 239.192.1.0 0.0.0.255 ! Basic service channels

!Premium Serviceip access-list standard premium-servicepermit 239.192.1.0 0.0.0.255 ! Basic service channelspermit 239.192.2.0 0.0.0.255 ! Premium service channels

! Premium Plus Serviceip access-list standard premium-plus-servicepermit 239.192.1.0 0.0.0.255 ! Basic service channelspermit 239.192.2.0 0.0.0.255 ! Premium service channelspermit 239.192.3.0 0.0.0.255 ! Premium Plus service channels

! Just all multicast groupsIp access-list standard all-groupspermit 224.0.0.0 15.255.255.255

• Consider manual global CLI configs


AAA ModelsRadius/Tacacs Provisioning

• PPPoX interface support with AAAUser-ID based authentication. Not specific to multicast.Radius server dependent: reuse profiles

• Multicast AAAaaa 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”

! 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 ModelsAuthentication with Radius Provisioning

User Access Router AAA Server

PPP AuthenticationAAA Authentication(usr,passwd,port)

Authentication Result

(Port, Mcast config profile)

PPPoXconnection

interface Fa0/1ipv6 mld limit 3 ! Three STB’sipv6 mld access-group premium-serviceipv6 multicast aaa accounting receive <acctacl> delay 10

First membershipAAA Authentication(interface name)

Non PPPconnection



Authentication

AAA Authentication(usr,passwd,port)

Authentication Result

(Port, Mcast config profile)

IGMP/MLD ReportIGMP/MLD Report

Accept Deny

Accept Deny

Triggered profile pushChange inprofile

AAA ModelsChanging User Profiles from Radius/Tacacs Provisioning


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 flowsWhen first joined on an interface (START)

When stopped being forwarded on interface (STOP)

FUTURE: Periodically, with counters

• Avoid many accounting record during zappingSend START record only throttle-seconds after join


AAA Receiver Accounting


MLD/IGMP ReportAAA Accounting Start(usr-IP/mac, channel)

MLD/IGMP LeaveMLD/IGMP Report AAA Accounting Stop(usrIP/mac, channel)AAA Accounting Start(usrIP/mac, channel)

AAA Accounting Interim(usrIP/mac, channel)With possible configurable delay as a throttling mechanism in the face of channel surfing


AAA Models FUTUREPer Join/Membership Authorization

• Allows dynamic AAA server based policiesMore flexible and expensive than provisioning basedFrequently changing policies (PPV,…)Admission control: With tracking of existing membershipsScalability via cache-timeout in AAA server replies

• Potential to combine models:Whitelist: AAA provisioning permits always allowed servicesGreylist: per join/membership authorization only invoked for requests not permitted by whitelist

E.g.: PPV, ..Maximizes scalability


AAA Models FUTUREPer Join/Membership Authorization


Authorization Result

IGMP/MLD Report

Accept Deny

Report Authorization(usrmac,channel)

Authorization Result

IGMP/MLD Report

Accept Deny

Report Authorization(usr-mac,channel)


Firewalls


Firewalls and MulticastOverview

• Firewall function is not NATFirewall and NAT often collocated

IOS: Source NAT and limited src/grp NAT

• IOS Firewall: specific firewall feature setNo multicast support requirements identified

Coexistence good enough!

• Firewall devices/appliances: (PIX, ..)Add IP multicast routing to device

And similar access control as IOS


Cisco IOS Firewall

• UnicastMostly 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 policiesIgnores multicast traffic (passes through)

• MulticastNo important control plane driven multicast flow setup identified / required by customers (so far)Use multicast access-control to permit multicast applications:

ip multicast boundary, …Safe because (you should know this now):

Multicast flows stateful, explicit joinFull control of flows with existing control mechanisms


PIX FirewallsOverview

• PIX Firewall pre v7.0IGMPv2 proxy routing only (for edge PIX)

• PIX Firewall v7.0PIX 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


PIX MulticastFeature SUMMARY (Incomplete)

• Multicast Support in PIXOS 7.0

• IGMP SupportStub multicast routing – IGMP Proxy Agent

IGMPv2, access group, limits

• PIM SupportPIM Sparse Mode, Bidirectional, SSM

DR Priority

Accept Register Filter

Multicast Source NAT

• 515, 525, 535 and ASA platforms


PIX MulticastCandidate Future Features

• Planned Multicast Support in PIXOS 7.2Multicast Boundary with autorp filter

PIM Neighbor filters

PIM Bidir Neighbor filters

• Future Support ? IGMPv3/SSM

IPv6 Multicast

Stateful MSDP inspection

MSDP

• FSWM 3.1 will support multicast similar to PIXOS 7.0


IPsec and Multicast


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

Permits to encrypt IP multicast trafficavoids RPF issues with crypto-map based IPsec

• “Secure Multicast” (12.4(6)T)

Transparent “tunnel mode” en/decryption

Inhibits need for overlay network

Allows to apply IPsec to both multicast data traffic and control plane traffic (e.g.: PIM)

GDOI--Key distribution mechanism (RFC3547)

Manual keying still available


Legacy behavior for IPsec multicast

• Not supported for multicast, broken!• Security associations (SA) - Rtr1/Rtr3 and Rtr2/Rtr3.• “tunnel mode” (unicast) encapsulated Rtr3->Rtr1, Rtr3->Rtr1• Broken because (lots of reasons):

Rtr1/Rtr2 do not see Rtr3 as PIM neighbors, but Rtr4Sending PIM joins to Rtr4 ineffective, Replication on Rtr3 ineffective, …Would require hacks/NBMA mode interaction on Rtr3, etc…

Rtr 1

Rtr 2Rcvr1

Rcvr2

Traffic flowRtr 3

Rtr 4Encrypt crypto-mapDecrypt crypto-map

Rtr1/Rtr3 SA

Rtr2/Rtr3 SA


Working P2P tunneling multicast with IPsecTunnels with explicit tunnel interfaces

• GRE tunnel Rtr1/Rtr3 and Rtr2/Rtr4Apply IPsec encryption only to GRE (unicast) traffic

Used by (for example) DMVPN solution

Also scales: Hub (Rtr3) can use single multipoint tunnel interface to support hundreds/thousands of spokes

Rtr 1

Rtr 2Rcvr1

Rcvr2

Traffic flowRtr 3


Rtr1/Rtr3 SA

Rtr2/Rtr3 SATunnel

Tunnel


Working P2P tunneling multicast with IPsecUse tunnels with explicit tunnel interfaces

• New: IPsec tunnel interfaceLooks like GRE tunnel to IP multicastDoes not replace GRE for DMVPN

GRE beneficial for NHRP operationsScalability of multipoint GRE

Beneficial for few IPsec tunnels, forwarding performance andinteroperability with 3rd party IPsec equipment.

Rtr 1

Rtr 2Rcvr1

Rcvr2

Traffic flowRtr 3


Rtr1/Rtr3 SA

Rtr2/Rtr3 SATunnel

Tunnel


Secure multicastHow to use multicast in core ?

• IPsec “Tunnel mode”: changes (S,G) – creates multicast overlay problem -> requires MVPN signaling or similar

Header preservation can avoid this

• Need SA for multicast packets between source/receiver routers “group of nodes”)

Manual keying group membership / scaling issues -> GDOI !

Rtr 1

Rtr 2Rcvr1

Rcvr2

Traffic flowRtr 3

Encrypt crypto-mapDecrypt crypto-map

?


IP header IP Payload

Original IP PacketIPSec Tunnel Mode

IPsec Tunnel Mode:IP Header Preservation

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

IP Payload

New hdr with Original IP hdr encapsulated

Original source and destination IP addressencapsulated in tunnel mode

IP Header PreservationOriginal hdr

(S,G)preserved

ESP header

IPSec packet

IP IP Payload


Secure multicastEncrypt 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 2Rcvr1

Rcvr2

Traffic flowRtr 3

Encrypt crypto-mapDecrypt crypto-map

Group SA Rtr1/Rtr2/Rtr3


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 !


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

GDOI example


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

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

DMVPN HUB Key Server

Spoke1

Spoke2

Spoke3

ISP

2

2

2

2

1

111

3

3

3

Note : Multicast traffic will be still forwarded to Hub for any spoke to spoke even with this deployment.

DMVPN HubKey Server


Secure PIM Control Traffic with IPSec

• Encrypt/Authenticate PIM PacketsCrypto map for 224.0.0.13 (PIM Control Messages)Use either IPSec options

Hash Functions: MD5, SHA1Security Protocols: Authentication Header(AH),

Encapsulating Security Payload (ESP)Encryption Algorithms: DES, 3DES, AESRecommended IPSec Mode: TransportRecommended Key method: Manual ?

IPSec AH recommended in PIM IETF drafts


Secure PIM Control Traffic Example

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

interface Ethernet0/0

crypto map pim-crypto

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

interface Ethernet0/0

crypto map pim-crypto


Secure multicast summaryKey Application Scenarios

Key Use Case Customer FeaturesEncryption of IP packets sent over Satellite Links

Organizations who wish to secure video communications through use of BB satellite

MPLS VPN Service Provider customer who wish to have multicast services between multiple sites of a customer VPN

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 DMVPNInstant spoke-spoke connectivity

Enterprise financial customers who wish to secure PIM control traffic in their network

Hardware Acceleration supportNative Multicast Encryption

Secured Multicast VPN

Security for mVPN packetsDoS protection for mVPN PECE-CE protection for Multicast

Secure PIM Control Traffic PIM control packets

encryption


Conclusion


ConclusionMulticast and Security

• Multicast is different from unicast !Why ? Remember ? … states, replication, joins, unidirectional..

• Rich framework of IOS CLI commands for controlCentered around controlling protocol operations, states (multicast) or policing packets (MQC, CoPP, - same as unicast)Can well provide “protected” service/slaNo “simple” protocol security against DoS (-> IPsec)

• PIX with “full”(PIM) IP multicast routing• Emerging solutions with multicast

AAA, IPsec (protect PIM or multicast data)


Questions ?


Recommended Reading

• Continue your Cisco Networkers learning experience with further reading from Cisco Press

• Check the Recommended Reading flyer for suggested books

Available Onsite at the Cisco Company Store


Complete Your Online Session Evaluation

• Win fabulous prizes; Give us your feedback

• Receive ten Passport Points for each session evaluation you complete

• Go to the Internet stations located throughout the Convention Center to complete your session evaluation

• Drawings will be held in theWorld of Solutions

Tuesday, June 20 at 12:15 p.m.

Wednesday, June 21 at 12:15 p.m.

Thursday, June 22 at 12:15 p.m. and 2:00 p.m.

IP Multicast Security - cisco.com · Receiver Side Explicit Join Based Traffic Forwarding (4) •...

Documents

Transcript of IP Multicast Security - cisco.com · Receiver Side Explicit Join Based Traffic Forwarding (4) •...