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

Re: Hop Limit in Inner Header (IPv6)



(Sorry about retaining all the preceding in this reply, but I have copied
this to the IPNG list in case the wider WG wants to make some further
comments)

The operation of tunneling as described in RFC2003 is in line with that
used by IPv6.

I have now had chance to read the stuff through again more carefully and
think that the problem is one of interpretation.  The ipsec-arch-sec
document should make it clear that if the inner packet originates on the
node that is responsible for encapsulation, then the TTL (or Hop Limit in
the IPv6 case) should not be decremented as no forwarding is taking place.

If the inner packet originates on a different node, then the TTL (HL) of
the inner packet should be decremented prior to forwarding into the tunnel.

Likewise, if the decapsulating node is not the final destination of the
inner packet, then its TTL(HL) should be decremented when it is forwarded
on from the decapsulating node towards its destination.

(Incidentally, there is a typo.  The IPv6 equivalent of the TTL field is
called Hop Limit, not Hop Count)

The issue raised by Karen Heron is that if this interpretation is not
correct, then the NDP protocol will break.  A 'built-in' security feature
of the protocol design is that all NDP messages can only be received from
the link to which you are fastened (physically or logically).  By setting
the HL to 255, an attempt to spoof an NDP message by forwarding it onto the
link can be detected.  *IF* IPSEC, using tunnel mode ESP, is to be used for
NDP then it is essential that this behaviour is maintained.

Of course, there may not be a need to use IPSEC in this mode for this purpose.

Peter
TICL

At 13:59 21/04/98 -0400, Robert Moskowitz wrote:
>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
> 

PGP signature


Follow-Ups: References: