Subject: Oppose: LL29 Link-local sources should specify TTL=1

From: Stuart Cheshire <[email-masked]>
Date: Tue, 4 Mar 2003 19:17:51 -0800

I need to point out that the text of the LL29 proposal contains some 
language that really encourages foggy thinking.

>   This requirement enables the normal behavior of Internet routers
>   to preclude leaking traffic that is supposed to be confined to a
>   single link out into the Internet when the local link has an
>   attachment to the Internet that it did not discover.

This notion that packets "leak", like water out of a cracked pipe, may 
seem natural, but not if you actually think about it.

Packets do not "leak". Packets are transmitted from host to host, by 
deliberate protocol action.

If the local link has an attachment to the Internet that the local hosts 
have not discovered, then they cannot send packets to it.

Hosts can only send packets to an attachment to the Internet *after* they 
have discovered it, and having discovered it, compliant hosts will not 
send any packets for forwarding.

The only remaining case is indiscriminate proxy ARP, which may *trick* 
hosts into sending packets to the wrong place, but these devices cause 
such serious damage anyway that "leakage" is the least of the users 
problems when all LL networking has completely failed. Fortunately, these 
problems have not been widely reported over the last five years. To the 
extent that these problems may exist, that's very strong argument that we 
need to publish this RFC soon, stating that indiscriminate proxy ARP 
boxes should not answer 169.254/16 requests. To the extent that TTL=1 
would allow these vendors to assume that there's no problem continuing 
the current behaviour, IPv4LL scores a huge own-goal.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Mar 2003 23:17:00 -0800

Mika Liljeberg wrote:
>Proxy ARP does not require your authorization. Your point, I guess, is
>that you can fix your own router. Not everybody can.

No, that was not my point.

My point was just that to use the term "proxy ARP" in a meaningful way, 
one needs to know what the word "proxy" means. An entity that gives 
correct answers on my behalf may be called a "proxy". An entity that 
gives incorrect answers on my behalf (that disagree with the answers I'm 
trying to give at the same time) is not a "proxy", it is an "impostor".

When a device indiscriminately answers ARP requests for addresses of 
which it actually has no knowledge, calling that entity a "proxy" imbues 
it with an air of legitimacy to which it is not entitled.

Lets just try to use clear terminology:

When a device gives correct ARP responses for addresses it knows about, 
we can call that "proxy ARP".

When a device presumes to make up ARP responses for addresses it knows 
nothing about, we should use "indiscriminate ARP", or some similar term 
to indicate that the device is giving answers that it is not qualified to 
give.

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Mar 2003 23:21:13 -0800

Philip Nye wrote:
>So here is a scenario:
>
>  Link A             Link B
>+--------+Gateway-A+--------+Gateway-B+--> to the Internet
>
>
>Gateway-A is the default gateway (for global traffic) on link A
>Gateway-B ditto for Link B
>
>If these gateways are not LL aware they will simply forward LL packets
>which reach them on towards the Internet.
>
>This scenario must be quite common.
>
>Now suppose that Link A and Link B have LL hosts on them.
>
>The only additional requirement for a malicious host on Link A to send a
>packet to a LL destination on Link B is that either Gateway-A or Gateway-B
>has been configured with a route which directs the LL prefix onto Link B.
>
>While this might be regarded as a misconfiguration, it is not a huge one
>and would likely go unnoticed. For example one or other gateway might be a
>general purpose machine which a user has added a route to precicely so that
>they can participate in LL exchanges on Link B.
>
>Furthermore additional Gateways and networks can be interposed between Link
>A and Link B without changing the basic principle but making the attack
>more remote.
>
>Philip

Philip, you didn't say so explicitly, but I assume you're giving this as 
an example of a situation where the TTL=255 check would give devices on 
Link B an assurance that the packets originated locally, in spite of bad 
behaviour by the routers serving Link B.

Mika Liljeberg wrote:
>Granted. I could use that same scenario to argue for TTL=1. :)

No, you can't. You can't assume that a remote hacker will neatly conform 
with what you request, in order to make their attack not work.