Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

From: Stuart Cheshire <[email-masked]>
Date: Wed, 11 Dec 2002 12:12:19 -0800

At Erik Nordmark's request, I am sending this response to the list for 
review and possible discussion.

An updated draft has been sent to the Internet Drafts directory.
You can also view it at:
<http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-03.txt>

>Hi Stuart.
>
>There were some Last Call comments on this document, which you've been
>sent. I'm still waiting on an reply on those.
>
>Here are some more comments, courtesy of the IESG review.
>
>At this point, I consider the ball back in your court on next steps
>for this  document.

Thanks.

James Carlson suggested the following text. It has been added.

>2.6 Historical Note
>
>   A widely-known, but ineffective, duplicate address detection
>   technique called "gratuitous ARP" is found in many deployed systems
>   [Ste94].  This traditional gratuitous ARP implementation sends only
>   an ARP Announcement per section 1.2.2 of this document when an
>   interface is first configured.  The result is that the victim (the
>   existing address holder) logs an error, and the offender continues
>   operation, often without even detecting the problem.  The
>   administrator is expected to note the log message on the victim and
>   repair the damage after the fact.
>
>   Implementors of this draft should be aware that this flaw is, as of
>   this writing, very widely deployed, and should take steps as
>   described in sections 2.4 and 2.5 to mitigate the problem.
>
>[...]
>   [Ste94]      Stevens, W., "TCP/IP Illustrated, Volume 1: The
>                Protocols", Addison-Wesley, 1994.

Ralph Droms suggested the following change. It has been done.

>One minor editorial comment: the details of an "ARP probe" are given in 
>both the third paragraph of section 1.1 and the second paragraph of section 
>2.1.  I suggest the text that refers to ARP cache pollution be moved from 
>section 2.1 to section 1.1, and then that remaining text describing an ARP 
>probe in section 2.1 be replaced by a reference to section 1.1.
>
>- Ralph

My answers to the IESG comments are below. I will consider the ball back 
in your court until I hear further instructions.

>Randy: 
>
>Section 1.2.1 et seq refer to "the widely-used natural interpretation
>of" a particular kind of ARP packet not explictly described in the ARP
>specification (NB: I have not verified that this packet isn't
>described in the ARP spec, I'm taking the author's word on this point
>for the moment). Alarm bells here, there are enough independent ARP
>implementations that this is almost certainly a statement of the
>author's opinion rather than a testable fact. Does this play well
>with, eg, the ARP code in your PDA? The boot ROM in your cable modem?

1. Every Mac sold for the last five years has done address conflict 
detection as described here, so I think we have good confidence that it 
works (or if it doesn't work in 100% of cases, at least that it causes no 
harm).

2. These are not newly proposed ARP functions, they are the same old ARP 
functions: When you want to send an IP packet to IP address X on your 
link, you send an ARP request for IP address X. If you get an answer, you 
know which hardware address has IP address X. If you get no answer, you 
conclude that IP address X is not currently in use on that link. If there 
were devices that indiscriminately answered every ARP request, you 
couldn't reliably communicate with any other host on your link because 
the other device would keep answering.

3. Finally, the DHCP specification (RFC 2131) already requires this 
behaviour; it just doesn't specify it very well.

>Section 1.2.3 suggests that broadcasting ARP responses is a good
>thing. I have always viewed it as a necessary evil used primarily to
>kludge around implementation issues for programs like DHCP servers on
>operating systems that lack a mechanism by which the DHCP server can
>stuff the ARP cache prior to responding when allocating an address.
>Anything that encourages more broadcasts without a damned good reason
>makes me nervous. I could be wrong, of course, but paranoia about
>broadcast has served me well in the past (I was pretty sure that the
>default setting required by RFC 1812 5.3.5.2 was a bad idea long
>before Smurf attacks justified my paranoia).

Section 1.2.3 says that broadcast ARP replies are "not needed in most 
situations". Section 2.5 says, "This is not recommended for general use." 
I believe the motivation for when you might prefer to use broadcast ARP 
replies, and why, is well explained in this section:

   This is not recommended for general use, but "Dynamic Configuration
   of IPv4 Link-Local Addresses" [v4LL] makes use of this optional
   capability, since in that case, detection of address conflicts using
   ARP is not merely a backup precaution to detect failures of some
   other configuration mechanism; detection of address conflicts using
   ARP is the sole configuration mechanism.

>I see no mention of DHCP relays anywhere in the document. Not
>particularly relevant to the author's presumed main purpose (conflict
>detection for IPv4 link local addresses), but since the document
>mentions DHCP extensively it probably ought to mention that DHCP is
>sometimes used in ways for which this mechanism won't help much.

The DHCP specification already requires this behaviour; it just doesn't 
specify it very well. This mechanism works in the presence of DHCP 
relays, and that is precisely why the DHCP specification requires this 
behaviour.

I don't know of any examples where, "this mechanism won't help much."

>I have not figured out yet whether the timing parameters in section
>2.1 make this mechanism prone to synchronized broadcast storms. The
>use of fixed length intervals after the initial random wait will keep
>probes in step if they start out in step, the question is whether the
>initial random wait is enough to avoid syncronized probes. To be
>fair, if assume that the initial random wait is not sufficient, we may
>be saying that we don't trust the random number generator being used
>by the machines performing the probes, in which case the usual
>solution (add some random jitter each time) may not help. So maybe
>this is just a requirement that implementations had damned well better
>be able to do the initial random wait properly (which may beg the
>question of seed material on deeply embedded devices).

The concept of synchronized broadcast storms applies to an ongoing 
unbounded repeating process. A protocol that sends four packets and then 
stops is not an ongoing unbounded repeating process. In any case, I don't 
believe that four packets constitutes a "storm". A "storm" usually refers 
to some unlimited feedback effect that produces an unbounded number of 
packets without limit until the problem is fixed.

>In view of my misgivings about section 2.1, the suggestion of much
>shorter fixed timeout intervalss on wireless networks in section 2.2
>does not improve my comfort level.

Again, I don't think four packets constitutes a "storm".

DHCP DISCOVER/OFFER/REQUEST/ACK is four packets, and many (or most?) 
hosts do that when they connect to the network today.

On the subject of time delay, we live in a world of gigabit Ethernet and 
gigahertz processors. The days when people were willing to wait 30 
seconds for their television set to "warm up" are behind us. We need to 
provide computers and networking that can meet the customer's 
expectations.

>I have a vague memory that the step described in section 2.3
>(so-called "gratuitous ARP") was considered somewhat controversial at
>one point, but I no longer remember why unless it's just dislike of
>the mandatory delay.

This does not impose any delay on use of the address.

The purpose of the ARP announcements is to make sure that other hosts on 
the link do not have stale ARP cache entries left over from some other 
host that may previously have been using the same address. Without ARP 
announcements to update peer caches, DHCP clients suffer irreproducible 
intermittent failures.

The DHCP specification (RFC 2131) already requires this behaviour:

   The client SHOULD broadcast an ARP
   reply to announce the client's new IP address and clear any outdated
   ARP cache entries in hosts on the client's subnet.

>Section 2.4 doesn't worry me as much as the earlier sections. The
>proposed mechanism for active defense seems like a fairly reasonable
>way of handling a situation that is already demonstrably broken.
>Note, however, that in pathological cases this mechanism could be used
>as a means of triggering broadcast storms (trick a bunch of machines
>into using the same address, then broadcast a packet that will make
>them all try to defend it at once). I don't think this is a serious
>risk, but something about it probably belongs in the security
>considerations section.

Please propose specific text.

If an attacker has a way to trick all your machines into using the same 
address, I think you have bigger problems to worry about than a few ARP 
packets.

>Section 2.5 is more of the same optimism about broadcast ARP replies.
>I've already commented on that, so I won't belabor the point.

Okay.

>Security Considerations section seems anemic. Aside from the specific
>minor issue mentioned above, there's the general issue that this is a
>mechanism by which an attacker can send packets via an unsecurable
>protocol that will provoke a host to respond in predictable ways.
>This is always a bit of a concern, and it's more of a concern with
>broadcast protocols.

I am willing to accept specific text.

I should say that I believe that the spoof ARP attack is not a new 
vulnerability. This document just says that hosts should detect it and 
recover.

As a real-world example, at the most recent IETF meeting in Atlanta, one 
of the networking guys had to come in to the meeting room and yank the 
power cord on the wireless base station to reset it. I asked him why? He 
told me that someone had manually set their IP address to be the same as 
the wireless base station, rendering the wireless base station useless. 
He had to come in and manually yank the power cord to power-cycle it so 
it would get a new DHCP address.

Clinging to your IP address in the face of ARP conflicts doesn't make 
your device more reliable -- it just means that it is now useless for 
longer, and requires a physical visit from a technician to fix it.

>Erik:
>
> Issues with draft-cheshire-ipv4-acd-02.txt
>
> High-order bit: the probing and annoucement part seems like very
> useful things to standardize.

Good.

