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

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.

Joe Touch wrote:

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

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area