Subject: Re: TTL=255 on xmit, no check on receipt please

From: Erik Nordmark <[email-masked]>
Date: Fri, 6 Dec 2002 08:48:38 +0100 (CET)

>   BUT, the fact that IPv6 uses this TTL check to solve what is more or
>   less an identical problem** provides very strong precedence for the
>   validity of the check.  The IPv6 working group felt that it was the
>   correct solution to the problem.  While IPv6 networks aren't exactly
>   common, there are numerous implementations and many many research
>   networks in both education and industry that have put the protocol
>   under a microscope from top to bottom.

>    **-- The problem I see in IPv4 LL addresses and the problem that 
>    is being solved with IPv6 Neighbor Discovery is the question of
>    protocol robustness in the face of a non-compliant node (e.g. one
>    that is broken or hostile).  IPv6 ND absolutely depends on the idea
>    that packets are from/to local link neighbors-- you don't have to
>    trust your neighbors, but you have to be sure the nodes you are
>    talking to really are your neighbors. 

AFAIK the problem is far from identical.
In v4LL the problem applies to packets which have at least one LL address
(either the source, dest, or both are LL).

In RFC 2461 the problem includes packets (such as Neighbor Solicitation
and Neighbor Advertisement) where neither the source or the destination
might be link-local. In fact, in common use the addresses are the (global)
addresses that the upper layers use to communicate.

When there is at least one LL address in the packets the routers
can filter the packet. But in the RFC 2461 this is not the case (unless
the routers take the performance hit of filtering on the ICMP type
instead of just the addresses). Hence RFC 2461 uses ttl=255 for a different
reason that v4LL.

  Erik

---

From: John Schnizlein <[email-masked]>
Date: Fri, 06 Dec 2002 07:17:57 -0500

Could we have a simple summary of the reasons that the intuitive
solution of TTL=1 to keep link-local (LL) traffic from being forwarded
off the link is bad, please?

One of the persuasive arguments on this thread is to maintain as
much compatibility with existing deployments as possible during the
deployment of LL addressing. Another is keeping LL traffic local.

The analysis should consider the common (but not pretty) configuration
of a router's local interface for proxy-ARP, in which it responds to
ARP requests for any IP address with its own MAC address. How does the
LL-only host guarantee that it does not send LL traffic to the proxy-ARP
router?

John

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Fri, 6 Dec 2002 10:27:23 -0600

> AFAIK the problem is far from identical.

  The *problem* is identical: ARP, IPv4 LL traffic, IPv6 LL traffic,
  IPv6 ND, and other protocols all suffer from the same "weakness," which
  is a problem to be solved: if protocol traffic is allowed to "leak"
  across link boundaries (i.e. across a layer-3 gateway) the protocol
  degrades and becomes unusable in the face of a non-compliant node
  (e.g. a hostile node).  There are a number of different solutions to
  this problem-- the TTL=255 check is just one of them.

  The *environment* this problem has to be solved in for each protocol
  is quite different, but in the case of IPv6 ND and IPv4 LL, I would
  argue the environment and motivations for a specific solution aren't
  even all that different.

  ARP solves this problem with simple network layer isolation, running
  directly at layer-2, which makes it impossible to cross a layer-3 gateway.

  IPv6 LL traffic solves the problem by making all layer-3 devices 
  filter traffic based on LL IP addresses.  This can be done because
  this condition was in the standard from day one so *all* IPv6
  gateways should correctly filter this traffic.  This solution has the
  added benefit of isolating any "out of spec" traffic to the local
  link network it was sourced from.

  As it has been pointed out several times on this list, IPv6 ND can't
  filter on LL IP addresses since the protocol is often used between
  globally routable addresses on the same link.  Thus, IPv6 ND uses
  a different solution and checks TTL=255 so hosts can verify packets
  originated on the local-link.  Nodes can discard questionable packets 
  before processing those packets and handing them up to high layers in
  the stack.  This prevents the protocol logic from being attacked by
  "out of spec" packets, but it does not prevent those bad packets from
  being delivered to the end host and consuming resources (bandwidth) on
  all the transient networks.

  Which brings us back to IPv4.  Obviously IP is a layer-3 protocol, so
  the solution ARP uses is out.  That leaves us with address filtering
  and TTL checks.  If we had a blank slate to work with, clearly
  address filtering at the gateways is the way to go, just as IPv6 LL
  traffic does.  It is simple, straight forward, and has the added
  bonus of isolating traffic (and resource usage) to the local network.

  But putting the words in the standard does not instantly change the
  hundreds of thousands of deployed IPv4 routers-- and with both Apple
  and Microsoft showing some level of interest in this standard, it is 
  reasonable to assume that it will be deployed on a sizable fraction 
  of the world's networks in a moderately short period of time.

  There is no reason we can't ask for address filters on the gateways,
  we just can't *depend* on them in a "real world" environment.  The
  *reasons* we can't depend on the gateways are different for IPv6 ND and
  IPv4 LL are different, but the end result is the same: we cannot
  depend on the gateways to do this for us-- the hosts must be able to
  determine the origin of the traffic themselves.

  That means IPv4LL needs a back-up plan to solve this problem, which 
  brings us back to the TTL check of setting and checking specific TTL
  values.  As has been discussed previously on the list, no matter what 
  the TTL is set to, the only TTL value worth checking is 255-- just as
  IPv6 ND does.

> Hence RFC 2461 uses ttl=255 for a different reason that v4LL.

  In my previous message I didn't mean to there was only one solution
  to the link-local traffic isolation problem, nor to say the
  motivations for a specific solution to the problem are the same in
  these protocols, only that the problem was the same: the need to
  isolate link-local traffic.

  But I would go further and say that the "reason" IPv6 ND (RFC 2461)
  uses TTL is because it can't depend on the routers to do the filtering
  (due to the lack of known addresses to filter) and the "reason" I
  think IPv4LL should use the TTL check is because we can't depend on
  the routers to do the filtering (due to standards deployment problems).

  So in my opinion even the reasons and motivations for the TTL=255
  solution to this common problem aren't all that different, even if
  the environmental conditions and limitations that bring those reasons
  about is different.

   -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: Brad Hards <[email-masked]>
Date: Sat, 7 Dec 2002 16:04:11 +1100

> off the link is bad, please?

There are two problems - keeping LL traffic from being forwarded, and telling 
if the datagram you have came from the local link.

TTL=1 mostly solves the first problem.

TTL=1 solves the second problem, only if _every_ machine implements it.

Setting 255, and checking 255 solves the second problem. You might discard 
packets from the local link.

Setting 255 also ensures compatibility with one implementation (MacOS 10.2) 
that is shipping.

The concept of local link is inherently ambiguous, because people have all 
kinds of weird bridge-filtering. LLv4 only works reliably if the ARP packets 
and every packet with a 169.254/16 address reach the same machines.

Don't forget that setting 128 or 255 clearly doesn't cause problems in 
reality, because there are a _lot_ of deployed examples.

Brad

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 02:31:55 -0500

> if the datagram you have came from the local link.

please explain again why the app needs to know if the datagram came from the
local link?  how does this relate to the group's charter?

---

From: Brad Hards <[email-masked]>
Date: Sat, 7 Dec 2002 18:31:09 +1100

On Sat, 7 Dec 2002 18:31, Keith Moore wrote:
> > There are two problems - keeping LL traffic from being forwarded, and
> > telling if the datagram you have came from the local link.
>
> please explain again why the app needs to know if the datagram came from
> the local link?  how does this relate to the group's charter?
I never mentioned "app", so you can relax - I'm not intruding on your turf :-)

This is not to say that some applications may not need to know if the IP is 
link-local, but I was working on the network layer dropping packets, based on 
some local policy decision.

As for charter, I won't buy into any more pointless arguments. 

Brad

BTW: I'm ready to implement whatever the RFC (if it ever gets released) says 
for Linux - the technical stuff for TTL is trivial for setting, and I'm happy 
to add checking for TTL. 
- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 03:04:03 -0500

> I never mentioned "app", so you can relax - I'm not intruding on your turf :-)

I'm not concerned about turf.  Let me phrase the question differently -
why is it important that the destination host enforce the restriction
that the packet came from the local link?

> for Linux 

Linux might be better off without it.

Keith

---

From: Brad Hards <[email-masked]>
Date: Sat, 7 Dec 2002 19:41:22 +1100

On Sat, 7 Dec 2002 19:04, Keith Moore wrote:
> > > please explain again why the app needs to know if the datagram came
> > > from the local link?  how does this relate to the group's charter?
> >
The normal excuse has been "operational sanity". I'm not sure I understand 
what this means.
We are talking about the case where routers are doing things that a router 
shouldn't, and I'd prefer to not have to deal with packets from a host that I 
may not be able to reach. That is worth avoiding.

> > BTW: I'm ready to implement whatever the RFC (if it ever gets released)
> > says for Linux
>
I'll do the "set 255" part, if nothing else (unless the RFC says something 
else). Interoperability with OS 10.2 is important, as Aidan pointed out in 
the Original Post on this thread.

Brad
- --

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 07 Dec 2002 09:52:16 -0500

> the Original Post on this thread.

Folks...Keith's unveiled insults to anyone working for a company that makes
money aside...there is a real time limit on how long this debate can last
before the standard becomes irrelevant.

There are apps about to be released that use current implementations of
Zeroconf. 

Why would they not wait for the standard? Well, if they read this list, they
may have come to the conclusion that they'll be lucky to get the LL part of
Zeroconf standardized in this *decade*. But people need to get work done
*now*. Not whenever insults and debates stop flying. But *now*. *Today*.

Standards are *only* valuable when they are used. If they are not used, or
unusable due to excessive domain-defending, and empire-guarding, then they
become a "who cares" sort of thing. That's a shame, and in the long term,
not very logical. But the world simply cannot delay implementations and work
for some random time waiting for a bunch of poindexters to argue previously
settled trivia. MIT is dropping AppleTalk zones, and we need something to
replace them. Zeroconf, and DNS-SD are ideal, and I only hope that MS and
Sun have implementations in place so we can move to that type of
functionality across the board. But we *cannot* sit with our thumbs up our
keisters for n years waiting for standards group to get done yelling at each
other.

If the idea that the world is not going to wait for this group is somehow
insulting, or is perceived as evil corporate entities sullying the purity of
the Internet, then I suggest those attitudes be re-examined. BBN was always
a profit-making enterprise, as was IBM. We need this standard, but we need
it in time to be relevant. If the IEEE took this much time for Ethernet,
we'd still all be using 1MB dreaming of a 10MB standard.

john

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 09:54:56 -0500

> may not be able to reach. That is worth avoiding.

I think it is worth avoiding, if you can make a case that the TTL check is 
a good indication of whether the reply will reach the host that sent the
packet.

> the Original Post on this thread.

actually I think the WG's job (or any WG's job) is to define what works well 
rather than trying to insist on compatibility with what is already deployed.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 10:05:42 -0500

[second reply]

> The normal excuse has been "operational sanity". I'm not sure I understand

okay, I might actually have figured out what it means.

if you see a packet from another link, then it will not have seen ARPs
from the local link, and it might therefore be coming from a source 
address that is used by a host on the local link.  so the response to the
packet might end up at a different host than the one that sent the first 
packet.

so the assumption is that the scope of a broadcast packet (hence an ARP) 
is the same as the scope of a packet with constant TTL.   it's probably
valid most of the time, though it seems risky to make assumptions about 
the relationship of scopes in L2 and L3.

Keith

---

From: Brad Hards <[email-masked]>
Date: Sun, 8 Dec 2002 10:51:34 +1100

On Sun, 8 Dec 2002 02:05, Keith Moore wrote:
> > The normal excuse has been "operational sanity". I'm not sure I
> > understand what this means.
>
Or it might not be reachable (hence you get a lot of re-transmissions).

This is what I assumed it meant, but wasn't sure, because the term is so 
ambiguous.

> the relationship of scopes in L2 and L3.
There is no assurance, but it is fairly reliable in practice. We do have some 
deployed experience to verify that.

You can build a system that breaks the L2/L3 relationship (bridge-walling), 
but unless we build an application layer IP allocation system, then there 
aren't any alternatives.

Brad
- --

---

From: Aidan Williams <[email-masked]>
Date: Mon, 09 Dec 2002 16:59:19 +1100

> off the link is bad, please?

Not bad, just not particularly useful.

LL traffic generated by LL-aware hosts will be delivered by ARPing
locally on the link.  Hosts that don't do this fail to communicate
at all using LL protocols.  These host don't produce leakage.

Non-LL-aware hosts responding to LL traffic will forward via a
default route.  They will *not* use TTL=1.  This will be the
majority of leakage traffic.

> deployment of LL addressing. Another is keeping LL traffic local.

I buy the compatibility argument.  Keeping LL traffic local with
a TTL=1 doesn't seem to gain us much.

> LL-only host guarantee that it does not send LL traffic to the proxy-ARP

*Any* IP address?  Would that router behaviour break the address
assignment process used by IPv4-LL anyway?  Or is it only answering
ARPs for addresses not deemed on the local net?

- aidan