Subject: [BEHAVE] Should NATs decrement the TTL field?

From: Philip Matthews <[email-masked]>
Date: Tue, 24 Apr 2007 09:06:59 -0400

Rather than continuing the general discussion on whether a NAT is a  
router
(see separate thread), I now think it is more productive to discuss
specific behaviors. To this end, I will ask:
       Should a NAT decrement the TTL field in the IP header when
       forwarding a packet?

Joe Touch has suggested that the answer should be "No" because
NATs should try to be invisible to applications on the private side
of the NATs. However, this "invisibility" argument is not resonating
with me right now, mostly because I am spending a lot of time right
now figuring out how to make P2PSIP overlays work through NATs
(in which using STUN and ICE play an important role).

In my current thinking, NATs are invisible to the extent that routers  
are invisible:
most applications do not need to know they are there, but some  
applications
do and all applications need to be prepared to accept ICMP messages
from them.

So I current think a NAT _should_ decrement the TTL field
(though I am willing to be convinced otherwise ...).

Note that this implies that a NAT needs to generate an ICMP "Time  
Exceeded"
message when the TTL reaches 0, and also implies that a NAT will show
up in a traceroute.

Comments?
Does anyone see a good reason why a NAT _should not_ decrement the  
TTL field
(other than the "try to be invisible" argument)?
Are there security implications to this question?

- Philip

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Apr 2007 06:19:30 -0700

Philip Matthews wrote:
> Rather than continuing the general discussion on whether a NAT is a router
> Joe Touch has suggested that the answer should be "No"...

I will claim that the answer *IS* "no".

...
> (though I am willing to be convinced otherwise ...).

If they're routers, they MUST decrement the TTL field, and do all the
rest of what 1812 requires.

I think it's necessary to realize that:
	- on the public side, NATs are RFC1122 end hosts
	- on the private side, they almost look like routers,
	except when they do not

So I'll presume you're proposing a new requirement for the private side
view; I disagree that the public side can, should, or ever will consider
them anything but end hosts that source and sink packets.

This would require a set of other actions, notably that all ICMPs
originating from the private side - from end hosts or from routers - be
translated into 1122-meaningful ICMPs originating from the host side of
the NAT.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: "Dave Hudson" <[email-masked]>
Date: Tue, 24 Apr 2007 07:58:28 -0700

* -----Original Message-----
* From: Philip Matthews [mailto:[email-masked]] 
* Sent: 24 April 2007 14:07
* To: Behave WG
* Cc: Joe Touch
* Subject: [BEHAVE] Should NATs decrement the TTL field?
* 
* In my current thinking, NATs are invisible to the extent that 
* routers are invisible:
* most applications do not need to know they are there, but 
* some applications do and all applications need to be prepared 
* to accept ICMP messages from them.

NATs in most non-enterprise uses usually can't be invisible on the
private side because they're usually the default gateway for the other
hosts on the private network.  They frequently also host other services
to the private network: DHCP server, HTTP-based configuration, UPnP,
etc.  The only devices I've seen that are transparent tend to be
security appliances such as firewalls and spam filters and I'm curious
about how widescale the deployment of transparent NATs might be?

* So I current think a NAT _should_ decrement the TTL field 
* (though I am willing to be convinced otherwise ...).
* 
* Note that this implies that a NAT needs to generate an ICMP 
* "Time Exceeded"
* message when the TTL reaches 0, and also implies that a NAT 
* will show up in a traceroute.