> But the ongoing conflict detection (causing
> IP address change when a conflict appears) and broadcast replies looks
> more like a useful experiment to me.

It has been a five-year experiment by Apple.

Concerning ongoing conflict detection, I refer you to the previous 
example of the wireless base station at the IETF meeting.

> Also, the timeouts claim to be related to IEEE 802.1D behavior doesn't
> match IEEE 802.1D reality. (See below)
>
>
> Specfic comments:
> The document is written as if it updates RFC 826 and DHCP (RFC 2132) but
> it doesn't explicitly say this.

I am willing to accept specific text.

> > 3. Rate-limiting in the case of an excessive number of repeated
> > conflicts.
>
> Would be helpful to say what is rate limited; the attempt to use
> a different address (and not e.g. the rate at which some packet is sent)

New text:

   3. Rate-limiting of address acquisition attempts in the case of an
      excessive number of repeated conflicts.

> > This document standardizes the widely-used natural interpretation of
> > an ARP Request where the Target Protocol Address is non-zero but the
>
> While this might be natural, I have no idea whether or not it is
> widely used. Wants me want to ask for the survey results of 50 ARP
> implementations and how they do this.

This is the interpretation required by DHCP (RFC 2131), so I would hope 
it is widely used, at least to the extent that DHCP clients are widely 
used.

> > This document standardizes the widely-used natural interpretation of
> > an ARP Request where the Sender and Target Protocol Address fields
> > contain the same address, namely that it is an assertion without an
> > associated question (an "ARP Announcement").
>
> Same general question as above, except that there is another
> natural case - that an ARP Reply where the sender and targer
> are the same. Given that ARP is widely implemented it would be
> useful to understand 1) to what extent implementations do
> announcements using requests or replies, and depending on that answer
> 2) whether the protocol could allow both forms of annoucements i.e.
> any packet with equal sender protocol address and target protocol address
> would be an announcement.

This is the interpretation described in Stevens (TCP/IP Illustrated, 
1994) under the name "Gratuitous ARP" and described as being widely used 
at that time.

It is also required by RFC 2131.

> > "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL] can
> > benefit from this optional capability.
>
> The "can benefit" is odd since it looks like a suggestion to
> fix v4LL to do this, when in fact it already does.

The full sentence is:

   This is not needed in most situations, but
   certain specialized uses of Address Conflict Detection
   such as "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL]
   can benefit from this optional capability.

Delete the "such as" clause and the sentence reads:

   This is not needed in most situations, but
   certain specialized uses of Address Conflict Detection
   can benefit from this optional capability.

I hope that is clear.

> It is perhaps better to have some statement up front that this
> protocol is a subset of the address conflict detection of v4LL.

I would rather the merits of this document be considered alone, without 
normative reference to other unpublished specifications.

However, I think the relationship goes the other way: v4LL uses a proper 
subset of the conflict detection mechanisms outlined in this document.

> > RFC 826 implies that replies to ARP requests are usually delivered
> > using unicast, but it is also acceptable to deliver ARP replies using
> > broadcast. The "Packet Reception" rules in RFC 826 specify that the
> > content of the "ar$spa" field should be processed *before* examining
> > the "ar$op" field, so any host that correctly implements the Packet
> > Reception algorithm specified in RFC 826 will correctly handle ARP
> > replies delivered via link-layer broadcast.
>
> I think there are implementations of RFC 826 which do not follow
> the pseudo-code in RFC 826. What do we know about the effect
> of broadcast arp replies on them? 
> For example, I looked at the Solaris ARP code and it treats
> a broadcast arp reply as an ARP announcement which, due to the structure
> of the implementation, incurs more processing overhead than a ARP
> packet which is not considered to be an announcement.
> I wouldn't be surprised if there are other surprising behaviors related
> to broadcast ARP replies.

Section 1.2.3 says that broadcast ARP replies are "not needed in most 
situations". Section 2.5 says, "This is not recommended for general use." 
I believe the motivation for when you might prefer to use broadcast ARP 
replies, and why, is well explained in this section.

> > server, etc.) that the proposed address is not acceptable. In
> > addition, if during this period the host receives any ARP probe where
> > the packet's 'target IP address' is the address being probed for, and
> > the packet's 'sender hardware address' is not the hardware address of
> > any of the host's interfaces, then the host MUST similarly treat this
> > as an address conflict and signal an error to the configuring agent
> > as above. This can occur if two (or more) hosts have, for whatever
>
> The above is the only place where multihoming comes into the spec by 
> mentioning "any of the host's interfaces".

