[168512] in North American Network Operators' Group
Re: BCP38.info
daemon@ATHENA.MIT.EDU (Nick Olsen)
Tue Jan 28 14:58:48 2014
From: "Nick Olsen" <nick@flhsi.com>
To: "David Miller" <dmiller@tiggee.com>, "Jared Mauch" <jared@puck.nether.net>,
<Valdis.Kletnieks@vt.edu>
Date: Tue, 28 Jan 2014 14:57:57 -0500
Cc: NANOG <nanog@nanog.org>
Reply-To: nick@flhsi.com
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Agreed.
Our's listed for AS36295 are two customers, Which I know for a fact have th=
eir 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 actu=
ally 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 anothe=
r area before being sent to the src.
Nick Olsen
Network Operations
(855) FLSPEED x106
----------------------------------------
From: "David Miller" <dmiller@tiggee.com>
Sent: Tuesday, January 28, 2014 2:47 PM
To: "Jared Mauch" <jared@puck.nether.net>, Valdis.Kletnieks@vt.edu
Cc: "NANOG" <nanog@nanog.org>
Subject: Re: BCP38.info
On 1/28/2014 2:16 PM, Jared Mauch wrote:
>
> On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks@vt.edu wrote:
>
>> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
>>
>>> 52731 ASN7922
>>
>>> It includes IP address where you send a DNS packet to it and another IP=
address responds to the query, e.g.:
>>
>>> The data only includes those where the "source-ASN" and "dest-asn" of t=
hese packets don't match.
>>
>> Hang on Jared, I'm trying to wrap my head around this. You're saying th=
at
>> AS7922 has over 50K IP addresses which, if you send a DNS query to that =
IP,
>> you get an answer back from *an entirely different ASN*? How the heck do=
es
>> *that* happen?
>
> Yup.
Jared,
What you detected is a misconfiguration of devices on those networks,
but that misconfiguration (in and of itself) is not necessarily what is
commonly referred to as "IP spoofing" in the context of BCP38.
You have *not* "shown" that these ASNs "allow IP spoofing". You have
collected one data point that indicates the mere possibility that these
ASNs allow IP spoofing.
In the example that you provided, you sent a DNS query to a Pacenet
(India) IP and received a response from a Vodafone (India) IP address.
The IP from which you received the invalid response is an open resolver
(bad thing). It is completely plausible that whatever device is being
queried has interfaces on both networks.
To have "shown" that this ASN "allows IP spoofing" you must have
demonstrated that this response packet, sourced from a Vodafone IP,
entered the "Internet" from a Pacenet router interface. Unless I am
missing something here, you haven't come close to showing that.
-DMM
