Re: Hop Limit in Inner Header (IPv6)
"Theodore Y. Ts'o" <tytso@MIT.EDU> Fri, 17 April 1998 00:58 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16231 for ipsec-outgoing; Thu, 16 Apr 1998 20:58:40 -0400 (EDT)
Date: Thu, 16 Apr 1998 21:12:17 -0400
Message-Id: <199804170112.VAA14509@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Karen Heron <heron@us.ibm.com>
Cc: ipsec@tis.com
In-Reply-To: Karen Heron's message of Wed, 15 Apr 1998 07:49:03 -0400, <5040300014982482000002L022*@MHS>
Subject: Re: Hop Limit in Inner Header (IPv6)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
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 Construction for Tunnel Mode, the inner header Hop Limit is decremented. This will cause problems for securing IPv6 NDP traffic. The hop limit is 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 packet 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 generated 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 that 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. - Ted
- Hop Limit in Inner Header (IPv6) Karen Heron
- Re: Hop Limit in Inner Header (IPv6) Theodore Y. Ts'o
- Re: Hop Limit in Inner Header (IPv6) Steve Bellovin
- Re: Hop Limit in Inner Header (IPv6) Peter Curran
- Re: Hop Limit in Inner Header (IPv6) Robert Moskowitz
- Re: Hop Limit in Inner Header (IPv6) Robert Moskowitz
- Re: Hop Limit in Inner Header (IPv6) Michael Richardson
- Re: Hop Limit in Inner Header (IPv6) Peter Curran
- Re: Hop Limit in Inner Header (IPv6) Michael Richardson