IPv6 Firewall - ICMP Error Message Handling (Tips for developers)

IPv4 ICMP handling by firewall is not critical. That is, if even ICMP messages are discarded by firewall,  many of IPv4 functions continue to work.  In IPv6, ICMP messages if not handled by firewall properly can break the IPv6 functions or reduce the performance of IPv6. For example:

• IPv6 ICMP Echo request and response messages can't be filtered blindly in IPv6. ICMP Echo request and response messages are used for proper functionality of Toredo tunneling. (Refer to rfc4380).
• Some ICMP types such as 'Neighbor solicition',  'Neighbor Advertisement',  'Router Solicitation' and 'Router Advertisement' are used to detect duplicate addresses, Stateless IP address assignment and router discovery.  These must be allowed by L2 firewall or by the router firewall for its local traffic.

 ICMP Error messages are very important for smooth IPv6 communications.  Firewalls should not be blindly dropping these packets.

• Unlike IPv4, IPv6 communication expects fragmentation and reassembly done by IPv6 end nodes.  The intermediate routers are expected to generate ICMP Error message Type 2 (Packet too big)  if the MTU of outbound interface is less than the packet size.  Intermediate router is expected to put the right PMTU value in the ICMP error message.  If these message don't go to transmitting end node, it does not have information on the PATH MTU and it continues to send packets with original MTU which gets dropped by the intermediate router.
• Destination Unreachable messages (Type 1) are also very important for applications running in end nodes to use alternative mechanisms.  If these messages are dropped by firewall,  applications in end nodes may take longer to use alternative mechanisms.
• Time Exceeded error message (Type 3) with Code 0 (Hopcount becomes 0) is needed for tracing the routers on the path.  Code 1 message is meant to indicate the end node did not receive all fragments with reassembly timeout.  It is really for debugging, but very much needed.
• Parameter Problem Error messages (Type 4) with Code 1(Unrecognized Next Header) and Code 2 (Unrecognized IPv6 Option) are useful for transmitted end node to know the extension headers and options to avoid in further communication.  

Unlike some ICMP messages, all ICMP Error messages work with unicast addresses.  Another important thing to observe is that ICMP Error messages can be generated by any router in between.  Many times these messages are not authenticated.  It means that  any attacker can send the ICMP Error messages.  Firewalls play very important role in filtering the bad and reducing the flood of ICMP Error messages reaching the trusted boundary.

If firewall allows attacker ICMP error messages,  receiving host can act on these messages and it might result to poor performance or some times even communication ceases.  For example by sending very small MTU in path MTU messages, attacker can make the end host to do excessive fragmentation there by reducing the performance of the end system and also the network.  By sending bad destination unreachable or parameter problem error messages, it can let end hosts choose alternative paths which might be expensive or they might make end hosts to back off for some time or they might even make the current active connection fail.

What is expected by firewalls to mitigate attacks resulting from malicious ICMP error messages yet still allowing genuine ICMP Error messages. Though there is a no solutions that works all the time,  but by following some guidelines the efficacy of attacker can be reduced significantly.  Some of the techniques are similar to IPv4 firewalls. 

• Check the destination IP of the outer IP packet of ICMP Error message. It should be same as the source IP of the original IP packet (inner IP packet).
• Make the firewall stateful.  Stateful firewalls typically create a session for each UDP/TCP and other connections.  When the ICMP Error message is generated by intermediate routers or destination node, it is expected to contain IP header of the original message and 8 bytes of transport header.  With this information in the ICMP Error message,   firewall can match the original session.  If there is session, there is a good confidence that the message is not spoofed.  For an attacker, it would be difficult to guess all 5 tuples of the original connections, specifically source port which changes for each connection.  
• In case of TCP connection, additional check can be made to ensure that ICMP error message is not generated by the attacker.  ICMP Error messages with  8 bytes of transport header contains the sequence number field.   If it is generated by the genuine router, then it would have done based on the TCP packet of original connection.  Firewall can check this sequence number with TCP state variables it is maintaining in the session. If the sequence number of the partial TCP header of ICMP error message is within some range of the sequence number maintained by the session, then firewall can believe it is a genuine ICMP error message as it would be difficult for attackers to guess the sequence number. 
• Any ICMP Error message that comes in when the idle flow of session is also can be considered as bad packet and can be dropped by firewall.  Firewall can maintain the time stamp in each flow whenever there is packet sent out.  If the ICMP Error message is received within the stored timestamp + X seconds, it can be considered as genuine.  If it is received after X value of last time stamp, then the ICMP error message can be dropped.

Though the stateful firewall can detect many spoofed ICMP error messages,  still it is expected that the administrator have control over ICMP error messages types (and codes) that are to be allowed to trusted networks.  Though it is unlikely that this control is expected on IP address/network basis,  but this control is expected on set of zones.

Data Model can be following:

•  internetGatewayDevice.security.VirtualInstance.{i}.ipv6firewall.icmpErrorMessageFilter  
• allowAll : String(8), RW : Takes value "yes" or "no":  Indicates whether to allow all ICMP Error message if there is a session match.  Following table indicates the allowed ICMP Error messages when this value is 'no'.
• minPMTUValueToAccept:  RW, Unsigned Int:  This indicates minimum PMTU value.  Firewall drops the ICMP Error message Type 2 if the PMTU value is less than this configured value.
• internetGatewayDevice.security.VirtualInstance.{i}.ipv6firewall.icmpErrorMessageFilter.allowList.{i}: Table whose rows can be added, modified and deleted by administartors
• rule ID :  RW, Unsigned Int,  Can't be modified once created -  Rule ID to identify the rule.l
• Description:  RW,  String(32), Optional -  Description of the record.
• FromZone: String(32), RW - One of the Zone IDs. It takes value of ZoneName from internetGatewayDevice.securityDomains.VirtualInstance.{i}.Zone.{i} table.
• ToZone: String(32), RW - One of the Zone IDs. It takes value of ZoneName from internetGatewayDevice.securityDomains.VirtualInstance.{i}.Zone.{i} table.
• icmpMessageType:  RW, Unsigned Int:  ICMP Error message type.
• icmpMessageCodeAll :  RW,  String(8), Yes or no:  "yes' indicates that all codes are allowed within ICMP message type given in 'icmpMessageType'.
• icmpMessageCode: RW, Unsigned Int,  ICMP Error message code.  Code is unique within a icmpMessageType.  Valid only if 'icmpMessageCodeAll' is "no",

It is strongly recommended to create a hash table based on ICMP message type for faster lookup.

"Recommendation for filtering ICMPv6 messages in Firewall - RFC 4890" recommends that the firewall allow some ICMP Error message types always.  To conform to this standard, it is suggested that the firewall creates rules in above table as factory defaults.  Those are:

•  Type1 (Destination Unreachable) and all codes
• Type2 (Packet too big)
• Type 3 (Time Exceeded)  : Code 0 ( Hop Count limit reached) and Code 1 (Reassembly timeout reached)
• Type 4 ( Parameter Problem) :  Code 0 (Erroneous Header),  Code 1 (Unrecognized Next Header),  Code 2 (Unrecognized IPv6 Option)

This article talked about handling of ICMP Error messages by firewalls.  In my next article, I would briefly describe the normal ICMP message handling by firewalls.