Subject: [Int-area] IP-in-IP, TTL decrementing when forwarding and BITW

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Jun 2006 08:43:32 +0300 (EEST)

Hi,

In TCPM WG, while discussing draft-ietf-tcpm-tcp-antispoof section 
3.2.1, we came across something that may or may not be an issue in 
IP-in-IP tunneling spec (RFC 2003).  The spec says (see below) "[inner 
header TTL is decremented], if the tunneling is being done as part of 
forwarding the datagram, ..."

Joe's interpretation is that BITW implementations of IP-in-IP need not 
decrement inner header TTL.  Personally, I don't think RFC 2003 was 
even intended to cover BITW implementations.

This may become important if you want to apply GTSM (i.e. TTL=255 
checking) to encapsulated packets between the two endpoints of the 
tunnel.  If BITW implementation is acceptable, the topological area 
where TTL=255 applies expands slightly.

Does anyone recall the intent of the RFC?
Is anyone aware of BITW implementations of RFC 2003?
Or do folks have strong feelings what the intent should be?

Joe Touch said:
> RFC2003, sec 3.1, third-to-last (emphasis mine):
>
>   When encapsulating a datagram, the TTL in the inner IP header is
>   decremented by one **if the tunneling is being done as part of
>   forwarding the datagram**; **otherwise, the inner header TTL is not
>   changed during encapsulation**.  If the resulting TTL in the inner IP
>   header is 0, the datagram is discarded and an ICMP Time Exceeded
>   message SHOULD be returned to the sender.  An encapsulator MUST NOT
>   encapsulate a datagram with TTL = 0.
> 
> If that packet is generated at that node, or if the packet is sent to
> the tunnel in a non-forwarding (BITW) step, that decrement would not happen.
>
>   The TTL in the inner IP header is **not changed when decapsulating**.
>   If, after decapsulation, the inner datagram has TTL = 0, the
>   decapsulator MUST discard the datagram. If, after decapsulation, the
>   decapsulator forwards the datagram to one of its network interfaces,
>   **it will decrement the TTL as a result of doing normal IP forwarding**.
>   See also Section 4.4.
> 
> The decapsulator decrements only if forwarding - again, if the packet
> stops at the destination or if the device isn't a forwarder (BITW), that
> wouldn't happen.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Jun 2006 06:56:31 -0700

FWIW, there are two cases I considered where tunnel decrementing might
not occur:

	1) BITW
		typically this is for IPsec tunnels, which are
		spec'd in 4301, but which in spirit ought to follow
		2003

		they might also be used for range-extenders

	2) host-host tunnels
		in this case, there is no forwarding step,
		i.e., packets generated at the same node
		as the tunnel encapsulator and destined
		for the same node as the tunnel decapsulator

Joe

Pekka Savola wrote:
> decrement inner header TTL.  Personally, I don't think RFC 2003 was even
> intended to cover BITW implementations.
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Jun 2006 21:25:00 +0300 (EEST)

(Btw, some people didn't know BITW stands for "Bump in the Wire".)

> 		they might also be used for range-extenders

No disagreement about host-to-host tunnels.

As said, I don't see BITW functionality specified or implied in RFC 
2003.  But I'd like to know what others think.

The reason why I think BITW is not important or even relevant in this 
context is that such "BITW-like behaviour" is better achieved by L2 
tunneling, which at the same time can also be agnostic of the various 
L3 protocols that might need to be "bumped".

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Jun 2006 11:31:40 -0700

Pekka Savola wrote:
> tunneling, which at the same time can also be agnostic of the various L3
> protocols that might need to be "bumped".

Agreed - I'd like to know what besides 'forwarding' might occur at those
nodes as well.

Come to think of it, L2 bridging is one - where the packet might end up
leaving the device, but the IP tunnel wouldn't decrement the TTL as a
result. That could happen if the tunnel terminates at a VPN router
(e.g., for IPsec transport + IPIP tunnel, as per RFC 3884)

Joe

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 02 Jun 2006 12:02:23 -0700

Hello Joe,

I can verify that these two cases were not part of the discussion
that motivated the production of RFC 2003.  In fact, there was
BITW in sight when the document was first discussed, and IP
security was completely different than it is today.  I'd have to
go back and look to even remember the details about pre IPsec
security details.

If anyone is interested in the details about why the document
was written (aside from the fact that it was needed for Mobile IP)
I can try to remember but it was a long time ago.  Joel Halpern
was the AD whom I was working with.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 02 Jun 2006 12:33:44 -0700

Hello again folks,

Sorry for my typo -- I meant to say that there
was NO BITW in sight at that time.

Regards,
Charlie P.

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Jun 2006 13:12:18 -0700

Charles E. Perkins wrote:
> that motivated the production of RFC 2003. 

Do you recall what was the case that motivates the condition ("IF")
regarding how TTLs interact with forwarding on the head and tail of tunnels?

Joe

---

From: "Bill Fenner" <[email-masked]>
Date: Sun, 4 Jun 2006 14:17:29 -0400

> regarding how TTLs interact with forwarding on the head and tail of tunnels?

I was only peripherally involved, but my recollection is that the
intent was to make a host<->host tunnel look the same as a physical
point-to-point interface.  The TTL decrement that it refers to is
simply the TTL  decrement that you would perform during IP forwarding,
and you're not doing IP forwarding if you originated the packet on the
tunnel interface.

(Talking about this is a little tough without shared terminology for
some of these concepts.  Steve Deering drew me a picture long, long
ago which I always wanted to turn into ASCII art for an I-D but never
did.)

Given that, the BITW implementation should decrement the TTL if it
thinks it's a router, or not if it is pretending to be part of the
host.

  Bill

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Jun 2006 14:29:55 -0700

> and you're not doing IP forwarding if you originated the packet on the

Agreed - or if you terminate it at the tunnel interface.

> thinks it's a router, or not if it is pretending to be part of the

Right - I had actually expected that to happen as part of the forwarding
step of the IP payload at the tunnel egress.

Thanks,

Joe