Subject: [nat66] Why not an application gateway?

From: Tom Pusateri <[email-masked]>
Date: Mon, 30 Mar 2009 23:15:10 -0400

So once you limit NAT for IPv6 to a 1:1 mapping (i.e. you no longer  
share an address), then it seems like there's isn't a big advantage  
over an application gateway.

In fact, I would much prefer an application gateway because you are no  
longer interfering with the packets. You are consciously directing  
them to a point of policy.

Today, there may not be the perfect way to configure the application  
gateway on the hosts but that problem can be easily solved with either  
one or more existing DHCP options or some new ones.

This provides the same topology hiding as well as the same multi- 
homing capabilities.

What am I missing?

Thanks,
Tom

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 22:51:42 -0500

Tom Pusateri wrote:
> share an address), then it seems like there's isn't a big advantage over
> an application gateway.

wtf?  application gateways have to be written for each protocol, whereas
NATs do not (at least for those protocols that don't do referrals).

that makes for a huge deployment mess.  it also breaks apps when the end
points upgrade their protocols and the ALGs don't keep track.

Keith

(now if we're going to have NATs at all, I'm a big fan of having a
standard signaling/control protocol that should work for all NATs.  but
that's not the same as an application gateway)

---

From: Erik Kline <[email-masked]>
Date: Mon, 30 Mar 2009 20:57:14 -0700

On Mon, Mar 30, 2009 at 8:51 PM, Keith Moore <[email-masked]> wrote:
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
>

Actually I would imagine that most applications would just need a
"generic" TCP or UDP proxy.  In essence a /128 to /128 NAT, with ALGs.
 Doing this requires listing all traffic mappings that need to be
permitted.  A lot of work, but explicit allow with implicit deny would
make most of the security that I know more comfortable.  It would be
more like have VIPs for things that need them.

2 cents,
-Erik

---

From: Erik Kline <[email-masked]>
Date: Mon, 30 Mar 2009 20:57:49 -0700

> more like have VIPs for things that need them.

s/security/security folks/

oops

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 00:01:36 -0400

> "generic" TCP or UDP proxy.  In essence a /128 to /128 NAT, with ALGs.

we should avoid ALGs like the plague.

for an idea of what I have in mind, take a look at draft-moore-nat-xc.

Keith

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 31 Mar 2009 00:09:54 -0400

> that's not the same as an application gateway)

You miss the point. If someone wants to build a big box that controls  
traffic and sneakily fabricates headers, they can build a big box that  
does it upfront and follows the end to end model without altering the  
packets. It doesn't have to be exactly what people are calling  
application gateways today.

A NAT firewall box that filters everything but the few applicatons  
that they want to allow through smells alot like multiple application  
gateways. Especially when they throw deep packet inspection into the  
mix.

Thanks,
Tom

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 00:23:01 -0400

> packets. 

wtf?  how does such a box follow the end to end model if it "sneakily
fabricates headers"?  either the box allows the endpoints to talk to
each other without interference (i.e. the e2e model) or it doesn't.

a box that munges traffic breaks the e2e model no matter whether it's
doing it at layer 3 or layer 4 or layer 7.

> A NAT firewall box that filters everything but the few applicatons that
> they want to allow through smells alot like multiple application
> gateways.

I certainly won't claim that providers can't do this, but such a thing
would break enough apps (whether deliberately or accidentally) that at
least in any market resembling the current one I'd expect significant
pushback from users.

Keith

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 31 Mar 2009 08:27:17 -0400

> doing it at layer 3 or layer 4 or layer 7.

Obviously I didn't communicate clearly enough. The NAT box is the one  
that sneakily fabricates headers. I am totally against this. I would  
rather it do what it is doing out in the open by terminating the TCP  
connection or re-originating the UDP packets from the policy box. This  
follows the end to end model which is what I'm advocating.

I am just trying to bring whats currently in the dark out into the  
light.

I run an HTTP proxy on my home gateway.
I run a sip proxy server on my gateway.
I run an SMTP server on my gateway.
For the needs of people behind current NAT boxes, we're not that far  
away.

Thanks,
Tom

>> that

---

From: Scott Brim <[email-masked]>
Date: Tue, 31 Mar 2009 08:30:16 -0400

> For the needs of people behind current NAT boxes, we're not that far  

And for those protocols that you don't proxy, e.g. ones that your edge
boxes have never seen before, would you just NAT?  At least that would
allow e2e application transparency for user innovation.

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 10:51:10 -0400

> follows the end to end model which is what I'm advocating.

it only follows the e2e model if the application endpoint that
establishes the connection intends to connect to that box.  if the
connection is intercepted (say by having the box lie about DNS results
or by having the box accept traffic destined for someone else's IP
address) it still violates the e2e model.

> I am just trying to bring whats currently in the dark out into the light.
> 
> For the needs of people behind current NAT boxes, we're not that far away.

a) for many protocols, application gateways do more harm than NATs
b) interception proxies of any kind are evil
c) you've named 3 protocols out of hundreds of thousands of protocols in use

again, wtf?

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Mar 2009 11:40:02 -0400

Could you explain what you mean by an "application gateway"?

Margaret

On Mar 30, 2009, at 11:15 PM, Tom Pusateri wrote:

> In fact, I would much prefer an application gateway because you are  
> no longer interfering with the packets. You are consciously  
> directing them to a point of policy.
>
> gateway on the hosts but that problem can be easily solved with  
> either one or more existing DHCP options or some new ones.
>