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]

 



>>>>> "Steven" == Steven M Bellovin <smb@xxxxxxxxxxxxxxx> writes:

    Steven> On Wed, 28 Feb 2007 20:42:04 -0500
    Steven> 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.
    >> 
    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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]