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

From: Aidan Williams <[email-masked]>
Date: Tue, 03 Dec 2002 12:11:25 +1100

Hi there,

I wrote a message yesterday that was a bit tortuous so I
thought I would summarise/try-again after having a sleep.

First, TTL and security.  I thought we had come to the consensus
that checking the TTL had no particular security value.  I agree
with this point of view.  Any security value that checking the
TTL=255 in my home network comes from the environment.  If I
do the same check whilst connected to the IETF network I don't
get much assurance of anything..

Second, how does leakage occur?  Leakage occurs when a node sends
a packet to a 169.254/16 address to a router, which forwards the
packet off the link.  The vast majority of deployed IPv4 routers
will follow their default route as they don't treat 169.254/16 as
special.

There are two possible leakers:
   LL-aware nodes, and non-LL aware nodes.

LL-aware nodes that forward 169.254/16 packets to their local
router are broken.  So broken that their LL communication will
plainly not work.  Therefore the implementation flaw where they
send LL-destined packets to a router is pretty unlikely.

Non-LL-aware nodes on the other hand are quite likely to send
169.254/16 destined traffic to their default router.
They don't have a route table entry to tell them not to.
If they receive packets with 169.254/16 source addresses
they will respond by sending packets to their default router
(examples are TCP connections, broadcast packets, etc).
When they send these packets they will use TTL=64
(or whatever the OS default is).

A statement in the IPv4 LL document requiring TTL=1 won't
be honoured by Non-LL-aware nodes, which are the main
leakage vector.  Hence a TTL=1 statement will have little
effect on leakage.

Thirdly, there are non-interoperable implmentations today.
We should try hard not to break those implementations.
Requiring TTL=255 on send avoids breaking the MacOS
implementation.  Allowing the TTL check to be ignored
helps with Windows.  This change won't make life worse
for existing implementations and it won't make existing
implementations interoperate any better than they do today.

Given that the actual TTL value has very little effect on
the actual likelihood of leakage, setting the TTL=255 on
send and dropping the receipt check is a good compromise.

regards
	aidan
____
:wq!

---

From: Daniel Senie <[email-masked]>
Date: Mon, 02 Dec 2002 21:30:11 -0500

At 08:11 PM 12/2/2002, Aidan Williams wrote:
>that checking the TTL had no particular security value.

No. The comment made was that we wouldn't discuss security, and whether the 
TTL value has security merit. There was no consensus that I saw to actually 
conclude whether there were any security advantages.

>I agree

The question is whether there is merit in ensuring, now and in the future, 
that link local traffic stay on the local link.

>will follow their default route as they don't treat 169.254/16 as

In the examples you and I discussed separately, I pointed out that the 
traffic would never get anywhere. A packet from another node on a local 
link MAY wind up going out through default gateway IF the node responding 
does not recognize LL. The default router may leak this response packet. 
However, the packet will at some point hit a router in the 
default-free-zone, and the expectation is no backbone or ISP will advertise 
169.254/16 in the DFZ.

Packets coming from outside a network into the LL network, with spoofed 
source addresses would have to originate nearby, be source routed, or 
otherwise find ways to bypass the routing table contents. Again, there seem 
to be other means to deflect such attacks.

169.254/16 is NOT globally routed, and so reaching in to a LL network is 
less easy than you let on in your analysis.

>implementations interoperate any better than they do today.

In examining the Windows XP machine I'm typing on, I find no evidence of 
the LAN interface retaining its LL address. It would appear Microsoft uses 
the same behavior as it has for some time, releasing the LL address at the 
point at which DHCP succeeds. As such, the only issue I see with 
interoperability is with putting Mac and Win machines on the same network 
with no DHCP server present. It could be argued Apple was a bit premature 
with its switch to require TTL=255 (vs. just setting it), and should have 
waited until this I-D was published as an RFC. This is not the first time 
an I-D has been used as justification for a change in behaviour, with 
questionable results (a case with an I-D altering DVMRP requirements on the 
MBONE many years ago has some similarity).

That said, I believe the TTL=255 on transmit is the right way to go, and a 
timeline of 1 or 2 years following the publication of the I-D as an RFC 
would be prudent as a grace period to impose a MUST on checking the TTL=255.

>send and dropping the receipt check is a good compromise.

While you're worried about leakage, there's another consideration to the 
TTL=255 issue. The claim and defend mechanism for LL addresses requires 
nodes to be within a single ARP domain. A router (not aware of LL, but 
configured for 169.254/something) could wreak havoc if connected between 
two LL segments. The TTL=255 is there, to my way of thinking, to help 
ensure routers CANNOT be present within a LL network.

Providing a grace period after publication would permit router vendors and 
host vendors time to release updated software which understands LL, 
providing a productive path forward.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 02 Dec 2002 22:35:37 -0500

> that link local traffic stay on the local link.

This point could use a bit more clarification.

