[168514] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: BCP38.info

daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Jan 28 15:05:14 2014

From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <939fe1a$25013901$31ba95f6$@flhsi.com>
Date: Tue, 28 Jan 2014 15:03:45 -0500
To: nick@flhsi.com
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Jan 28, 2014, at 2:57 PM, Nick Olsen <nick@flhsi.com> wrote:

> Agreed.
>=20
> 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.=20

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=


home help back first fref pref prev next nref lref last post