This is the behaviour of pretty-much every low-end NAT I've ever seen
tested (and that's a lot of them) - it's also the expected behaviour for
the cdrouter test suite which is used by many OEMs for testing such
routers (incidently this is the same test suite that has been doing
things like verifying hairpinning behaviour since the very early BEHAVE
drafts were being written).

I can't imagine any OEM I've dealt with not wanting a NAT to show up in
a traceroute since they tend to want to use this to diagnose
connectivity problems.

Regards,
Dave

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Apr 2007 08:17:57 -0700

Dave Hudson wrote:
> private side ...

Folks,

We really need to distinguish between what SOME NATs do (or can do) and
what ALL NATs MUST do.

The MUSTs define what it is to be a NAT, a router, or a host. Everything
else is interesting, but not relevant IMO.

---

Further, this underscores my position that what a NAT is depends on what
side you're looking at. From the public side, IMO they're hosts. From
the private side, IMO, they're routers. IMO, that actually provides a
reasonable definition of what a NAT is.

To that end, ICMP code 13's could rightly be sent back to private-side
hosts, but that side is almost never interesting. It's the public side
behavior we need to determine, and IMO that's entirely already specified
by RFC1122.

> This is the behaviour of pretty-much every low-end NAT I've ever seen

The key question is "what should a host do when this happens". Hosts
don't decrement the TTL; they just receive the packet. TIME_EXCEEDED is
not the appropriate response.

This isn't a clue that NATs are routers, but rather that they are
already visible to the rest of the Internet in ways that many don't want
to believe.

...
> a traceroute since they tend to want to use this to diagnose

Agreed - from the inside, not from the outside.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Apr 2007 08:30:36 -0700

> I will claim that the answer *IS* "no".

To clarify - the answer is "you can't expect it to be YES", and to be a
router you MUST expect then answer to be "YES".

Joe

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 24 Apr 2007 11:40:05 -0400

Joe, I agree with rationale you are using here, but I am not sure NATs were
really understood well around the time endpoints and router behavior was
defined. TTL is for preventing loops. For all practical purposes NATs are
middleboxes and hence not the ultimate destination of the packets. So if we
agree with that then they must decrement TTL or manage it in a way to
prevent loops.

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Apr 2007 09:47:55 -0700

address, they source and sink packets, and things behind them are
intended to be invisible. That's no different from a end host that sinks
IP packets and generates some backend messages internally (e.g., on its
SATA link to the disk) or inside its internal interconnects.

> So if we agree with that then they must decrement TTL or
> manage it in a way to prevent loops.

IMO, if we're going to revise the definition of a NAT, there are some
requirements:

	A- to the public side, obey 1122
	B- to the private side, obey 1812

This means that for packets going from public->private, the TTL must be
decremented. It also means that for packets going from private->public,
the TTL need not be decremented.

I think that's OK, since a loop through a single NAT would require going
 public->private at some point. If you always go private->public, there
can be no loop.

However, this presumes we're redefining a NAT to fit better (IMO) into
the Internet architecture to remove these ambiguities (e.g., what ICMP
codes to send at what time). I'm in favor of that - and might even want
to participate - but I didn't think that was in the charter of this WG.

Joe
--=20

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Apr 2007 15:24:08 -0400

>>>>> "Philip" == Philip Matthews <[email-masked]> writes:
    Philip> specific behaviors. To this end, I will ask:

    Philip> Should a NAT decrement the TTL field in the IP header when
    Philip> forwarding a packet?

  ABSOLUTELY.

  If it doesn't do that, then I can't see it.
  I need to see it to know that I'm being screwed over.

    Philip> In my current thinking, NATs are invisible to the extent
    Philip> that routers  are invisible:

  I agree.

    Philip> Note that this implies that a NAT needs to generate an ICMP
    Philip> "Time  Exceeded" message when the TTL reaches 0, and also
    Philip> implies that a NAT will show up in a traceroute.

  Yes.
  I don't like calling NAT boxes "home routers", because they don't
behave as routers from both sides.  Unfortunately, I've lost that war
with the "market"

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 25 Apr 2007 22:00:58 -0700

> Are there security implications to this question?

I think so - an important security property is the properties  
described in the "Privacy and Topology Hiding" section of draft-ietf- 
v6ops-nap-06 (note this draft has been approved and will be an RFC  
soon).  Requiring decrement of TTL would reveal internal topology  
information which is a big deal in cases where you are trying to hide  
if you are currently in europe of US for privacy reasons. Obviously  
lots of NATs are deployed where people don't care about topology  
hiding but this is a big concern in some deployments.

I can't imagine how requiring that NATs do, or don't, decrement the  
TTL will help the P2PSIP stuff much but perhaps I am just not seeing  
the importance.

Cullen <with my individual hat on>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 25 Apr 2007 22:05:45 -0700

I have seen this loop argument before and I seem to recall the  
conclusion of it was as long a NATs don't increment the TTL when  
going from the public side to private side, that the TTL will still  
stop all loops. I might be wrong.

PS - what Joe said about modeling NATs as generally looking like host  
on outside and router on inside seemed like a good guideline to try  
and figure out what they should do.

On Apr 24, 2007, at 8:40 AM, Medhavi Bhatia wrote:

> Joe, I agree with rationale you are using here, but I am not sure  
> NATs were really understood well around the time endpoints and  
> router behavior was defined. TTL is for preventing loops. For all  
> practical purposes NATs are middleboxes and hence not the ultimate  
> destination of the packets. So if we agree with that then they must  
> decrement TTL or manage it in a way to prevent loops.
>