On 13-Nov-2007, at 10:08, Drew Weaver wrote:

Hi there, I just had a real quick question. I hope this is found to be on topic.

Is it to be expected to see rfc1918 src'd packets coming from transit carriers?

You should not send packets with RFC1918 source or destination addresses to the Internet. Everybody should follow this advice. If everybody did follow that advice, you wouldn't see the packets you are seeing. The cynical answer, however, based on observation of real-life networks, is "yes" because people are naturally messy creatures.

We have filters in place on our edge (obviously) but should we be seeing traffic from 192.168.0.0 and 10.0.0.0 et cetera hitting our transit interfaces?

I guess I'm not sure why large carrier networks wouldn't simply filter this in their core?

I can think of lots of things that large carrier networks (as well as smaller, non-carrier networks!) do that seem on the face of it to defy explanation, of which this is just one example :-) Joe

On Tue, 13 Nov 2007, Drew Weaver wrote:

Hi there, I just had a real quick question. I hope this is found to be on topic.

Is it to be expected to see rfc1918 src'd packets coming from transit carriers?

I would recommend grilling your carriers to find out why they're not dropping packets sourced from or destined to 1918 addresses. jms

Hi there, I just had a real quick question. I hope this is found to be on topic.

Is it to be expected to see rfc1918 src'd packets coming from transit carriers?

We have filters in place on our edge (obviously) but should we be seeing traffic from 192.168.0.0 and 10.0.0.0 et cetera hitting our transit interfaces?

I guess I'm not sure why large carrier networks wouldn't simply filter this in their core?

[pick-a-random-BCP38-snipe ...] It's a feature: You can tell which of your providers does BCP38 this way. Heh. It's the networking equivalent of all the bad sorts of DOS/Windows programming. You know, the rule that says "once it can run successfully, it must be correct." Never mind checking for exceptional conditions, buffer overruns, etc. It's the same class of problem where corporate IT departments, listening to some idiot, filter all ICMP, and are convinced this is okay because they can reach ${one-web-site-of-your-choice}, and refuse to contemplate that they might have broken something. Once your network is routing packets and you aren't hearing complaints about being unable to reach a destination, it's got to be configured correctly ... right? Consider it life on the Internet. Do their job for them. Around here, we've been doing BCP38 since before there was a BCP38. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

The text below is from a 'security' list in reply to me questioning his statement, "Thus it is possible to route "private" address ranges." I'd be interested in hearing comments from this group if it's on-topic. Thanks, --Michael ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Michael, Lets take an example: Attacker --- ISP1---cloud---ISP2---Target.Router---Target.Host If I can source route a packet to ISP2 this will forward the packet via target.router to the target host. It does not matter that target.router filters source route. Most ISP routers (and I have seen configs for over 1000 of them and only seen source route blocked on less then 10 of these! [1]) do not filter source routing (ie no "no ip source-route" entry). As a result, source routed packets float about the Internet. Additionally, "most" ISPs do not have egress filters for private addressing. They allow these packets as a source address on packets. Many tools (even NC - Netcat) support a source route option. This allows the attacker to select the path that is taken to the host and also the return path. So setting the attack up the attacker will source route to ISP2 which will be the last router outside the target's router. As this is a default gateway for the target, all packets are sent from it to the ISP unless egress filters are placed on Target.router. Though the packets would normally "float" around the internet until their TTL expires them, they have been source routed. As such, ISP2 will have a "memory" of where to send them if it received the packet. Now remember that all packets come out of target.router to ISP2. So all packets make it to ISP2. Due to source routing, packets sent to ISP2 follow the reverse of the source route used to reach ISP2 and return to the attacker - even though they are using a "non-routed" address. Source route allows the packets to follow a set path. It does not require the standard routing protocols and is thus dangerous. Source routing is used in a number of multicast protocols (still) and many are loath to disable it. There are two primary types of source routing - Loose Source Routing and Strict Source Routing. I would suggest a read of RFC 791. In strict source routing, the sender specifies the exact route the packet must take. Have a read of: http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Techni... Clear as mud? Regards, Quote: "Source routing is an IP option which allows the originator of a packet to specify what path that packet will take, and what path return packets sent back to the originator will take. Source routing is useful when the default route that a connection will take fails or is suboptimal for some reason, or for network diagnostic purposes. For more information on source routing, see RFC791." [1] Disclaimer 1. I do not do much work with ISPs these days and they may have cleaned up their act in the last 5 years - though I doubt it.