Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC



On Wed, 28 Feb 2007 20:42:04 -0500
Sam Hartman <hartmans-ietf at mit.edu> wrote:

> >>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker at verisign.com>
> >>>>> writes:
> 
>     >> From: Fred Baker [mailto:fred at cisco.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.org
https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.