Here's a link to what firewalking is actually meant for:

http://articles.techrepublic.com.com/5100-10878_11-5055357.html

Basically, the idea of firewalking is to send traffic with increased TTL (time to live) to they'll try to go PAST the firewall.  This is effective in that, if a port is open on the firewall, you can get past the firewall, and enumerate services running on servers / machines sitting in the DMZ, or on the production network (if the DMZ isn't properly configured, or is not being used.)

It IS a popular technique, and I use it all the time, as do others, in testing the effectiveness of ACL's.  Basically, you'll quickly find out if ACL's are only allowing traffic to the proper hosts behind the firewall, if they're blocking the traffic, or if they're not stopping anything, at all, and you start seeing responses from systems that SHOULDN'T be accessible from the public firewall / router interfaces.

It can be handy, as sometimes, you'll find a vulnerable machine / service sitting in there, that you wouldn't normally find through 'traditional' port scans and others, and it allows you to 'map out' the dmz, etc.

HTH.

Great I see that It is a technique that must or should be used as a complement with of an nmap scan

If you disable the outbound ICMP you would also effect the internal users wanting to get out.  Is it an option to disable the inbound ICMP?  Granted, this would still allow an attacker internally from firewalking from an internal server to see what outbound ports are available on the firewall.

I see that the common thing to do is to block only incoming traffic from the outside and let all the outgoing icmp pass