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