Networking-Blog

My WordPress Blog

Categories

ICMP TYPE NUMBERS 

ICMP TYPE NUMBERS

The Internet Control Message Protocol (ICMP) has many messages that
are identified by a "type" field.

Type	Name					Reference
----	-------------------------		---------
  0	Echo Reply				 [RFC792]
  1	Unassigned				    [JBP]
  2	Unassigned				    [JBP]
  3	Destination Unreachable			 [RFC792]
  4	Source Quench			 	 [RFC792]
  5	Redirect				 [RFC792]
  6	Alternate Host Address			    [JBP]
  7	Unassigned				    [JBP]
  8	Echo Request			        [RFC792]
  9	Router Advertisement			[RFC1256]
 10	Router Selection			[RFC1256]
 11	Time Exceeded				 [RFC792]
 12	Parameter Problem			 [RFC792]
 13	Timestamp				 [RFC792]
 14	Timestamp Reply				 [RFC792]
 15	Information Request			 [RFC792]
 16	Information Reply			 [RFC792]
 17	Address Mask Request                     [RFC950]
 18	Address Mask Reply			 [RFC950]
 19	Reserved (for Security)			   [Solo]
 20-29	Reserved (for Robustness Experiment)	    [ZSu]
 30	Traceroute				[RFC1393]
 31	Datagram Conversion Error		[RFC1475]
 32     Mobile Host Redirect              [David Johnson]
 33     IPv6 Where-Are-You                 [Bill Simpson]
 34     IPv6 I-Am-Here                     [Bill Simpson]
 35     Mobile Registration Request        [Bill Simpson]
 36     Mobile Registration Reply          [Bill Simpson]
 37     Domain Name Request                     [Simpson]
 38     Domain Name Reply                       [Simpson]
 39     SKIP                                    [Markson]
 40     Photuris                                [Simpson]
 41-255 Reserved				    [JBP]
CheckPoint, Cisco Routers, FireWalls
No comments yet.

Tags:

by admin

ICMP Access-List

ASA/PIX Inbound ICMP through the PIX is denied by default;
outbound ICMP is permitted, but the incoming reply is denied by default.

Pings Outbound

Responses to outbound ICMP can be permitted with either a conduit statement or an
access-list statement, based on which you use on the PIX. Do not mix conduits and access lists.

This example shows how to permit responses to ICMP requests initiated by device 10.1.1.5 inside
(static to 192.168.1.5) from all devices outside:

static (inside,outside) 192.168.1.5 10.1.1.5 netmask 255.255.255.255 0 0

!— and either

conduit permit icmp 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 echo-reply
conduit permit icmp 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 source-quench
conduit permit icmp 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 unreachable
conduit permit icmp 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 time-exceeded

!— or

access-list 101 permit icmp any host 192.168.1.5 echo-reply
access-list 101 permit icmp any host 192.168.1.5 source-quench
access-list 101 permit icmp any host 192.168.1.5 unreachable
access-list 101 permit icmp any host 192.168.1.5 time-exceeded
access-group 101 in interface outside

Pings Inbound

Pings initiated from the outside, or another low security interface of the PIX,
are denied be default. The pings can be allowed by the use of static and
access lists or access lists alone.

In this example, one server on the inside of the PIX is made accessible to external pings.
A static translation is created between the inside address (10.1.1.5) and the outside address (192.168.1.5).

pix(config)#static (inside,outside) 192.168.1.5 10.1.1.5 netmask 255.255.255.255
pix(config)#access-list 101 permit icmp any host 192.168.1.5 echo
pix(config)#access-group 101 in interface outside

 

In this example, the PIX cannot send echo replies in response to echo requests:

icmp deny any echo outside

As with access lists, in the absence of permit statements, there is also an implicit deny of all other ICMP traffic.

This command permits pings from the network immediately outside the PIX:

icmp permit 192.168.1.0 255.255.255.0 echo outside

