Martin CasadoL
I don't understand how this could be the case. If they are
using an ISP-wide NAT then I assume the public facing address
of the NAT is legitimate, in which case the DHCP allocated
addresses have no effect on public routing....
Unless those DHCP-allocated addresses are from public space and end up
"covering" public addresses you might wish to reach.
I see, thats a very good point. Though this is assuming that NATing
rules are applied based on the source
prefix. You could instead perform NAT based on the incoming interface,
but that obviates any local
communication. I guess the problem is fundamental, if we are using some
public prefix (say
1.2.3/24) and I send a packet to 1.2.3.11, the network cannot determine
whether I'm intending
to send traffic internally or externally. The choices are, (i) always
assume external (no internal-to-internal traffic)
or (ii) always internal (blackout certain regions of the inet).
This is a pretty serious blunder ... though may be difficult to
determine remotely due to the interposition of
proxies and tunnelling.
.martin
As an example, using some of my address space: if you set up your NAT device
so that its public address is that which is assigned by your ISP, and have
it assign addresses from 192.135.198.0/24 on your LAN, you'll find that the
hosts on your LAN can no longer connect to my web server at 192.135.198.111,
because they believe it is "on their LAN" as opposed to "on the other side
of the NAT".
This obviously gets worse for the users if the "LAN side" address space is
significantly larger than a single /24.
Matthew Kaufman
[EMAIL PROTECTED]
http://www.amicima.com
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
