On Wed, 28 Feb 2007 20:42:04 -0500 Sam Hartman <hartmans-ietf@xxxxxxx> wrote: > >>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx> > >>>>> writes: > > >> From: Fred Baker [mailto:fred@xxxxxxxxx] > >> > >> On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote: > >> > >> > The core assumption here seems to be that NAT is a bad thing > >> so lets > get rid of NAT rather than trying to make NAT work. > >> > ... > The only protocol which really cares about the source > >> and destination > IP addresses is IPSEC and we have discovered > >> that is a design error. > >> > >> I guess you haven't been around the applications that have > >> trouble with this very much. > > Hallam-Baker,> As I explained to you in private, you missed the > Hallam-Baker,> point here. My statement was carefully chosen and > Hallam-Baker,> the language very precise. You missed it. > > > Hallam-Baker,> IPSEC is as far as I am aware the only application > Hallam-Baker,> where the actual value of the sending and receiving > Hallam-Baker,> address is critical. This is because they are > Hallam-Baker,> cryptographically signed with a MAC address. > > I think this is more a statement about what protocols you've spent a > lot of time with than about what people have done. > > in most IPsec deployments and in all of the other security protocols > that have the same flaw. > More precisely, any protocol that uses secondary connections, the parameters of which are carried in-band in a secured connection, can't easily be NATted. The most obvious example is FTP. 4217 notes that it only works through NAT if the client is aware of the NAT's existence, and that there are serious security issues even so. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf