Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt

From: Daniel Senie <[email-masked]>
Date: Tue, 26 Nov 2002 13:55:32 -0500

At 01:02 PM 11/26/2002, you wrote:
>One more issue with this document (the IESG has already sent back a
>number of comments -- I hope the WG starts working on revising the
>document soon!)
>
>The document has the following text with regards to TTLs:
>
> > 2.7 Link-Local Packets Are Not Forwarded
> >
> >    Any host sending an IPv4 packet with a source and/or destination
> >    address in the 169.254/16 prefix MUST set the TTL in the IP header
> >    to 255. This includes multicast and broadcast packets with a source
> >    address in the 169.254/16 prefix.
> >
> >    This allows hosts to guard against misconfigured routers, which may
> >    allow packets to leak in from outside the local link. Since even the
> >    most dysfunctional router will decrement the TTL in the IP header, a
> >    host can know with reasonable certainty that any packet received with
> >    a TTL of 255 did come from another host on the local link. A host
> >    receiving a packet with a source and/or destination address in the
> >    169.254/16 prefix and a TTL less than 255, MAY choose to consider
> >    such packets as potentially having been generated by a malicious
> >    attacker outside the local link, and MAY choose to silently discard
> >    such packets. [See Appendix for details of current implementations.]
>
>I have received some private comments (with which I happen to agree)
>that the above paragraph essentially blesses non-interoperability, or
>makes it much more likely that non-interoperability will result from
>this spec. That is, there are currently deployed boxes that use LL
>addresses, but that don't set the TTL to 255.

Two comments:

1. I had to read this paragraph 3 times before I got your proper meaning. 
Mostly due to sentence structure and length.

2. I see no compatability problem in requiring SETTING the TTL to 255. 
There is a concern about the check, however. My personal take is it'd be 
better to SET the TTL to 1, and thereby solve the issue at the sending node.

>  Consequently, any check
>of the TTL in received packets will result in failed communication
>with some boxes. The IETF traditionally takes a dim view of having
>specs encourage behavior that is non-backwards compatable, unless
>there is compelling benefit.

>  In the case here, it seems like the 255
>check provides a small security benefit, with the emphasis on
>small.

Given the requirements on zeroconf being discussed, it may represent the 
ONLY security available to some devices. I know there are companies who are 
insisting link local be used with gateways and nat boxes, a practice I feel 
undermines the whole point of link local and will create massive problems.

>  It is not clear that the potential benefts outweigh the
>downsides.
>
>I can imagine several ways to address this issue:
>
>- allow the above MAY, but require that the default setting be to
>   disable the check, so that folks need to explicitely enable it, in
>   which case they are making the choice to be non-interoperable with
>   some devices.

I'd suggest the SET be to 255 regardless. This doesn't hurt ANYTHING. I'd 
like the receive side to be a SHOULD, but with a caveat that for some time 
this will cause compatability issues. The setting of the recommended 
behavior (setting of switches) should be discussed further. Configuration 
switches and zeroconf certainly could be seen as being at odds with one 
another.

>- get rid of the idea of the check at all, as it provides too little
>   security in practice to be useful.

Doesn't get my vote. Ultimately, it's a question on how certain you want to 
be that I can't reach into your house and randomly activate your light 
switches. Those are likely the kind of devices which will have limited 
stacks and need the level of protection this issue addresses.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Nov 2002 14:11:10 -0500

> Mostly due to sentence structure and length.

Sorry about that...

> 2. I see no compatability problem in requiring SETTING the TTL to 255.

Agree.
     
> better to SET the TTL to 1, and thereby solve the issue at the

note that setting the TTL to 1 doesn't "solve" the  issue
completely. If the concern is that LL packets stay on the  local link,
there are two different pieces:

- if the sender sets the TTL to 1, it can ensure that the packet stays
  locally.

- if the receiver wants to verify that a packet didn't originate off
  link, all it sees is the TTL when it reaches the recipient. It could
  have a TTL of 1 because it started with a TTL of 10, but went
  through 9 routers...  But if one verifies that that the TTL is 255,
  that's a pretty good sign the packet didn't travel through any
  routers. One can assume that  Bad Guys will set the TTL to something
  other than 1 if they are trying to cause problems...

Thomas

---

From: Daniel Senie <[email-masked]>
Date: Tue, 26 Nov 2002 14:30:07 -0500

>- if the sender sets the TTL to 1, it can ensure that the packet stays

Whis was my area of concern.

>   other than 1 if they are trying to cause problems...

Very true. Another reason to not have routers touch link local packets at 
all. Perhaps another short document updating RFC 1812 is in order.

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 15:24:37 -0500

