BRKIPM-2262 - Multicast Security (2014 Milan)

Multicast Security

BRKIPM-2262

Toerless EckertPrincipal Engineer

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

Housekeeping Visit the World of Solutions and Meet the Engineer Visit the Cisco Store to purchase your recommended readings Please switch off your mobile phones


Abstract / Session GoalsThis 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.

444


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

Yesbut covered in MVPN presentations, not here!

AAA with multicastpolicy frameworkAuthentication, Authorization,

Accounting?Moved to Appendix

NAT supported by Cisco routersbut not security

Introduction


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

AccessPermission/Credential

AdmissionResource availability

Policy

Statecreation

Packet levelpolicing, encryption

DeviceControl plane

LinksNetworkData plane

ServiceContent

LocalRouterswitch

Hop-by-HopCoordinated

VRF/VPN

Policy-ServerAAA


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. UnicastPer-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. 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: Deny traffic from Source to receiver AUnicast: can filter anywhere on pathMulticast: 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 groupFilter on egres after last replication

L3 router or L2 switch same principle

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.Multicast: implicit protectionASM:

Sources can attack groupsNo independent host attacks

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

U

n

i

c

a

s

t

A

S

M

RP

S

S

M

FirstHop

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 attackjust 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)

A

s

m

/

B

i

d

i

r

Ouch

A

S

M

/

P

I

M

-

S

M

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 tables, Increase convergence times

RP

Source(s)

J

o

i

n

S

1

,

G

1

J

o

i

n

G

2

J

o

i

n

S

2

,

G

2

1.

2.

State

State

State

State3.



Unicast/MulticastFilter packetsip access-group Traffic stops where filter is configured

MulticastPer tree filter at control planeTraffic stops where filtered branch hits treeFilter at receiverstop traffic at source

ip multicast boundary Unicast

Per prefix route-filtersIneffective with aggregation (default-route)

R1

A

Source

e0

R2

R3

R4

I

G

M

P

m

e

m

b

e

r

s

h

i

p

P

I

M

J

o

i

n

P

I

M

J

o

i

n

P

I

M

J

o

i

n

R1

A

Source

e0

R2

R3

R4

I

G

M

P

m

e

m

b

e

r

s

h

i

p

e0

Filtering:Data-plane only vs. Control Plane


Multicast vs. UnicastSummary Unicast:

MUST protect hosts AND network nodes against sender attackersOften using Transport (UDP/TCP) ports or DPI

MulticastProtect 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 SecurityCovered 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 SecurityCovered Elsewhere

Overload router CPU with packetsbrute 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 PacketsNon-Multicast Specific

ip receive access-list 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!


CPL/MQCModular QoS CLIPolicing (Rate-Limiting) and Shaping of Packets

Multi-purpose, unicast & multicastMain uses

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

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

Other - not security related: Queue outbound multicast data packets according to diffserv classes Shape outbound multicast data packets to control burstyness Tag packets with DSCP bits according to application->Diffserv policies

HIDDEN


CPL/MQCModular QoS CLIFour main CLI layers/sections

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 interfaceThe point of application of a QOS policy

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

ip access-group extended mc-control-acl

permit ip any 224.0.0.0 0.0.0.255class-map match-all mc-control-class

match access-group mc-control-aclpolicy-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

HIDDEN


MQCModular QoS CLIThree Ways to apply MQC

Explicit service policies on interfaces standard case

Microflow-policing Automatic creation of service policies for individual flows

CoPPControl Plane Policing Apply to control plane packets (policing only) Same packet processing rules as for ip receive acl

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


MQC for Control PacketsCoPP and Interface Example

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

class-map match-any class-all-controlmatch access-group acl-access-if-control ! As abovematch access-group acl-core-if-control ! Eg: OSPF, BGP, PIM

! CoPP Control plane policingpolicy-map control-plane-policy

class class-all-controlpolice rate 800000 bps burst

control-plane ! The virtual control-plane IFservice-policy input control-plane-policy

! Interface level policing / droppingpolicy-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 interfaceservice-policy input access-if-policy ! No class-core-if-control in


MQC for Control PacketsCoPP 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) policieseg: access, core, More powerful and cumbersome Isolate attack domains to single interface Use-Case: aggregation router connecting to multiple customersEasier: per-vrf limits (PE router)