Is the goal just that well-behaved nodes that implement LL not
generate traffic that leaves the link? Or is it to prevent as much as
possible that LL traffic (regardless of the souce) doesn't leave the
link, even when implementations screw up somewhat, or LL addresses are
used by implementations that don't actually implement LL addressing?

Seems like using a TTL of 1 as much as possible will help keep traffic
local, since such traffic, regardless of how it is sent, just won't go
far. In contrast, setting the TTL to 255, would be about the worst
choice, if the most important criteria is to keep LL traffic on link.

Given your statement above, I'm confused about the later conclusion
that the TTL should be set to 255. Am I the only one who thinks
setting the TTL to 255 on send will make it harder to keep LL traffic
on the local link?

> less easy than you let on in your analysis.

What you seem to be aruging is that there will in general be enough
routers that filter LL traffic. Thus leaking LL traffic won't be a
problem in general, even if not every router actually does the
filtering. It's not important that *every* router filter LL traffic,
just the key ones.

This seems a useful line of analysis. At what routers does LL
filtering need to happen in order to minimize problems? Are there
sufficient economic incentives to ensure that filtering will be
enabled on those routers?

I guess one place there will be problems if packets from one link
reach another, and there are address collisions on the two links. Then
the traffic doens't just go nowhere, it gets sent to nodes that might
get confused.

> That said, I believe the TTL=255 on transmit is the right way to go,
> and a timeline of 1 or 2 years following the publication of the I-D
> as an RFC would be prudent as a grace period to impose a MUST on
> checking the TTL=255.

How does a node implementing LL interoperate with a node not
implementing LL addressing at all (i.e, that only uses a global
address)? The node not implementing LL won't set the TTL to 255. Those
nodes will never set the TTL to 255, as they don't plan on ever
implementing LL addressing. Will the TTL==255 check on receipt ever be
a reasonable thing to do then?

> providing a productive path forward.

Will all nodes/routers be required to implement LL addressing in the
future? I had assumed it would be an optional standard, one only those
nodes planning on assigning LL addresses to their interfaces would
need to implement.

Thomas

---

From: Daniel Senie <[email-masked]>
Date: Mon, 02 Dec 2002 23:32:35 -0500

>setting the TTL to 255 on send will make it harder to keep LL traffic

Setting TTL=255 permits stations that know to do so, the ability to know if 
packets have traversed routers. Knowing this, it is possible to squelch 
traffic originating beyond a router (even if that router knows about 
169.254/16 addresses).

Clearly in the short term setting TTL=255 leads to a greater possibility of 
a router being willing to transmit traffic beyond the local link, but this 
is mitigated by the fact that implementations which do set TTL=255 will 
also be new implementations, which we would hope do not screw up and send 
packets via default route that have a source IP address in 169.254/16. In 
other words, if the node is compliant and aware of LL rules, it should 
NEVER send a TTL=255 packet to a router.

>filtering. It's not important that *every* router filter LL traffic,

I'm arguing there would be significant effort involved in generating an 
attack against a LinkLocal network in a house/enterprise/etc. across the 
public network using normal routing, since we expect 169.254/16, which has 
been identified as special use for some years, to NOT be in the 
default-free-zone. Unless the attacker has access to the routing gear that 
connects the site via some means, it will be hard to get such packets 
forwarded to that LAN segment.

>enabled on those routers?

The question for you is whether you want to consider the lack of a route in 
the DFZ routing table a "filter?" I would argue it'd be useful and helpful 
if routers were required to route 169.254/16 to a null device, and drop 
packets with a 169.254/16 source address.

>the traffic doens't just go nowhere, it gets sent to nodes that might

This I allude to below. It breaks the claim-and-defend model of selecting 
addresses to permit routing between such segments.

>address)?

The question I'd ask is, why does it need to? I work with the assumption 
that there will be NO communication between LL and global address spaces. 
If you have an application which requires talking to devices that only 
operate on LL, then the application needs to be on a node that has both a 
LL address and a global address. In other words, you need an application 
level entity (which could be an application level gateway).

>  The node not implementing LL won't set the TTL to 255. Those

My argument above effectively gives my answer on this.

>future?

Only those which wish to talk to other nodes using LL addressing.

>  I had assumed it would be an optional standard, one only those

I have been working on the assumption that only those nodes which want to 
talk to other nodes using LL would need to implement it. Devices which are 
designed to permanently operate only on LL addressing would only be 
accessible from nodes which themselves have an LL address. Any attempt to 
communicate further would be blocked by the TTL rule in the present draft. 
The question is whether this is a good thing? At this point, I think it is.

See section 1.5 in the Zeroconf requirements I-D. I think this backs up 
what I'm saying here. The implication is that link local addressing is, 
well, local to the link. This implies no passage through routers. checking 
TTL=255 ensures packets have not passed through a router (where router is 
defined in RFC 1812, certainly any piece of equipment can be altered to do 
non-standard things). It may be helpful to think of Link Local addresses as 
being handled in similar fashion to Limited Broadcast (255.255.255.255, see 
RFC 1812 section 5.3.5.1) in terms of how a router can and should respond 
to such addresses.