As with access lists, in the absence of permit statements, there is also an implicit deny of all other ICMP traffic.
!
!
To ping the pix inside ip address from the other side of the tunnel,
you will need to enable “management-access inside“.
!
As far as pinging from the pix, you would need to create an IPSEC SA that
contains the pix outside ip address since the source of the ICMP packet will
be the outside interface address.
eq :

ping 172.20.186.1 inside
ping 80.233.56.1 outside

Cisco Routers
No comments yet.

Tags:

by admin

Path MTU Discovery and Filtering ICMP

Path MTU

 

The smallest MTU of any link on the current path between two hosts.
This may change over time since the route between two hosts, especially on the Internet, may change over time. It is not necessarily symmetric and can even vary for different types of traffic from the same host.

Fragmentation

When a packet is too large to be sent across a link as a single unit, a router can fragment the packet.
This means that it splits it into multiple parts which contain enough information for the receiver to glue them together again. Note that this is not done on a hop-by-hop basis, but once fragmented a packet will not be put back together until it reaches its destination.

Fragmentation is undesirable for numerous reasons, including:

  • If any one fragment from a packet is dropped, the entire packet needs to be retransmitted. This is a very significant problem.
  • It imposes extra processing load on the routers that have to split the packets.
  • In some configuration, simpler firewalls will block all fragments because they don’t contain the header information for a higher layer protocol (eg. TCP) needed for filtering.

DF (Don’t Fragment) bit


This is a bit in the IP header that can be set to indicate that the packet should not be fragmented by routers, but instead an ICMP “can’t fragment” error is returned sent to the sender and the packet is dropped.

ICMP Can’t Fragment Error


This error (type 3 (destination unreachable), code 4 (fragmentation needed but don’t-fragment bit set)) is returned by a router when it receives a packet that is too large for it to forward and the DF bit is set.
The packet is dropped and the ICMP error is sent back to the origin host.

Normally, this tells the origin host that it needs to reduce the size of its packets if it wants to get through. Recent systems also include the MTU of the next hop in the ICMP message so the source knows how big its packets can be.
Note that this error is only sent if the DF bit is set; otherwise, packets are just fragmented and passed through.

MSS

The MSS is the maximum segment size.
It can be announced during the establishment of a TCP connection to indicate to the other end the largest amount of data in one packet that should be sent by the remote system.

Normally the packet generated will be 40 bytes larger than this; 20 bytes for the IP header and 20 for the TCP header. Most systems announce a MSS that is determined from the MTU on the interface that the traffic to the remote system passes out from the system through.

Path MTU Discovery (PMTU-D)

Now you know that Path MTUs vary.
You know that fragmentation is bad.

The solution?

Well, one solution is Path MTU Discovery.

A. The idea behind it is to send packets that are as large as possible while still avoiding fragmentation.

B. A host does this by starting by sending packets that have a maximum size of the lesser of the local MTU or the MSS announced by the remote system.

C. These packets are sent with the DF bit set.

D. If there is some MTU between the two hosts which is too small to pass the packet successfully, then an ICMP can’t fragment error will be sent back to the source. It will then know to lower the size; if the ICMP message includes the next hop MTU, it can pick the correct size for that link immediately, otherwise it has to guess.

Now, to the problem with ICMP filtering and PMTU-D

Many network administrators have decided to filter ICMP at a router or firewall.
There are valid (and many invalid) reasons for doing this, however it can cause problems. ICMP is an integral part of the Internet and can not be filtered without due consideration for the effects.


In this case, if the ICMP can’t fragment errors can not get back to the source host due to a filter, the host will never know that the packets it is sending are too large.

This means it will keep trying to send the same large packet, and it will keep being dropped–silently dropped from the view of any system on the other side of the filter.

While a small handful of systems that implement PMTU-D also implement a way to detect such situations, most don’t and even for those that do it has a negative impact on performance and the network.

Many packet filters will allow you to setup filters to only allow certain types of ICMP messages through.


e.g :

access-list  199 remark Permit Path MTU to function.
access-list 199 permit icmp any any packet-too-big

If you reconfigure them to let ICMP can’t fragment (type 3, code 4) messages through the firewall, the problem should disappear.

Cisco Routers
No comments yet.

Tags: , ,

by admin