Subject: Support: LL3 TTL=255 on send, check on receive?

From: Stuart Cheshire <[email-masked]>
Date: Mon, 3 Mar 2003 22:22:14 -0800

In April 2001 Dave Thaler argued that there was some small but non-zero 
benefit in TTL=255.

I was convinced by his arguments then, and I remain convinced.

Summary:

TTL=255: incentive for ISPs (etc.) to do the right thing
         easily detect offenders
         guard against attack from off-link attackers

TTL=1:   no incentive for ISPs/router vendors to do the right thing
         no way to easily detect offenders
         no protection against attack from off-link attackers

>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: Robert Elz <[email-masked]>
Date: Tue, 04 Mar 2003 14:36:40 +0700

Date:        Mon, 3 Mar 2003 22:22:14 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | In April 2001 Dave Thaler argued that there was some small but non-zero 
  | benefit in TTL=255.
  | 
  | I was convinced by his arguments then, and I remain convinced.
  | 
  | Summary:
  | 
  | TTL=255: incentive for ISPs (etc.) to do the right thing

That argument works for multicast (from whence it originated) but
is pretty meaningless here.

  |          easily detect offenders

I fail to see any difference this makes (before the detection point,
the TTL will have been decreased by some arbitrary amount, so the value
of the TTL can't be used - there's no difference at all whether a node
sent with TTL 255 or 254 or 253 or ...)    Simply seeing packets
with a LL address in them outside their "home" is enough to note that
something is broken, finding the source of the bad packets (when it is
the source addr that is LL, which is far and away the most likely case
for packets to escape) is not going to be easy in any case (may require
the efforts of the itrace people).

  |          guard against attack from off-link attackers

This is meaningless without knowing what is to be guarded, or how the
TTL helps.  What it actually does is allow the node to know that a
source is not on the same link - but only if it checks the TTL.   None
of the proposals (none of LL3, LL21 LL29 or the current words in the draft)
suggest that nodes should check the TTL - the strongest is the current
draft wording which says that nodes MAY check (LL3 even waters down that
one...)

If there is some application protocol that can gain from a TTL check
(the way ND and stuff use the similar thing in IPv6) then that protocol
can specify the TTL that must be used for that application protocol when
using LL addresses.

But that only works if this doc doesn't specify something which might
cause a conflict.

Some protocol might want to specify that a TTL of 255 must be used,
whereas another protocol (perhaps one using multicast) might want to
specify that a TTL of 1 be used.

With the specs as you'd have them, how is SLP using LL addresses to
be done?   As I recall it, SLP likes hosts to use TTL=1 for their
first search (especially looking for a DA).   On a LL link it really
should make no difference - but we'd have colliding specs, and no
way to comply with more than one of them.

Just leave out the TTL part of this spec, it adds nothing,
except complexity.

kre