Subject: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 Aug 2001 11:50:34 +0200 (CEST)

Here are some comments.

The text in section 1.2 which attempts to define link seems to exclude
all link layers that modify some part of the link-layer packet.
This clearly excludes MPLS and might exclude source routing token ring
as two examples.
Why not just refer to or copy the definitions of "link" and the terms
it depend on from RFC 2460?
And presumably the definitions belong in section 1.1 and not 1.2.

I don't understand what the text in section 2.1 about 
   This means that even without using any other
   persistent storage, a host will usually select the same link-local
   address each time it is booted [...]
relates to the fact the you refer to RFC 1750 which says "It recommends 
the use of truly random hardware techniques ..."

If you have truly random hardware techniques then you would *not* get the
same random number on each boot. So what is the relationship really with
RFC 1750?

Section 2.1 claims that 169.254/16 is assigned by the IANA for this
purpose. I didn't think it had a reference to the draft so I went to
look. Turns out it isn't explicitly listed in
http://www.iana.org/assignments/ipv4-address-space

We need to make sure we have the correct instructions for the IANA
which might include transferring the ownership of the address block
to refer to this spec.

The algorithm in section 2.3 seems to force an unneeded IP address
change if a single packet is lost.
A is trying to use address X, which is already in use by B.
A sends arp request. B sees it and responds with a gratuitus reponse.
This response is lost.
A sends the arp request again after 2 seconds. (It is supposed to do this 4 
times). B sees it. Now the rules say that it MUST cease to use the address.
This doesn't seem very robust.

Have both Apple and Microsoft implemented exactly this?

   If the destination address is the 255.255.255.255 broadcast address
   or a multicast address, then the host may use either its link-local
   source address or a routable address, as appropriate.
Huh? Sending to a global multicast address with a link-local source
is a good idea?
How about allowing either for broadcast or multicasts to 224.0.0.0/24
but mandating global source for other multicasts.

Section 2.5 a few paragraphs that seem to endorse the construction of
boxes that depend solely on the IP addresses being used for some notion
of weak security. As we all know bridges to wireless media breaks
any such assumptions. I don't think the IETF should be endorsing such
weak security in standards track documents.
How about making 2.5 state the protocol mechanisms and the
in the security considerations section state that 
1) the protocol prevents packets using link-local addresses from being injected
   outside the link through the use of a ttl 255 check, and 2) users of
link-local addresses should be aware of the existence of
   bridges e.g. to wireless media that make the use of ttl 255 a very
   weak security mechanism.

The way I view it section 3.2 talks about constraints when the APIs allow
applications to specify and retrive interface information, and
section 3.3 talks about issues when such APIs are not available.
But the section titles doesn't match this so I'm confused about the intent.

Section 3.2 recommends using a single link-local address across multiple
interfaces but it doesn't explain why this is better or simpler than
using different ones.
I think it can be worse in some cases. If a conflict appears on one interface
forcing the host to pick a new link-local on that interface it would be
nice if that didn't effect connections using link-local addresses on
all interfaces.

Section 3.3 seems to skip the issue about how to connect or send the first
UDP to a link-local address in the absense of API support to identify 
interfaces.
Using the source IP address to identify the interface works after the initial
exchange e.g. after a tcp connection has been established.
But making it work for UDP responders when the socket is bound to INADDR_ANY
seems hard.

   In addition, this kind of host should probe for, and defend, all of
   its link-local addresses on all of its active interfaces that are
   using link-local addresses.
I don't see why this is strictly needed.
The host needs to ensure that its IP are unique across the interfaces but
it should be able to handle having a local address X on interface #1 while
address X is also assigned to a remote node on interface #2.
The assumptions for this section (which I don't understand as I stated
above) seems to say that the interface can always be implicitly derived
from the local address for the socket, in which case this isn't
a problem.

And defending its addresses on all interfaces has the disadvantage of
increasing the risk of having to pick a new address.
 
The example in 3.3.1 doesn't seem to match what is said at the top
of section 3.3: "[...] enable use of the source address as an unambiguous 
interface identifier".
This means that in 3.3.1 P identifies the interface and the only Q on
that interface is assigned to B.
If A wants to talk to itself it can use a source of 127.0.0.1 (indentifying
the loopback interface) and the same as a destination, or a source of P and
dest P, etc.
Allowing a source of P and a destination Q for loopback traffic seems counter
to using the strong end system model.

But I still don't understand the description in section 3.3 is supposed to
handle what is common in the BSD API: a TCP socket is created and then 
connected to the destination address. In this case there is nothing which
can be used to infer the interface. Is that intended to be outside the
scope of section 3.3?

The second paragraph in section 3.4 seems to conflict with the current model
in section 3.1 - if you want to support multiple interfaces being bridged
togther in the same link then the interfaces better have distinct link local
addresses. Otherwise you don't know which interface packets will arrive on
which means that the communication bound to an interface per the strong ES
model will fail half the time (when the packets arrive on a different interface
than were connection is sending packets).

  Erik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Aug 2001 08:41:59 -0700 (PDT)

> weak security in standards track documents.

It is worth thinking about the nature of the protection that is
afforded. Today, the Internet enables hackers all over the world to gain
access to a much larger range of victims than would otherwise be possible. 

It is alleged that a St. Peterburg hacker has gained access to 33 million
credit cards. How could such a thing be possible without the Internet? It
would take a long time to gain that many credit card numbers foraging
through dumpsters. 

So one of the major problems that we have with security today is that the
range of potential attackers is greatly increased by the Internet --
making criminals orders of magnitude more productive. It also renders
conventional criminal investigation techniques ineffective. 

Q: "Where were you the night of Friday the 13th?"
A: "Sitting at my desk in front of the computer in St. Peterberg, Russia."

In contrast, if I leave the door to my house open, I can only be robbed by
people who happen to be in the vicinity at the time. To rob my house, the
criminal has to be in that physical location, and will leave evidence of
his/her presence (fingerprinters, DNA, etc.). It can be argued that moving
from the "Internet crime" paradigm to the "local criminal" paradigm
reduces the risk of theft by orders of magnitude -- bringing us back to
the "antique" model of criminality that existed prior to the Internet. 

So, from this perspective, the security afforded by linklocal addresses is
actually quite strong, provided that hosts and routers properly support
them (the subject of another discussion). If potential attackers can be
limited to those that are on my segment, you  have accomplished a
lot -- you can now only be attacked by people in the immediate
(network) vacinity. Conventional models of criminal activity apply; social
controls operate (neighborhood associations); family structures may be
invoked (if your machine is attacked by a child). Jeff Schiller pointed
this out during the original Zeroconf WG discussion. 

By this notion, bridges do not really "weaken" the protection -- the
mechanism is not a firewall, and this should be made clear. 
It's only value is restricting the source to someone within some
reasonable proximity of the destination. Even with 802.11 networks, home
phone & powerline networks, etc. we are talking about fairly small
proximity.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 11:54:15 +0200 (CEST)

> phone & powerline networks, etc. we are talking about fairly small

I think we are in agreement on the larger issues.
I just want the document to be clear in pointing out that
the restriction of communication to link-local addresses doesn't
solve all security issues. 

The current document could be read to recommend using link-local
addresses as the sole security solution for some boxes. I think
the proper thing to do is to point out the issues - what link-local
addresses protect against and what the residual threats are.
The standard place to have such discussion is in the security considerations
section.

   Erik