North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: RFC1918 addresses to permit in for VPN?
Randy Bush wrote: >yes, but the sub-discussion is quite bogus. lsr is not required to get >through a nat. the nat presents an outer address that maps directly to the >inner address. attack the outer address directly and you have attacked the >inner address. life is simple. Your points are valid, but when did we begin discussing NATs in this thread? I thought that this was another discussion about using RFC 1918 address space on publicly visible interfaces. A router with all of its interfaces numbered using RFC 1918 space, and no tricks like source routing to get in the way, will not be directly reachable from the global Internet. That saves it from one class of attacks, but still leaves it open to others. The most common excuse I've seen for using RFC 1918 space on public interfaces is "I wanted to conserve address space." Silly. People are afraid, without reason, of ARIN and the other RIRs, and take conservation to such an extreme that the network becomes ugly at best and unusable at worst. >that's all a nat does, translate addresses. again, changing your car's >license plates does not make it less vulnerable to accidents. This isn't a great analogy though, because a whole class of attacks on the Internet rely on the ability to reach the target directly, and reachability is influenced by addressing. On the road, an accident can occur between any two vehicles, license plates or IPv4 addresses or not. >people commonly confuse nats with packet filters, stateful filters, algs, >etc. of course the readers of this list would not be so easily confused. People think of security when they think of NAT because it's usually implemented in such a way that a small amount of additional security is provided to the devices that sit behind the translator. Obviously (to the readers here,) there are other ways to achieve the same level of filtering without the translation. Mark