As I stated in another message, it may be worthwhile to follow the I-D 
under discussion (assuming it reaches RFC status) with a second 
standards-track document which specifically updates RFC 1812 in terms of 
how to deal with Link Local addressing.

---

From: Aidan Williams <[email-masked]>
Date: Tue, 03 Dec 2002 16:18:28 +1100

Daniel Senie wrote:
> link MAY wind up going out through default gateway IF the node 
> responding does not recognize LL. The default router may leak this 
> response packet. However, the packet will at some point hit a router in 
> the default-free-zone, and the expectation is no backbone or ISP will 
> advertise 169.254/16 in the DFZ.
> 

I agree -- when I have talked about packets following the default
route I mean up to the DFZ where they (hopefully) get dropped.

I disagree that this is "never get anywhere".
I think of this as leakage, and the packets get somewhere.
In the networks I use, "somewhere" is at least 6 hops away.

> otherwise find ways to bypass the routing table contents. Again, there 
> seem to be other means to deflect such attacks.
> 
> 169.254/16 is NOT globally routed, and so reaching in to a LL network
 > is less easy than you let on in your analysis.
> 

My analysis is concerned with how packets leak *out*.

Perhaps a more useful example is an LL-only host attempting
to communicate with a local non-LL-aware host (this is explicitly
allowed in the draft).  The packets received by the non-LL-aware
host will have a LL source address and a global destination.
When the non-LL-aware host replies, where do the packets go?
Answer: out the default route and up to the DFZ.

Packets with spoofed LL source addresses don't need to originate
nearby and don't need stuff like source routes to get them through
since they are routed purely on the destination address.  OTOH,
Getting packets with LL destinations delivered through the internet
is as you rightly point out, hard.

> the LAN interface retaining its LL address. It would appear Microsoft 
> uses the same behavior as it has for some time, releasing the LL address 
> at the point at which DHCP succeeds. As such, the only issue I see with 
> interoperability is with putting Mac and Win machines on the same 
> network with no DHCP server present.

Fair point.  Still, it would be nice if the standard let them
work in that circumstance.

> ensure routers CANNOT be present within a LL network.

Hmmm.  Thinking about this, I don't think ARP has a TTL.
Were you thinking that the TTL check should be applied to
IP packets forwarded or to ARP proxies (somehow)?

- aidan

---

From: Aidan Williams <[email-masked]>
Date: Tue, 03 Dec 2002 17:12:49 +1100

> choice, if the most important criteria is to keep LL traffic on link.

We should be looking at minimising (or at least understanding
and documenting) all sources of leakage we can think of.

> Am I the only one who thinks

The right answer would *seem* to be obvious.. ;-)
However...

I think the main cause of leakage will be from nodes that
don't understand 169.254/16.  They'll use whatever TTL they
normally use (which won't be 1 and won't be 255).  These
packets will head up the default route and get dropped at
the same place the TTL=255 packets will be dropped at.
(TTL=255 packets will last longer in routing loops, but I
  don't think this is something we should be concerned about.)

If we are *not* worried about interoperability (I thought this
was how we got into this discussion in the first place) then
a choice of TTL=1 for LL-aware implementations would make people
feel better but (IMO) wouldn't make much difference to the
actual amount of leakage.

> enabled on those routers?

My best guess is: probably.  In Australia the main cost is in
overseas transmission.  Various key routers can be configured
with an ACL that drops 169.254/16 traffic easily enough before
burning dollars going overseas.

> the traffic doens't just go nowhere, it gets sent to nodes that might

This is an interesting thing to think about.  Routers forwarding
link-local along some path won't consider themselves connected
to a 169.254/16 subnet, so they won't ARP for LL IP addresses
(they'll be ARPing for router next hops) and hence the LL traffic
will pass over those links as a ship in the night.

If someone chose to forward 169.254/16 to a particular link,
then yes, all hell breaks loose on that link from an address
conflict point of view as the router ARPs for random 169.254
addresses as it tries to deliver packets.

> a reasonable thing to do then?

Exactly.  No, I don't think the TTL=255 makes sense in this case.
But that isn't all.

Harping on a theme: for the whole thing to work, the non-LL-aware
host has to know to send the responses to the local link rather than
off to the default router.  Not going to happen.... hence leakage.

> nodes planning on assigning LL addresses to their interfaces would

Optional.

- aidan

---

From: "Bill Rees" <[email-masked]>
Date: Mon, 2 Dec 2002 22:25:09 -0800

----- Original Message -----
From: "Aidan Williams" <[email-masked]>
To: "Thomas Narten" <[email-masked]>
Cc: "Daniel Senie" <[email-masked]>; "zeroconf" <[email-masked]>
Sent: Monday, December 02, 2002 10:12 PM
Subject: Re: TTL=255 on xmit, no check on receipt please

> and documenting) all sources of leakage we can think of.

So the idea is to isolate LL nets from the rest of the world?  How does
traffic move between LL and non LL nets then?

---

From: Aidan Williams <[email-masked]>
Date: Tue, 03 Dec 2002 17:36:22 +1100

Daniel Senie wrote:
> This I allude to below. It breaks the claim-and-defend model of 
> selecting addresses to permit routing between such segments.
> 

Doesn't claim and defend get broken purely because the router
ARPs repeatedly for 169.254 addresses?  (Section 2.5, IPv4-LL)

There isn't a TTL to check in the ARP packet which would allow
a host to ignore "ARPs resulting from non-local packets".

One could perhaps try to identify the router and ignore ARPs
from it, but that seems really flaky.

- aidan

---

From: Daniel Senie <[email-masked]>
Date: Tue, 03 Dec 2002 09:01:34 -0500

>ARPs repeatedly for 169.254 addresses?  (Section 2.5, IPv4-LL)

To defend, a station ARPs its own address to see if someone else responds. 
Unless proxy-arping, a router has no business answering for addresses that 
are not its own.

>a host to ignore "ARPs resulting from non-local packets".

I think you're missing the point.

>from it, but that seems really flaky.

The router's ARPs will be (assuming it's configured to know about 
169.254/16) for other stations. Stations claiming and defending an address 
will ARP for the address they already are using themselves. These two are 
different in terms of actions taken.

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 3 Dec 2002 14:54:07 -0000

> From: "Thomas Narten" <[email-masked]>
> ...

In crude terms yes.

However, the use of Set/check TTL=255 will ensure that LL addressing only
works between LL aware hosts (note. a host can use a routable address and
still be LL aware). As such it is restrictive since it means that these will
be completely unable to communicate with non LL aware hosts (including some
legacy LL implementations) but this very fact is likely to lead to less
leakage since communication with a Non-LL aware host (which might send
packets to a router) will die almost immediately.

Use of Set/No-check TTL=255 brings the dubious benefit of greatest potential
for interoperability between compliant and non-compliant or partially
compliant hosts but at the expense of greatest potential for hard to track
issues with leakage and odd address conflicts.

The third alternative of TTL=1 is more or less the same except that it
excludes interoperability with some Apple implementations.

note: The view that TTL=1 will restrict leakage is almost completely wrong,
The only leakage it will stop is from hosts which stick to the spec well
enough to set TTL to 1 but not well enough to avoid sending the packet to a
router.

Philip Nye

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Dec 2002 11:00:16 -0500

okay, I'm convinced that having LL-aware hosts set TTL=1 (rather than 255
or some other value) isn't of much use.

I'm also convinced that checking for TTL==whatever isn't of much use.
yes with the check your apps will ignore packets originating from off-link, 
and that will reduce replies and reduce the load on systems.  but it 
doesn't do anything to stop LL traffic from getting through routers.  
to do that, you actually have to configure those routers to not forward 
such traffic.  

I'm curious, has anyone actually tried to see what it would take to get 
a non-LL-aware host to communicate with an LL-only host?

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 3 Dec 2002 10:46:29 -0800

> traffic move between LL and non LL nets then?

The idea is to let devices on the same link communicate even when other 
infrastructure, such as a DHCP server and gateway is broken or 
non-existent. Devices using LL addresses may coexist on a network with 
devices using global addresses. The LL devices may communicate with the 
devices that have a global address if both devices are aware of LL. The 
trick is that the device with the global address has to know to arp for 
the LL addresses instead of sending the packets through the default 
gateway.

-josh

---

From: Daniel Senie <[email-masked]>
Date: Tue, 03 Dec 2002 15:03:14 -0500

At 01:46 PM 12/3/2002, Joshua Graessley wrote:

>the LL addresses instead of sending the packets through the default gateway.

Right. Succinctly, all stations that want to use LL have to know about LL. 
So there's NO requirement that LL stations be able to communicate with 
stations not participating in LL.

I think some of the wording in the draft could be tightened a bit, based on 
my reading last evening. Might cut down on confusion over this point.

Dan

---

From: Aidan Williams <[email-masked]>
Date: Wed, 04 Dec 2002 11:09:17 +1100

Daniel Senie wrote:
 > To defend, a station ARPs its own address to see if someone else
 > responds. Unless proxy-arping, a router has no business answering for
 > addresses that are not its own.
 >

The router is just asking, not answering.

Anyway, I was confused about the collision thing.

Reflecting a bit more I don't think claim/collide gets broken.
Any node using the address just answers the ARPs and the packets get
(uselessly) delivered to it.  Doing a TTL=255 check would allow the
node ignore this traffic.

Stepping back a bit, the TTL check allows ingres LL traffic to be
ignored.  Makes no difference to egress LL traffic.  If you buy my
contention that most egress LL traffic will come from non-LL-aware
hosts, specifying TTL=1 won't help either.

