Should routers send redirects by default?
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:
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
On Fri, 20 Aug 2010, Jack Bates 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 email: swmike@swm.pp.se
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
On Fri, Aug 20, 2010 at 1:40 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 20 Aug 2010, Jack Bates 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.
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
On Aug 21, 2010, at 12:20 AM, Christopher Morrow wrote:
o routers are required to be able to send redirect messages o routers should NOT do this by default
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote:
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) :-) -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ********************************************************************
On Aug 20, 2010, at 3:56 PM, Butch Evans wrote:
On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote:
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 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
On Fri, 2010-08-20 at 16:03 -0400, Jared Mauch wrote:
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. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ********************************************************************
On Fri, 20 Aug 2010 16:08:19 CDT, Butch Evans said:
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.
On Fri, 2010-08-20 at 17:54 -0400, Valdis.Kletnieks@vt.edu wrote:
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? -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ********************************************************************
On Fri, 20 Aug 2010, Valdis.Kletnieks@vt.edu wrote:
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. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
See below Jared Mauch On Aug 20, 2010, at 6:16 PM, Brandon Ross <bross@pobox.com> wrote:
On Fri, 20 Aug 2010, Valdis.Kletnieks@vt.edu wrote:
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.
-- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Fri, 20 Aug 2010, Jared Mauch wrote:
The issue is routers typically do this in software requiring a punt and CPU theft from bgp, ospf etc.
You mean like ICMP echo, ICMP can't fragment, ICMP unreachable...? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
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 On Aug 20, 2010, at 6:36 PM, Brandon Ross <bross@pobox.com> wrote:
On Fri, 20 Aug 2010, Jared Mauch wrote:
The issue is routers typically do this in software requiring a punt and CPU theft from bgp, ospf etc.
You mean like ICMP echo, ICMP can't fragment, ICMP unreachable...?
-- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Fri, 20 Aug 2010 18:16:35 EDT, Brandon Ross said:
How does turning off ICMP redirects on the router prevent a rouge PC from sending ICMP redirects to it's neighbors?
If I know for a fact that the network is designed such that I will never ever receive a valid ICMP redirect because there is exactly one route off the network, I can safely turn off "accept ICMP redirects" and be done with it. If I have to allow ICMP in, it becomes a much more interesting iptables/whatever issue. On Fri, 20 Aug 2010 15:34:17 PDT, Owen DeLong said:
This is worse than said PC issuing rogue RAs exactly how?
It's the exact same problem, actually.
Perhaps we should pressure switch vendors to add ICMP Redirect protection to the RA Guard feature they haven't implemented yet?
You mean you aren't already? ;)
On Fri, 20 Aug 2010 18:16:35 EDT, Brandon Ross said:
How does turning off ICMP redirects on the router prevent a rouge PC from sending ICMP redirects to it's neighbors?
If I know for a fact that the network is designed such that I will never ever receive a valid ICMP redirect because there is exactly one route off the network, I can safely turn off "accept ICMP redirects" and be done with it. If I have to allow ICMP in, it becomes a much more interesting iptables/whatever issue. On Fri, 20 Aug 2010 15:34:17 PDT, Owen DeLong said:
This is worse than said PC issuing rogue RAs exactly how?
It's the exact same problem, actually.
Perhaps we should pressure switch vendors to add ICMP Redirect protection to the RA Guard feature they haven't implemented yet?
You mean you aren't already? ;)
On Aug 20, 2010, at 2:54 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 20 Aug 2010 16:08:19 CDT, Butch Evans said:
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? Owen
See below Jared Mauch On Aug 20, 2010, at 6:34 PM, Owen DeLong <owen@delong.com> wrote:
On Aug 20, 2010, at 2:54 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 20 Aug 2010 16:08:19 CDT, Butch Evans said:
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.
Owen
On Fri, Aug 20, 2010 at 4:08 PM, Butch Evans <butche@butchevans.com> wrote: I would suggest the recommendation be that ICMP Redirects, proxy ARP, directed broadcast, source routing, and acceptance/usage of all fancy/surprising features should be off by default. Where "surprising" is defined as the sort of thing that is nonessential, has questionable benefits, can cause problems, and that people will forget to turn off. Redirects seem to fall into the non-essential with questionable benefits (in most cases) category.
For most of the networks that I manage (or help to manage), I can see no reason why this would be an issue.
If none of your hosts accept redirects, then it is not really apparent that redirects are harmful. If some of your hosts accept redirects, then redirects may be capable of causing headaches. You might have a gateway using a protocol such as VRRP, with redundancy for the default gateway address of subnet $X. And you have other routers for other subnets which just happen to have an extra ip on subnet $X. But the other subnets' routers' IPs on subnet $X are not redundant, and the packets are supposed take a secondary route if that "second hop" router goes down, since the $X default gateway will dynamically figure this out in a couple of seconds. Then the ICMP redirect becomes a redirect to /dev/null. And almost random sets of hosts will lose communications with each other for the redirect timeout duration, if they are not smart enough to implement methods of detecting the redirect is now bad. Sending ICMP redirects is not a huge security risk. ACCEPTING redirects is a larger risk. The redirects can be used by an adversary that acts as a "router", to extend the lifetime of or increase the effectiveness of an ARP hijacking or switch CAM flooding tactic, to continue to steal traffic from a host, and ensure they get every packet. The adversary with an IP on the same subnet as target hosts can use forged ICMP redirects, in order to cause hosts to misdirect packets sent to certain IPs, so that the attacker's local subnet IP address is the first hop in the path, instead of the hosts' default gateway. -- -J
On Wed, 2010-08-25 at 20:08 -0500, James Hess wrote:
On Fri, Aug 20, 2010 at 4:08 PM, Butch Evans <butche@butchevans.com> wrote: I would suggest the recommendation be that ICMP Redirects, proxy ARP, directed broadcast, source routing, and acceptance/usage of all fancy/surprising features should be off by default.
Off by default, but be supported is my recommendation. I am assuming that the function in IPv6 is the same (or similar) to that of IPv4. There was another post in this thread (I can't recall who it was that posted it) that indicated there was more to the redirect in v6 than for v4, but I am not yet very familiar with v6.
"surprising" is defined as the sort of thing that is nonessential, has questionable benefits,
Perhaps "questionable" to you, but I have had specific need to have ICMP redirect for two specific networks. In those networks it WAS essential and had a very specific, measurable benefit.
Redirects seem to fall into the non-essential with questionable benefits (in most cases) category.
You are being a little presumptuous here. Perhaps for "most cases", I'd agree that they are non-essential, but there are cases where it is desirable and lack of support (as in the PIX) makes things very difficult at times.
If none of your hosts accept redirects, then it is not really apparent that redirects are harmful. If some of your hosts accept redirects, then redirects may be capable of causing headaches.
In one case where I needed ICMP redirect to work, I had 2 routers on the network (one was a Linux device and the other was a PIX). Each of these were terminating VPNs from various sources. There were several (about 90) hosts on the LAN segment. Each of these hosts had the PIX as their default route. It would have been a very simple matter to add routes to the PIX and have it redirect the traffic destined for the remote networks behind the Linux device. The PIX, however, does not support ICMP redirects AT ALL. I'm all for securing a network segment, but failure to support a valid function of ICMP is one reason I have never purchased a PIX...and never will. I can see your point that it should be off by default. But to be off and not even supported is just wrong, IMHO. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ********************************************************************
On Fri, Aug 20, 2010 at 4:03 PM, Jared Mauch <jared@puck.nether.net> wrote:
On Aug 20, 2010, at 3:56 PM, Butch Evans wrote:
On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote:
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
- Jared
2010/8/20 Jared Mauch <jared@puck.nether.net>
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.
On Cisco routers (at least some of them), have you tried the command show running-config all This command displays all configuration, including hidden default values. This may help when this command is present. Don't know about other vendors. Yann
On Aug 21, 2010, at 2:11 AM, Yann GAUTERON wrote:
2010/8/20 Jared Mauch <jared@puck.nether.net>
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.
On Cisco routers (at least some of them), have you tried the command show running-config all
This command displays all configuration, including hidden default values.
This may help when this command is present.
Don't know about other vendors.
This varies by IOS (software revision), and because not all devices actually have the access to this "mainline" featureset due to when they branched for their localized hardware support. I certainly wish they could get there now, and it's better in the newer access (CPE) hardware. While related, the larger problem IMHO is them removing stuff like "show parser dump exec" and "show parser dump config". I have been a supporter of exposed defaults for years, including "more secure" and "more robust" defaults. The folks on the IETF list seem to think that the existing rate-limit mechanics will protect the routers. We did not arrive at these settings as a result of those rate-limits working properly sadly. - Jared
Redirects in IPv6 are no worse nor better an idea than unauthenticated RAs for default routers with nearly identical security implications. Owen Sent from my iPad On Aug 20, 2010, at 10:20 AM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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
On Fri, Aug 20, 2010 at 4:10 PM, Owen DeLong <owen@delong.com> wrote:
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
Owen
Sent from my iPad
On Aug 20, 2010, at 10:20 AM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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
On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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 ... In ipv4 there's a relatively widely used practice of disabling ip redirects.
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.] As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them. --Ricky
On Fri, 20 Aug 2010, Ricky Beam wrote:
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.)
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On 08/21/2010 02:08 AM, Brandon Ross wrote:
On Fri, 20 Aug 2010, Ricky Beam wrote:
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.)
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted?
As was mentioned in an other part of the thread. You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower. It might also help you notice you have a roque host when you are looking at your network-traffic and if you know your network doesn't have any ICMP-redirects normally. disabling on the host: OpenBSD: echo net.inet.icmp.rediraccept=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.rediraccept=0 sysctl net.inet6.icmp6.rediraccept=0 FreeBSD: echo net.inet.icmp.drop_redirect=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.drop_redirect=0 sysctl net.inet6.icmp6.rediraccept=0 Linux: echo net.ipv4.conf.all.accept_redirects = 0 >> /etc/sysctl.conf echo net.ipv4.conf.all.send_redirects = 0 >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf
On 08/21/2010 02:08 AM, Brandon Ross wrote:
On Fri, 20 Aug 2010, Ricky Beam wrote:
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.)
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted?
As was mentioned in an other part of the thread. You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower. It might also help you notice you have a roque host when you are looking at your network-traffic and if you know your network doesn't have any ICMP-redirects normally. disabling on the host: OpenBSD: echo net.inet.icmp.rediraccept=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.rediraccept=0 sysctl net.inet6.icmp6.rediraccept=0 FreeBSD: echo net.inet.icmp.drop_redirect=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.drop_redirect=0 sysctl net.inet6.icmp6.rediraccept=0 Linux: echo net.ipv4.conf.all.accept_redirects = 0 >> /etc/sysctl.conf echo net.ipv4.conf.all.send_redirects = 0 >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf
Eric J. Katanich wrote:
You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower.
Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups). Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc). It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here). Jack
On Aug 21, 2010, at 10:12 AM, Jack Bates wrote:
Eric J. Katanich wrote:
You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower.
Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups).
Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc).
It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here).
One of the use cases for the redirects listed is that someone may DHCPv6 a prefix, but (!!!) not know the netmask of the prefix, so may not know what is on-net. ie: here's your host address, good luck! This surely isn't something I had expected as an output of the IETF, as i figured that even the most basic folks advocating for "internet engineering" would tell a host the netmask so it would know what is on-net vs off-net. This tells me that the use of redirects isn't quite as straightforward as "helping" but more as "crutch" for not wanting to consume an extra byte for mask and few bytes for a default-router. It also means they are unlikely to be as limited in their rate as you suggest, it will make the IPv6 router look more like a flow-swithced device (having to send a redirect for each subnet/mask that is different) and effectively make the host participate (via redirects) in this routing protocol. - Jared
On Sat, 21 Aug 2010 10:32:00 -0400 Jared Mauch <jared@puck.nether.net> wrote:
On Aug 21, 2010, at 10:12 AM, Jack Bates wrote:
Eric J. Katanich wrote:
You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower.
Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups).
Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc).
It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here).
One of the use cases for the redirects listed is that someone may DHCPv6 a prefix, but (!!!) not know the netmask of the prefix, so may not know what is on-net. ie: here's your host address, good luck!
That's not the case. What they're saying is that an address by itself does not _imply_ a prefix length i.e. don't assume a /64. This isn't any different to IPv4 in the last 15 years - "192.168.0.1" by itself doesn't imply a /24 since CIDR came along. RFC5942 does into details. Basically it says if a node doesn't have a separate indication that a prefix is onlink (i.e. via a configured prefix length, or via PIO options in an RA), then don't assume the internal structure of the address is known (i.e. don't assume a /64).
This surely isn't something I had expected as an output of the IETF, as i figured that even the most basic folks advocating for "internet engineering" would tell a host the netmask so it would know what is on-net vs off-net.
This tells me that the use of redirects isn't quite as straightforward as "helping" but more as "crutch" for not wanting to consume an extra byte for mask and few bytes for a default-router.
It also means they are unlikely to be as limited in their rate as you suggest, it will make the IPv6 router look more like a flow-swithced device (having to send a redirect for each subnet/mask that is different) and effectively make the host participate (via redirects) in this routing protocol.
- Jared
On Sat, 21 Aug 2010 09:12:47 -0500 Jack Bates <jbates@brightok.net> wrote:
Eric J. Katanich wrote:
You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower.
Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups).
I'm don't think that would work. In IPv6, redirects serve two purposes, where as in IPv4 they only served one - o allow an IPv6 router to indicate to an end-node that another onlink IPv6 router is a better path towards the destination (i.e. the IPv4 purpose). This situation doesn't seem to occur very often - when there are two routers on a link they're usually there for availability, rather than presenting a significantly different set of paths to potential offlink destinations. Usually they'll be hidden behind a single virtual router via HSRP or VRRP. o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink. This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information. So a redirect status parameter isn't prefix specific.
Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc).
It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here).
Jack
On Sat, 21 Aug 2010 20:42:01 -0400, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
In IPv6, redirects serve two purposes, where as in IPv4 they only served one -
IPv4 redirects serve exactly the same two situations... both are situations where a router would be required to hairpin a packet -- either the destination is on-wire or the path to it is elsewhere on-wire. Let's say host 1.100 has a default gw of 1.1 and no other routes. A packet destined for 2.1 would go to 1.1, even if 2.1 is on the same wire. Following old rules, 1.1 sends a redirect and drops the packet. Most hosts would ignore that redirect as it "makes no sense" (redirects are not a substitute for device routes. I've seen this happen too many times.) Now, if 2.1 was behind 1.2, the redirect would tell 1.100 to go there instead. (This isn't as much of a problem these days since routers don't to the "drop packet" part -- which used to be mandated by RFC. And "secondary" networks have given way to inter-VLAN routing.) --Ricky
On Sun, Aug 22, 2010 at 10:12:01AM +0930, Mark Smith wrote:
o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink.
This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information.
It may be true the situations where redirects are required for this are few in number, but I think it is not true that the use of redirects is limited solely to the configuration gap between introducing a new prefix. In NBMA networks, it is said that the nodes will have IPv6 addresses with no covering advertised prefixes ("IPv6 Core Protocols Implementation", page 393, just spotted while reading today). Additionally, the typical use of /128 "role addresses" for services aliased onto lo0 mean the router has a /128 route for the role address to an on-link device, but a covering prefix advertisement would be both futile and inappropriate. I don't necessarily want to say that your conclusion is false, but rather that it seems to me there are more enumerations in the set. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/
On Tue, 24 Aug 2010 13:25:01 -0700 "David W. Hankins" <David_Hankins@isc.org> wrote:
On Sun, Aug 22, 2010 at 10:12:01AM +0930, Mark Smith wrote:
o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink.
This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information.
It may be true the situations where redirects are required for this are few in number, but I think it is not true that the use of redirects is limited solely to the configuration gap between introducing a new prefix.
In NBMA networks, it is said that the nodes will have IPv6 addresses with no covering advertised prefixes ("IPv6 Core Protocols Implementation", page 393, just spotted while reading today).
Additionally, the typical use of /128 "role addresses" for services aliased onto lo0 mean the router has a /128 route for the role address to an on-link device, but a covering prefix advertisement would be both futile and inappropriate.
I don't necessarily want to say that your conclusion is false, but rather that it seems to me there are more enumerations in the set.
Before coming to any conclusions, we'd need to more strictly define what the NBMA topology is. Is it fully transitive i.e. all nodes can see all other nodes, and that the only property that makes it different from a conventional LAN is the absence of a broadcast/multicast capability? Or is there only partial visibility, such that end-nodes only have permanent visibility to a router i.e hub-and-spoke? In the latter case, another property is whether or not direct communcations paths can be set up between the spoke nodes on demand, such as in the case of Dynamic Multi-point VPNs. Whether ICMPv6 redirects are necessary or useful, or whether other somewhat similar mechanisms, such as Next Hop Resolution Protocol, are used in an NBMA subnet very much depends on the sort of connectivity it provides or can provide between the nodes on the subnet. Regards, Mark.
I appreciate the discussion.. Eric, are you reflecting messages back to the list without additional content for a reason? list-admin folks, could we ping eric and see what's busted? On Fri, Aug 20, 2010 at 9:08 PM, Eric J. Katanich <ekat@onyxlight.net> wrote:
On 08/21/2010 02:08 AM, Brandon Ross wrote:
On Fri, 20 Aug 2010, Ricky Beam wrote:
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.)
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted?
As was mentioned in an other part of the thread.
You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower.
It might also help you notice you have a roque host when you are looking at your network-traffic and if you know your network doesn't have any ICMP-redirects normally.
disabling on the host: OpenBSD: echo net.inet.icmp.rediraccept=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.rediraccept=0 sysctl net.inet6.icmp6.rediraccept=0
FreeBSD: echo net.inet.icmp.drop_redirect=0 >> /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 >> /etc/sysctl.conf sysctl net.inet.icmp.drop_redirect=0 sysctl net.inet6.icmp6.rediraccept=0
Linux: echo net.ipv4.conf.all.accept_redirects = 0 >> /etc/sysctl.conf echo net.ipv4.conf.all.send_redirects = 0 >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf
On Fri, 20 Aug 2010 20:08:34 -0400, Brandon Ross <bross@pobox.com> wrote:
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted?
It stops *one vector* of MITM attack. If a router honors redirects (and it never should), an evil host can intercept traffic of hosts that aren't on the local network. This is 5000% beyond the scope of the original question, btw. --Ricky
On Fri, 20 Aug 2010, Ricky Beam wrote:
On Fri, 20 Aug 2010 20:08:34 -0400, Brandon Ross <bross@pobox.com> wrote:
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted?
It stops *one vector* of MITM attack. If a router honors redirects (and it never should), an evil host can intercept traffic of hosts that aren't on the local network.
Are you saying that turning off the transmittal of ICMP redirects on most routers will simultaniously disable the honoring of ICMP redirects that that router receives? If that's not what you are saying then you are wrong.
This is 5000% beyond the scope of the original question, btw.
I disagree. The decision about whether or not a feature should be on by default or not should be clear evidence that said feature is/could be harmful. So far I have not heard a single compelling argument for how the _transmittal_ of ICMP redirects can cause any signficicant harm to a network other than what the other typical protocols that are enabled by defualt (ping, can't fragement, etc) cause. I will make the statement: The transmittal of ICMP redirects by a router _cannot_ be exploited to create a man in the middle attack. Before anyone responds to that statement, please read it very carefully. This statement does not comment on whether a host or router should be configured to _receive_ an ICMP redirect and act on it, that clearly can be used to create a MITM attack. How many of you that routinely disable ICMP redirect on your routers also routinely disable the reception of ICMP redirects on your hosts? For those of you that do not, why not? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Fri, 2010-08-20 at 21:34 -0400, Brandon Ross wrote:
So far I have not heard a single compelling argument for how the _transmittal_ of ICMP redirects can cause any signficicant harm to a network other than what the other typical protocols that are enabled by defualt (ping, can't fragement, etc) cause. I will make the statement:
I agree with you here, Brandon. I asked the question: "What is the real security hole?" because I cannot see any real risk here for MOST of the networks that I am involved in. I can see the possibility of MITM attacks with ICMP redirects, but that is not the case for (as you point out) a router that issues an ICMP redirect. Also, it is not my experience that most host OS have this disabled either. That being the case, it seems to me that eliminating the behavior of transmitting these redirects in a router are of little value in protecting against MITM attacks.
The transmittal of ICMP redirects by a router _cannot_ be exploited to create a man in the middle attack.
I'd have to agree with this. More because my limited research (which includes responses I've seen on this thread) seems to indicate that this is the case.
Before anyone responds to that statement, please read it very carefully. This statement does not comment on whether a host or router should be configured to _receive_ an ICMP redirect and act on it, that clearly can be used to create a MITM attack.
If a network has a single router, then wouldn't this also create a DOS situation under the right circumstances? I mean, if it can create MITM, it would HAVE to also create DOS possibilities. What is the distance of a route learned from an ICMP redirect? If it is greater than 0 (connected route) or 1 (static route) but less than the cost of other dynamically learned routes, then I can see the why this may be a problem for a router to respond to an ICMP redirect packet. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ********************************************************************
On Fri, 20 Aug 2010 19:49:43 -0400 "Ricky Beam" <jfbeam@gmail.com> wrote:
On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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 ... In ipv4 there's a relatively widely used practice of disabling ip redirects.
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.]
You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect. Sometimes it won't be. 1 ICMP redirect could result in potentially congestion inducing load being shifted off of a single router's interface. It seems that there might be a common and unstated assumption here that ever router uses hardware forwarding and has high speed 1Gbps+ interfaces that have <50% utilisation. The majority of routers - CPE - don't meet that assumption.
As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them.
--Ricky
On Fri, 20 Aug 2010 20:43:39 -0400, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect.
I am saying no such thing. (a single redirect packet is always more efficient.) I *am* saying ICMP redirects are a mistake that should not be replicated in IPv6. They are too easy to abuse, which is why they are almost universally ignored by IPv4 hosts. In a *properly* configured network, redirects should not be necessary. (everything on the local LAN should know what's on the local LAN.) [For the record, my own networks don't follow that rule. :-) Coworkers throwing random crap on the wire doesn't help. *sigh* Don't go there.] IPv6 has more than enough mistakes glued into it. Redirects are a mess that does not need to be there. For the purests who insist on making ugly networks that are trival to subvert, make ICMPv6 redirects *OPTIONAL*, *REQUIRING* explicit configuration to enable. Without strong authentication/authorization mechanisms, it'll be the same mess that it is in IPv4. --Ricky
On Fri, 20 Aug 2010 21:24:43 -0400 "Ricky Beam" <jfbeam@gmail.com> wrote:
On Fri, 20 Aug 2010 20:43:39 -0400, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect.
I am saying no such thing. (a single redirect packet is always more efficient.) I *am* saying ICMP redirects are a mistake that should not be replicated in IPv6. They are too easy to abuse, which is why they are almost universally ignored by IPv4 hosts.
I thought we were talking about IPv6 redirects not IPv4 ones. How much do you know about their operation and purposes?
In a *properly* configured network, redirects should not be necessary. (everything on the local LAN should know what's on the local LAN.) [For the record, my own networks don't follow that rule. :-) Coworkers throwing random crap on the wire doesn't help. *sigh* Don't go there.]
IPv6 has more than enough mistakes glued into it. Redirects are a mess that does not need to be there. For the purests who insist on making ugly networks that are trival to subvert, make ICMPv6 redirects *OPTIONAL*, *REQUIRING* explicit configuration to enable. Without strong authentication/authorization mechanisms, it'll be the same mess that it is in IPv4.
Know anything about IPv6 SeND?
--Ricky
On Fri, 20 Aug 2010 19:49:43 -0400 "Ricky Beam" <jfbeam@gmail.com> wrote:
On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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 ... In ipv4 there's a relatively widely used practice of disabling ip redirects.
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.]
You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect. Sometimes it won't be. 1 ICMP redirect could result in potentially congestion inducing load being shifted off of a single router's interface. It seems that there might be a common and unstated assumption here that ever router uses hardware forwarding and has high speed 1Gbps+ interfaces that have <50% utilisation. The majority of routers - CPE - don't meet that assumption.
As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them.
--Ricky
On Fri, 20 Aug 2010, Ricky Beam wrote:
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.)
Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Fri, Aug 20, 2010 at 07:49:43PM -0400, Ricky Beam wrote:
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.]
I am not sure that is so much of an issue in IPv6. I know that in IPv4 3rd party ICMP redirects were quite common among the kiddies to knock each other off IRC, but ICMPv6 redirect reception in hosts has a number of saves and limitations that mean it should be far less, perhaps not an issue, provided your local network is secure and BCP 38 is in use. For example, an ICMPv6 implementation will not process a redirect from a router that is not the host's current next-hop for the target destination. Because this is a Link-Local Address, an off-link attacker has quite a problem guessing (and on-link attackers are a problem anyway). But I have a different memory of why we first started disabling redirects, back in the day. My memory is that hosts typically implement redirects with /32 routes, with no aggregation, installed upon receiving a redirect message. The ICMP message does not contain any TTL, and none was specified in RFC, so consequently over the lifetime of a device receiving redirects the routing table grows until every redirected destination is enumerated, or the system restarts. The ultimate size of the table reached can be quite large, beyond the scale typically engineered for in a host. Of course, that was back in the day when hosts were typically slower than the LANs they were connected to. So every additional host route installed increased per-packet forwarding overhead and decreased throughput considerably. Although ICMPv6 Redirect messages also lack a (router-advertised) TTL, an examination of [1] leads me to believe they will time out because they are implemented as part of the ND llinfo cache. A stale cache entry (the equivalent of a /128 route with link layer information) will ultimately be cleaned. If the destination is reused later, So it may be that the same conclusion does not hold, except in the unusual condition where a large number of redirects are required over a relatively short period of time (such as devices that have a large number of active sessions with hosts that its routers redirect; web servers, smtp systems...). [1] Li, Q., Jinmei, T., Shima, K., "IPv6 Core Protocols Implementation", October 2006. ISBN 13: 978-0-12-447751-3 ISBN 10: 0-12-447751-8 -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/
On Tue, Aug 24, 2010 at 01:02:49PM -0700, David W. Hankins wrote:
will ultimately be cleaned. If the destination is reused later,
Ah, I forgot to complete this thought in editing. If packets are sent to the destination later (after a cache entry is expired) the host obviously starts over as if there was no redirection. In this way, changes in topology are ultimately discovered, whether the redirection changes or is no longer needed. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/
On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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 ... In ipv4 there's a relatively widely used practice of disabling ip redirects.
I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.] As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them. --Ricky
On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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
Hi Chris, If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked: Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you? Thanks, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Tue, Aug 24, 2010 at 4:32 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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
Hi Chris,
If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked:
sure :) (other folks should also chime in, or I thought that was the spirit of your question...)
Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you?
I've never had redirects solve a problem for me.
Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you?
I've never had redirects solve a problem for me.
Once upon a time, gatekeeper.dec.com was a MIPS Ultrix box connected to a LAN segment (the IP prefix for that LAN segment was 16.1.0.0/24, and gatekeeper used to be 16.1.0.2). Also connected to the LAN segment were routers belonging to AlterNet (or maybe it was UUnet by then) and BARRnet. gatekeeper's static default route was pointed at the BARRnet router. The BARRnet and AlterNet routers exchanged routes out of sight of the LAN segment in question. When BARRnet knew that the destination of a packet would be the AlterNet router, it would issue an ICMP redirect to gatekeeper (or any of the other hosts that pointed default at the BARRnet router). The redirects let us make pretty efficient use of the interfaces toward both from the collection of gatekeeper and uucp-gw{1,2} and the NNTP relays and such. Had we shovelled all the traffic at BARRnet, all the time, we wouldn't have stretched our DELNIs as far as we did. That was 1994 - and in fairly short order (within two years) we went from DELNIs to DECswitch 900s, MIPS Ultrix to Digital UNIX (or whatever it was called) on AlphaStations (so many AlphaStations), and ICMP redirects to the private IX that became PAIX. Stephen
On Wed, 25 Aug 2010, Stephen Stuart wrote:
Once upon a time
I think the question is what sensible defaults should be. In my environment we turn off proxy-arp and redirects, and it is my firm belief that this is actually what should be the default. In my opinion: A host SHOULD support listening to redirects and MUST have a knob to turn off this listening if implemented. A router MUST have redirects off as default but MUST support a knob turning them on and when sending a redirect it MUST forward the packet that generated the redirect. I know most of the above is completely against current standards, but for me these are more in tune with todays reality in networking as I see them. -- Mikael Abrahamsson email: swmike@swm.pp.se
A host SHOULD support listening to redirects and MUST have a knob to turn off this listening if implemented. A router MUST have redirects off as default but MUST support a knob turning them on and when sending a redirect it MUST forward the packet that generated the redirect.
wfm randy
On Wed, 25 Aug 2010 01:18:15 -0400 Christopher Morrow <christopher.morrow@gmail.com> wrote:
On Tue, Aug 24, 2010 at 4:32 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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
Hi Chris,
If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked:
sure :) (other folks should also chime in, or I thought that was the spirit of your question...)
Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you?
I've never had redirects solve a problem for me.
So how do you know? If redirects are enabled by default, then they may have fixed a problem for you that you didn't know existed and never realised existed. When your packets get there successfully you don't go and investigate why. You only troubleshoot failure, not success. I think the only way to know an absolute answer would be to have witnessed this sequence of events - have an environment where redirects are switched off - suffer from a problem that redirects are designed to solve - switch redirects on and have the problem not disappear Of course, the problem not disappearing when redirects are enabled might also mean a misdiagnosis of what the problem really is. Regards, Mark.
On Aug 24, 2010, at 4:32 PM, William Herrin wrote:
On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
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
Hi Chris,
If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked:
Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you?
I have, but it was a long long time ago (~1997), and it was a stupid problem.... We had a bunch of hosts on a LAN - their default GW was an AGS+ connected to provider X. Also on the same network was a Bay Networks BCN (AFAIR) connected to provider Y. In general most flows were relatively long lived (some NNTP, some FTP.. oh, and Quake!). There was no reasonable way to inform the hosts if provider X went away. The AGS+ would also run a bit too hot if it had to accept all of the traffic and then punt the relevant parts over to the BCN.... Unrelated, but this network also did static IPs for dial customers (who could dial into one of ~lots of RAS boxes) -- this meant that the RAS boxen has to inject /32s into OSPF for each customer -- this meant that if certain routers (like the AGS+) bounced there was enough churn that other routers would fall over (the BCN would hit some watchdog and fall over, and if you tried to bring it up into a network that was already converged it would run out of RAM and happily drop into some debugger console). Fun times... W
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade)
participants (21)
-
Brandon Ross -
Butch Evans -
Christopher Morrow -
Christopher Morrow -
David W. Hankins -
Dobbins, Roland -
Eric J. Katanich -
Jack Bates -
James Hess -
Jared Mauch -
Leen Besselink -
Mark Smith -
Mikael Abrahamsson -
Owen DeLong -
Randy Bush -
Ricky Beam -
Stephen Stuart -
Valdis.Kletnieks＠vt.edu -
Warren Kumari -
William Herrin -
Yann GAUTERON