"Steven" == Steven M Bellovin <smb(_at_)cs(_dot_)columbia(_dot_)edu>
Steven> On Wed, 28 Feb 2007 20:42:04 -0500
Steven> Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu> wrote:
>> >>>>> "Hallam-Baker," == Hallam-Baker, Phillip
>> <pbaker(_at_)verisign(_dot_)com> >>>>> writes:
>> >> From: Fred Baker [mailto:fred(_at_)cisco(_dot_)com]
>> >> 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.
Steven> More precisely, any protocol that uses secondary
Steven> connections, the parameters of which are carried in-band
Steven> in a secured connection, can't easily be NATted. The most
Steven> obvious example is FTP. 4217 notes that it only works
Steven> through NAT if the client is aware of the NAT's existence,
Steven> and that there are serious security issues even so.
While what you say is true, it is unrelated to Kerberos, SASL, IPsec
or GSS's use of ip addresses.
We're way down a rat hole here.
Ietf mailing list