No, it is also mentioned in 2.4:

   Address conflict detection should not be limited to only the time of
   initial interface configuration, when a host is sending ARP probes.
   Address conflict detection is an ongoing process that is in effect
   for as long as a host is using an address. At any time, if a host
   receives an ARP packet (request *or* reply) where the 'sender IP
   address' is the host's own IP address, but the 'sender hardware
   address' does not match any of the host's own interface addresses,
   then this is a conflicting ARP packet, indicating some other host
   also thinks it is validly using this address.

This is necessary for the case when a host has two interfaces (say 
wireless and Ethernet) on the same link.

> I would assume that ACD can 
> operate independently for each interface even though v4LL has some 
> extra stuff related to multi-interface nodes.

No, the specification needs to deal with the case when a host has two 
interfaces (say wireless and Ethernet) on the same link.

> Section 2.2 on timeouts seems to not work.
> The 802.1d standard suggests default timers which result in it
> taking about 30 seconds until a switch port passes traffic after
> it has been enabled. I've personally observed more like 45 seconds
> when my office Ethernet drop has had spanning tree protocol enabled.

We live in a world of gigabit Ethernet and gigahertz processors. The days 
when people were willing to wait 30 seconds for their television set to 
"warm up" are behind us. We need to provide computers and network devices 
that can meet the same customer expectations.

> But in most cases this isn't needed. When DHCP is used (whether it is
> a desktop machine or some portable handheld wireless device) then
> no DHCP will happen until the switch starts forwarding packets.
> And the link-local case is handled in the v4LL specification.
> This leaves manually configured addresses.
> If you take into account that IEEE 802.1 is rapidly moving to
> obsolete spanning tree protocol in favour of the rapid spanning tree
> protocol, I don't see benefit in making the DHCP clients take 30-45
> seconds longer to initialize the stack just because that might be
> the conservative number for manually configured IP addresses until
> RSTP is deployed.
> And this calls into question the 4 packets spaced 2 seconds apart - 
> perhaps 1 or 2 packets are sufficient if you assume that the L2 is 
> forwarding frames by the time the ACD protocol runs.

Most network operators today, with good reason, set their port blocking 
time to five seconds.

The eight-second delay was determined empircally from customer feedback 
gathered over the last five years.

I am also working with the IEEE 802 committees on an update to rapid 
spanning tree that allows a host to reliably determine when link 
connectivity has been established, within 2.5 seconds of connection. When 
a Mac determines that it is connected to one of these newer switches, and 
confirms that proper link connectivity has been established, it will then 
start probing using the shorter timeouts given in Section 2.2.

With increasing use of portable devices, fast network connectivity is 
important. People want to plug in, complete the task at hand, and move 
on. USB and FireWire have extablished an upper limit on how long people 
are willing to wait between connecting a storage device and having it 
show up on the desktop read to read and write. About 3-5 seconds is a 
good goal. Quicker would be better, but sadly the need to be aware of 
spanning tree (and rapid spanning tree) makes that impossible.

> > (c) If a host has been configured such that it should not give up its
> > address under any circumstances, perhaps because it is an important
> > company server with a well-known IP address, then it MAY elect to
>
> company vs. university vs. home server presumably doesn't matter.
> s/company//
> It isn't "well-known" (as in potentially hard-coded in applications)
> that matter. Instead it is the assumption that the address be 
> temporarely stable because of long running connections and/or it being 
> in the DNS with a longish DNS TTL, that matters here.

I have changed the text:

   (c) If a host has been configured such that it should not give up
   its address under any circumstances (perhaps because it is the kind
   of device that needs to have a well-known stable IP address, such
   as a link's default router, or a DNS server) then it MAY elect
   to defend its address indefinitely.

The examples in parenteses are informative, not exhaustive.

> Section 2.5 on broadcast arp replies
> has a MAY and goes it to say that they should not be used universally.
> I think the MAY refers to MAY implement. In order to be able to
> operationally control the use I suspect it needs to be more strict
> and e.g. say "MAY be implemented. When implemented, there MUST be a 
> knob to enable the use of broadcast arp replies, and this knob MUST 
> default to false" or something similar that gives control on the *use* 
> of this.

I don't want to use language that may in future paint v4LL into a corner.

A Zero Configuration device may want to make use of address conflict 
detection. If address conflict detection requires a mandatory 
user-configuration option, then that means that Zero Configuration 
devices require mandatory user-configuration options, a 
self-contradiction.

I am willing to accept suggested text that doesn't require mandatory 
user-configuration options, but removing the burden of manual 
configuration is the whole point of Zero Configuration networking in the 
first place, so I am reluctant to compromise on that.

> Finally, references should be split between normative and non-normative
> per rfc-editor policy.

Done.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Dec 2002 16:05:50 -0500

> devices require mandatory user-configuration options, a 

actually, this is the biggest single problem with v4LL.

zero configuration is a misnomer.  the set of devices that can
practically be used with zero configuration is approximately the 
null set.  for instance, almost any networked device needs some kind
of authentication, and this inevitably requires some sort of
configuration - either in the device itself, or the clients
that are authorized to use that device, or both.

I quote from this group's charter:

> ZEROCONF requirements will make networking as easy as possible, but no 
> easier. In some cases other considerations may dominate ease of use. For 
> example, network security requires some configuration which may not be 
> as easy as the unacceptable alternative of 'no security.' 

it's high time that this group stopped ignoring this.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 11 Dec 2002 16:37:29 -0500

> that are authorized to use that device, or both.

Um...in home networks and ad hoc networks that only need to exist for a few
minutes, there is no authentication needed. Many, and perhaps most small
business networks don't require authentication either.

This isn't good or bad, but just a simple fact. The authentication you see
in .edu and large business domains is not the norm across the board. For the
people who don't need authentication, then Zeroconf is not a misnomer.

> it's high time that this group stopped ignoring this.

Well, if you want to be pedantic, literal Zeroconf is a physical
impossibility, but we're not including installing the NIC, connecting the
cables, etc.

john

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

---

From: [email-masked]
Date: Wed, 11 Dec 2002 19:38:21 -0600

On Wednesday, December 11, 2002, at 03:05 PM, Keith Moore wrote:

> null set.

We network and use USB and Firewire printers, scanners, hard drives and 
cameras all the time with zero configuration. Not to mention computers 
and printers using technologies like Appletalk.

-Rod Lopez

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Dec 2002 00:59:15 -0500

> cameras all the time with zero configuration. 

USB and Firewire are not the same as IP.   For instance, how frequently
do you have multiple devices on USB or Firewire that are accessible
from anywhere in the Internet, are potentially compromised, and can
be used to launch attacks on other devices on those buses?

Also, it's somewhat more reasonable for a USB or Firewire device to not 
need authentication, because you're not going to find many USB or Firewire
networks with hundreds or more devices that have external Internet access. 
L2-switched IP subnets with that many devices are quite common.

Keith

---

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

> be used to launch attacks on other devices on those buses?

  And how many LL networks are accessible from anywhere in the Internet?

  As soon as you set a non-LL address, your addressing scheme is
  outside of what zeroconf can provide, and it isn't really our
  problem (although *finding* the device with services like mDNS is
  still pretty useful).

> L2-switched IP subnets with that many devices are quite common.

  No, but for YEARS new printers, new consumer-level routers, new
  wireless access points, new VoIP phones, new video conference gear
  and many other embedded networking devices have all shipped with
  a 192.* address.  You put them on the network, point your browser at
  them, spend five minutes reconfiguring the network settings and you
  get on with life.  The risk is not zero, but it is very very small,
  and it sure beats trying to type in IP addresses and netmasks with
  the three buttons on the front of the device.

   -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: Thu, 12 Dec 2002 11:24:34 -0500

>   And how many LL networks are accessible from anywhere in the Internet?

"LL network" is a misnomer.  LL will be imposed on essentially all  
IP networks.  The hosts on those networks will still be as vulnerable 
to compromise from existing sources as they are now, and LL adds new 
vulnerabilities.
 
>   the three buttons on the front of the device.

Initial configuration is a different story.  At least if the initial
configuration is done over a wired interface you can hook up the
device to a network consisting of that device and another computer
for the sake of initial configuration.  

No, it's not safe to do this on a production network.  I've seen an
attack which relied on an OS being installed over the network with
no initial root password (because the OS let you set that after
installation) - the attacker could tell when you were finished installing 
the OS (from one of the mirror servers) and could compromise your 
computer before you got a password set.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 12 Dec 2002 12:22:38 -0500

> to compromise from existing sources as they are now, and LL adds new

Please, because I'm really curious. On an ad hoc network with 3 hosts(two
laptops and a printer) and a small hub, with no external connection, and no
wireless running, exactly *how* vulnerable are they in the real world?

> for the sake of initial configuration.

Direct connects describe a fair chunk of ad hoc networks.

> computer before you got a password set.

Um...how many devices require a complete OS Install over a network prior to
initial network/user configuration?

john

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

---

From: Peter Johansson <[email-masked]>
Date: Thu, 12 Dec 2002 11:00:21 -0800