Filter for Control Plane PacketsNon-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 Multicastmls rate-limit multicast ipv4 partialmls rate-limit multicast ipv4 fib-miss mls rate-limit multicast ipv4 ip-optionsmls rate-limit multicast ipv4 igmp mls rate-limit all ttl-failure mls rate-limit multicast ipv4 pimPIM rate limiter requires 12.2(33)SXHThe 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?!!: PIMv1legacy protocol behaviormrinfoeavesdropping (use SNMP)DVMRPflood and pruneGood:mtracemulticast equivalent of traceroute


IGMP/MLD Protocol PacketsBad: Unicast IGMP packetsfor IGMP/UDLRGood: 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 stormsForged (multicast) IGMP/MLD membership reports

Not a problem!? .. The router can solve


IGMP/MLD Protocol PacketsThe 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/MLDControl Packets L2 switch

Geek - o - meterGeek - o - meter


ip access-list extended control-packetsdeny 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-packetsinterface ethernet 0

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

IGMP PacketsExample Extended ACL for Various IGMP Packets

http://www.iana.org/assignments/igmp-type-numbers Numeric port = IGMP type number 0x1



PIM PacketsMulticastMulticast 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.

MulticastPIM Control Packets


PIM PacketsUnicast 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!

RPDRUnicast

PIM Control Packets

PIM-SM Domain


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

C-RP-Announce: Multicast (224.0.1.39) to all MAs. Discovery: Multicast (224.0.1.40) to all Routers. Normally Dense mode flooded (IOS)! 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 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.210.0.0.1

ip multicast-routingip pim sparse-modeip multicast-routingaccess-list 1 permit 10.0.0.2Access-list 1 deny anyInterface e0

ip 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)

C

MA

A

list 1 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-discovery)

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

interface s0ip multicast boundary 1



BSR ControlConstrain BSR Messages

ip pim bsr-border Filters 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

Interface S0ip 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 registermessages

RPS0

ip pim register-rate-limit 2

DRPIM-SM registerstop messages


Access NetworksProtection Against Attacks

Attacks by hosts (multicast) PIM Hellosbecome DRno traffic forwarded to LAN Same applies to DF-election packets for Bidir-PIM

PIM joinsreceive 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 packetsannounce 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 switchIn wiring

closet

R1 R2

S1Access

LAN


access-list 2 permit

interface e0ip pim sparse-modeip pim neighbor-filter 2 ! Only allow R2ip pim bsr-border ! No BSRip multicast boundary 1 ! No autorp

e0 e0


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

PIM Hellos

L2 switchIn wiring

closet

R1 R2

S1Access

LAN


access-list 2 permit

interface e0ip pim sparse-modeip pim neighbor-filter 2 ! Only allow R2ip pim bsr-border ! No BSRip 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)


Access NetworksGeneric Considerations Unicast

Must use passive on access interfaces (or secure unicast routing protocols).Use CoPP or packet-filtering to filter unicast protocol packets (IGP,)

Non-passive LAN must allow transit BSR/AutoRP difficult to secure.

Redundant and non-redundant access-networks (global) ip pim rp-address override If not using AutoRP/BSR Inhibits effects of attacks with AutoRP/BSR packets..

(global) ip pim announce-filter acl-none Inhibit learning of RPs on AutoRP mapping agent.

ip access-group in Filter IGMP queriesrepresent attack from hosts Filter DVMRP packets

HIDDEN



L3 Wiring Closet Access NetworksProtection 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 switchIn wiring

closet

R1 R2

S1

AccessLAN

e0 e0


Non-Redundant Access-NetworksProtection 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 hostsMany wireless Access-Point attachments

All broadband services access interfacesDSLp2p PPPoX interface between BBRAS and PC or Home-Router or shared LAN to multiple homesCable: CMTS to home-LANCan still have internal or box redundancy within BBRAS/CMTS transparent to routing

Can filter all PIM protocol packets from LAN!

L3 switch/routerIn datecenter, Eg: cat6k / VSS

R1

BBRAS

DSLAM

HomeGateway

DSL linePPPoXtunnel

va1234VirtualAccess

Interface


Non-Redundant Access-NetworksProtection 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/routerIn datecenter, Eg: cat6k

R1

BBRAS

DSLAM

HomeGateway

DSL linePPPoXtunnel

va1234VirtualAccess

Interface

ip access-list extended no-control-plane permit igmp any 224.0.0.13 ! IGMPv3 reportspermit igmp any any 6 ! IGMPv2 reportspermit igmp any any 7 ! IGMPv2 leavepermit igmp any any 14 ! mtracepermit igmp any any 15 ! mtracedeny igmp any any ! Queries, PIMv1, DVMRP,

