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

["Charles E. Perkins" <[e-mail]>]

Hello again folks,

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

Regards,
Charlie P.

Charles E. Perkins wrote:

>
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area