Agreed.
Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src.
Nick Olsen
Network Operations
(855) FLSPEED x106
Sure, but this means that network is allowing the spoofing 
What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested.
I'm seeing a lot of other email related to BCP-38 right now on another list, but I wanted to share some data (again) in public regarding the state of network spoofing out there.
I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network.
- jared
Hi,
I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network.
At the Internet Society we are flashing out an idea of an anti-spoofing
"movement", where ISPs can list themselves as not spoofing-capable on
our website. The requirement is that they can demonstrate that they
block spoofed packets, for instance by successfully running the Spoofer
test. I think your, Jared, test can add to this picture.
Sort of a positive spin on the name and shame technique.
It is not ideal, as one test is not a real proof of such capability, but
might help raising awareness, at least. Does this sound as something
that can be useful and fly?
Andrei
This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing.
It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . .
Another question is whether or not it's possible that in at least some cases, MITMing boxes on intermediary networks are grabbing these queries and then spoofing the scanner source IP as they redirect the queries . . . . if this is taking place, then it would be the network(s) with the MITMing box(es) which allow spoofing, irrespective of whether or not the intended destination networks do, yes?
Hi,
I think I might have already deleted subject matter a few days ago in re: BCP38.
What exactly are you trying to do?
I agree my general comment about the recent NTP weaknesses should be addressed via IPv6 RFC may have been mis-understood.
I meant mostly that with IPv6 NAT goes away, all devices are exposed, and we also have the 'internet of things' - much more subject to potential abuse.
An NTPv5 solution that could be done with NTP services already, and would be more of a 'best practices of how this shit starts up and what it can do' and educating vendors to have reasonable behavior in the first place?
And an NTPv6 solution/RFC/guideline that was similar, could help?
Neither will 'solve the problem' - but I think the idea of managing what somebody can do and having the provider filter in/out on IPv4 and/or mobile ipV4, much less ipV6 is very unorthodox and much against the spirit of having global m:n communications be helpful for humanity.
My apologies if I mis-understand your recent and last few e-mails.
I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol to 'protect the end user' is the wrong way to go when compared to just having things work in a secure manner.
- Mike
I meant mostly that with IPv6 NAT goes away,
I don't know if this is true or not - and even if it is true, it's going to be a long, long time before the IPv4 Internet goes away (like, maybe, pretty much forever, heh).
An NTPv5 solution that could be done with NTP services already, and would be more of a 'best practices of how this shit starts up and what it can do' and educating vendors to have reasonable behavior in the first place?
Yes, but that's many years away, and doesn't address legacy issues.
And an NTPv6 solution/RFC/guideline that was similar, could help?
Again, many years away, and doesn't address legacy issues.
I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol to 'protect the end user' is the wrong way to go when compared to just having things work in a secure manner.
Yes, but since the latter part of this statement is unattainable in the foreseeable future, the idea is actually to protect *the rest of the Internet* from misconfigured CPE.
Doesn't matter - the same people that aren't upgrading to a correctly
configured NTPv4 aren't going to upgrade to an NTPv5. No need at all
for a protocol increment (and actually doing that has its own issues).
Not working in the Internet access business but as Internet citizen
this sounds interesting.
You would need some motivations to make ISPs register and perhaps some
kind of validation in the future. But as initial step it sounds cool.
.as