deny pim any any ! Hello, Join/Prune, BSRdeny ip any 224.0.0.39 ! AutoRPdeny ip any 224.0.0.40 ! AutoRP ! BSRpermit ip any any

interface e0ip pim sparse-modeip igmp version 3ip access-group no-control-plane-in interface virtual-template 0


Non-Redundant Access-NetworksSimplify 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 e0ip pim passiveip igmp version 3


L3 Wiring Closet Access NetworksFor Base IOS Images Catalyst 3xx0 IP base image

IOS image targeted to be used in L3 wiring closet least expensive, supports (only) subset of routing required for L3 wiring closet:

Unicast routing: EIGRP stubsubset of EIGRP routing: No transit routes. Not usable on R1, R2

PIM stub: In IP base, VLAN interfaces only supportip pim passive, but not ip pim sparse/sparse-dense/dense-mode Before introduction of PIM stub, IP base images did not support

any IP multicast routing! Full unicast routing and unlimited multicast support exist in

IP services and other IOS images on same platform

PIM Hellos

L3 switchIn wiring

closet

R1 R2

S1

e0 e0

gig0 gig1

vlan1 vlan1

interface gig0 / gig1ip pim sparse-mode

Interface vlan1ip pim passive ! No alternative

HIDDEN


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

R1

R2Spoofed MSDP PeeringAttempt to bring down

Existing peering

DoS

ip msdp peer 10.0.0.2ip 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 Limit mrinfo answers to specific requesters


Access Control Includes Scoping


Access ControlOverview

Control which ASM groups and SSM channels systems endpoint can send to or receive from Packet level filter (ASM/SSM) :ip access-groupipv6 traffic-filter

PIM-SM filter which sources can send to which group:ip pim accept-registeripv6 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 boundaryipv6 multicast boundary


ip access-list extended sourcepermit ip 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 ! Log ?permit ip any any

interface ethernet0ip address 10.1.1.1 255.255.255.0 ip access-group source in

Well 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 routingno 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-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-groupipv6 mld access-group H2224.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 10access-list 10 permit 192.16.1.1

RP

Unwanted Sender

Source Traffic

R

e

g

i

s

t

e

r

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-registeripv6 pim accept-register


Disabling Multicast Groups ip/ipv6 multicast group-range

Disable all operations for groups denied by 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 ControlOverview

IPv4: per-interface either or all of A, B ,C (one each) A: ip multicast boundary [ filter-autorp ] Group scope boundaries Payload filtering of AutoRP messages

B: ip multicast boundary in C: ip multicast-boundary out Extended form for access-control, SSM scopes

IPv6: per-interface one config of A A: ipv6 multicast boundary scope Scoping simple due to IPv6 architecture No B, C options (yet)


Interface/Protocol Level Access ControlIPv4 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/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 ]

e0


Interface/Protocol Level Access ControlIPv6 Scope Boundaries

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 always

filters scope 2.. addresses

ACL for scope implicitly defined:

SITE scope: 5

R2

R1

R3

R4

R5

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 !

REGION zone: 7



Interface/Protocol Level Access ControlShape and Structure of Scopes (RFC4007)

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 arch Scope expanding ring search Smaller scopes subset of larger scopes(IPv4, historical)

Recommendations IPv4 Define IPv4 scopes as non-overlapping ranges

R1

R2

R3

R5

R4

Picture:Non-convex scope

HIDDEN



R1Src1

Src2 Rcv

RcvScope5 zone 1

Scope 5zone 2

RP1

RP2(zone2,*,G)

(zone1,*,G)

Interface/Protocol Level Access ControlLocation of Scope Boundaries

IPv6 arch RFC4007: scope boundaries cut through router ! If implemented it makes router become effectively a VPN-PE

..and an 6VPE router a hierarchical PE!

IOS/IOS-XR: link-local scope separate scope on each interface No way to put multiple interfaces into separat larger scope (except separate VRF) Scope boundaries only cut through links!

NOT SUPPORTED

R1

Scope 1 (link scope)zone 1 (serial0)

Scope 1 (link scope)zone 2 (ethernet0)

s0

e0

SUPPORTED

HIDDEN



Interface/Protocol Level Access ControlSeparate In/Out Filtering

ip multicast boundary in Applies to incoming interface. Inhibits traffic received on the interface

ip multicast boundary 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 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 ControlFiltering 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/PIMJoin/membership G

OIF check

Interface ethernet 1ip multicast boundary deny-groups ! eitherip 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 permittednormal 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)


E.g.: to RP

IIF check (1)

Interface ethernet 0ip multicast boundary deny-groups ! eitherip 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)