So in the end I think we are left with:
   - compatibilty of existing implementations
versus
   - being able to reject ingres LL traffic.

You made the point recently that most windows implementations disable
LL whenever DHCP is around.  This would tend to limit the potential
interoperability problems quite nicely.. ;-)  However, the two
implementations will fail for the "two strangers on a train" case
today.  Do we care?

Personally, I can't see much chance of ingress LL traffic arriving on
a link (ie traffic coming in destined to 169.254/16).  So the TTL=255
check seems a bit like a solution in search of a problem.

I could live with either.

regards
	aidan
____
:wq!

---

From: Daniel Senie <[email-masked]>
Date: Tue, 03 Dec 2002 22:40:43 -0500

>The router is just asking, not answering.

Exactly.

>Anyway, I was confused about the collision thing.

OK.

>Reflecting a bit more I don't think claim/collide gets broken.

And to make this work, nodes ARP for their own address to ensure they keep 
it, and answer any arps for their address from others. Since a node trying 
to find an address to use will ARP for the proposed address, and select it 
if there is no response from another station, it is able to know it's OK to 
use that address. For this to work, the two stations need to be within the 
same ARP domain, i.e. same segment.

>node ignore this traffic.

A misconfigured router which is handling a sub-piece of the 169.254/16 
space (for example if someone set up a router to handle 169.254.20/24) 
could create real problems but would also decrement the TTL. In this way, 
the TTL helps limit such damage. I would hope nobody would ever try to 
configure such a thing, but...

>ignored.

You agree this is a good thing?

>   Makes no difference to egress LL traffic.  If you buy my

On egress, a LL-aware node should never be sending an LL-sourced packet to 
a router. A non-LL-aware device might try to send a packet with a 
169.254/16 destination, if it got something from a LL-aware node that it 
tried to answer. Arguably, altering the I-D to specify LL-aware nodes which 
have a routable address and want to talk to another LL-node MUST use their 
LL address would simplify things and probably eliminate a lot of confusion. 
The only case where an LL-aware node can successfully talk to another node 
on the local link such that the sender uses LL address and the destination 
address is routeable would be a case where the recipient node is also 
LL-aware. If they're both LL-aware, why not restrict them to using the LL 
addresses on both sides? I suspect the reason to allow this at all would 
have something to do with results from name resolution, but would like to 
hear if that is correct, or if there is some other reason.

>implementations will fail for the "two strangers on a train" case

I suggested we put a grace period into the document (based on publication 
date of the document) to resolve this. It's something Microsoft could 
adjust in a service pack without serious interoperability problems with 
their existing nodes. First service pack would be to set TTL=255, but not 
do the receive check, some time later, a service pack would add the TTL=255 
check.

>check seems a bit like a solution in search of a problem.

I guess I'm most concerned at this point with the placement of a router 
within a LL network and having that router answer ARPs for a subset of the 
addresses. Or a router configured for Proxy-arp. Either way, the TTL=255 
check seems a prudent measure to ensure such configurations will NOT 
function, thereby avoiding unfortunate circumstances.

>I could live with either.

At this point I'd really like to see the TTL=255 language remain, though as 
I said adding an implementation timeline to ensure transition would seem a 
good idea as well. The "strangers meet on a train" issue already exists 
between Mac OS X 10.2 (current release) and Windows machines, if I 
understand what the folks from Apple have said. If the resultant RFC says 
what the draft presently says, it would be in Microsoft's interest to at 
least add the TTL=255 on transmit as soon as practical.

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Dec 2002 16:11:41 +1100

Date:        Tue, 03 Dec 2002 22:40:43 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | I guess I'm most concerned at this point with the placement of a router 
  | within a LL network and having that router answer ARPs for a subset of the 
  | addresses. Or a router configured for Proxy-arp.

