Subject: RE: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1

From: "Christian Huitema" <[email-masked]>
Date: Thu, 27 Feb 2003 12:00:50 -0800

My preference would be that the document makes no recommendation of TTL
at all, or that if it makes any recommendation that recommendation could
be overridden by the application.

An example is LLMNR, which specifies a "check TTL=255 on receive" in
order to avoid some specific attacks. This check is implemented by the
application; the draft explains how to use existing API on various
systems to set and check the TTL value. 

Another example is the Universal Plug & Play discovery protocol, SSDP.
The implementation recommendation specifies that the TTL should be set
to 4 or 1 (depending on the version) before sending a multicast packet;
it does not specify a check on receive. The concern there was to avoid
leakage, and the resulting network overload in some configurations.

My proposed resolution is that the IPv4LL specification should not make
any recommendation whatsoever regarding the TTL, and that if we make one
it should be qualified by stating that this is a default value that can
be overridden by the application. I would suggest accepting LL29, but
rewriting it as:

	Any host sending an IPv4 packet with a source and/or destination
	address in the 169.254/16 prefix SHOULD set the TTL in the IP
header
	to 1, unless another value is specifically requested by the
application. This includes multicast and broadcast packets with a
source address in the 169.254/16 prefix."

-- Christian Huitema

---

From: Mika Liljeberg <[email-masked]>
Date: 27 Feb 2003 22:58:35 +0200

> source address in the 169.254/16 prefix."

I support this proposal. Setting TTL=1 on send, no check on receive is
the conservative and compatible approach to take. Checking TTL=255 on
receive is a bogus idea for two reasons:

1) It's damn nigh impossible to send a packet with a 169.254/16
destination address from an outside network. An attacker is much better
off choosing a routable destination address.

2) Every host should implement adequate security measures, regardless of
what destination address the attacker is trying to use.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Feb 2003 17:49:09 +0700

Date:        Thu, 27 Feb 2003 12:00:50 -0800
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | My proposed resolution is that the IPv4LL specification should not make
  | any recommendation whatsoever regarding the TTL,

That's LL21, which I also believe is the best way.

  | and that if we make one
  | it should be qualified by stating that this is a default value that can
  | be overridden by the application.

Agreed.    Which certainly rules out TTL checking by recipients (except
perhaps specific protocols that impose extra rules, which is where
such things should be done).

  | I would suggest accepting LL29, but rewriting it as:

I could live with that, though TTL=1 (except perhaps in multicast)
achieves nothing (the packets don't go to routers anyway, so nothing
is going to be considering forwarding them).   TTL's for multicast
are a whole other world, but for sure, using anything other than
TTL=1 for a multicast from a LL source addr would make no sense.
Broadcast doesn't matter, those packets don't get forwarded anyway,
regardless of TTL or source addr (or if the dest addr is 169.254.255.255).

How about "MAY set the TTL in the IP header to 1 unless..." for unicast
packets, and "MUST set the TTL in the IP header to 1" for multicast ?
That is, if we have to say anything at all about TTL's, which I would
still prefer not to do at all.

kre

---

From: John Schnizlein <[email-masked]>
Date: Fri, 28 Feb 2003 08:27:32 -0500

Specifying that hosts must not send LL traffic to routers, which 
appears to be the basis of the assumption that LL traffic does 
not go to routers, makes them responsible for something they
do not actually control. Since proxy-ARP gives the host a reply 
that appears to be that of the ultimate host, but is a router,
the originating host cannot enforce the requirement.

Relying on a mechanism that is known not to work in a well-know
case is not sufficient protection against LL traffic leaking out.

John

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Feb 2003 22:26:25 +0700

Date:        Fri, 28 Feb 2003 08:27:32 -0500
    From:        John Schnizlein <[email-masked]>
    Message-ID:  <[email-masked]>

  | Relying on a mechanism that is known not to work in a well-know
  | case is not sufficient protection against LL traffic leaking out.

But why does it matter?   That is, who cares?   Nothing in the text in
LL21 says that a host should not set TTL==1, and for a host that knows it
is doing link local, and so forwarding off link should never happen anyway,
that probably makes lots of sense.

An occasional packet bound for nowhere, in a somewhat bizarre scenario
(how many routers do you know that proxy-arp for 169.254.*.* ?) doesn't
seem to me like sufficient justification to add this as an extra requirement.

This is particularly as we are told there are scenarios now where hosts
have to send with TTL==255 for their packets to be received, so it is
quite likely that some implementations are going to want to at least allow
that - the gain from TTL=1 isn't enough to prohibit it IMO.

kre

---

From: John Schnizlein <[email-masked]>
Date: Fri, 28 Feb 2003 16:00:06 -0500

At 10:26 AM 2/28/2003, Robert Elz wrote:

>(how many routers do you know that proxy-arp for 169.254.*.* ?) 

My concern regards legacy routers that proxy for all addresses
outside the subnet for which the interface is configured.
This is a "historic" method of avoiding router discovery that
was widely used on stub networks when listening to the (RIP)
routing protocol was discouraged.

While I would prefer that hosts get reasonable parameters for
configuration of a default gateway, I consider it rude to cause
these old network configurations that used to be causing no
trouble to start spewing LL traffic out into the Internet.
Expecting the people who have this old configuration to change
it to "protect the Internet from trash" coming from their subnets
is not reasonable.

Does using TTL=1, which rather blatantly declares "no forwarding"
on link-local traffic have any down side, after adjusted as
Christian proposed for applications that "know better"?

John