Multicast (S,G) packetInterface ethernet 0ip multicast boundary deny-groups ! eitherip 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 joins 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



E.g.: to RP

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


Multicast (S,G) packet


Interface/Protocol Level Access ControlMore Protocol Details

PIM-DM:Does not flood on egress boundary. Sends prune on ingress boundary Left as an exercise to archaeologist readers

Filtering based on state, not packets!: No per-source filtering for Bidir-PIM or PIM-SM/SPT-

infinity

Bidir-PIM:boundaries ineffective for upstream bidir-PIM traffic Upstream traffic forwarded (logically) on (*,G/M) state, not

(*,G) state ! Not subject to multicast boundary For Bidir-PIM groups, use ip multicast boundary

AND ip access group. No problem on cat6k: ip multicast boundary already acts

as packet filter too!

R1

RP

Boundaries ineffectiveFor upstream Bidir traffic

Multicast (S,Gbidir) Upstream packet

boundary boundary in

boundary boundary out

HIDDEN



Interface/Protocol Level Access ControlAutoRP Filtering Domain Boundary

Scope boundaryuse 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 regiondeny 239.193.0.0 0.255.255.255

Interface ethernet 0ip multicast boundary region filter-autorp

RP


Interface/Protocol Level Access ControlSemantics 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-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 ControlExample: 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-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 ControlExample: Subscriber Interfaces

ip multicast boundary ext-acl outsupersedes ip igmp access-group ext-aclUse ip multicast boundary in/out

independent of host or router subscriberConsider ip access-group ext-acl inbecause 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

SourcedPackets


Access ControlRecommended Interdomain MSDP SA Filter

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

! domain-local applications

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

HIDDEN


Admission Control


Admission ControlGoals

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 ControlMSDP Control Plane

ip msdp sa-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

T

r

a

n

s

i

t

a

l

l

S

A

EnterpriseCustomer1

ISP

EnterpriseCustomer2

ISP2

ISPPeer2

ISPPeer2

Large #SA Large #SA

Small #SA

MSDP peerings

Small #SA



Admission ControlGlobal/per-VRF Route Limits

No state created beyond State triggering packets still punted, but discarded

Syslog warnings created beyond

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

ip multicast route-limit [ ]Geek - o - meterGeek - o - meter


Admission ControlIGMP/MLD Admission Control

ip igmp limit [ except ]ipv6 mld limit [ except ] Always per interface Global command sets per-interface default Counts entries in IGMP/MLD (per-interface) table

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


Admission Controlper-interface mroute limits

ip multicast limit [ rpf |out|connected ]

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 permitting the flow

S1,G1

MulticastLookup/ingress statesAccounted against s0

Ingress (rpf/connected)

MulticastEgress/Replicationstates, accounted

Against s1, s2 egress (out)

s2s1

s0


Admission ControlPer Interface Mroute LimitHow It Works

Works similar to ip multicast boundary Same filtering for input and outputDifference:

Denied input multicast boundary creates OIF=0 flow state (not on cat6k/cisco7600 due to HW filtering) Best protection against unwanted packets

Denied input multicast limit does not create state Protect against state creation! But leaves unwanted punted packets: Add CoPP to protect against unwanted packets

Can replace multicast boundary with multicast limit! ip multicast boundary out ip multicast limit out 0 Must invert (permit deny)

HIDDEN


Admission ControlHow to Use It

Protection against DoS attacks by creating too many trees First level of defense: Global/per-vrf mroute-limitssufficiently larger than expected

Second level of defense Global IGMP/MLD limit defaultapplies 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 CLIOverview

Defaultcount trees as 1 Effectively just count number of trees Add global config to define how to count each tree: ip multicast limit cost

Multiple configs possible, first acl match determines tree cost Usage:

Decide on unit for and , 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 bandwidthbetween CPs

Bandwidth Based CAC via CLIExample

4. 250 Mbps for each CP250 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 usersper DLAM

DSLAM

DSLAM

DSLAM

Cisco 7600

10GE

ContentProvider 1

ContentProvider 2

ContentProvider 3

ContentProviders

ServiceProvider

PayingCustomers

MPEG4 SDTV

MPEG2 SDTVMPEG4 SDTV

MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

PE


3. Requested Policy:Fair sharing of bandwidthbetween CPs

Bandwidth Based CAC via CLIExample

4. 250 Mbps for each CP250 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 usersper DLAM

DSLAM

DSLAM

DSLAM

Cisco 7600

10GE

ContentProvider 1

ContentProvider 2

ContentProvider 3

