Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

ICMP(v6) filtering?

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


shane at time-travellers

Aug 3, 2012, 12:39 AM

Post #1 of 15 (1003 views)
Permalink
ICMP(v6) filtering?

All,

Is there any reason to filter ICMP6? Specifically the ones that I
actually see when debugging, such as echo (ping) and destination
unreachable (traceroute)?

Do people on this list filter such traffic?

It annoys me, but I may be missing something important.

Cheers,

--
Shane


gert at space

Aug 3, 2012, 12:42 AM

Post #2 of 15 (977 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

Hi,

On Fri, Aug 03, 2012 at 09:39:18AM +0200, Shane Kerr wrote:
> Is there any reason to filter ICMP6? Specifically the ones that I
> actually see when debugging, such as echo (ping) and destination
> unreachable (traceroute)?
>
> Do people on this list filter such traffic?
>
> It annoys me, but I may be missing something important.

We do not filter any ICMP (we do rate-limit ICMP to our routers, though,
to protect the control-plane). I like ping and traceroute :-)

If a customer insists on filtering ICMP, I point them at RFC4890

4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E.
Davies, J. Mohacsi. May 2007. (Format: TXT=83479 bytes) (Status:
INFORMATIONAL)

... which usually results in a reasonable compromise...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279


me at benedikt-stockebrand

Aug 3, 2012, 5:39 AM

Post #3 of 15 (978 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

Hi Shane and list,

> Is there any reason to filter ICMP6?

yes, in some cases you may want to filter e.g. routing headers and
such. More generally speaking, with new ICMP6 types possibly coming
up you may want to whitelist rather than blacklist individual ICMP6
types/codes.

> Specifically the ones that I actually see when debugging, such as
> echo (ping) and destination unreachable (traceroute)?

Ping is a matter of personal preferences, or more specifically if you
rather want to explain an external security auditor why you leave your
network open to scanning (assuming he has the average sub-limited
knowledge of IPv6) or if you rather have the necessary infrastructure
at hand to diagnose and fix a network problem.

It's really your call, or maybe your management's.

As far as the unreachables go, this is generally considered something
not to block because it leads to horrendous timeout behaviours. Geoff
Houston had a couple of implementation specific timeout values for
various OSes at the last RIPE meeting in Ljubljana---IIRC they went up
as far as three minutes.

> Do people on this list filter such traffic?

If I was an ISP I'd rather not filter them---doing so is likely to
cause trouble with customers doing things one doesn't expect. But on
a leaf site I prefer to whitelist ICMP6s. I allow

1 Destination unreachable
2 Packet too big
3 Hop Limit exceeded
4 Parameter Problem
135, 136 Neighbor Discovery

because they are in virtually all cases essential for normal
operation. Additionally I allow

128, 129 Echo Request/Reply

because I want to be able to monitoring and troubleshoot, in
subnets where I use autoconfiguration I also allow

133, 134 Router Solicitation/Advertisement

and finally in case I accidentially upgrade a switch with something
MLD-aware

130-132, 143 Multicast Listener Discovery

Everything else is blocked. This includes

137 Redirect

because in the network topology I'm currently running they can't occur
anyway, and

138 Router renumbering

because (a) I don't use it and (b) this one has rather serious
security implications. Plus whatever routing headers and such that
don't even make it on my personal list of relevant ICMP6 types.


Finally, you can frequently limit a number of ICMP6 types to traffic
between link-local addresses, with hop limit of 255, and especially if
you're using Linux exclude them from being forwarded.

> It annoys me, but I may be missing something important.

Well, the most important thing is probably some new ICMP6 type being
defined and causing significant trouble on existing implementations.


Cheers,

Benedikt

--
Business Grade IPv6
Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/


phil at philkern

Aug 3, 2012, 5:48 AM

Post #4 of 15 (977 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On Fri, Aug 03, 2012 at 12:39:16PM +0000, Benedikt Stockebrand wrote:
> > Specifically the ones that I actually see when debugging, such as
> > echo (ping) and destination unreachable (traceroute)?
> Ping is a matter of personal preferences, or more specifically if you
> rather want to explain an external security auditor why you leave your
> network open to scanning (assuming he has the average sub-limited
> knowledge of IPv6) or if you rather have the necessary infrastructure
> at hand to diagnose and fix a network problem.

And you trade that with being unable to communicate with Teredo hosts.
Depending on what you do there's potentially a lot of Teredo traffic[1].
That's why echo request/reply is in the "must not filter" list in
RFC4890.

But then I guess that Windows would actually prefer IPv4 communication
to IPv6 Teredo communication, so the legacy IP fallback might save you
in some cases.

Kind regards
Philipp Kern

[1] With Bittorrent running behind IPv4 NAT and native IPv6 it's likely
that you receive most of the data from Teredo endpoints. At
surprisingly good speeds.
Attachments: signature.asc (0.57 KB)


merike at doubleshotsecurity

Aug 3, 2012, 6:52 PM

Post #5 of 15 (969 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On Aug 3, 2012, at 12:42 AM, Gert Doering wrote:

> Hi,
>
> On Fri, Aug 03, 2012 at 09:39:18AM +0200, Shane Kerr wrote:
>> Is there any reason to filter ICMP6? Specifically the ones that I
>> actually see when debugging, such as echo (ping) and destination
>> unreachable (traceroute)?
>>
>> Do people on this list filter such traffic?
>>
>> It annoys me, but I may be missing something important.
>
> We do not filter any ICMP (we do rate-limit ICMP to our routers, though,
> to protect the control-plane). I like ping and traceroute :-)
>
> If a customer insists on filtering ICMP, I point them at RFC4890
>
> 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E.
> Davies, J. Mohacsi. May 2007. (Format: TXT=83479 bytes) (Status:
> INFORMATIONAL)
>
> ... which usually results in a reasonable compromise...

ICMP filtering started with smurf attack in mid 90's. It doesn't necessarily make sense for IPv6 IMHO.

Rate limiting is what I've seen most folks implement and what I usually recommend since configuring explicit ICMPv6 filters
for specific types ends up inevitably with some mistakes and operational issues.

- merike


dougb at dougbarton

Aug 5, 2012, 8:00 PM

Post #6 of 15 (949 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On 08/03/2012 05:39, Benedikt Stockebrand wrote:
> yes, in some cases you may want to filter e.g. routing headers and
> such.

Do you have references to this issue?

> More generally speaking, with new ICMP6 types possibly coming
> up you may want to whitelist rather than blacklist individual ICMP6
> types/codes.

This is the opposite of what should be done, for 2 reasons. First, you
should only blacklist things you know you're having problems with.
Second, but taking the approach you suggest you miss out if the protocol
changes and you don't update your filters.

The whole concept of blanket ICMP restrictions in v4 was bad, doing it
for ICMPv6 is really bad.

--

I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)


cb.list6 at gmail

Aug 5, 2012, 8:04 PM

Post #7 of 15 (954 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On Aug 5, 2012 8:00 PM, "Doug Barton" <dougb [at] dougbarton> wrote:
>
> On 08/03/2012 05:39, Benedikt Stockebrand wrote:
> > yes, in some cases you may want to filter e.g. routing headers and
> > such.
>
> Do you have references to this issue?
>

http://tools.ietf.org/html/rfc5095

> > More generally speaking, with new ICMP6 types possibly coming
> > up you may want to whitelist rather than blacklist individual ICMP6
> > types/codes.
>
> This is the opposite of what should be done, for 2 reasons. First, you
> should only blacklist things you know you're having problems with.
> Second, but taking the approach you suggest you miss out if the protocol
> changes and you don't update your filters.
>
> The whole concept of blanket ICMP restrictions in v4 was bad, doing it
> for ICMPv6 is really bad.
>
> --
>
> I am only one, but I am one. I cannot do everything, but I can do
> something. And I will not let what I cannot do interfere with what
> I can do.
> -- Edward Everett Hale, (1822 - 1909)


dougb at dougbarton

Aug 5, 2012, 8:07 PM

Post #8 of 15 (951 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On 08/05/2012 20:04, Cameron Byrne wrote:
> On Aug 5, 2012 8:00 PM, "Doug Barton" <dougb [at] dougbarton
> <mailto:dougb [at] dougbarton>> wrote:
>>
>> On 08/03/2012 05:39, Benedikt Stockebrand wrote:
>> > yes, in some cases you may want to filter e.g. routing headers and
>> > such.
>>
>> Do you have references to this issue?
>>
>
> http://tools.ietf.org/html/rfc5095

Oh yeah, that ... I thought people would have upgraded by now. :)


--

I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)


me at benedikt-stockebrand

Aug 7, 2012, 4:03 AM

Post #9 of 15 (906 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

Hi Doug and list,

Doug Barton <dougb [at] dougbarton> writes:

> On 08/03/2012 05:39, Benedikt Stockebrand wrote:
>> yes, in some cases you may want to filter e.g. routing headers and
>> such.
>
> Do you have references to this issue?

as Cameron pointed out there is a chance that there are still type 0
routing header implementations around; especially with long-lived
embedded devices (think network printers if nothing else) this can be
an issue.

Plus, I have network printer here which actually supports some basic
IPv6 but it didn't tell anywhere in the specs when I bought it (about
5--7 years ago); while I can protect its possibly rather buggy
implementation by simply keeping it inaccessible from anywhere except
trusted clients, other people may not be as lucky.

Additionally, I still remember at least one ICMP6 type being assigned
by IANA that was implemented in at least some BSD kernels but never
reached RFC status; the draft has long since expired, but the
implementation may still be out there.

And if you're connecting devices to untrusted networks (think
auditorium WLANs in a college/university), then you should consider
(and I mean "consider", not "just do without further thought")
filtering router advertisements and ICMP6 redirects as well.

>> More generally speaking, with new ICMP6 types possibly coming
>> up you may want to whitelist rather than blacklist individual ICMP6
>> types/codes.
>
> This is the opposite of what should be done, for 2 reasons. First, you
> should only blacklist things you know you're having problems with.
> Second, but taking the approach you suggest you miss out if the protocol
> changes and you don't update your filters.
>
> The whole concept of blanket ICMP restrictions in v4 was bad, doing it
> for ICMPv6 is really bad.

That depends.

In an ISP or similar context, basically whenever I am providing
unrestricted network connectivity for others, I'd do absolutely
nothing about ICMP6 filtering for my users/customers, and only rate
limit ICMP6 for my own equipment. That's an extreme case, even if it
is fairly common for a lot of people on this list.

But if you need to maintain security in a tightly controlled
(e.g. corporate or governmental) network with strictly defined
functionality, then that's a different situation; in that case you
effectively have to find a balance between micro-managing anything
that's allowed ("in triplicate, and signed by the entire management
board"), preserving flexibility for changing network usage, support
for devices outside your administrative control, and the capability to
quickly fix problems.

I personally consider filtering echo requests/replies rather extreme,
but from what I've learned from some customers these extreme cases do
exist and sometimes require such extreme measures. And, to reply on
Philipp's comment, no, Teredo is not an issue in such environments.


Think about it another way: There are people out there who actually
understand IPv6 well enough to implement it; if these people bother to
add filters of some kind, then there's a chance they've run into some
installation that actually made that filter useful---it's not always
done just due to customer pressure.


Cheers,

Benedikt

--
Business Grade IPv6
Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/


phil at philkern

Aug 7, 2012, 1:08 PM

Post #10 of 15 (902 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

Hi,

am Sun, Aug 05, 2012 at 08:00:05PM -0700 hast du folgendes geschrieben:
> The whole concept of blanket ICMP restrictions in v4 was bad, doing it
> for ICMPv6 is really bad.

I would like to whitelist ICMPv6 to all hosts in our network, even if the
TCP/UDP ports are currently filtered statefully and need explicit whitelisting.
But is there a cunning plan to stop address sweeping attacks that cause a lot
of neighbor solicitations and cache entries? We already have this problem with
IPv4, given that we have quite a bit of unused (legacy) space. Is the only
level to solve that some kind of IDS/IPS? Or is there also a way to rate-limit
such traffic? (Possibly at the expence of some legitimate neighbor
solicitations.)

Kind regards
Philipp Kern
Attachments: signature.asc (0.57 KB)


shade at shadez

Aug 7, 2012, 1:16 PM

Post #11 of 15 (907 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

Hi Phillip,

Without having checked this, weren't neighbour solicitations sent with TTL
1 to avoid specifically this problem?

Kind regards,

Dimitar Pavlov
On Aug 7, 2012 11:08 PM, "Philipp Kern" <phil [at] philkern> wrote:

> Hi,
>
> am Sun, Aug 05, 2012 at 08:00:05PM -0700 hast du folgendes geschrieben:
> > The whole concept of blanket ICMP restrictions in v4 was bad, doing it
> > for ICMPv6 is really bad.
>
> I would like to whitelist ICMPv6 to all hosts in our network, even if the
> TCP/UDP ports are currently filtered statefully and need explicit
> whitelisting.
> But is there a cunning plan to stop address sweeping attacks that cause a
> lot
> of neighbor solicitations and cache entries? We already have this problem
> with
> IPv4, given that we have quite a bit of unused (legacy) space. Is the only
> level to solve that some kind of IDS/IPS? Or is there also a way to
> rate-limit
> such traffic? (Possibly at the expence of some legitimate neighbor
> solicitations.)
>
> Kind regards
> Philipp Kern
>


phil at philkern

Aug 7, 2012, 1:26 PM

Post #12 of 15 (905 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On Tue, Aug 07, 2012 at 11:16:07PM +0300, Shade wrote:
> Without having checked this, weren't neighbour solicitations sent with TTL
> 1 to avoid specifically this problem?

Well, yeah, the case I'm concerned about is traffic to non-existent addresses.
Not packets with solicitations themselves. Basically the router taking care of
getting its cache up-to-date. We already had the problem with ARP.

Kind regards
Philipp Kern


ek at google

Aug 7, 2012, 1:38 PM

Post #13 of 15 (898 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

http://tools.ietf.org/html/rfc6583 tried to capture some of these
concerns. See also: http://tools.ietf.org/html/rfc6583#section-6 ;
http://tools.ietf.org/html/rfc6583#section-7


mch-v6ops at xs4all

Aug 8, 2012, 1:28 AM

Post #14 of 15 (891 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

>
> But is there a cunning plan to stop address sweeping attacks that cause a lot
> of neighbor solicitations and cache entries? We already have this problem with

Simply rate limit ND? And the more important question, what would people assume is a fair limit for a LAN which has let's say 100 hosts attached?

Marco


dr at cluenet

Aug 8, 2012, 1:42 AM

Post #15 of 15 (896 views)
Permalink
Re: ICMP(v6) filtering? [In reply to]

On Wed, Aug 08, 2012 at 10:28:05AM +0200, Marco Hogewoning wrote:
> > But is there a cunning plan to stop address sweeping attacks that cause a lot
> > of neighbor solicitations and cache entries? We already have this problem with
>
> Simply rate limit ND?

It's not as simple as that, otherwise it would be a non-issue. See RFC
6583 for a discussion of the problem, especially section 6.4.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.