[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hop Limit in Inner Header (IPv6)

At 03:32 PM 4/17/98 +0100, Peter Curran wrote:

I am not familiar with NPD, but from RFC 2003 we have:

   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.

   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.

This is a little different from IPsec-arch-04:

        2. The TTL in the inner header is decremented by the
           encapsulator prior to forwarding and by the decapsulator if
           it forwards the packet.  (The checksum changes when the TTL
           changes.)

but none the less, both decrement.  I might point out that tunneling in
ipsec-arch's parentage is the 2003 work, if not 2003 itself.  It is
interesting to note that 2003 does not decrement on decapsulating, though.


>It sounds as if there is a danger of creating an illogicality here.
>
>When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across
>an IPv4 network of any size) then the inner packet hop-limit is not
>decremented because both hosts are on the same logical link connecting
>them.  As the packet is not *forwarded* into the tunnel, then the hop-limit
>remains unchanged.
>
>By the same logic, why should the hop-limit be decremented when the packet
>is being sent across an IPSEC tunnel that exists between the same two nodes?
>
>IMHO, this shouuld not happen because it is not logical.  If the packet
>originated on a 3rd node, was passed to the 1st and then sent down a tunnel
>to the 2nd then I agree the hop-limit should be deceremented - the packet
>is forwarded from one link to another.
>
>The proposed mechanism will break NDP.
>
>Another question that should be considered relates to the scope of the IPv6
>addresses. Is it illogical for an IPSEC tunnel to exist between two nodes,
>if the end-points of the tunnel are recognised by link local addresses and
>yet not on the same physical link?  What if they are not on the same site?
>
>In the former case, link local addresses could be assigned to the tunnel
>ends - the two devices will be on the same logical link.
>
>Peter
>TICL
>
>
>At 21:27 16/04/98 -0400, Steve Bellovin wrote:
>>	    From: Karen Heron <heron@us.ibm.com>
>>	    Date: Wed, 15 Apr 1998 07:49:03 -0400
>>	
>>	    In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio
>>	n
>>	    for Tunnel Mode, the inner header Hop Limit is decremented.  This
>>	    will cause problems for securing IPv6 NDP traffic.  The hop limit i
>>	s
>>	    set to 255 in NDP packets and checked in the receiving node to make
>>	    sure it came from the same link.  If this NDP exchange is secured
>>	    using tunnel mode and the hop limit is decremented before the packe
>>	t
>>	    is encapsulated, the receiving node will reject the NDP packet and
>>	    neighbor discovery will fail, even if the two nodes are on the same
>>	    link.  Should the Hop Limit not be decremented for locally generate
>>	d
>>	    traffic?  If not, I don't see how NDP traffic can be secured using
>>	    tunnel mode - maybe I've missed something in the drafts that said
>>	    this.  If this question has already been answered, I'd appreciate a
>>	    pointer to the discussion (I didn't see it in the archives).
>>	
>>	Karen,
>>		I would think that if a packet originates at host A, and the
>>	packet then gets encapsulated by security gateway G and sent down the
>>	IPSEC tunnel to host B, that host A and host B are not on the same
>>	network.  
>>	
>>		In fact, even if the packet is originated and encapsulated at
>>	host A, and sent over a IPSEC tunnel, which might send the packet
>>	halfway across the world, when it is decapsulated at host B, the hop
>>	count should be decremented, since it is extremely unlikely that they
>>	are really "neighbors".
>>	
>>		I'm not completely familiar with what exactly NDP is trying to
>>	do, but if you're using tunnel mode, you can't distinguish between
>>	whether your communications partner is on the same ethernet, or on the
>>	wrong side of MAE-EAST (you can tell that by the number of packets tha
>>	t
>>	get dropped, though :-).  If this is what NDP is trying to do, then
>>	fundamentally you shouldn't be using tunnel mode.  Whether you always
>>	decrement the hop count, as the spec currently states, or never
>>	decrement the hop count, you still don't know whether someone is next
>>	door or on the other side of the planet.
>>
>>My own view is that a tunnel is a virtual wire between two nodes.  NDP
>>should work across that tunnel only to the extent that the packet
>>originated on one endpoint and terminated on the other.  ("Neighbor" is
>>a topological construct here, and ignores phyiscal reality.)
>> 
>
>
Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com
Follow-Ups: References: