Subject: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive?

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

This issue will be discussed for the next week ending on March 6, 2003.
Please post your comments to the zeroconf list so we can arrive at a
consensus action.

This issue is available at http://www.spybeam.org/ll21.html and is
reproduced here for the record:

Description of Issue  Alternate text for: TTL=255 on send, check on
receive?    
Submitter Name  Robert Elz    
Submitter Email Address [email-masked]    
Date first submitted  8 Feb 2003    
Reference
http://www.spybeam.org/ll3.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: 
See LL3 
Lengthy description of problem:
See LL3 

Requested Change: 
Delete the first two paragraphs of section 2.7.

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 Feb 2003 21:35:37 +0700

Accept LL21 (well, obviously...)

More reasons given in a message I sent (only to) Erik (which I am
hoping he will forward to the list, I didn't keep a copy...) related
to LL3 (for which LL21 is an alternative resolution).

kre

---

From: John Schnizlein <[email-masked]>
Date: Thu, 27 Feb 2003 10:00:43 -0500

This well-intended proposal should be rejected as insufficient 
because the paragraph following them is inadequate. (copied below)

The new requirement that all routers, wherever LL hosts appear,
must not perform traditional proxy-ARP for the special case of
source or destination addresses with 169.254/16 prefixes is not
reasonable. Expecting all routers to be changed in order to
protect against undesirable leakage of LL traffic is not practical.

There is still a reasonable way that hosts using LL addresses can
minimize the risk of leakage: TTL=1.

John

>Delete the first two paragraphs of section 2.7.

These two paragraphs - and the next one - are as follows:
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.]

   An IPv4 packet whose source and/or destination address is in the
   169.254/16 prefix MUST NOT be sent to any router for forwarding, and
   any network device receiving such a packet MUST NOT forward it,
   regardless of the TTL in the IP header. Similarly, a router or other
   host MUST NOT indiscriminately answer all ARP requests for addresses
   in the 169.254/16 prefix. A router may of course answer ARP requests
   for the one (or more) own link-local address(es) that it has
   legitimately claimed for its own use according to the claim-and-
   defend protocol described in this document.

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 27 Feb 2003 10:51:33 -0500

> minimize the risk of leakage: TTL=1.

That only prevents leakage out. It does not prevent bad packets from other
links leaking *in*.

john

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

---

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

At 10:51 AM 2/27/2003, John C. Welch wrote:
>That only prevents leakage out. 
>It does not prevent bad packets from other links leaking *in*.

This is a true statement, but not relevant to the goal of avoiding
causing harm to the rest of the Internet due to the creation of
special link-local behavior.

What bad packets are you concerned about? If the standard specifies
that link-local traffic does not get out, then it should not be out
there to leak in.

John

---

From: Erik Guttman <[email-masked]>
Date: Thu, 27 Feb 2003 17:31:56 +0100 (CET)

> That only prevents leakage out. It does not prevent bad packets from other

[WG chair hat off]
To refresh everyone's memory - there were two main reasons why it was
seen to be a good idea to set TTL=255 to send and check 255 on receive.

 1. A host could filter improperly sent packets from off-link (mistaken
    or malevolent).

 2. Setting TTL to 255 would be consistent with the behavior of some
    shipped systems, eventually *all* such systems (someday).

The counter arguments to this were:

 1'. This does not provide meaningful security against off-link attacks.

     Sending with TTL=1 would ensure that conforming hosts would not
     improperly send packets off link.

     Setting TTL>1 will encourage leakage, from improperly configured
     routers.

 2'. There are many shipped systems which send with other TTL settings
     and it is not clear when these will go away.  Filtering for only
     receivers with TTL=255 will do harm.

The counter arguments for this were:

 1''. setting TTL=1 will not encourage folks to reconfigure routers
      to refuse to forward datagrams in the LL prefix.

Erik

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 27 Feb 2003 11:39:47 -0500

> special link-local behavior.

Well, since you (in theory), can't route LL packets anyway, because your
router should be rejecting LL - addresses, I don't see the *Internet* being
harmed. It's rather resilient, as Bob Metcalfe found out a few years ago.

> that link-local traffic does not get out, then it should not be out

If LL traffic can't get out, then the TTL doesn't matter anyway. But TTL = 1
is a bit too passive for me. TTL = 255 is not terribly better, but it
handles packets coming in correctly better, in that TTL decrementing is not
something that breaks too often, but it is very possible to accidentally
tell your router to pass LL traffic. If that happens, the TTL could very
easily be 1, even though it came from a totally different link. It's going
to be a little harder to get a router to not decrement.*

john

*I am not going to go down the road of deliberate attempts at spoofage.
That's a different can of worms, and will bypass any TTL setting we set up
anyway.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 27 Feb 2003 12:00:26 -0500

Wasn't there a moratorium declared some time ago on discussion 
of vague security claims for TTL settings?

Declaring routers that comply with all existing router requirements
"improperly configured" because they do not perform special operations
for a new specification is not compatible with the do-no-harm goal.
The special handling of a particular prefix might require more than
a simple configuration change, and how could we justify forcing
everyone to reconfigure their routers to protect the Internet from
link-local traffic, when we have an easy alternative using TTL as
intended, to limit the spread of packets beyond their useful scope.

John

---

From: Erik Guttman <[email-masked]>
Date: Thu, 27 Feb 2003 18:03:28 +0100 (CET)

> of vague security claims for TTL settings?

Please do not consider any topic off limits, as long as it directly
pertains to the issue being discussed.

Regards,

Erik
ZEROCONF WG chair