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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Feb 2007 16:34:34 -0800

> From: Fred Baker [mailto:[email-masked]] 
> 
> 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.

As I explained to you in private, you missed the point here. My statement was carefully chosen and the language very precise. You missed it. 

IPSEC is as far as I am aware the only application where the actual value of the sending and receiving address is critical. This is because they are cryptographically signed with a MAC address.

No other protocol has this specific dependency.

> Any client-server application 
> works fine across a NAT, as long as it is the client that 
> initiates the connection.

This fits into a category I call 'not making NAT work properly' which is a separate case.

We could make NAT work effectively but to do so would require us to change the way we look at network administration. We would have to move away from the model of well known ports and start using the DNS as the exclusive mechanism for service discovery.

If I start a Webcam on my box it would have to send a message to my NAT box to say 'I am offering WebCam service on this address and port' the NAT box would in turn have to assign an external port for the service and advertise this on the external DNS.

Yes we can make these things work, but it does take a determination to do so. IPSEC is the one protocol that would still stick out. But even that is fixable if you introduce an additional field that the sender fills with a static nonce value that is invariant for the connection.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Feb 2007 20:42:04 -0500

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    >> > 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.
    >> 

    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.

Other examples include Kerberos, GSS-API (in some cases) and SASL (in
some cases).
Fortunately it was easier to fix these than IPsec.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 28 Feb 2007 21:13:17 -0500

On Wed, 28 Feb 2007 20:42:04 -0500

> in most IPsec deployments and in all of the other security protocols
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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Feb 2007 23:20:11 -0500

>>>>> "Steven" == Steven M Bellovin <[email-masked]> writes:

    Steven> On Wed, 28 Feb 2007 20:42:04 -0500
    Steven> Sam Hartman <[email-masked]> wrote:

    >> >>>>> "Hallam-Baker," == Hallam-Baker, Phillip
    >> <[email-masked]> >>>>> writes:
    >> 
    >> 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.
    >> >> 
    >> 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.