Engineering Workshops 262 Best Current Practices.

Engineering Workshops

1

Best Current Practices


2

Best Current Practices

• There's a lot of uncollected experience out there – compilation and documentation of BCPs is badly needed!

• There is an Internet2 Network multicast cookbook. In particular, note the links at:http://noc.net.internet2.edu/i2network/multicast-cookbook.html#further


3

Some BCPs forMulticast TCAM Problems


4

Multicast TCAM Problems

• First make VLAN ACLs to block ICMP and TCP to 224/4. This will at least catch poorly-written address scanners that are either pinging or trying to opena TCP connection.

• On 6500 do "mls ip multicast threshold" to limit the packet rate at which multicast entries get added to the TCAM. This way, slow scans don't take up TCAM slots.

• Graph the mroute MIB to see what ASM groups are popular. You'll be floored by how many belong to Norton Ghost. 229.55.150.208 is one of them.


5

Multicast TCAM Problems

• Set up multicast boundaries for admin scoped groups like 239.255/16 to be link local unless you really care about them working campus-wide. These include Microsoft SSDP and Apple's discovery protocols.

• Block IAPP (Inter Access Point Protocol) if you aren't doing so already.

• See http://noc.net.internet2.edu/i2network/multicast-cookbook.html#MSDP_Filter_contentsand http://noc.net.internet2.edu/i2network/multicast-cookbook.html#furtherfor other bogons to block.


6

Some BCPs forMulticast Security


7

What’s Unique About Multicast?

•By simply sending an IP packet, any host can:– create control plane state in routers & switches– force routers & switches to generate & process protocol packets– flood a large number of hosts with a large traffic stream


8

Why Is This a Problem?

•Hosts can intentionally or unintentionally generate a DoS attack on multicast-enabled routers & switches by overloading the control plane.•Worms which scan 224/4 are the most common problem. •Several worms have unintentionally disrupted many multicast enabled networks (ramen, slammer, etc.)


9

Sender-Based Vulnerabilities: ASM•When host sends a packet to a 224/4 address:•The first router (aka the PIM DR)...– creates a multicast route (S,G) » result = memory allocation on RP/RE (rib) and forwarding hardware (fib) - potential for memory exhaustion

– encapsulates data packet inside PIM register and sends to RP » result = processor cycles on the DR & RP - potential for CPU exhaustion


10

Sender-based Vulnerabilities: ASM

•The PIM RP...– receives PIM Register [processor]– creates (S,G) state [memory]– de-encapsulates the data packets [processor]– forwards the packets down the shared tree [processor] – sends PIM join towards source [processor]


11

Sender-Based Vulnerabilities: ASM

•If it’s also an MSDP speaker, the RP...– creates MSDP SA state [memory]– sends MSDP SA with encapsulated data to all MSDP peers [processor] •Note: MSDP SAs are flooded to every MSDP speaker on the Internet !


12

Sender-Based Vulnerabilities: ASM

•Every MSDP speaker on the Internet...– receives the MSDP SA and deencapsulates the data packet [processor]– creates MSDP SA state and forwarding state [memory]– forwards the data packet down shared tree [processor]


13

Does SSM Solve This Problem?

•SSM does not have sender-based vulnerabilities !– First hop router simply drops packets if no forwarding state (hopefully in ASIC)– No PIM Registers = no data packets inside control plane packets– No MSDP = packets can’t reach all MSDP speakers & no data packets inside control plane packets•SSM still has receiver-based vulnerabilities


14

Receiver-Based Vulnerabilities: SSM & ASM

•When a host joins a multicast group, it sends an IGMP host report packet to a multicast group•Ethernet switches often snoop IGMP packets [memory & processor]•The first hop router...– creates (*,G) and/or (S,G) state if necessary [memory]– sends PIM join towards RP (ASM) or towards source (SSM) [processor]


15

Receiver-Based Vulnerabilities: SSM & ASM

•Every router in the path...– receives a PIM join packet [processor]– creates forwarding state as necessary [memory]•Unintentional receiver-based attacks are unlikely


16

Protection Options: Sender-Based

•On first-hop routers, filter multicast packets to unusable groups. See www.iana.org/assignments/multicast-addresses•Prevents creation of forwarding state and PIM register processing for unusable groups


17

A Bit on “Unusable” Groups

•Ethernet MAC overlaps with 224.0.0.0/24 (225.0.0.0/24, 225.128.0.0/24, etc)– Should not use, but a few people are•What about “reserved” addresses ?– 224.3.0.64 - 224.251.255.255– 225.0.0.0 - 231.255.255.255– 234.0.0.0 - 238.255.255.255•Might reduce impact of worms significantly by eliminating use of this address space


18


•On PIM RP, filter register packets. Only allow packets from your source addresses and “usable” group addresses.•This prevents unnecessary register processing and forwarding state creation on the RP.•Redundant if all DRs have same filters, but...


19


•On all MSDP speakers...– filter SAs by source, group, & RP as appropriate (see “unusable” addresses)•Note the "Proposed MSDP filtering changes on Abilene" thread on [email protected]» begins with https://mail.internet2.edu/wws/arc/wg-multicast/2006-05/msg00056.html

– set limits on total SAs from each peer


20


•On all MSDP speakers...– set per-source SA limits (Juniper); cool feature. need per-source PIM Register limits too.– set per-instance SA limits.– rate-limit all MSDP traffic destined to router.– turn off data encapsulation for MSDP?


21


•On all multicast routers...– rate-limit total PIM traffic to the router– rate-limit all 224/4 traffic to the router– block mcast packets to “unusable” groups


22


•On all multicast routers...– only allow udp to 224/4; exceptions for PIM, OSPF, etc.– disable sdr/sap– set forwarding table limits (Juniper)»set routing-options multicast forwarding-cache


23

Protection Options: Receiver-Based

•On all multicast routers...– rate-limit PIM and IGMP packets– per-interface multicast route limits would be useful•Per-port MAC limits in switches; not sure if this applies to IGMP snooping. If it doesn’t, it should.


24

Multicast Security

•Summary– SSM solves sender-based vulnerabilities. Will ASM cease to be supported for inter-domain?– Blocking reserved groups would help a lot.– So would turning off data encapsulation for MSDP.– So would per-source PIM and MSDP limits.– Need more features from vendors to protect multicast-enabled routers & switches.•See also: http://aharp.ittns.northwestern.edu/papers/mcast-template.html


25

Lab 7Preventing DoS from

Scanning Hosts Time: Approx. 45 minutes


26

The Future of Multicast


27

SSM Revisited


28

Rationale for SSM• Why go to all the trouble involved in using

RPs (tree-switching, MSDP) when the RPT is dropped for the SPT as soon as the first packet flows down the RPT?– The RP is not really forwarding data, just

doing source discovery.– Isn’t there an easier way ?

• This is the rationale for Source-Specific Multicast (SSM).


29

SSM Makes MSDP Unnecessary

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

ASM MSDP Peers(irrelevant to SSM) RP

sSource in 232/8

Receiver learns

S AND G out of

band; e.g., from a

Web page


30

SSM Makes MSDP Unnecessary

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

ASM MSDP Peers(irrelevant to SSM) RP

sSource in 232/8

Receiver learns

S AND G out of

band; e.g., from a

Web page


31

Summary: Advantages of SSM• No RPTs• No register packets• No RP mapping required (no RP required!)• No RP-to-RP source discovery (no MSDP required!)• No RP means no concentration of traffic towards

the RP, and no single point to attack• Rogue sources cannot easily spoof traffic• SSM can use entire multicast address space, but

232/8 is reserved for SSM exclusively


32

Bi-Directional Multicast


33

Bi-Directional Multicast

• SSM is a subset of PIM to deal with one-to-many broadcasts.

• What’s left are few-to-many and many-to-many group communications.

• Can PIM be optimized for the many-to-many case?– In many-to-many, every source is also a

receiver.• So in standard PIM, trees must be built to

the source as well as from the source.


34

Bi-Directional PIM

• Standards Track RFC 5015 • Already in commercial use

– Example: Cisco Multicast Hoot 'n' Holler• www.cisco.com/en/US/netsol/ns340/ns394/ns165/ns70/

networking_solutions_package.html• Hoot 'n' Holler connects a large number of push-to-talk

terminals, all of which can hear a transmission from any particular source


35

What is Bi-Directional PIM?

• In Bi-Dir, communication is always two-way. However, PIM trees are always uni-directional.

• Bi-Dir could be achieved several ways:– Modify PIM to allow bi-directional trees– Set up trees to and from every source

• However, the actual path taken was to drop SPT.– All traffic must go through an RP– No Register Messages– No (S,G) traffic – (*,G) traffic only


36

The Designated Forwarder (DF)

• Bi-Dir PIM does not use either encapsulation of data to the RP or SPT.– There is a specific RP Address (RPA) for any given

Bi-Dir group.• RPF always points toward the RPA.

– For each link (hop) for a Bi-Dir group, there is a Designated Forwarder (DF).

• DFs are elected if need be based on the routing metric toward the RPA.

– The DF forwards any multicast data toward the RPA.– The DF also acts as a PIM DR as needed.


37

PIM Bi-Dir Operation

• PIM Bi-Dir uses normal PIM-SM mechanisms to pass traffic down the tree, like a PIM-SM group before SPT switch-over.

• PIM Bi-Dir uses the DF to pass traffic up the tree toward the RPA.– This is a new routing feature.– DF election rules prevent forwarding loops.


38

PIM Bi-Dir Pros and Cons

• Pros – PIM Bi-Dir solves the bursty source problem.– No traffic-based signaling.– No (S,G) state.

• Reduces the router load and eases debugging.

• Cons– SPT and RPT cannot be mixed.– If PIM Bi-Dir is deployed in a PIM domain, it must be

deployed in every router.• Otherwise forwarding loops will result.

– The RP is once again a single point of failure.• Its placement and its ability to handle load become

important.


39

IPv6 and Multicast


40

IPv6 and Multicast

• In some ways IPv6 changes little for multicast, except for the increased address length.– PIM is hardly changed.– IGMP is replaced by Multicast Listener

Discovery (MLD) Protocol.• With

– IGMPv2 ---> MLDv1 (RFC 2710) and– IGMPv3 ---> MLDv2 (RFC 3810)


41

MTU and Multicast in IPv6

• One thing that has changed is the MTU and the treatment of fragmentation.– MTU = Maximum Transmissible Unit

• In IPv6, fragmentation must be performed at the edges. – Packets that are too large for an

intermediate hop are dropped.

• In unicast, hosts are supposed to performPath MTU (PMTU) discovery.


42

IPv6 MTU

• What to do in multicast?• Multicast MTU discovery has been

implemented, but it does not scale well.– The source could receive many ICMPv6

“Packet Too Big” messages.– A source with many listeners could “Auto-

DoS” itself by sending out too big a packet!• What to do?

– Set the Multicast MTU to 1280 (the IPv6 minimum MTU).


43

Inter-domain Multicast in IPv6

• SSM hardly changes for IPv6, except for the changes mandated by the IPv6 address length and header.

• ASM is another story:– MSDP will not be supported in IPv6.– So will inter-domain ASM die?

• Embedded RP to the rescue.


44

Embedded RP in IPv6

• RFC 3956• The idea is simple:

– In standard IPv6 an address is 128 bits, of which only 64 bits are used for routing.

– But a group address gets to use all of the 128 bits except for the multicast prefix (8 bits).

– So, there is plenty of room to store a 64-bit unicast address.


45

Embedded RP addresses | 8 | 4 | 4 | 8 | 8 | 64 | 32 |

+--------+----+----+--------+----+----------------+----------+

|11111111|flgs|scop|reserved|plen| network prefix | group ID |

+--------+----+----+--------+----+----------------+----------+

• The first 8 bits are the prefix.• The flags MUST be 0111 for embedded RP.• Then the last 4 bits of the “reserved” field are

used to encode the RP Interface ID (RIID), and there are 32 bits for group addresses (4 billion per RP).


46

Creating the RP addresses | 8 | 4 | 4 | 8 | 8 | 64 | 32 |

+--------+----+----+--------+----+----------------+----------+

|11111111|flgs|scop|reserved|plen| network prefix | group ID |

+--------+----+----+--------+----+----------------+----------+

• A little complicated:

– The first “plen” bits of the network prefix form the first “plen” bits of the address.

– The RIID forms the last 4 bits of the address.

– The middle bits are all “0”.


47

Embedded RP in Use

• Embedded RP means that anyone in another PIM domain who wants to join your group, knows where your RP is.

• RP is a single point of failure.• Interdomain joins are now straightforward,

and MSDP is not needed.• This was implemented in GÉANT from

scratch in a few days!


48

Next Steps


49

"Why don’t we use multicastmore often?"

• Extensive discussion of this question on [email protected]:https://mail.internet2.edu/wws/arc/wg-multicast/2004-05/thrd2.html

• See also the follow-up discussion,subject line "I rest my case"


50

"Why don’t we use multicastmore often?"

• One reason seems to be that there is insufficient demand for the high-bandwidth applications that really need multicast in order to scale.

• In turn, this demand won't emerge until last-mile broadband is more widespread.

• Last-mile broadband won't reach a large number of homes for a while yet, but it's a reality on campuses right now.

• This could make campuses the place where large-scale multicast applications (say, hundreds of thousands of users) first take root.


51

Information Online

• http://multicast.internet2.edu especially the tutorial-style paper at http://multicast.internet2.edu/almeroth.pdf

• http://fivebits.net/proj/dbeacon/• www.multicasttech.com/faq/

andwww.multicasttech.com/status/

• http://videolab.uoregon.edu• Greg Shepherd’s multicast site:

www.shepfarm.com/multicast/• www.cisco.com/en/US/products/ps6552/

products_ios_technology_home.html• www.sprint.net/index.php?module=faq/multicasting


52

Stay in touch!• The Internet2 Multicast Working Group mailing list

is a good place to share experiences and get help.https://mail.internet2.edu/wws/arc/wg-multicast Multicast workshop attendees are added to this list automatically.

• The ResearchChannel Internet2 Working Group list is very active; many multicast events are announced here.See www.researchchannel.org/tech/i2wg.asp

• Please fill out the workshop evaluation form.• Corrections, suggestions, questions about future

workshops? Please contact Ben Chinowsky ([email protected]).

Date post:	31-Dec-2015
Category:	Documents
Upload:	lizbeth-watts
View:	223 times
Download:	2 times

Engineering Workshops 262 Best Current Practices.

Documents