Forget the TTL issue - if a router is configured to proxy arp
(and don't most come that way by default?) then it will answer
all ARP requests for the LL addresses - which would mean that
no LL addresses could ever get assigned, wouldn't it?

That is, the router sees an ARP for an address that it doesn't
believe is on the local interface, it has a route (default route
almost certainly) to where the packet should go, so it answers the
ARP - packets for that address come to me.

If the ARP was from some node attempting to assign an address, it will
just go on and try another - with the same result.

Most low end routers in particular are likely to act like that, as
it avoids (works around) all kinds of configuration problems on end
hosts (who cares what the netmask gets set to, ...)

If you can convince yourselves that this isn't going to be any kind of
real problem, then I doubt that anything that is done with TTLs matters.

Certainly using the IPv6 "TTL must be 255" (where that applies) as a
justification for anything is meaningless here.

The (as reported here anyway) mboned WG justification would still apply,
if you wanted to go that way (that is, to try and "encourage" upgrades).
But here I doubt that anything breaks which should work if no upgrade is
done, and no real harm is done if there's no upgrade, so I doubt that it
would work.

TTL==1 achieves nothing.

Just remove all text about TTL setting (and particularly checking),
it achieves nothing, but creates lots of noise.

kre

---

From: Erik Guttman <[email-masked]>
Date: Wed, 4 Dec 2002 11:56:16 +0100 (CET)

Dan,

On Tue, 3 Dec 2002, Daniel Senie wrote:
> Arguably, altering the I-D to specify LL-aware nodes which 

Its not simplicity and confusion we want to address, but the failure
mode in which a v4LL-unaware host forwards a datagram with a v4LL
destination to a router.

> LL-aware. 

I think this is right, but please see below for an analysis.

> If they're both LL-aware, why not restrict them to using the LL 

I do not follow this last sentence.

---

If a host which is not v4LL-aware receives a datagram from a LL address,
it will respond by forwarding to a router, right?  

I am not aware of any host implementations which will use ARP to attempt
to forward a packet which is not in the same subnet as the host.  Are
there any which do this by default?  (Is it even a good idea?)

If I'm right, v4LL to v4LL-unaware also fails the strangers on a
train test for this reason.

There are additional problems if non-v4LL aware hosts do ARP for v4LL
addresses: 
 - For a multi-homed host, which interface should they perform ARP on to
   resolve a v4LL address?  
 - Application protocols will fail when (if) addresses change, which
   will be unexpected.   

In short, much of the complexity of v4LL would be exposed to a v4LL
unaware host if they attempted to communicate from a source global to a
destination v4LL address. 

I think there is great merit in your suggestion that v4LL configured
hosts should only communicate with v4LL destinations.  In this case,
no host would forward a datagram with a v4LL destination to a router.

This change does not limit interoperability with existing
implementations, either. 

Erik

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Wed, 4 Dec 2002 11:46:02 -0600

> justification for anything is meaningless here.

  Using it for *justification* (as in "they are doing it so we
  should too") is somewhat meaningless.  That isn't good design or good
  engineering.

  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.

  What does that mean to Zeroconf?  Not a lot.  I think it means that
  the TTL=255 check is just one possible solution to one particular type
  of problem.  It is one more tool in our bag of tricks, design
  principals, and basic constructs used in protocol design.  
  
  The fact that IPv6 Neighbor Discovery uses this same solution doesn't
  really change any of this, except in how much one might trust or
  respect the idea.  The only reason I originally posted to this list 
  the fact that IPv6 also uses the TTL=255 check currently in the
  Zeroconf draft standard is to point out that this is *not* a "new and
  radical" idea.  that just came out of thin air.  It is not some 
  never-before-seen gimmick dreamed up just for this working group.  It 
  is an established and accepted design component in the networking 
  protocol design field.

  Does that mean Zeroconf should use it?  Not necessarily-- a strong
  history by itself is, as you have pointed out, not justification in
  and of itself.   So while doing something just to do it isn't good
  design, using "off the shelf" systems and components (perhaps with
  minor modifications) to solve extremely similar problems *is* good
  design.   I think there is a problem in this component of the 
  Zeroconf standard that needs to be solved, and I happen to think the
  TTL=255 check is the correct solution.  Others may disagree, but I
  haven't seen any better solutions proposed.

   **-- 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. 
   
   IPv4 LL addressing also makes the assertion that this is true
   (link-local really is link-local), although the actual dependence
   on this is up to the higher layer protocols.  That said, I think
   the IPv4 LL spec should make every effort to insure that any packet
   delivered up the stack to higher-level protocols is really from a
   link-local neighbor.  We, as the lower-layer protocol, cannot make
   any assumptions about how this data is used or how the conditions
   of the protocol are being used (wise or not).  We have stated the this
   protocol is used to deliver to link-local traffic and ONLY link-local
   traffic, so we should design a protocol that does exactly that, even
   in the face of nodes and routers that are attempting to use LL 
   addresses outside the LL spec (which we can assume to be common,
   given the retro-fit nature of this spec).

   I feel setting the TTL to 1 is of very limited value.  The spec says
   hosts should not send LL traffic to a router for forwarding.  Any
   host sending a packet to a router for forwarding is already in
   violation of the standard, so having the standard require a specific
   TTL seems redundant.  I admit that "don't send to routers" isn't
   always the easiest thing to get right, and we should assume that
   hosts (even those trying to follow the standard) will sometimes get
   it wrong.  But, as others have pointed out, where exactly this packet
   will be routed is very questionable.  It isn't likely to be accepted
   by any ISP, so the only network you are likely to effect is the local
   site network.  Even this can be prevented with proper ACLs or other
   filters.

   Setting the TTL to any value other then one is pointless (in solving
   the problem at hand) unless the value is checked when the packet is
   received, before it is handed up the stack.  Checking for any value
   other then 255 is pointless because it can be faked fairly
   trivially by just sending all possible values.

   So the question is, should we have a TTL=255 check at all, or should
   we just ignore the TTL issue all together.  I would be happy to
   ignore the TTL issue all together if someone was able to come up
   with a system that would enforce the "link-local is link-local"
   condition put forth by the protocol and higher-layer
   protocols/applications can assume to always be true (for whatever
   reason or wisdom).  I haven't seen any other way to make sure this
   condition stays true, so I'm strongly in favor of the TTL=255 check.

    -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: Keith Moore <[email-masked]>
Date: Wed, 04 Dec 2002 14:09:17 -0500

>    on this is up to the higher layer protocols.  

Nowhere in the charter of this WG is any approval to develop a service
that is defined to only work on the local link.

regardless of whether a TTL check is imposed, I strongly object to :

- the idea that LL guarantees that the packet came from the local link
  (since tunneling is always a potential threat), and 

- the idea that a higher layer protocol can reasonably treat a packet that 
  comes from a local link differently than a packet that comes from elsewhere.

Keith

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 4 Dec 2002 21:23:19 -0000

> From: "Daniel Senie" <[email-masked]>
> ...

The justification given in the I-D is that there are hosts around which have
great difficulty supporting two concurrent addresses on the same interface -
some stacks would need major revision. I think this is valid and I don't
think it hurts so long as hosts with routable addresses don't turn off their
LL logic.

There has been quite a bit of confusion in this discussion between hosts
which have a routable address but are nevertheless LL aware, and those which
are simply not LL aware. The latter just can't communicate with LL devices.

There is a grey area in between occupied by hosts which have some manual
configuration or earlier LL implementation (mainly Windows and Mac), which
might or might not interoperate depending on TTL values. For example, when
Windows finds a DHCP server and switches off it's LL address, does it also
turn off all LL aware processing?

The issue of whether to set and or check TTL=255 or not comes down to issues
of partial interoperability in this greay area.

Personally, I am in favour of setting and checking as I think this will be
more robust and cause rejection of dodgy traffic at an earlier point.

> The "strangers meet on a train" issue already exists

Agreed.

Philip nye

---

From: Aidan Williams <[email-masked]>
Date: Thu, 05 Dec 2002 15:01:16 +1100

> no host would forward a datagram with a v4LL destination to a router.

This is probably prudent.  Now that we allow hosts to run zeroconf
protocols at the same time as non-zeroconf protocols (ie we dropped
the "transition" idea) I think it is reasonable to insist that hosts
wanting to speak to an IPv4-LL address have one themselves.

Re "no host would forward":

Never say never?  I think there is still the possibility that LL
broadcast or multicast packets with IPv4LL unicast source addresses
could get picked up by non-ll-aware hosts which then respond
with a packet along a default route..

- aidan

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Thu, 5 Dec 2002 11:41:13 -0600

> wanting to speak to an IPv4-LL address have one themselves.

  Of course this just means that many routers will now have LL
  addresses on one or more interfaces since one of the key markets
  for Zeroconf (besides printers) is web config tools for lower-end
  routers (such as DSL gateways and cable "modems").  This is part of
  the reason I keep saying "a LL host should not send packets to a
  router *for forwarding*", since clearly a host should be able to send
  packets to a router using LL addressing (one one side or the other)
  if it is sending them to the address assigned to the router's
  interface on the local link (e.g. talking *to* the router, not *thru*
  the router). 

  You also have the problem that devices with embedded network stacks,
  like printers, now need two addresses (one to service GR addressed
  hosts and one to service LL addressed hosts).  While more then one IP
  per interface is available in many (but far from all) host IP stacks,
  this is much *much* less true of embedded devices and their less
  robust stacks.  Allowing multiple addresses per interface, and the
  internal routing logic for them, isn't exactly a trivial change.

> with a packet along a default route..

  That's a good point, and for multicast would even take that further
  to wonder if the packet would be forwarded into the global multicast
  space by a router that does not understand LL addresses.  Requiring
  that all LL multicast use link-local addresses only, but that could
  still cause a great deal of traffic to "leak".  Something like the
  TTL check would prevent it from being acted upon, but unlike packets
  addressed to the LL address space which is likely to hit a "default
  free zone" router soon enough and get dropped, the limiting bad
  multicast traffic would require very aware routers.

  Of course, the same could be said of 10.x.x.x source addresses, or
  any other private space.  The problem is not unique to the LL address
  pool.
  
  I think limiting LL communications to LL addresses on both sides does
  solve many tricky problems, such as the ones you point out.  It comes
  at a much higher cost to the device developer, however, and I'm not
  sure the price is worth it.

   -j

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Thu, 5 Dec 2002 12:20:09 -0600

> that is defined to only work on the local link.

  True.  However, the path Zeroconf WG has chosen to go down under that
  charter has brought us to using link-local addresses, and *that* does
  define the constraint of link local addresses only working on the
  local-link.

  If they didn't, they wouldn't be called "link-local addresses."

  Other schemes exist to solve the "zero configuration problem" (such
  as a model similar in concept to IPv6 "site-local" addresses), but
  that's not the path we've chosen to go down (personally, I think this
  is a good thing, as such systems are usually orders of magnitude more
  complex).

>   (since tunneling is always a potential threat), and 

  If the tunneling was done at layer-3, the tunnel end-point would be
  acting as a gateway, and the tunnel wouldn't be effected by
  link-local addresses (at least, not any differently then any other
  gateway).

  If the tunneling was done at layer-2, any devices "thru" the tunnel
  would still be "link-local" and using LL addresses would not be
  outside the protocol.  This "threat" is no different then someone
  running at cat5 cable down the hall, putting an live jack in your
  lobby, or a wireless AP next to the parking lot.  You're mixing the
  idea of physical security and control with the layered networking model.
  The "link-local" is only defined by "no layer 3 transport devices",
  not any kind of physical topology.  If someone puts in a layer-2
  tunnel on a network, that is no different then a switch, repeater,
  "hub", bridge, or multi-port transceiver passing traffic over Ethernet,
  FDDI, wireless, lasers, or tin-cans-and-string-- or a tunnel.

  Just as ARP has a "local link scope", if you setup a layer-2 tunnel
  you would expect (and actually require) ARP to work correctly across
  it, or the tunnel would be worthless.  This is not any kind of
  suprise-- this is the protocol working exactly as advertised.

  The only time the concept of "threat" enters into this is if you are
  making higher layer data-security or connectivity-security related
  decisions based off required physical constraints perceived from the
  lower networking layers.  In the general case, this is a really Bad Idea.
  Anyone that assumes link-local provides local control when they don't
  have control over *all* of the machines on that link doesn't understand
  how networking works.  That's almost as bad as thinking a switched
  network gives you better local-link sniffing "security."  But none of
  these issues are new.  It is just as true for existing network
  designs-- we find dorm kids running layer-3 tunnels over HTTP through
  our firewalls all the time as we control the network, but not the
  hosts.  It pays to know exactly what that gives (or does not give) you.

>   comes from a local link differently than a packet that comes from elsewhere.

  This is not for us to decide and is totally outside of the scope of
  this working group.  I happen to agree that this would be *highly*
  questionable for most application security models when dealing with
  connection ACLs or authentication systems, but that isn't for us to
  decide-- it is up to those designing the higher layer protocols or
  application level security model.  We might offer suggestions as a
  lower-layer protocol (although I question even this in the actual
  standards document), but we are in no position to dictate how the
  protocol is layered, except in the conditions and assumptions of our
  own protocol-- and one of those conditions that the protocol makes
  and should do its best to enforce is "link-local is really link-local."

  If you change the question from "treating a link local packet differently" 
  to "treating a layer-2 only delivered packet differently", I think we
  get closer to the idea at hand.  There are a handful of protocols that,
  in order to function correctly, are required to make the assumption
  that traffic is link-local (or to be more specific, the protocol
  logic could be totally screwed up by a node outside of the domain of
  the protocol if non-link-local traffic was accepted), yet do not 
  put inherent "trust" in link-local nodes.  Admittedly, all of the
  protocols that are coming to mind have to deal with routing and
  figuring out the difference between paths that will cross layer-2
  only or layer-2 and layer-3 devices, but such examples do exist.
  
  Regardless, I think we would be presuming too much to think we, as a
  working group, can think of every possible future use for a well
  integrated Zeroconf and/or LL network, and that we can see the future
  well enough to say there will *never* be an appropriate (according to
  best practices) use for link-local "only" communications.  
  
  But I still agree with you that the net-admin that thinks they don't
  need to wrapper LL addresses just as tightly (if not more so!) as any
  other address needs to have a little talking to.  This is the same
  kind of netadmin that has an open wireless AP in their office next to
  the parking lot.

   -j

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Dec 2002 13:32:51 -0500

>   this working group.  

wow...this working group has done many things that are *way* outside
its charter, and yet you are claiming that debunking a common false
assumption about LL that has been explicitly stated by many participants 
of this WG (so we can't pretend that the meme isn't out there) is out
of scope.

the mind boggles.

Keith

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Thu, 5 Dec 2002 12:43:47 -0600

On Thu, Dec 05, 2002 at 01:32:51PM -0500, Keith Moore scratched on the wall:
> its charter,

  And you seem to be one of the first people to point out relations to
  the charter and IETF policies and procedures.  What's your point?

> and yet you are claiming that debunking a common false

  No, I tried to say that changing the standard to match common
  misconceptions is not the correct solution.
  
  Elsewhere in this preivious message (in parts that you trimmed) I did
  say that we might want to include clarifiaction of this point since
  it *is* a common misconception, but that I wasn't sure such text or
  clarification actually belonged in the standards document itself.
  An appendix or a totally different "best pratices" document makes
  more sense to me, as this is not, in the purest sense, a technical
  issue.

    -j

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Dec 2002 13:54:35 -0500

there are a number of features in the current specification that 
are problematic and cannot be justified by the group's charter.
I am hoping that they will get fixed.

Keith