On Wed, 28 Feb 2007 20:42:04 -0500
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.
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf