Re: BCP38.info

[Jared Mauch <jared () puck nether net>]

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".
>
> 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.
>
> Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From 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