General question on rfc1918
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? Thanks, -Drew
Re: General question on rfc1918
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
RE: General question on rfc1918
They do. What you are seeing are probably forged packets. Nmap etc. all let you forge SIP, in fact they automate it. One Nmap mode actually actively obfuscates network scans by doing random SIPs--e.g. 10,000 random SIPs and one real one--this makes it hard to figure out who is actually scanning your networks. Of course, if you don't filter incoming traffic on your inner interfaces, then the traffic could be from your own network. A lot of people filter only on their external ints: outgoing traffic limited to [mynetwork1, mynetwork2, mynetwork3] incoming traffic limited to [public IP addresses] Make sense? --Patrick Darden --Internetworking Manager --ARMC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Drew Weaver Sent: Tuesday, November 13, 2007 10:09 AM To: nanog@merit.edu Subject: General question on rfc1918 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? Thanks, -Drew
Re: General question on rfc1918
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
Re: General question on rfc1918
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.
Re: General question on rfc1918
From [EMAIL PROTECTED] Tue Nov 13 09:12:04 2007 Cc: nanog@merit.edu nanog@merit.edu From: Joe Abley [EMAIL PROTECTED] To: Drew Weaver [EMAIL PROTECTED] Subject: Re: General question on rfc1918 Date: Tue, 13 Nov 2007 10:10:26 -0500 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. Really? What do you do if a 'network internal' device -- a legitimate use of RFC1918 addresses -- discovers 'host/network unreachable' for an external-origin packet transitinng that device? evil grin Your comment _is_ generally correct, but there are some significant 'corner cases' that do complicate life. Packets that could conceivably generate a reply/response and have an RFC 1918 address (source -or- dest) should be ingress *and* egress filtered -- unless there is specific agreement with the adjacent network with regard to coordinated use of specific portions of that space. Packets which are strictly error/status reporting -- e.g. IMP 'unreachable', 'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at network boundaries _solely_ because of an RFC1918 source address.
Re: General question on rfc1918
On 13-Nov-2007, at 10:35, Robert Bonomi wrote: 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. Really? What do you do if a 'network internal' device -- a legitimate use of RFC1918 addresses -- discovers 'host/network unreachable' for an external-origin packet transitinng that device? evil grin You drop the packet at your border before it is sent out to the Internet. This is why numbering interfaces in the data path of non-internal traffic is a bad idea. Packets which are strictly error/status reporting -- e.g. IMP 'unreachable', 'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at network boundaries _solely_ because of an RFC1918 source address. I respectfully disagree. Joe
RE: General question on rfc1918
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 That is kind of the general theme I've been hearing back from most nanog'ers yet I have a feeling they're going to have no idea what I'm talking about. -Drew
Re: General question on rfc1918
On Tue, 13 Nov 2007, Drew Weaver wrote: Is it to be expected to see rfc1918 src'd packets coming from transit carriers? Yes. Any ISP which uses RFC1918 on internal links may generate various ICMP error packets (e.g. traceroute/TTL expire, PMTU discovery/Fragmentation required, etc) from router interfaces which have RFC1918 addresses for transit traffic. Some people filter them anyway, and get *'s in traceroutes and PMTU weirdness. #include old debate about using RFC1918 addresses on transit links #include other old debate about filtering stuff in backbones or edge
Re: General question on rfc1918
Joe Abley (jabley) writes: You drop the packet at your border before it is sent out to the Internet. This is why numbering interfaces in the data path of non-internal traffic is a bad idea. Unfortunately many providers have the bad habit of using RFC1918 for interconnect, on the basis that a) it saves IPs b) it makes the interconnect not vulnerable [1]. Packets which are strictly error/status reporting -- e.g. IMP 'unreachable', 'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at network boundaries _solely_ because of an RFC1918 source address. I respectfully disagree. Same here, and even if egress filtering didn't catch it, many inbound filters will. [1] I'v also heard of ISPs having an entire /16 of routable addresses for their interconnect, but they just don't advertise to peers.