ContentProviders

ServiceProvider

PayingCustomers

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

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


Bandwidth Based CAC via CLIExample: Input CAC

What difference does Input vs. outputlimit 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 usersper FTTH switch

DSLAM

DSLAM

DSLAM

Non CiscoPE

10GE

ContentProvider 1

ContentProvider 2

ContentProvider 3

ContentProviders

ServiceProvider

PayingCustomers

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

PE

IOS-Rtr

IOS-Rtr

IOS-Rtr


Bandwidth Based CAC via CLIExample: Input CAC

What difference does Input vs. outputlimit 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 usersper FTTH switch

DSLAM

DSLAM

DSLAM

Non CiscoPE

10GE

ContentProvider 1

ContentProvider 2

ContentProvider 3

ContentProviders

ServiceProvider

PayingCustomers

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

PE

IOS-Rtr

IOS-Rtr

IOS-Rtr

! 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 PE ---... ! CACip multicast limit rpf 250000 acl-CP1-channelsip multicast limit rpf 250000 acl-CP2-channelsip multicast limit rpf 250000 acl-CP3-channels


Bandwidth Based CACACL Details ASM: only match (/count) (*,G) = (0.0.0.0,G) states:

SSM: count each (S,G) state

ip access-list extended acl-MP2SD-channelspermit ip host 0.0.0.0 239.0.4.0 0.255.0.255

ip access-list extended acl-MP2HD-channelspermit 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.255ip access-list extended acl-CP2-channels

permit ip host 0.0.0.0 239.2.0.0 0.0.255.255

ip access-list extended acl-MP2SD-channelspermit ip any 232.0.4.0 0.255.0.255

ip access-list extended acl-MP2HD-channelspermit ip any 232.0.18.0 0.255.0.255

...ip access-list extended acl-CP1-channels

permit ip any 232.1.0.0 0.0.255.255ip access-list extended acl-CP2-channels

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 MulticastOverview

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 FirewallUnicast

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) FirewallsOverview

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/supportedObsoletes solutions like

GRE tunnels through PIX Third-party DVMRP-only firewall


ASA/FWSM Multicast Features ASA

IGMP Support Stub multicast routingIGMP 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 trafficavoids 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

GDOIKey distribution mechanism (RFC3547) Manual keying still available


GRE tunnels and DMVPNIPsec 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 2Rcvr1

Rcvr2

Traffic flowRtr 3

Rtr 4

Encrypt crypto-mapDecrypt crypto-map

Rtr1/Rtr3 SA

Rtr2/Rtr3 SA


P2P IPsec Tunnel InterfaceGRE 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 2Rcvr1

Rcvr2

Traffic flowRtr 3

Rtr 4


Rtr1/Rtr3 SA

Rtr2/Rtr3 SA


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

Rcvr2

Traffic flowRtr 3


?


IP header(S,G) IP Payload

Original IP Packet

IPsec Tunnel ModeIP 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 ModeIPSecpacket

ESP or AHheader


OriginalIP header

(S,G)

ESP or AHheader



Dynamic Group SA KeyingGDOI

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 / GETvpnEncrypt 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


Group SA Rtr1/Rtr2/Rtr3


Secure PIM Control Traffic with IPSecStrategy/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 IPsecsetup)

Use either IPSec optionsHash Functions: MD5, SHA1Security Protocols: Authentication Header(AH), Encapsulating Security Payload (ESP)Encryption Algorithms: DES, 3DES, AESNOT 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-hmacmode transport

crypto map pim-crypto 10 ipsec-manualset peer 224.0.0.13set session-key inbound ah 404 bcbcbcbcbcbcaaaaset session-key outbound ah 404 bcbcbcbcbcbcaaaaset transform-set pimtsmatch address 106

Secure PIM Control Plane Global config (once)

Per interface configinterface Ethernet0/0

crypto map pim-crypto


Secure PIM Control PlaneDiscussion

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


SummaryMulticast 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 SimplicitySSM No attack points in network

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

Assume best effortno business critical application running Secureprotect to be ~comparable to unicast Simple config global mroute/igmp limits!

ip multicast-routingip pim ssm defaultno ip dm-fallbackip multicast route-limit 1000 900ip igmp limit 100interface ethernet 0 ! All backbone

ip pim sparse-mode

Interface vlan 1 ! All (non-redundant) accessip pim passiveip igmp version 3


Adding ASM ServiceAnd 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 messagessee 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 SLAAccess 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 solutionstatic:

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

Documents

BRKIPM-2262 - Multicast Security (2014 Milan)