[168516] in North American Network Operators' Group
Re: BCP38.info
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Jan 28 16:11:41 2014
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <25c18b08$e24670d$4597c3a5$@flhsi.com>
Date: Tue, 28 Jan 2014 16:11:16 -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 4:07 PM, Nick Olsen <nick@flhsi.com> wrote:
> While I see what you're saying. It's still not "Spoofed".
>=20
> The device in question receives the request. And then generates a =
response with the src address of the egress interface of the device dst =
to the IP and port that requested it... In this case. The GRE tunnel. =
Unless I'm missing something here about replying to a request only on =
the interface which it ingressed the device. And the fact that it's UDP. =
not TCP. So it's fire-and-forget.
>=20
> Thus, Nothing was ever spoofed. It just simply was returned from a =
different interface of the same device. =46rom our point of view. We saw =
the packet of DNS-SRC>OurCustomer. And the other ISP, Which transported =
the reply. only saw Customer-SRC>DNS-DST.
Nope, what happens is I send from my IP address (lets say 10.0.0.1). I =
send a packet to 192.168.0.1. It has 172.16.0.1 as it's DNS server.
192.168.0.1 has a rule that says send UDP/53 packets I process to =
172.16.0.1. Since i'm "outside" it's "NAT", the rule ends up taking the =
source IP, which isn't part of it's "NAT" set, and ends up copying my =
"source" IP into the packet, then forwards it to the DNS server.
172.16.0.1 is responding to 10.0.0.1 DIRECTLY.
It took me awhile in looking at this to figure out what was happening. =
Was interesting when you find out the 192.168.0.1 CPE was doing.
You may not call it "spoofing" as it's doing what it was supposed to =
do/configured to do, but it shouldn't be sending the packet with *my* IP =
address.
- Jared=
