Doing some trimming - hate to have to scroll down 20 lines to get to the
new content ;)
> > Not as clear as is what is going on below, and as Kris stated, it
> > shouldn't happen with ICMP, but just throwing it out for
> > consideration.
> >
> > Cheers,
> > kx
> >
>
> +1 on strange things with ICMP. The UDP socket code I've been writing
> lately has seen some of strangest ICMP messages back. Between all the
> different OS, firewalls, NATs, and other strange network
> devices out there,
> you're going to see some crazy ICMP packets.
Load balancers. You missed that one. And that *could* be the case here -
some misbehaving device doing load balancing in the path. And then the
answer could either be from the same host, but different interface - or
from a totally different host, which shares the original IP our friend
here was scanning with other hosts - and the load balancer algorithm
didn't work right.
>
> I haven't given it more than 2 seconds of thought, but we could try
> something TCP SYNCOOKIE inspired for our ICMP ECHO requests.
>
> Say we stuffed some useful data in the payload like:
>
> <64 bit timestamp><32 bit salt><32 bit target IP XOR 32 bit
> salt><32 bit
> checksum (CRC?)>
>
> Then when we receive an ICMP ECHO REPLY from a host we don't
> know about, we
> check the payload. If:
>
> * The time is within some reasonable range
> * The salt matches the salt being used by the nmap process
> * The XOR of the salt and jumbled IP field match an IP we're probing
> * The checksum computes
>
> Then we accept the echo reply as valid even though something
> is slightly
> broken.
>
> Or maybe I'm missing something this is a terrible idea?
You're suggesting something very similar in concept to
http://www.ietf.org/rfc/rfc3947.txt - "Negotiation of NAT-Traversal in
the IKE". Too bad for it to really work you need for the other end, the
receiving one, to also understand what you're trying to do and report
back to you "yeah, here's how I should look - check if that is how you
see me" and then detect NAT/PAT/other in the path from source to
destination.
Otherwise, it's all guesswork - and not only that, but adding
complex[itude]? complex[iness]? - heck, adding more code to nmap to
handle a corner case, which means more chance of errors in the normal
case, more time spent debugging the new (and the old) code . . . not
worth it, unless it becomes a widespread issue :)
A puzzle - will remain like that for the time being :)
Dario
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Oct 26 2007
Intro
