Re: IPv6 and DHCP and ICMP

[John Ladwig <John.Ladwig () SO MNSCU EDU>]

Agreed, especially re: egress traffic.



To be fair, I think that a part of historic blocking of all ICMPv4 came from smurf and ICMP-composed DOS and DDOS 
attacks.  The rest can be explained by people not fully understanding the evolving role of ICMP in the IPv4 Internet, 
and the originally poor control flexibility for ICMP in earlier router ACLs and firewalls.



There's also a thread in the audit community that reinforces the "mappable networks are bad" paradigm.  Which isn't 
entirely without merit, but IPv6 does have scoped addresses especially for  multicast, plus we're planning to make use 
of additional strategies for Internet/institutional network traffic policy expressible in the fairly coarse mask-based 
ACLs available to us currently.



That said, we've pretty much decided that traceroute6 is going to be a fact of life in IPv6 networks.



   -jml


From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of randy 
marchany
Sent: Wednesday, May 23, 2012 9:31 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] IPv6 and DHCP and ICMP

One of the "prime directives" in any security  strategy is asking a) what is the purpose of a particular security 
control b) how effective is the control?

Which brings me to ICMP blocking? I believe it's totally ineffective for the reasons below.

What is the purpose of ICMP blocking? To keep someone from mapping your network? Do you think someone can't map your 
net if ICMP is blocked? Do you have wireless nets? Yes? Then your network is mapped. Do you have web servers? Yes? Then 
your net can be mapped. Do you have stateless firewalls at the border? Yes? Your net can be mapped by inverse mapping. 
Do you prevent "outbound" connections? Yes? then why not disconnect from the Internet :-)? No? your net has been mapped.
IMHO, blocking ICMP v4 or v6 accomplished nothing from a security perspective. There are far more effective strategies 
to accomplish the same goals. Our preliminary work with v6 (and by extension v4) is shows you can't hide a machine on 
the net if there's wireless connectivity. So why bother? Accept the fact that a machine can be identified on the net 
and change your focus to protecting the data on a machine rather than the machine itself.

So to answer the 2 initial questions I raised at the beginning of the post:

1. What is the purpose of ICMP blocking? To keep someone from mapping your net.
2. How effective is the control? Not effective at all because there are multiple ways to map a network and we cannot 
block all of them without interfering with the "business" purpose of your organization.

My personal opinion is that I don't care what comes into my net. I care about what "leaves" my net.  Protect the data.

-r.
On Wed, May 23, 2012 at 8:10 PM, Michael Sinatra <michael () rancid berkeley edu<mailto:michael () rancid berkeley 
edu>> wrote:
On 05/23/2012 14:22, John Ladwig wrote:
ICMPv4 should **never** have been "completely eliminated" from public

network (interacting with local network), but there's only a small set
of messages that **need** to pass an Internet/local policy boundary.

Limited, yes, but I've seen way to many blanket drop policies that I'm a
little touchy on the subject.

There's a slightly larger set of required ICMPv6 messages that must
cross an Internet/local policy boundary to enable, for example, path-MTU
discovery.

Our current proposals, LAN and WAN testbed configurations follow RFC
4890 ICMPv6 recommendations for firewall transit "must not be dropped"
and "normally should not be dropped" pretty closely, although we're not
currently testing mobile IPv6, and haven't decided whether to support it
in the near term.

+1 on RFC 4890--it's a really good resource both for firewalls and router ACLs.  Keep in mind that blocking all ICMPv6 
means blocking all IPv6.  You simply won't have connectivity if you block ND, for example.

michael