--- 1/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt 2006-03-09 22:15:20.000000000 +0100 +++ 2/draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt 2006-03-09 22:15:20.000000000 +0100 @@ -1,19 +1,19 @@ IPv6 Operations E. Davies Internet-Draft Consultant -Expires: April 17, 2006 J. Mohacsi +Expires: September 7, 2006 J. Mohacsi NIIF/HUNGARNET - October 14, 2005 + March 6, 2006 Best Current Practice for Filtering ICMPv6 Messages in Firewalls - draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt + draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt 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 @@ -24,25 +24,25 @@ 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 April 17, 2006. + This Internet-Draft will expire on September 7, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. @@ -80,43 +80,44 @@ 4.3. Recommendationd for ICMPv6 Local Configuration Traffic . . 15 4.3.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 15 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 16 4.3.3. Traffic that May be Dropped but will be Caught Anyway . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.4. Traffic for which a Dropping Policy Should be Defined . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 19 - A.1. Destination Unreachable Error Message . . . . . . . . . . 19 + Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 20 + A.1. Destination Unreachable Error Message . . . . . . . . . . 20 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 20 - A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 20 + A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 21 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 21 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 22 A.6. Neighbor Solicitation and Neighbor Advertisement Messages . . . . . . . . . . . . . . . . . . . . . . . . . 22 - A.7. Router Solicitation and Router Advertisement Messages . . 22 - A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 22 + A.7. Router Solicitation and Router Advertisement Messages . . 23 + A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 23 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 23 - A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 23 + A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 24 A.13. Node Information Query and Reply . . . . . . . . . . . . . 24 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 24 - A.15. Unused and Experimental Messages . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 - Intellectual Property and Copyright Statements . . . . . . . . . . 27 + A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25 + Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . . . 34 1. Introduction When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC2463], [I-D.ietf-ipngwg-icmp-v3] plays a fundamental role including being an essential component in establishing communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 may have a detrimental effect on the establishment of IPv6 communications. On the other hand, allowing @@ -180,21 +181,21 @@ [RFC3122]. o Communicating which multicast groups have listeners on a link to the multicast capable routers connected to the link. Uses messages Multicast Listener Query, Multicast Listener Report (two versions) and Multicast Listener Done (version 1 only) as specified in Multicast Listener Discovery MLDv1 [RFC2710] and MLDv2[RFC3810]. o Discovering multicast routers attached to the local link. Uses messages Multicast Router Advertisement, Multicast Router Solicitation and Multicast Router Termination as specified in - Multicast Router Discovery [I-D.ietf-magma-mrdisc]. + Multicast Router Discovery [RFC4286]. o Providing support for some aspects of Mobile IPv6 especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link. The Home Agent Address Discovery Request and Reply; and Mobile Prefix Solicitation and Advertisement messages are specified in [RFC3775] o An experimental extension to ICMPv6 specifies the ICMP Node Information Query and Response messages which can be used to retrieve some basic information about nodes [I-D.ietf-ipngwg-icmp- name-lookups]. @@ -483,21 +484,22 @@ and it is not assumed that firewalls are uniformly capable in this respect. Firewalls which are able to perform deep packet inspection may be able to check the header fields in the start of the errored packet which is carried by ICMPv6 error messages. If the embedded packet has a source address which does not match the destination of the error message the packet can be dropped. This provides a partial defence against some possible attacks on TCP that use spoofed ICMPv6 error messages, but the checks can also be carried out at the - destination. + destination. For further information on these attacks see [I-D.gont- + tcpm-icmp-attacks]. In general, the scopes of source and destination addresses of ICMPv6 messages should be matched, and packets with mismatched addresses should be dropped if they attempt to transit a router. However some of the address configuration messages carried locally on a link may legitimately have mismatched addresses. Node implementations need to avoid over-zealous filtering of these messages delivered locally on a link. 4.2. Recommendations for ICMPv6 Transit Traffic @@ -513,28 +515,28 @@ o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the necessary packet inspection capabilities. Connectivity checking messages: o Echo Request (Type 128) o Echo Response (Type 129) - For Teredo tunneling [I-D.huitema-v6ops-teredo] to IPv6 nodes on the - site to be possible, it is essential that the connectivity checking - messages are allowed through the firewall. It has been common - practice in IPv4 networks to drop Echo Request messages in firewalls - to minimize the risk of scanning attacks on the protected network. - As discussed in Section 3.2, the risks from port scanning in an IPv6 - network are much less severe and it is not necessary to filter IPv6 - Echo Request messages. + For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be + possible, it is essential that the connectivity checking messages are + allowed through the firewall. It has been common practice in IPv4 + networks to drop Echo Request messages in firewalls to minimize the + risk of scanning attacks on the protected network. As discussed in + Section 3.2, the risks from port scanning in an IPv6 network are much + less severe and it is not necessary to filter IPv6 Echo Request + messages. 4.2.2. Traffic that Normally Should Not be Dropped Error messages other than those listed in Section 4.2.1 o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0 Mobile IPv6 messages that are needed to assist mobility: o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) @@ -777,39 +779,38 @@ 6. Acknowledgements Pekka Savola created the original IPv6 Security Overview document which contained suggestions for ICMPv6 filter setups . This information has been incorporated into this document. He has also provided important comments. Some analysis of the classification of ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in a draft relating to ICMPv6 and IKE. + The Netfilter configuration script in Appendix C was contributed by + Suresh Krishnan. + 7. References 7.1. Normative References [I-D.ietf-ipngwg-icmp-name-lookups] Crawford, M. and B. Haberman, "IPv6 Node Information - Queries", draft-ietf-ipngwg-icmp-name-lookups-12 (work in - progress), July 2005. + Queries", draft-ietf-ipngwg-icmp-name-lookups-15 (work in + progress), February 2006. [I-D.ietf-ipngwg-icmp-v3] Conta, A., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. - [I-D.ietf-magma-mrdisc] - Haberman, B. and J. Martin, "Multicast Router Discovery", - draft-ietf-magma-mrdisc-07 (work in progress), May 2005. - [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. @@ -839,36 +840,48 @@ [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005. + [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", + RFC 4286, December 2005. + 7.2. Informative References [I-D.chown-v6ops-port-scanning-implications] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", - draft-chown-v6ops-port-scanning-implications-01 (work in - progress), July 2004. + draft-chown-v6ops-port-scanning-implications-02 (work in + progress), October 2005. - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-05 (work in progress), - April 2005. + [I-D.gont-tcpm-icmp-attacks] + Gont, F., "ICMP attacks against TCP", + draft-gont-tcpm-icmp-attacks-05 (work in progress), + October 2005. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. + + [netfilter] + netfilter.org, "The netfilter.org project", Firewalling, + NAT and Packet Mangling for Linux , 2006, + . + Appendix A. Notes on Individual ICMPv6 Messages A.1. Destination Unreachable Error Message Destination Unreachable (Type 1) error messages [RFC2463] are sent any-to-end between unicast addresses. The message can be generated from any node which a packet traverses when the node is unable to forward the packet for any reason except congestion. Destination Unreachable messages are useful for debugging but are @@ -977,25 +990,25 @@ A.5. ICMPv6 Echo Request and Echo Response Echo Request (Type 128) uses unicast addresses as source addresses, but may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC2463]. Echo Requests travel end-to-end . Similarly Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. They are mainly used in combination for monitoring and debugging connectivity. Their only role in establishing communication is that they are required when verifying - connectivity through Teredo tunnels[I-D.huitema-v6ops-teredo]: Teredo - tuneling to IPv6 nodes on the site will not be possible if these - messages are blocked. It is not thought that there is a significant - risk from scanning attacks on a well-designed IPv6 network (see - Section 3.2) and so connectivity checks should be allowed by default. + connectivity through Teredo tunnels[RFC4380]: Teredo tuneling to IPv6 + nodes on the site will not be possible if these messages are blocked. + It is not thought that there is a significant risk from scanning + attacks on a well-designed IPv6 network (see Section 3.2) and so + connectivity checks should be allowed by default. A.6. Neighbor Solicitation and Neighbor Advertisement Messages ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 136) messages are essential to the establishment of communications on the local link. Firewalls need to generate and accept these messages to allow them to establish interfaces onto their connected links. Note that the address scopes of the source and destination addresses on Neighbor Solicitations and Neighbor Advertisements may not match. @@ -1043,27 +1056,27 @@ and version 2 [RFC3810] (Listener Query and Listener Report Version 2 - Types 130 and 143) messages are sent on the local link to communicate between multicast capable routers and nodes which wish to join or leave specific multicast groups. Firewalls need to be able to generate Listener messages in order to establish communications and may generate all the messages if they also provide multicast routing services. A.11. Multicast Router Discovery Messages - Multicast Router Discovery [I-D.ietf-magma-mrdisc] (Router - Advertisement, Router Solicitation and Router Termination - Types - 151, 152 and 153) messages are sent by nodes on the local link to - discover multicast capable routers on the link, and by multicast - capable routers to notify other nodes of their existence or change of - state. Firewalls which also act as multicast routers need to process - these messages on their interfaces. + Multicast Router Discovery [RFC4286] (Router Advertisement, Router + Solicitation and Router Termination - Types 151, 152 and 153) + messages are sent by nodes on the local link to discover multicast + capable routers on the link, and by multicast capable routers to + notify other nodes of their existence or change of state. Firewalls + which also act as multicast routers need to process these messages on + their interfaces. A.12. Router Renumbering Messages ICMPv6 Router Renumbering (Type 138) command messages can be received and results messages sent by routers to change the prefixes which they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. These messages are sent end-to-end to either the all- routers multicast address (site or local scope) or specific unicast addresses from a unicast address. @@ -1137,20 +1151,344 @@ disallow forwarding of these incoming messages as a potential security risk. Unknown outgoing Error messages should be dropped as the administrator should be aware of all messages that could be generated on the site. Also the Seamoby working group has had an ICMPv6 message (Type 150) allocated for experimental use in two protocols. This message is sent end-to-end and may need to pass through firewalls on sites that are supporting the experimental protocols. +Appendix B. Example Script to Configure ICMPv6 Firewall Rules + This appendix contains an example script to implement most of the + rules suggested in this document when using the Netfilter packet + filtering system for Linux [netfilter]. When used with IPv6, the + 'ip6tables' command is used to configure packet filtering rules for + the Netfilter system. The script is targeted at a simple enterprise + site that may or may not support Mobile IPv6. + + #!/bin/bash + # Set of prefixes on the trusted ("inner") side of the firewall + export INNER_PREFIXES="2001:DB8:85::/60" + # Set of hosts providing services so that they can be made pingable + export PINGABLE_HOSTS="2001:DB8:85::/64" + # Configuration option: Change this to 1 if errors allowed only for + # existing sessions + export STATE_ENABLED=0 + # Configuration option: Change this to 0 if the site does not support + # Mobile IPv6 Home Agents - see Appendix B.14 + export HOME_AGENTS_PRESENT=1 + # Configuration option: Change this to 0 if the site does not support + # Mobile IPv6 mobile nodes being present on the site - + # see Appendix B.14 + export MOBILE_NODES_PRESENT=1 + + ip6tables -N icmpv6-filter + ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter + + # Match scope of src and dest else deny + # This capability is not provided for in base ip6tables functionality + # An extension (agr) exists which may support it. + #@TODO@ + + # ECHO REQUESTS AND RESPONSES + # =========================== + + # Allow outbound echo requests from prefixes which belong to the site + # for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type echo-request -j ACCEPT + done + + # Allow inbound echo requests towards only predetermined hosts + # for pingable_host in $PINGABLE_HOSTS + do + ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ + --icmpv6-type echo-request -j ACCEPT + done + if [ "$STATE_ENABLED" -eq "1" ] + then + # Allow incoming and outgoing echo reply messages + # only for existing sessions + ip6tables -A icmpv6-filter -m state -p icmpv6 \ + --state ESTABLISHED,RELATED --icmpv6-type \ + echo-reply -j ACCEPT + else + # Allow both incoming and outgoing echo replies + for pingable_host in $PINGABLE_HOSTS + do + # Outgoing echo replies from pingable hosts + ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ + --icmpv6-type echo-reply -j ACCEPT + done + # Incoming echo replies to prefixes which belong to the site + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type echo-reply -j ACCEPT + done + fi + + # Deny icmps to/from link local addresses + ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP + ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP + + # Drop echo replies which have a multicast address as a + # destination + ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ + --icmpv6-type echo-reply -j DROP + + # DESTINATION UNREACHABLE ERROR MESSAGES + # ====================================== + + if [ "$STATE_ENABLED" -eq "1" ] + then + # Allow incoming destination unreachable messages + # only for existing sessions + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -m state -p icmpv6 \ + -d $inner_prefix \ + --state ESTABLISHED,RELATED --icmpv6-type \ + destination-unreachable -j ACCEPT + done + else + # Allow incoming destination unreachable messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type destination-unreachable -j ACCEPT + done + fi + + # Allow outgoing destination unreachable messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type destination-unreachable -j ACCEPT + done + + # PACKET TOO BIG ERROR MESSAGES + # ============================= + + if [ "$STATE_ENABLED" -eq "1" ] + then + # Allow incoming Packet Too Big messages + # only for existing sessions + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -m state -p icmpv6 \ + -d $inner_prefix \ + --state ESTABLISHED,RELATED \ + --icmpv6-type packet-too-big \ + -j ACCEPT + done + else + # Allow incoming Packet Too Big messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type packet-too-big -j ACCEPT + done + fi + + # Allow outgoing Packet Too Big messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type packet-too-big -j ACCEPT + done + + # TIME EXCEEDED ERROR MESSAGES + # ============================ + if [ "$STATE_ENABLED" -eq "1" ] + then + # Allow incoming time exceeded code 0 messages + # only for existing sessions + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -m state -p icmpv6 \ + -d $inner_prefix \ + --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ + -j ACCEPT + done + else + # Allow incoming time exceeded code 0 messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type ttl-zero-during-transit -j ACCEPT + done + fi + + #@POLICY@ + # Allow incoming time exceeded code 1 messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type ttl-zero-during-reassembly -j ACCEPT + done + + # Allow outgoing time exceeded code 0 messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type ttl-zero-during-transit -j ACCEPT + done + + #@POLICY@ + # Allow outgoing time exceeded code 1 messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type ttl-zero-during-reassembly -j ACCEPT + done + + # PARAMETER PROBLEM ERROR MESSAGES + # ================================ + + if [ "$STATE_ENABLED" -eq "1" ] + then + # Allow incoming parameter problem code 1 and 2 messages + # for an existing session + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -m state -p icmpv6 \ + -d $inner_prefix \ + --state ESTABLISHED,RELATED --icmpv6-type \ + unknown-header-type \ + -j ACCEPT + ip6tables -A icmpv6-filter -m state -p icmpv6 \ + -d $inner_prefix \ + --state ESTABLISHED,RELATED \ + --icmpv6-type unknown-option \ + -j ACCEPT + done + fi + + # Allow outgoing parameter problem code 1 and code 2 messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type unknown-header-type -j ACCEPT + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type unknown-option -j ACCEPT + done + + #@POLICY@ + # Allow incoming and outgoing parameter + # problem code 0 messages + for inner_prefix in $INNER_PREFIXES + do + ip6tables -A icmpv6-filter -p icmpv6 \ + --icmpv6-type bad-header \ + -j ACCEPT + done + + # NEIGHBOR DISCOVERY MESSAGES + # =========================== + + # Drop NS/NA messages both incoming and outgoing + ip6tables -A icmpv6-filter -p icmpv6 \ + --icmpv6-type neighbor-solicitation -j DROP + ip6tables -A icmpv6-filter -p icmpv6 \ + --icmpv6-type neighbor-advertisement -j DROP + + # Drop RS/RA messages both incoming and outgoing + ip6tables -A icmpv6-filter -p icmpv6 \ + --icmpv6-type router-solicitation -j DROP + ip6tables -A icmpv6-filter -p icmpv6 \ + --icmpv6-type router-advertisement -j DROP + + # Drop Redirect messages both incoming and outgoing + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP + + # MLD MESSAGES + # ============ + + # Drop incoming and outgoing + # Multicast Listener queries (MLDv1 and MLDv2) + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP + + # Drop incoming and outgoing Multicast Listener reports (MLDv1) + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP + + # Drop incoming and outgoing Multicast Listener Done messages (MLDv1) + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP + + # Drop incoming and outgoing Multicast Listener reports (MLDv2) + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP + + # ROUTER RENUMBERING MESSAGES + # =========================== + + # Drop router renumbering messages + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP + + # NODE INFORMATION QUERIES + # ======================== + + # Drop node information queries (139) and replies (140) + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP + ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP + + # MOBILE IPv6 MESSAGES + # ==================== + + # If there are mobile ipv6 home agents present on the + # trusted side allow + if [ "$HOME_AGENTS_PRESENT" -eq "1" ] + then + for inner_prefix in $INNER_PREFIXES + do + #incoming Home Agent address discovery request + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type 144 -j ACCEPT + #outgoing Home Agent address discovery reply + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type 145 -j ACCEPT + #incoming Mobile prefix solicitation + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type 146 -j ACCEPT + #outgoing Mobile prefix advertisement + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type 147 -j ACCEPT + done + fi + + # If there are roaming mobile nodes present on the + # trusted side allow + if [ "$MOBILE_NODES_PRESENT" -eq "1" ] + then + for inner_prefix in $INNER_PREFIXES + do + #outgoing Home Agent address discovery request + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type 144 -j ACCEPT + #incoming Home Agent address discovery reply + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type 145 -j ACCEPT + #outgoing Mobile prefix solicitation + ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ + --icmpv6-type 146 -j ACCEPT + #incoming Mobile prefix advertisement + ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ + --icmpv6-type 147 -j ACCEPT + done + fi + + # DROP EVERYTHING ELSE + # ==================== + + ip6tables -A icmpv6-filter -p icmpv6 -j DROP + Authors' Addresses Elwyn B. Davies Consultant Soham, Cambs UK Phone: +44 7889 488 335 Email: elwynd@dial.pipex.com @@ -1192,18 +1530,18 @@ 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. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.