Re: Hop Limit in Inner Header (IPv6)
Steve Bellovin <smb@research.att.com> Fri, 17 April 1998 01:17 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA16377 for ipsec-outgoing; Thu, 16 Apr 1998 21:17:40 -0400 (EDT)
Message-Id: <199804170127.VAA09270@postal.research.att.com>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
cc: Karen Heron <heron@us.ibm.com>, ipsec@tis.com
Subject: Re: Hop Limit in Inner Header (IPv6)
Date: Thu, 16 Apr 1998 21:27:05 -0400
From: Steve Bellovin <smb@research.att.com>
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 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.)
- 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