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
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
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
I would recommend grilling your carriers to find out why they're not dropping packets sourced from or destined to 1918 addresses.
jms
I would recommend grilling your carriers to find out why they're not
dropping packets sourced from or destined to 1918 addresses.
Jms
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"
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 Painter" <tvhawaii@shaka.com> writes:
michael's colleague writes:
> 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.
There are good reasons to allow source routed packets to pass through
a backbone unfettered; among other things it can facilitate debugging
of routing anomalies by a knowledgeable individual. ISPs by and large
are in the business of hauling bits around; they are not in the
business of implementing security policy for their customers. One
which tried was Pilot Network Services Inc. They are no longer
around. Victim of .bomb or fundamentally unsound business plan? We
could conjecture on and on but this isn't the place for that.
On the customer edge (ie, not the service provider's router) one can
implement whatever security policy suits, and live with the
consequences... good, bad, or indifferent. My personal opinion is
that 1918 address space is not inherently worse or better than any
other address space out there from which one could suffer an attack,
and though stateful firewalls are a huge help (and equal opportunity
for dropping bogus stuff regardless of src/dst addresses) anyone who
is dependent on a {src_addr, src_port, dst_addr, dst_port, seqnum }
tuple for established connection security ought to wake up and smell
the coffee; it's almost 2008 - get your crypto on.
My $0.02
---Rob
aloha michael,
i realize that good practice many not be general practice, but ...
lsr is encouraged at routers bordering with bgp peers for debugging
purposes, i.e. so that A may learn B's routing towards C without
calling/writing/bothering B's engineers.
but lsr really should be blocked at hosts, e.g.
# grep lsr /etc/ipfw.rules
add deny log all from any to any ipoptions ssrr,lsrr,rr
i am not aware of a similar common use case for ssr.
randy
Michael Painter wrote:
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.
Not true. DVMRP with tunnels hasn't been used for inter-domain multicast for a long time.
Many implementations, including FreeBSD, have deprecated the use of IPIP and LSRR.
I believe most folk who are serious about inter-domain multicast are running BGP with PIM-SM and MSDP. However, this hasn't really been accessible to the individual hobbyist until now, and there are no free MSDP implementations out there that I know of.
If security is a concern, turn LSRR off on packet filtering NAT gateways, if you don't know *for sure* that the forwarding plane is smart enough to block LSRR according to a well-defined site security policy.
There are however cogent arguments for turning LSRR on in an AS's transit routers here:
Source-routing not considered harmful
regards,
BMS