Network Working Group R. Pashby Internet Draft Bowhead Support Document: draft-pashby-magma-simplify-mld-snooping-00.txt July 2005 Expires: January 2006 Simplifying IPv6 MLD Snooping Switches Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2006. Abstract The purpose of this draft is to simplify the design of MLD Snooping switches and provide a method for sending Solicited Node multicast addresses to be send to every port to improve network security and management. IPv6 Addressing Architecture requires that all nodes must join the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned. This causes MLD snooping switches to create potentially huge multicast forwarding tables just to handle Neighbor Discovery. A simple change to alleviate this would be to allow switches to forward a range of addresses that include the Solicited-Node multicast addresses to every port. This also could help in network discovery and discovering security breaches as discussed in [spoof]. Similarly the same allowance could be made for Local Network Control Block (LNCB) addresses. Table of Contents: 1. Introduction 2. Applicability 3. MLD Snooping Switch Multicast Forwarding Rules 4. Security Considerations 5. Acknowledgments 6. References 7. Author's Information 1. Introduction The purpose of this draft is to simplify the design of MLD Snooping switches and provide a method for sending Solicited Node multicast addresses to be send to every port to improve network security and management. IPv6 Addressing Architecture requires that all nodes must join the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned. This causes MLD snooping switches to create potentially huge multicast forwarding tables just to handle Neighbor Discovery. A simple change to alleviate this would be to allow switches to forward a range of addresses that include the Solicited-Node multicast addresses to every port. This also could help in network discovery and discovering security breaches as discussed in [spoof]. [mldsnoop] states that it is preferred that the entire IPv6 address be used instead just the MAC address. This would cause a 2-2/3 increase in hardware than was required for IPv4. Current layer IGMP snooping switches were designed with the criteria of the number of multicast groups that needed to be supported were determined by the number of "real" IP multicast flows (i.e. video conferences, financial ticker info, broadcast TV/radio, etc). However, with the currently defined IPv6 thousands of multicast groups need to be supported just to allow Neighbor Discovery. This also would cause a large increase in hardware to handle these groups with little real benefit. Many current releases of OS' that support IPv6 do not send MLD joins for the Solicited Node Address. This fact means that if MLD snooping layer 2.5 switch is introduced into a network, large numbers of IPv6 networks would fail to work. Similarly, many OS' in network servers and services also do not send MLD joins for Local Network Control groups. There is another document [spoof], that recommends that Neighbor Discovery Advertisements and Host Redirects be sent to the nodes Solicited Node Address instead of the nodes Unicast Address and require that nodes may silently ignore those packets if they are received not addressed to the Solicited Node Address. That proposal along with this proposal would allow a security device to detect when these security holes are breached. This document reduces the requirement that MLD snooping switches track group joins for per host multicast groups (e.g. Solicited Node Multicast Address) and Local Network Control Block (LNCB) addresses. The proposal would define ranges of Multicast IDs that would be forwarded to all ports and would not require tracking of MLD joins and leaves. The ranges specified are found in a corresponding document [scopedmc]. 2. Applicability This document does not preclude MLD snooping switches to base there multicast forwarding decisions on the full IPv6 address, but does allow for switches to be designed with possibly significant less hardware requirements. This document does not relax the requirement for hosts to send MLD joins for the Solicited Node Address, however does relax the requirement that an MLD snooping switch does not require them for proper operation of Neighbor Discovery. An MLD snooping switch is required to forward the Dynamically Assigned Link-Local Scoped Multicast Ids (DALS) to all ports. 3. MLD Snooping Switch Multicast Forwarding Rules The following rules must be used for MLD snooping Layer 2 switches: - Forward packets addressed to LNCB addresses to all ports. This includes the All Hosts Multicast address. - Forward packets addressed to the DALS addresses to all ports. - Track MLD joins and leaves for forwarding all other multicast groups per [snoop]. 4. Security Considerations Forwarding traffic to all ports can cause vulnerability to Denial of Service attacks. However, there is a tradeoff between security, cost and manageability. The perceived vulnerability is contained to only devices on the link. It is almost impossible to remove Denial of Service attacks from devices connected on the physical link. This document does not increase the vulnerability more than that of a non-MLD snooping switch. Also, there currently is a mechanism that would forward packets to all ports by addressing them to the All Hosts Multicast address. There should be access controls to deny all packets addressed to Dynamically Assigned Link-Local Scoped Addresses from being forwarded onto a link. 5. Acknowledgments Brain Haberman, John Hopkins University Karen O'Donoghue, US Department of Navy 6. References [spoof] Pashby, R., "Detection of IPv6 Neighbor Discovery and Host Redirection Spoofing", draft-pashby-ipv6-detecting- spoofing-00.txt, July 2005 [mldsnoop] Christensen, M., Kimball, K., Solensky, F., "Considerations for IGMP and MLD Snooping Switches, draft-ietf-magma-snoop-12.txt, February 2005 [scopedmc] Pashby R., "Multicast Scoped Address Assignment Guidance", draft-pashby-mboned-mc-scoped-addr-00.txt, July 2005 [RFC2375] Hinden, R., Deering, S., "IPv6 Multicast Address Assignments", RFC2375, July 1998 7. Author's Information Ronald Pashby Bowhead Support Services Ronald.Pashby.ctr@navy.mil (540) 653-6070 Copyright (C) The Internet Society (2005) This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.