Subject: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive?

From: Erik Guttman <[email-masked]>
Date: Thu, 27 Feb 2003 13:54:58 +0100 (CET)

The following issue will be under discussion till March 6, 2003.  At
that time a consensus call will be made.  Please post your comments on
the zeroconf mailing list.

Please see http://www.spybeam.org/ll3.html

The issue is reproduced here for the record:

Description of Issue TTL=255 on send, check on receive? 
Submitter Name Erik Guttman 
Submitter Email Address [email-masked]
Date first submitted 6 Feb 2003 
Reference
http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html
http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html
Comment Type ['T'echnical | 'E'ditorial] T 
Priority ['S' Must fix | '1' Should fix | '2' May fix ] S 
Section 2.7
Rationale/Explanation of issue:
There are various problems with the current text relating to setting
TTL=255 and checking it. Lengthy description of problem: 

The current text says:

"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."

And:

"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."

WG chair attempt at an unbiased overview of the points raised so far:

    * Setting the TTL to 255 may cause packets to leave the LAN as
routers do not know to filter them.

      (REBUTTAL: If a host knows enough to set to 255 it also knows
enough not to forward such a message to a router in the first place.)

      (REBUTTAL TO REBUTTAL: A message to a multicast address will be
forwarded. Some routers also perform proxy ARP, so these messages can
escape from the local LAN).
    * Some existing implementations do not set to 255. Filtering will
decrease interoperability. We must 'do no harm.'
    * The security benefits to be had here are dubious. The document is
misleading in that it creates unreasonably high expectations of security
benefits from this feature.
    * Setting the TTL to 1 will prevent routers which have not been
specifically configured to specially treat v4LL source addressed
messages from forwarding LL messages.

      REBUTTAL: This decreases the incentive to reconfigure routers to
comply with these recommendations.

REBUTTAL TO REBUTTAL: We cannot expect all routers in the world to be
reconfigured overnight.

Thomas Narten wrote:

The way I understand the issues:

Enforcing the 255-on-receipt check is non-backwards compatable. Indeed,
it occurred to me today that its non-backwards compatable with nodes
that don't even implement LL addressing. Consider a node A, on the same
link with B. A has a global address, B has a LL address. If A attempts
to communicate with B, but B notices that the dest address is LL, and
then checks for a TTL of 255 (following the recommendation in the
current ID), communication will likely fail. So here we have a case
where two nodes with valid addresses can't communicate for non-obvious
reasons. Neither implementation is violating a Standard. Note the A has
not implemented LL at all, so it can't be violating any LL standard. 

Is this not a potential interoperability problem that we shouldn't
knowingly encourage?

However, now that Apple does this check, setting the TTL to anything
other than 255 is also problematic.

That might argue for setting it to 255 (and explaining in the document
why), but also saying SHOULD NOT or MUST NOT do the check on receipt
since we know it also causes problems with existing implementations
that don't set the TTL this way. (Note we could say that the test
might be changed in a future standard once the deployed base is
upgraded/junked, but it is too early to say that today if one wants to
avoid interoperability problems today).

But setting the TTL to 255 (rather than 1) also will lead to more LL
packets going off link then if the TTL is set to 1. Sure, hosts aren't
*supposed* to forward them to routers, but some leakage will
inevitably happen as a result of misconfigurations, and other things
that are "not supposed to happen". This may cause operational
problems. How much? Hard to say. Depends on how many (and which)
routers do filtering. I don't believe we need 100% compliance here in
order to get enough filtering in practice to keep LL traffic from
leaking in horrible ways. For a home site, for example, does it care
if its LL traffic goes off link? Probably not. What it cares about is
that it doesn't go across the DSL link to its ISP (or that packets
from the ISP come in with LL addresses). But that is something the ISP
probably cares about enough to ensure that filters are fairly likely
to get put at that boundary. Etc.

Stuart Cheshire wrote:

There are four practical alternatives for the Working Group to choose
between:

1. Always check TTL=255
2. Always check TTL=1
3. Don't check TTL at all
4. Have an optional (user configured) check for TTL=255

The three metrics to examine are:

(Mac) Always compatible with existing Macs
(Win) Always compatible with existing Windows boxes
(Orig) Always able to determine if packet originated on the local link

The scores:
(Mac) (Win) (Orig)
1. Always check TTL=255 + - +
2. Always check TTL=1 - - -
3. Don't check TTL at all + + -
4. User configured TTL=255 + - -

Option 1 works with Macs. Option 1 tells you the origin of the packet. 
Option 1 works with Windows, but only after you've changed the registry
key as described in Appendix A.3. (This registry change doesn't have to
be done manually by the user -- we're recommending to printer vendors
that their printer driver software should automatically make the
registry change so that Windows will automatically work properly with
their Zeroconf printers.) 

Option 2 works with nothing today. It tells you nothing about the origin
of the packet. It may limit forwarding of the packet, but this is a moot
point because compliant hosts don't send LL packets to routers for
forwarding anyway.

Option 3 works with today's Macs and Windows boxes, but doesn't tell you
the origin on the packet.

Option 4 lets the user configure whether they want their printer to
guard gainst off-link packets, or whether they want their printer to be
compatible with the old version of Windows they are using. If the user
configures it to check, it might not work with old Windows boxes,
generating expensive support calls, so it fails the "Always works with
Windows" test. If the user configures it to not check, then it might
accept off-link packets, so it fails the "Always able to determine if
packet originated on the local link" test. I have only one further
comment to make on this topic: Which part of "Zero" and "Configuration" 
did you not understand? If we have to configure something to make it all
work properly, lets configure the Registry key on last-year's Windows
boxes to make them work better, not force the customer who buys next
year's Zeroconf devices to understand and change some configuration
setting to make them work worse. 

Of the four, options 1 and 3 get two points each.

Option 1 has the benefit that receivers know the origin of the packet.

Option 3 has the benefit that it saves Microsoft the hassle of having to
change its software.

My vote goes for option 1, because it gives the bigger long-term
benefit.

Some people have suggested a policy where we require senders to set the
TTL to 255, but not check the TTL on reception, and then in future,
after Windows has been updated, we update the specification to require
the check too. This simply doesn't work. The fact is that there is no
incentive for vendors to set the TTL correctly if no one is checking. 
The longer time goes on, the more non-conformant devices there will be,
and it will become impossible to enforce the check later. We have to
decide now. 

Bernard Aboba wrote:

The way to think about this is what the default behavior should be.

The single most important thing about TCP/IP is that it is interoperable
-- that is, that you can take two hosts with dissimilar operating
systems and do an FTP between them. 

Put together, Zeroconf now has the potential to break the basic
interoperability of TCP/IP -- by taking two hosts that formerly could do
an FTP using global addresses and now making them unable to communicate.
The breakage occurs two ways -- by introducing non-interoperable IPV4
linklocal, and by introducing non-interoperable name resolution.

I would argue that if Zeroconf does nothing else, it MUST "do no harm". 
That is, two hosts with global addresses MUST be guaranteed to be able
to continue to communicate interoperably after Zeroconf is introduced. 

To accomplish this, we need several things:

a. Zeroconf protocols MUST be a last resort -- that is, linklocal
addresses MUST NOT be used if the two peers have global addresses
available.

b. A host MUST NOT by default silently discard packets with TTL < 255.
Ran Atkinson wrote:

Probability of a packet both leaking and arriving with a TTL exactly
equal 1 is quite low. Leaking and having a TTL between 1 and 254 is MUCH
MUCH higher probability -- and is protected against. 

> Are you saying that the sending problem is more important than the
> receiving one?

Among other things, I do think the sending problem is more significant
-- but also note that I think that TTL of 1 actually helps the
overwhelming
majority of receivers also.

Please see the archive from mid October 2002 to the end of December 2002
for more on this thread.

Requested Change: 
Replace "A host receiving..." with

"At a future time, when legacy pre-standard implementations are in the
minority a follow on standard may be issued which will state that hosts
SHOULD discard packets with a source and/or destination address in the
169.254/16 prefix and a TTL less than 255. This will lessen the
possibility that a host with a v4LL configured address will receive a
datagram from a host off the local link, to which it cannot respond."

---

From: John Schnizlein <[email-masked]>
Date: Thu, 27 Feb 2003 09:44:11 -0500

The subject line seems to include a typo, since I recall no discussion of TTL=244, but much discussion of 255 and 1.

The proposal (at the very end) advocates TTL=255 on send, check on receive. 

This should be rejected in favor of TTL=1 on send, which implies that all traffic that is supposed to be local to the origin link is not forwarded by a reasonable router. The argument that the originating host can prevent a packet with a larger TTL from reaching a router is flawed; proxy-ARP is a clear counter-example. Do no harm is more important than compatibility with pre-standard implementations.

At 07:54 AM 2/27/2003, Erik Guttman wrote:
>...
>...

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 27 Feb 2003 09:44:54 -0500

> 4. Have an optional (user configured) check for TTL=255

<SNIP for brevity>

What Stuart said works for me.

john

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Feb 2003 12:34:00 -0600

One somewhat sad note WRT this discussion is that the two legacy 
installed bases we have to contend with are Microsoft Windows, from 
Windows 98 through the present, and Apple.   If I have a Windows 98 
machine that can't communicate with an Apple because of this problem, I 
can't get an upgrade from Microsoft to fix the problem - Microsoft, 
AFAIK, does not support Win98 anymore, so I have to buy an upgrade to 
WinXP, at great cost, and great loss of performance.   But chances are 
that I can get an upgrade from Apple, for a reasonable price.   So I 
would rather have the solution that requires me to get an upgrade from 
Apple than the one that requires me to get an upgrade from Microsoft.   
This would seem extremely unfair to Apple, except that it is Apple that 
made the change requiring a TTL of 255.

Requiring that the TTL be set to one seems like it's good enough - it 
prevents accidental leakage.   Off-network attacks on IPv4ll-addressed 
nodes seem unlikely anyway - how does the remote device know which IP 
address to attack, since the IP address is not visible off-link?

So while I agree that there is a minor technical advantage to Apple's 
change, I don't think it's worth the cost, and I don't agree with 
Stuart's cost/benefit analysis.