Polling a little bit here, there's an active discussion going on
6man@ietf about whether or not v6 routers should:
o be required to implement ip redirect functions (icmpv6 redirect)
o be sending these by default
Essentially 12+ years ago in RFC2461
(http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861
(http://tools.ietf.org/html/rfc4861) there are a set of message types
defined and use cases discussed which seem to lead to the idea that:
routers should be reqiured to implement redirect logic/functionality
routers should by default be enabled to send these redirect messages.
In ipv4 there's a relatively widely used practice of disabling ip
redirects. secure router and secure host templates disable this
functionality, and have for quite some time. There are a host of
reasons for this I don't really want to debate them though 
It would
be instructive to get a sense of how many folks do NOT disable this
sort of thing, or how many folks RELY on these functions working in
their network build today.
For the 6man discussion though, I presume that in ipv4 we take a set
of configs/actions because of somewhat sane reasons, I suspect we
would want to have the same config/end-state in v6? One proposal is to
do this with:
o routers are required to be able to send redirect messages
o routers should NOT do this by default
With the proviso that some consenting adults may choose to enable by
default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that
muddies the waters it'd be nice to just hear about the proposal there
and leave the hinkiness of the rest out of the picture I hope that
folks who currently run v6 network(s) might respond, there are quite a
few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk...
thanks for your time, of couse if you want to chat more directly about
this the 6man list is open and at:
<http://www.ietf.org/mail-archive/web/ipv6/current/maillist.html>
-Chris
Why should the ietf dictate a default on this? Requiring implementation I could understand, but setting the default? Should the ietf also specify requirement of allowing configuration change of a default?
Honestly, redirects are not near the problem as icmp unreachables.
Jack
Christopher Morrow wrote:
Why should the ietf dictate a default on this?
Because that's what the IETF does, sets a SHOULD on "best common practice" after discussion in the community.
Requiring implementation I could understand, but setting the default? Should the ietf also specify requirement of allowing configuration change of a default?
I'd say by definition it's meaningless of talking about a default that can't be changed.
As I stated in the 6man discussion, I prefer routers to by default not send redirects. We do that in our configuration template.
Mikael Abrahamsson wrote:
As I stated in the 6man discussion, I prefer routers to by default not send redirects. We do that in our configuration template.
I often turn them off, but I'm not sure why. If they aren't needed, generally they won't be issued anyways (p2p links, router only segments, etc). About the only case where they might be issued and I don't want them is in policy routing situations. In host based broadcast domains, I usually want them to limit the amount of traffic redirection I need to do.
Jack
I concur with this position from an opsec standpoint; at the same time, I don't know that *mandating* a default configuration setting for a legal (if largely iatrogenic) mode of operation is something that the IETF should be doing.
Here's an alternate formulation which gets the point across, but doesn't stray into the area of :
1. Routers are required to be able to send redirect messages.
2. It is recommended that routers should NOT do this by default.
As was mentioned somewhere in the 6man thread, the root of the problem has to do with the ugliness of IPv6 in general, and the whole v6 ICMP/ND mess in particular. Unfortunately, those ships have long since sailed; while it's tempting to try and retrofit fixes for poor design decisions in the fundamental protocol specifications by mandating sane implementation defaults in conformance documents, a recommendation rather than a mandate seems more situationally-appropriate in this context.
The 'right way', impractical though it may be, is in fact to fix this problem is to go back and fix the protocol specifications; since that isn't going to happen, making recommendations gets the point across without being overbearing.
YMMV, of course.
I do not currently have an IPv6 deployment, so my input may be lacking
in real usefulness here. With IPv4, however, I have been a little
irritated at a few situations where I NEEDED this to work and it did not
(certain PIX routers come to mind here). There are risks involved with
ANY "automated" type traffic to be sure, but for my money, it SHOULD be
possible to configure every router to support the network needs. So for
my money, I'd suggest:
* routers MUST support ip redirect
* "default" configurations irrelevant to me
I do agree with one or two of the other posters that it should not be
within the purview of the IETF to "mandate" these defaults. Each of us
will learn the defaults of the particular gear we use and can adjust
config templates to match, given the needs of the network we are
deploying. Just my $0.02 (may be worth less than that)
One of the challenges is that some vendors have a poor track-record of
documenting these defaults. this means unless you frequently sample
your network traffic, you may not see your device sending decnet mop
messages, or ipv6 redirects
Personally (and as the instigator in the ipv6/6man discussion) if the
vendors could be trusted to expose their default settings in their
configs, i would find a default of ON to be more acceptable. As their
track-record is poor, and the harm has been realized in the network we
operate (at least), I am advocating that as a matter of policy enabling
redirects not be a default-on policy. If people want to hang themselves
that's their problem, but at least they won't come with a hidden noose
around their neck.
- Jared
Redirects in IPv6 are no worse nor better an idea than unauthenticated RAs for default routers with nearly identical security implications.
Owen
Redirects in IPv6 are no worse nor better an idea than unauthenticated RAs for default routers with nearly identical security implications.
this answered a different question... wanna try answering the question
I posed originally? 
-chris
One of the challenges is that some vendors have a poor track-record of
documenting these defaults. this means unless you frequently sample
your network traffic, you may not see your device sending decnet mop
messages, or ipv6 redirects
I agree.
Personally (and as the instigator in the ipv6/6man discussion) if the
vendors could be trusted to expose their default settings in their
configs, i would find a default of ON to be more acceptable.
The reason it doesn't matter to me WHICH one it is (on OR off) is
because if/when a need arises to have ICMP redirect to be working (this
is the exception and NOT the norm), it is easy to see why things do not
work as expected. If my preferred gear is a Linux box (and it is,
usually), and for some reason I need this to work, I simply run a
tcpdump to capture the packets and I see that the redirect (which would
be expected) is missing, then I can easily fix the problem by enabling
that feature. Same is true for the reverse.
If people want to hang themselves
that's their problem, but at least they won't come with a hidden noose
around their neck.
Maybe I'm missing something. Can you point me to something that will
help my understand WHY an ICMP redirect is such a huge security concern?
For most of the networks that I manage (or help to manage), I can see no
reason why this would be an issue.
Polling a little bit here, there's an active discussion going on
6man@ietf about whether or not v6 routers should:
o be required to implement ip redirect functions (icmpv6 redirect)
o be sending these by default
I do not currently have an IPv6 deployment, so my input may be lacking
in real usefulness here. With IPv4, however, I have been a little
irritated at a few situations where I NEEDED this to work and it did not
(certain PIX routers come to mind here). There are risks involved with
ANY "automated" type traffic to be sure, but for my money, it SHOULD be
possible to configure every router to support the network needs. So for
my money, I'd suggest:
* routers MUST support ip redirect
* "default" configurations irrelevant to me
I do agree with one or two of the other posters that it should not be
within the purview of the IETF to "mandate" these defaults. Each of us
will learn the defaults of the particular gear we use and can adjust
config templates to match, given the needs of the network we are
deploying. Just my $0.02 (may be worth less than that)
One of the challenges is that some vendors have a poor track-record of
documenting these defaults. this means unless you frequently sample
and changing them... so, picking a good default I think is important.
You'd prefer less config headaches I bet vs having to constantly hack
templates?
your network traffic, you may not see your device sending decnet mop
messages, or ipv6 redirects
Personally (and as the instigator in the ipv6/6man discussion) if the
yes thanks! (just following a path as requested by another 6man person)
vendors could be trusted to expose their default settings in their
configs, i would find a default of ON to be more acceptable. As their
track-record is poor, and the harm has been realized in the network we
operate (at least), I am advocating that as a matter of policy enabling
redirects not be a default-on policy. If people want to hang themselves
that's their problem, but at least they won't come with a hidden noose
around their neck.
yes, that was my point as well.
-chris
as always, thanks! I am hoping we all don't have to continue to
hack templates, if the option is sane to begin with and is documented
in the code/config/docs by the vendor(s).
-Chris
In general, it's not a big deal, except that unlike a proper routing protocol
where you can redirect a /16 or a /default at a time and withdraw it when
needed, ICMP redirects tend to form host routes that have to individually be
redirected back if the routing flips back to its original status.
Until a PC or something on the network gets pwned, and issues selective forged
ICMP redirects to declare itself a router and the appropriate destination for
some traffic, which it can then MITM to its heart's content. *Then* you truly
have a manure-on-fan situation.
While I don't disagree with your assessment, isn't this true beyond JUST
this one function? I mean, if I understand the "problem" correctly, is
it the EXISTENCE of ICMP redirect that is the "security hole" or is it
that it is used by a router? Don't most host operating systems ignore
an ICMP redirect for a host if they are not asking for a route anyway?
(I'm not sure I stated that very well...) In other words, ICMP redirect
is NOT a broadcast and so it would be ignored if it wasn't directed to
my specific MAC. Am I mistaken in that assumption?
I believe the question was along the lines of, "why do I turn this off on my router?"
How does turning off ICMP redirects on the router prevent a rouge PC from sending ICMP redirects to it's neighbors?
I'm in the same boat here. I know there's a lot of conventional wisdom that says to turn it off, but I'm yet to hear a convincing argument as to why I should bother. Now configuring your hosts to ignore them, that I could understand.
See below
Jared Mauch
Until a PC or something on the network gets pwned, and issues selective forged
ICMP redirects to declare itself a router and the appropriate destination for
some traffic, which it can then MITM to its heart's content. *Then* you truly
have a manure-on-fan situation.
I believe the question was along the lines of, "why do I turn this off on my router?"
How does turning off ICMP redirects on the router prevent a rouge PC from sending ICMP redirects to it's neighbors?
I'm in the same boat here. I know there's a lot of conventional wisdom that says to turn it off, but I'm yet to hear a convincing argument as to why I should bother. Now configuring your hosts to ignore them, that I could understand.
The issue is routers typically do this in software requiring a punt and CPU theft from bgp, ospf etc.
This is worse than said PC issuing rogue RAs exactly how?
Perhaps we should pressure switch vendors to add ICMP Redirect
protection to the RA Guard feature they haven't implemented yet?
Owen
You mean like ICMP echo, ICMP can't fragment, ICMP unreachable...?
Yea the stuff that sometimes is done in hw and sometimes in sw and causes varying pain. You may find the discussion interesting to read if you feel redirects are "ok" or tolerable.
If vendors can't expose their defaults they really should not be enabling these things as it causes trouble.
I've had problems with both v4 and v6 redirects. Perhaps you have not.
Jared Mauch
See below
Jared Mauch
Maybe I'm missing something. Can you point me to something that will
help my understand WHY an ICMP redirect is such a huge security concern?
For most of the networks that I manage (or help to manage), I can see no
reason why this would be an issue.
In general, it's not a big deal, except that unlike a proper routing protocol
where you can redirect a /16 or a /default at a time and withdraw it when
needed, ICMP redirects tend to form host routes that have to individually be
redirected back if the routing flips back to its original status.
Until a PC or something on the network gets pwned, and issues selective forged
ICMP redirects to declare itself a router and the appropriate destination for
some traffic, which it can then MITM to its heart's content. *Then* you truly
have a manure-on-fan situation.
This is worse than said PC issuing rogue RAs exactly how?
Perhaps we should pressure switch vendors to add ICMP Redirect
protection to the RA Guard feature they haven't implemented yet?
One of my points is that redirects are routing updates of a dynamic nature. If the hosts are intended to participate in the routing process perhaps they should speak a protocol that can be secured further vs something that can't.
Please join the discussion on ipv6 at ietf. It's part of a router and host requirements document.