Subject: Re: TTL=255 on xmit, no check on receipt please

From: Stuart Cheshire <[email-masked]>
Date: Mon, 9 Dec 2002 16:12:20 -0800

>Could we have a simple summary of the reasons that the intuitive
>solution of TTL=1 to keep link-local (LL) traffic from being forwarded
>off the link is bad, please?

Below is the mail from Dave Thaler which originally carried the debate 
back in April 2001.

Summary:

TTL=255: incentive for ISPs to do the right thing
         easily detect offenders

TTL=1:   no incentive for ISPs/router vendors to do the right thing
         no way to easily detect offenders

>Subject:     RE: IPv4 linklocal security
>Date:        4 Apr 2001 7:18 pm
>From:        Dave Thaler, [email-masked]
>To:          Stuart Cheshire, [email-masked]
>CC:          [email-masked]
>
>However, the discussion of TTL=1 vs TTL=255 basically repeats a
>discussion that occurred in the MBoneD WG at IETF 38 (Memphis).
>The meeting notes don't say much, but are at
>http://www.ietf.org/proceedings/97apr/97apr-final/xrtftr65.htm
>
>The essence of the discussion is that Ross Finlayson gave a presentation
>in which he asked what the best TTL was, for each multicast scope.  He
>suggested publishing a list of recommended TTLs for each scope.
>Van Jacobson and I both argued that TTL=255 should always be used, so
>the meeting minutes skip to the conclusion which was "The final 
>recommendation was to abolish the use of TTL as a boundary mechanism",
>and as a result no list of TTLs per scope were published (and any
>old lists on web pages were removed).
>
>One of the arguments that Van and I made was that using TTL=255
>provides two things: 
>1) an incentive for ISPs to do the right thing
>by configuring routers to fix "holes" in scopes (in the zeroconf
>context this translates to not forwarding 169.254/16), or even
>better, an incentive for router vendors to do this automatically, and
>2) (less importantly) a way to easily detect offenders.
>
>In contrast TTL=1 provides no incentive for ISPs/router vendors to 
>do the right thing.
>
>Whether this argument is strong enough to use TTL=255 in the
>Zeroconf scenarios is up to this WG to decide, but it was
>good enough for the MBoneD WG in 1997.
>
>The two rules at the top of this email are orthogonal to the 
>TTL decision.  Even with the two rules on address checking,
>I'd still prefer TTL=255.
>
>-Dave

---

From: Daniel Senie <[email-masked]>
Date: Thu, 26 Dec 2002 20:13:41 -0500

At 07:41 PM 12/26/2002, Christian Huitema wrote:
> > > One has to weigh the potential benefits (including security, if any)
> > > when deciding whether the benefits of a TTL=255 check are high
>enough
> > > to out weight the negatives (like reduced interoperability).
> >
> > While there are very few true security benefits, the ability to easily
> > discard routed LL packets is an operational benefit that should be
> > implemented. The interoperability issues with non 255 packets can be
>fixed
> > via update mechanisms easily enough.
>
>I don't think so. I really believe that all this is a trade off. If what
>you want is a properly architected link local "zeroconf" service, then
>you should use IPv6.

Let us avoid the prospects of IPv6 deployment in this discussion. IPv6 will 
be deployed, or not, independent of whether zeroconf is well implemented on 
IPv4.

>  If you insist on IPv4, it must be for compatibility
>with existing implementations etc. That means that the zeroconf IPv4
>should be designed to maximize interoperability with existing IPv4
>service that were not necessarily zeroconf aware.
>
>If you consider interoperability, the TTL 255 requirement for IPv4
>addresses is not very productive. There is a wide body of deployed
>implementations that use the auto-configured IPv4 address and set the
>initial TTL to a value other than 255, which means that implementations
>will not in practice require a check to the value 255 for a very long
>time. So you will be left with a "set 255, don't check" implementation,
>which means that you won't get any protection, and also means that if
>your packet is somehow swallowed by a mis-configured router, it will
>travel all the way to the Internet core.
>
>On the other hand, if you set TTL=1, you will actually be able to
>interoperate with existing IPv4 implementations, and also to be robust
>in the presence of non-zeroconf aware router.

Two problems with that argument:

1. There's an existing implementation, deployed, which sets TTL=255.

2. We've established through discussion that zeroconf stations would not 
send to a router regardless, since they would not have a default route 
anyway. The only real path for getting packets from a zeroconf station to a 
router would be via another station on the network that's not aware. Even 
if the router tried to be that local station, the packet would be addressed 
to that router, and not to a station beyond, negating the TTL=1 as a useful 
way to preclude leakage.

Given what I've heard from the Microsoft folk, it appears it'll take a 
while to get TTL=255 on transmit deployed. That is, though, the right 
answer in my opinion. Checking of TTL=255 will have to wait a while. The 
best compromise at this stage appears to be to set TTL=255 on transmit for 
the best possible compatability with the deployed Apple Mac OS 
implementation, but not implement the TTL=255 check on receipt unless a 
user explicitly asks for it or after a significant period of time. I 
suggest we settle on 3 or 5 years as the timeline for requiring TTL=255 on 
receipt (time to be measured from publication date of the LL document).

Regardless, I believe TTL=1 provides no value in the zeroconf environment, 
and we should remove it from the discussion.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 27 Dec 2002 12:39:20 -0500

At 12:17 PM 12/27/2002, Christian Huitema wrote:
> >> And you should use IPv6 anyhow.
> >
> > Yes, but we can't wait 7 years for this to be ubiquitous enough...some of
> > use need to get work done *now* as well.
>
>There is absolutely zero barrier to deployment of IPv6 in a zeroconf 
>scenario. We are speaking of communication between 2 computers on the same 
>link, so the only requirement is agreement between these two computers on 
>which software to use. The 7 years argument is plain bogus: we can make it 
>work right now.

If the software stacks were pre-installed, perhaps. Vendors seem to still 
be a distance from this. There are some in the zeroconf group who hope to 
also add embedded devices to zeroconf networks. The embedded space is a 
long way from being ready for IPv6, from what I've seen.

>
>Using IPv6 does require a software upgrade on those computers that don't 
>have an IPv6 stack, but deploying a new IPv4 feature like auto-IP on those 
>computers that don't support it yet also requires a software upgrade.

Except that for the most part we're talking about something which MOST host 
platforms PRESENTLY support. LinkLocal has been shipped by Microsoft for 
many years (win98), has been in Mac OS for some time and I believe it's in 
the Linux distributions.

>Different parties may argue that one is easier or more productive than the 
>other, and different parties will in fact argue different side of this 
>argument. The truth is that we are speaking about shades of gray.
>
>The other strong argument is that using IPv6 link local is a better 
>solution than what zeroconf attempts to do with the IPv4 hack: at least, 
>you get addresses that are for all practical purposes globally unique, and 
>thus are not affected by events such as link split or intermittent 
>connectivity.

Since the document under review is specifically an IPv4 document, is there 
any chance we can limit the discussion? As I said in a previous email, 
there's a lot of controversy over whether IPv6 is ready to be deployed, and 
what it'll take to get it out. However, this document is about an IPv4 
solution which to a large degree is already deployed, and would benefit 
from standardization.

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 28 Dec 2002 11:34:08 -0800

>many years (win98), has been in Mac OS for some time and I believe it's in

Look, I am not saying that we should not issue a standard that documents the existing practice. I am saying that the main reason for standardizing an IPv4 solution is "compatibility with the installed base", which is exactly the argument you just repeated.The point is,  if we wanted an incompatible solution, we could just use IPv6. If the IPv4 solution aims for compatibility, then it should consider that these Windows 98 boxes that you mention set the TTL to 128, which is precisely the argument for "no check on receipt."

-- Christian Huitema