At 12:59 AM 12/12/2002 -0500, Keith Moore wrote:

>USB and Firewire are not the same as IP.   For instance, how frequently do 
>you have multiple devices on USB or Firewire that are accessible from 
>anywhere in the Internet, are potentially compromised, and can be used to 
>launch attacks on other devices on those buses?

IEEE 1394, when hosts implement RFC 2734, is the same thing as IP. Windows 
XP incorporates "bridging" capabilities that make IP/1394 and IP/Ethernet 
appear to be on the same subnet as each other even though their link layers 
differ. If either the Ethernet segment or the IEEE 1394 segment is 
connected to something with routing capability to the Internet (cable 
modem, DSL, PPP with connection sharing, etc.) these devices meet all of 
your criteria above, Keith. I think this configuration exists more often 
than you believe and is growing.

>L2-switched IP subnets with that many devices are quite common.

IEEE 1394 is a serious answer for home networking solutions since it BOTH 
supports IP and offers quality of service (lacking in Ethernet) appropriate 
to video applications. To the extent that it is adopted as a solution, you 
will have networks with many devices that have Internet connectivity. 
Enough to warrant consideration.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Dec 2002 15:01:33 -0500

> than you believe and is growing.

Perhaps.  But that doesn't reduce the need for LL devices to implement 
security; rather, it increases the need for firewire devices to implement 
security.

Keith

---

From: Jim Busse <[email-masked]>
Date: Thu, 12 Dec 2002 13:19:50 -0800

John:

A real-world scenario is that one host could be diseased, and that disease
could be transmitted.  That disease might not show up in the LL ad-hoc
network, but might show up when the newly diseased host is connected to a
non-LL net.

If the machines and the app for transmission were authenticated, the risk
would be reduced.  If this authenticated app is the only app that can
transmit, then the user must select the disease for transmission (the
disease couldn't transmit itself, it would lack the authentication
credentials necessary).  Once the user has selected the disease and
transmitted it, the disease is easily contained and now quickly locatable
with a disease elimination device or software.  If the disease is permitted
to propagate itself, it could end up anywhere on the un-diseased host,
making the scan more difficult and probably more time-consuming.

A tightly-configured firewall won't protect you, because the disease might
be inside a dll, and you probably enabled dlls to run as an app because many
software programs require it, thus giving the disease access to the network
(whether LL or not).

Best regards,

Jim

---

From: Jim Busse <[email-masked]>
Date: Thu, 12 Dec 2002 13:40:44 -0800

From: "Keith Moore" <[email-masked]>
> security; rather, it increases the need for firewire devices to implement

Keith is absolutely correct.  Think about it:  you connect a diseased device
to your 400mbit firewire, and with the bridging to 100mbit ethernet, you
will never notice the 400mbit throughput degradation while the diseased
device could easily be saturating the 100mbit ethernet.

Please consider the arguments in rfc3365 "Strong Security Requirements".  I
understand this is for Standard Protocols.  The probable wide adoption of
Zeroconf will make it pervasive, even if it is not a Standard Protocol, and
we should take steps to add the strong security to it.

I made the same argument earlier, but the author of Zeroconf requirements
document was unwilling to specify the security measures necessary.

Jim

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Peter Johansson" <[email-masked]>
Cc: "Zero Configuration" <[email-masked]>
Sent: Thursday, December 12, 2002 12:01 PM
Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

> > >USB and Firewire are not the same as IP.   For instance, how frequently
do

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 12 Dec 2002 16:57:22 -0500

> network, but might show up when the newly diseased host is connected to a

Authentication isn't going to prevent Viral issues. You'll just have a virus
from an authenticated host. Also, in my ad hoc scenario, exactly what would
you be authenticating *to*?

> would be reduced.

No it wouldn't at all. Bad guys can be authenticated just like good guys.
It's called lying, and bad people do it all the time.

> If this authenticated app is the only app that can
> credentials necessary).

This is only valid if ONLY good apps can be authenticated. This is a naïve
and dangerous assumption.

> Once the user has selected the disease and

Again, authentication won't keep this from happening.

> software programs require it, thus giving the disease access to the network

Well, there are firewalls that scan for virii. So it just might. But again,
authentication won't do a thing to prevent viral infections.

john

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

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 12 Dec 2002 16:58:29 -0500

> document was unwilling to specify the security measures necessary.

How do you propose to specify a security mechanism that works correctly, and
easily across every platform that can run Zeroconf protocols inside of ten
years?

john

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

---

From: Jim Busse <[email-masked]>
Date: Thu, 12 Dec 2002 14:45:58 -0800