> ONLY security available to some devices. 

in my mind, that argues for requiring TTL=1.  companies shipping
product that depend on LL as a security mechanism deserve to lose.

> switches. 

if you use IP, you need to be able to accept traffic from anywhere.
relying on LL to provide security is simply unacceptable, and IETF
should not endorse the practice.

Keith

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Tue, 26 Nov 2002 16:19:59 -0600

> product that depend on LL as a security mechanism deserve to lose.

  You want to design something that is intentionally easy to break and
  generate bogus packets for?  Just to force people to fix their
  routers?  Isn't that kind of like designing a connection protocol
  that prevents passwords just to force you to setup your firewall
  correctly?

> if you use IP, you need to be able to accept traffic from anywhere.

  This is simply not true.  How may 10.x.x.x hosts are there connected,
  in some way, to the Internet?  Several thousand?  million?  How many
  should I be able to reach?  Exactly one (or zero).

  Not everything is globally routed.  Link-local addresses are the
  essence of this idea.  Having a system in place that can verifies
  correct routing (TTL=255), even if it does not PREVENT incorrect
  routing, is of great value-- especially in an environment where 
  most of the address space is automatically setup and don't inherently
  depend on any or on a correct routing infrastructure.

  Having a system that cannot prevent incorrect routing since the
  sender can override the checked value (TTL=1+) NOR can it verify
  correct routing has no value at all.

> should not endorse the practice.

  This isn't a question of security beyond the basic idea of A) make
  sure the packets are correctly routed and B) prevent a script-kiddie
  from being able to make the system eat itself.

  Link-local addresses should be link-local.  That's the whole point.
  If you choose to use that condition as part of your bigger
  data-security plan, that is somewhat questionable, but that doesn't
  change the fact that "link-local is link-local" should be a routing
  invariant.  Since the whole point of link-local is that it is, well,
  local, that should ultimately be enforced by the hosts, not the
  router.  TTL=255 gives the hosts the power to check for valid
  routing.  TTL=1 gives you nothing that can't be faked.

  I would consider the TTL=255 check more of an operational "sanity
  check" then one having to do with true security.  It is really like
  the idea of "Don't respond to ICMP echo requests that don't have a
  desk address equal to your unicast address (e.g. not broadcasts)." 
  No, it doesn't keep the packets from getting there, and yes, the host
  still has to process and discard the packet, but it also keeps the
  network from killing itself when some outsider tries a simple attack
  like sending a ICMP echo request to a large subnet's broadcast
  address.

  Getting back to the 10.x.x.x example, one of the key ideas in routing
  is that if machine A (w/ the address 10.0.0.1) sends me a packet from
  10.0.0.1 to my address of 128.128.128.128, and I send a packet from
  128.128.128.128 to 10.0.0.1, it should go to the same machine the
  original packet came from.  This is a really basic and core
  fundamental assumption of IP routing.  TTL=255 allows hosts (the key
  "routing" systems in link-local addresses) to enforce this and
  recognize bogus packets.  No other test does.

   -j

-- 
                     Jay A. Kreibich | Integration & Software Eng.
                        [email-masked] | Campus IT & Edu. Svcs.
          <http://www.uiuc.edu/~jak> | University of Illinois at U/C

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 17:40:44 -0500

>   routers?  

Nope.  I want to design something that allows ad hoc networks to be
self-configuring (as described in the group's charter), but which 
makes absolutely no claims about providing security.  

Trying to make this into a security mechanism just won't fly.

>   should I be able to reach?  Exactly one (or zero).

You're asking the wrong question.  Try this: for how many of those 
hosts is the use of 1918 addresses a sufficiently effective security 
mechanism by itself to prevent attacks on those hosts?  answer: 
not many, because it's too easy to tunnel, and there are too many 
threats are from inside.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 26 Nov 2002 17:40:32 -0500

> all. Perhaps another short document updating RFC 1812 is in order.

This would be the most logical idea, and a more reliable solution. But then
again, wouldn't you have the same problems with backwards compatibility with
this solution as well. being too slavish to backwards compatibility results
in nothing getting done.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Daniel Senie <[email-masked]>
Date: Tue, 26 Nov 2002 17:46:54 -0500

>this solution as well. being too slavish to backwards compatibility results

There is always that tradeoff. RFC 2644 updates 1812. I'm sure it took a 
while before it was implemented. Was it worth doing, though? I think so.

I see no reason why such a document couldn't be generated to complement the 
LL draft. I'd be happy to whip this up and submit it, if the chairs would like.