Thanks for your thoughts, John.  I would like to reply to several:

1.  >Authentication isn't going to prevent Viral issues.

True, by itself.  Please take the suggestions in RFC3365 as considerations
to provide a more complete security implementation.  Authentication is
simply one of them.

2. > what would you be authenticating *to*?

Authentication protocols are already available.  I would suggest that one be
selected (a very political thing, I'm sure) and that Zeroconf not pretend to
invent yet another authentication protocol.  However, after evaluating the
different protocols, it may become obvious that a "zeroconfiguration"
version is necessary.  Since that investigation isn't done yet, this is just
conjecture.

3.  >It's called lying, and bad people do it all the time.

Yeah, I know.  I was just swindled on ebay.  But in that scenario, neither
the seller nor the buyer were authenticated.  I'm sure I would not have been
swindled if there was a security procedure for the seller.  He might have
lied in the authentication, but I might have caught him in one of the other
protocols.  In any case, if there were strong security measures in place,
I'm srue I wouldn't have been swindled.

Jim.

----- Original Message -----
From: "John C. Welch" <[email-masked]>
To: "Zeroconf" <[email-masked]>
Sent: Thursday, December 12, 2002 1:57 PM
Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

john

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

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 12 Dec 2002 18:16:14 -0500

> version is necessary.  Since that investigation isn't done yet, this is just

You still need a trustable authentication authority, or you are
authenticating to an untrusted host, and the process is then worse then
useless, since you feel safe, even though you are not.

> I'm srue I wouldn't have been swindled.

How would a bogus authentication prevent you from being swindled?

john

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

---

From: Jim Busse <[email-masked]>
Date: Thu, 12 Dec 2002 15:20:18 -0800

John:

I think RFC3365 suggests a mechanism to define security requirements:  from
section 5, reprinted here without permission, it says:

"designers really
   need to look at the threats to their own protocol and design
   appropriate counter-measures.  The purpose of the "Security
   Considerations" Section required to be present in an RFC on the
   Internet Standards Track is to provide a place for protocol designers
   to document the threats and explain the logic to their security
   design."

So since I agree, I think that the threats should be identified, and
measures be put in place to counteract those threats, or not, depending what
the designers identify as appropriate counter-measures.

Probably 10 years isn't enough, because new threats may appear that need to
be addressed.  Therefore, I think this is kind of like your firewall with
virus scan, it needs periodic updates to address new threats.

Jim

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 12 Dec 2002 19:20:10 -0500

> virus scan, it needs periodic updates to address new threats.

But now you are talking about permanently delaying a standard for a target
that will NEVER be hit.

The only logical thing is to have many warnings about security, and leave it
up to the people applying and using the standard to deal with the specific
implementation of security.

john

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

---

From: Aidan Williams <[email-masked]>
Date: Fri, 13 Dec 2002 14:48:47 +1100

> we should take steps to add the strong security to it.

I for one would benefit from any concrete suggestions you might have
as to specific security mechanisms that could be added to IPv4-LL.

> document was unwilling to specify the security measures necessary.

I'm not sure I understand what you mean.  I can see how a protocol
document might specify the security mechanisms/measures to counter
specific threats but I don't understand what mechanisms you are
wanting to see in the requirements document.  Again, a specific
suggestion (feel free to knock up some text) would be appreciated.
Perhaps a paragraph citing RFC3365 would suffice?

- aidan

---

From: Jim Busse <[email-masked]>
Date: Thu, 12 Dec 2002 22:19:18 -0800

Aidan:

Thank you for responding.

On 5/5/30 2002, at 4:01PM, I wrote to you:

"....securing of a Zeroconf Network.  Please consider these comments:

"...the risks need to be identified, with the methods clarified in the
requirements and protocol drafts to secure against these risks.  Where
there's no security methods identified, , then, or where it's external to
the Zeroconf requirements or link-local drafts, will be obvious to the
implementers, and not implied.  I think, although requirements draft 10 says
"implications", the "implication" to my device or implementation may not be
clear.  Also, just to say "messages...are authenticated" again is not
sufficient.  I think we should say how they are authenticated.

"I know it's a big job, but I think it's time the IETF protocol developers
start considering as many of the security aspects of their work as
possible".

I was very very pleased when I read RFC3365.

In that 5/5 email, I went on to try to identify the attack categorization,
which I really haven't thought about since then, because of your feedback,
("I am reticent to include what could amount to an entire textbook of
network security into the requirements draft") and the lack of responses
from any of the other cc'd individuals.  Based on your email below, I would
like to pursue this issue further.

Even though I have architected and helped implement a remotely-configurable
firewall, been involved with the development of voice and fingerprint
authentication for PC clients, and with Intel's IPAA implementation, I am no
"security expert", and probably can't do a sufficient job.  With your
agreement, I would like to take the issue up with the IETF Security Area
working group, and probably specifically with the IP Security Remote Access
sub-group, to see if we can come up with some wording for both the LL and
Zeroconf requirements drafts.

Best Regards

Jim

----- Original Message -----
From: "Aidan Williams" <[email-masked]>
To: "Jim Busse" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; "Peter Johansson"
<[email-masked]>; "Zero Configuration" <[email-masked]>
Sent: Thursday, December 12, 2002 7:48 PM
Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

---

From: Aidan Williams <[email-masked]>
Date: Fri, 13 Dec 2002 17:45:13 +1100

> like to pursue this issue further.

To quote more fully from my response:

   | What aspects of these categories change when a network
   | starts using zeroconf protocols?
   |
   | I'm reticent to include what could amount to an entire
   | textbook of network security information into the
   | requirements draft.
   |
   | On the other hand, I don't want to miss any gotchas.

I would again encourage consideration of the security aspects
that are specific to or introduced by zeroconf protocols.

If you think there is a need for general security guidance
(ie security issues that are not specific to zeroconf protocols)
then I think we can cover that with references to books or RFCs
in the area.  Suggestions are welcome.

> I would like to take the issue up with the IETF Security Area

Input from people willing to improve or develop security
requirements for zeroconf protocols would be most welcome.
Perhaps you could say more about how ipsra would be relevant.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Dec 2002 12:01:15 -0500

> as to specific security mechanisms that could be added to IPv4-LL.

the simplest suggestion is the one that is consistently overlooked -
to not impose v4LL by default, on hosts or networks that 
don't want to use it.

then you can really start thinking of the risks of v4LL in terms of 
"ad hoc IPv4 networks" rather than in terms of "all IPv4 networks"
 
Keith

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 13 Dec 2002 09:21:40 -0800

> "ad hoc IPv4 networks" rather than in terms of "all IPv4 networks"

I'm not really sure how IPv4LL security issues relates to Stuart's 
address conflict detection draft, perhaps the subject needs to be 
changed.

I don't see how "not impos[ing] v4LL by default, on hosts or network 
that don't want to use it" will change the scope of security issues. 
This won't limit the use of IPv4LL addresses to just ad hoc networks. 
IPv4LL is useful on all IPv4 networks especially for initially 
configuring a device and for devices that simply don't need global 
addresses.

IPv4LL is a way for devices to acquire addresses for communication on 
the local-link in the absence of configured addresses. As Aidan 
Williams suggested, I think any security discussion should focus on the 
issues that are specific to or introduced by IPv4LL addresses.

-josh

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Dec 2002 12:29:58 -0500

> This won't limit the use of IPv4LL addresses to just ad hoc networks.

okay, fine.  but you either need to limit v4LL to ad hoc networks,
or you need to figure out how to introduce v4LL to all IP networks
without compromising the security of those networks.  and no, you
can't reasonably assume that all or even most of the threats are not 
on the local link.

at least if v4LL were easily disabled then networks would have an
effective countermeasure to those additional threats.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 13 Dec 2002 12:47:04 -0500

> effective countermeasure to those additional threats.

Um...and how do you propose to enforce this? You can't, you aren't, and it
won't happen.

If you are going to require that LL be disabled by default, or turn itself
off and require manual reactivation in the presence of other configuration
methods, then why bother with it at all.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 13 Dec 2002 11:18:09 -0800

> can't reasonably assume that all or even most of the threats are not

Are there specific security issues you are referring to?

> effective countermeasure to those additional threats.

What threats? The Security Considerations section lists two threats:

1) IPv4LL addresses may open a network host to attacks by giving it an 
IP address where it may not have had an IP address before.

2) ARP is insecure so a host using IPv4 may be unable to allocate an 
address if a misbehaved/malicious host claims all addresses.

In both of these cases, the threats are to hosts that are actually 
acquiring an IPv4LL address. The first is really only applicable to a 
host that would not otherwise have an IP address and is just a general 
warning that connectivity comes with risks. The second threat is a case 
that may render a host unable to acquire an IPv4LL address.

In what way does introducing IPv4LL addresses compromise the security 
of a network?

-josh

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Dec 2002 14:20:00 -0500

> Are there specific security issues you are referring to?

yes.  do you really expect me to list them all again?

Keith