From owner-zeroconf@merit.edu Thu May 2 13:14:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15674 for ; Thu, 2 May 2002 13:14:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82D04912B5; Thu, 2 May 2002 13:14:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 506D3912C1; Thu, 2 May 2002 13:14:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16D6B912B5 for ; Thu, 2 May 2002 13:14:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D72C85DDF7; Thu, 2 May 2002 13:14:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 59CC55DDF6 for ; Thu, 2 May 2002 13:14:31 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g42HEVs01787 for ; Thu, 2 May 2002 10:14:31 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 2 May 2002 10:14:01 -0700 Received: from [206.111.147.149] (vpn-gh-1097.apple.com [17.254.140.72]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g42HEUs15622 for ; Thu, 2 May 2002 10:14:30 -0700 (PDT) Message-Id: <200205021714.g42HEUs15622@scv3.apple.com> Subject: Time to Publish draft-ietf-zeroconf-ipv4-linklocal Date: Thu, 2 May 2002 10:14:29 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Draft-ietf-zeroconf-ipv4-linklocal-05.txt is in the Internet Drafts directory. This draft reflects all the changes agreed from the "Summary of Issues for draft-ietf-zeroconf-ipv4-linklocal-04.txt" list posted 11th November 2001. It also includes Section 2.3 "Shorter Timeouts on Appropriate Network Technologies" which was proposed 8th April. That change met with vocal approval from Peter van der Stok and no complaints from anyone else. There are two other minor wording changes at Keith Moore's request. 1. Keith Moore criticised the definition of "on the same link": >a better definition might be one that reflects the operational >realities of the kind of address defense you describe here - if a >link-level broadcast from node A reaches node B, or vice versa, A >and B are on the same link. if that's the case then you can't >afford address collisions between A and B, and if that's not the >case then your address defense protocol won't work anyway. As a result, I modified the text to explicitly mention broadcast packets: This document describes link-local addressing, for IP communication between two hosts on a single link. Two hosts are considered to be on the same link if, when one host sends packets to the other, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified. The link-layer *header* may be modified, such as in Token Ring Source Routing [802.5], but not the link-layer *payload*. In particular, if any device forwarding a packet modifies any part of the IP header or IP payload then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as Ethernet repeaters, bridges, hubs or switches and still be considered to be on the same link for the purpose of this document, but not through any device like an IP router that decrements the TTL or otherwise modifies the IP header. 2. Keith Moore requested addtional section headings: >section 2.7: > > this section should be weeded down to include only the stuff > that applies to routers. portions that apply to network > operators (DNS configuration) should go in a separate, clearly > labelled, section. portions that apply to application writers > should go in yet another separate, clearly labelled section. As a result, I have created new section headings: 2.8 Devices may Assume Link-Local Packets are Local 2.9 Higher-Layer Protocol Considerations 2.10 Privacy Concerns --- This is now, I believe, the finished document. If you think othewise, this is your last chance to speak up and say why. (I forgot to add Keith Moore's name to the Acknowledgements section, but that will be fixed.) Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 3 05:38:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07846 for ; Fri, 3 May 2002 05:38:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7320912EF; Fri, 3 May 2002 05:38:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72A09912EE; Fri, 3 May 2002 05:38:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29DD9912F0 for ; Fri, 3 May 2002 05:38:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E58475DE15; Fri, 3 May 2002 05:38:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by segue.merit.edu (Postfix) with SMTP id 3FD7D5DD8D for ; Fri, 3 May 2002 05:38:19 -0400 (EDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA22910; Fri, 3 May 2002 19:38:13 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal In-Reply-To: <200205021714.g42HEUs15622@scv3.apple.com> References: <200205021714.g42HEUs15622@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 May 2002 19:38:12 +1000 Message-Id: <19790.1020418692@mundamutti.cs.mu.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 2 May 2002 10:14:29 -0700 From: Stuart Cheshire Message-ID: <200205021714.g42HEUs15622@scv3.apple.com> | As a result, I modified the text to explicitly mention broadcast packets: I'm not sure that quite matches the intent - not that anything in what you wrote is incorrect, but that the way broadcast is used to define a link layer is somewhat simpler than that. It used to be that a LAN was essentially a cable, and every packet passed by every possible receiver - two nodes were on the same link if packets sent by one would be able to be seen by the other, and not otherwise. Hubs and repeaters were just seen as parts of the wire, they amplified signals, allowed longer cable lengths (affected collisions on LANS where collisions occur) and stuff - but had no effect on where packets were transmitted. The arrival of bridges (and later switches) changed all that - now the link layer only sends packets to nodes that are likely to actually want to receive them, usually, so the definition of a link layer changed. But - the way that a link level broadcast works hasn't altered - by definition a broadcast packet (link layer broadcast packet) gets sent to every node on the LAN (on the link) - switches don't alter that, and can't (or half the known protocols that use broadcast would break). So, now a good definition of whether two nodes are on the same link is whether a (link level) broadcast packet transmitted by one is visible to the other (whatever its content, if being visible depends on content, then some kind of helper is probably forwarding, and that doesn't count). So, it isn't really a question of what is, or isn't, modified in various payloads - it is possible to have two separate links where nothing in the link level payload is altered when packets move from one to the other, what really defines a link, as best we can do in these days of dubious and ambiguous forwarding devices, is where broadcast packets go. That also relates to Keith's point ... | >if that's the case then you can't | >afford address collisions between A and B, and if that's not the | >case then your address defense protocol won't work anyway. as all of this depends upon how broadcast works - the defence protocol depends upon broadcast (link level) packets being seen at every other possible user of the address, and the area where address collisions matter is the same set (where an ARP query might otherwise result in multiple different responses). kre From owner-zeroconf@merit.edu Fri May 3 12:24:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18569 for ; Fri, 3 May 2002 12:24:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADBF1912FC; Fri, 3 May 2002 12:24:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79426912FD; Fri, 3 May 2002 12:24:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9602B912FC for ; Fri, 3 May 2002 12:24:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 623F55DDEA; Fri, 3 May 2002 12:24:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 14B0C5DDAF for ; Fri, 3 May 2002 12:24:28 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g43GORt15887 for ; Fri, 3 May 2002 09:24:27 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 3 May 2002 09:23:57 -0700 Received: from [206.111.147.149] (vpn-gh-1097.apple.com [17.254.140.72]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g43GOPs11052; Fri, 3 May 2002 09:24:25 -0700 (PDT) Message-Id: <200205031624.g43GOPs11052@scv3.apple.com> Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal Date: Fri, 3 May 2002 09:24:26 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Robert Elz" Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Hubs and repeaters were just seen as parts of the wire, they >amplified signals, allowed longer cable lengths (affected >collisions on LANS where collisions occur) and stuff - but had >no effect on where packets were transmitted. > >The arrival of bridges (and later switches) changed all that - >now the link layer only sends packets to nodes that are likely >to actually want to receive them, usually, so the definition of >a link layer changed. I agree with what you are saying, but I disagree that the definition changed. Bridges and switches took the filtering algorithm that every Ethernet card implements and moved it up the cable to the hub, so that packets the Ethernet card would throw away anyway got filtered *before* they were sent down the cable, but the burden was on the switch vendors *not* to change the operating model. Vendors could never have sold "switches" if they didn't preserve the exact same operational model as standard Ethernet, because there would have been some higher level application software that stopped working. (Packet sniffers arguably fall outside the "standard Ethernet operating model".) However, I don't think you are advocating any change to the document. We're disagreeing over tiny nuances of wording. This is what the document says: Two hosts are considered to be on the same link if, when one host sends packets to the other, using unicast, multicast, or broadcast... My intent by use of the phrase, "sends packets to the other," was to mean when one host sends packets which, according to rules of Ethernet, the other host should receive. (I think that is reasonably conventional use of the word "to". Of course that depends on what the meaning of the word "is" is :-) If the other host should receive those packets, but doesn't, then the network is broken. If the other host receives those packets, but they arrive modified, then something in the middle modified them, therefore they are on separate links. If the other host receives all such packets unmodified, then the hosts are on the same link. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat May 4 06:01:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21464 for ; Sat, 4 May 2002 06:01:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DDA891359; Sat, 4 May 2002 06:01:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A31B89135B; Sat, 4 May 2002 06:01:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C17F291359 for ; Sat, 4 May 2002 06:01:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 794E75DDD3; Sat, 4 May 2002 06:01:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by segue.merit.edu (Postfix) with SMTP id E1AA05DDC3 for ; Sat, 4 May 2002 06:01:00 -0400 (EDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA03656; Sat, 4 May 2002 20:00:53 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal In-Reply-To: <200205031624.g43GOPs11052@scv3.apple.com> References: <200205031624.g43GOPs11052@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 May 2002 20:00:52 +1000 Message-Id: <29764.1020506452@mundamutti.cs.mu.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 3 May 2002 09:24:26 -0700 From: Stuart Cheshire Message-ID: <200205031624.g43GOPs11052@scv3.apple.com> | If the other host receives all such packets unmodified, then the hosts | are on the same link. Yes, if it gets all of the unicast/multicast/broadcast packets, that's probably close enough ... as long as it is clear that all need to get through, I guess when I read your words it seemed to me that if any of them could be delivered, it would be OK - but I have seen equipment that forwards (unaltered - ie: bridges) unicast traffic, but blocks broadcast. It is really where the broadcast packets go that matters most. kre From owner-zeroconf@merit.edu Wed May 8 21:58:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29357 for ; Wed, 8 May 2002 21:58:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1ADA912C0; Wed, 8 May 2002 21:58:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99484912C2; Wed, 8 May 2002 21:58:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D381912C0 for ; Wed, 8 May 2002 21:58:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 921615DDF3; Wed, 8 May 2002 21:58:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 057BB5DDDB for ; Wed, 8 May 2002 21:58:02 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id SAA17731 for ; Wed, 8 May 2002 18:58:02 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id SAA22479 for ; Wed, 8 May 2002 18:58:00 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g491vvjd025062 for ; Thu, 9 May 2002 11:57:58 +1000 (EST) Message-ID: <3CD9D7A3.42A19FDE@motorola.com> Date: Thu, 09 May 2002 11:57:55 +1000 From: Aidan Williams Reply-To: Aidan_Williams-A15677@email.mot.com Organization: aidan@arc.corp.mot.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: I-D ACTION:draft-ietf-zeroconf-reqts-10.txt References: <200205081128.HAA00995@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, draft-zeroconf-reqts-09.txt went through WG last call, but has encountered objections from the IESG particularly relating to security. Questions were also raised about the usefulness of the sections on naming in evaluating candidate zeroconf name resolution protocols. I agreed to take over editing of the document from Myron Hattig. Thanks go to Myron for his work on the previous revisions. I would like to restart discussion on the mailing list. Please read and comment on the draft. Post your comments to the mailing list, preferrably with a concrete suggestion as to how to improve the draft. (text would be lovely!) In particular, you'll find some sections contain a paragraph soliciting input (search for the word "solicit"). Those sections are: 3.1.2 Relationship to other unicast IP address assignment mechanisms (in the section on IP interface configuration) 3.2.2 Relationship to the DNS (in the section on name resolution) 4. Security Considerations This a summary of the changes I have made: - I tweaked some of the first sections of the document. - I replaced the "Conflicts and State Changes Requirement" section with a section called "Maintaining Consistent Network State" - I re-introduced the scenario section, splitting it out from requirements. I know this potentially makes things more verbose, but I hope the result isn't too bad. The benefit of doing this is that there are now some *general* requirements that may be applicable to other zeroconf protocls (ie not just the 4 we were focussing on) This resulted in an increased number of requirements, particularly in the addressing and naming section. - I applied the scenario section requirements to * IP addressing * the naming section but left the * multicast * and service discovery section pretty much untouched. This was because they are pretty good, and I've just had enough typing on the thing this week.. :) They will need updating to give them a consistent "look & feel". - I added a couple of sections "Relationship to (DNS|DHCP)" - I re-did the security section to address the objections from the IESG. It is somewhat shorter, and less detailed. It seems to me that a lot of the material in the previous section would have been better covered in the per-protocol documents. It really wasn't possible for me to come up with the canonical security section. I have tried to map out the landscape, and have generated some questions to try and get feedback from people. I wrote down three security scenarios which I hope should generate some discussion. regards aidan ____ :wq! From owner-zeroconf@merit.edu Tue May 14 19:02:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11023 for ; Tue, 14 May 2002 19:02:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B76591220; Tue, 14 May 2002 19:02:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6C5C91226; Tue, 14 May 2002 19:02:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 163FB91220 for ; Tue, 14 May 2002 19:02:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6B295DF52; Tue, 14 May 2002 19:02:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 74C4E5DDA7 for ; Tue, 14 May 2002 19:02:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4EN26g13832; Tue, 14 May 2002 19:02:07 -0400 (EDT) Message-Id: <200205142302.g4EN26g13832@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu, iesg@ietf.org Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal In-reply-to: (Your message of "Thu, 02 May 2002 10:14:29 PDT.") <200205021714.g42HEUs15622@scv3.apple.com> Date: Tue, 14 May 2002 19:02:06 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk These are my comments on draft-ietf-zeroconf-ipv4-linklocal-05. I'm cc'ing IESG on the assumption that the draft would go to IESG anyway. As there are still substantial problems with this document, I don't see any need to wait until IESG issues a Last Call. NOTE: Many of the criticisms on the -04 version of the document have not been adequately addressed, so they are re-iterated here for completeness. (read: rather than trying to reconcile -05 with those comments, I simply made a fresh pass over -05. But I remember making similar comments about -04 on most of these issues.) Executive Summary: The protocol has significant deficiencies which cannot be fixed by simple changes in the text. More work is needed. ------------------------------------------------------------------------------ Issue 1: This protocol will break distributed applications. Consider a distributed application that runs on several hosts. Some of these hosts are on a local network and support autoconfiguration, some of these hosts are on a remote network which has intermittent connection to the local network. That local network can either be connected or disconnected from the remainder of the network. The components of the application may start when the network is in either state, and the network can transition from one state to another without warning (as the connection goes up and down). There are several reasons why such a scenario is realistic: the routers and other hardware that connect the local network to the outside world may suffer frequent power failures; lots of sites have flaky links to the outside world, etc. Each component of the distributed application also needs to be able to send its address+port to other components. This is a common and reasonable thing to do - FTP has long allowed it for third-party mediated transfers, SIP does it for call setup, Gnutella does it to inform third parties about the locations of files, distributed computing and cluster computing applications (Globus, Legion, NetSolve, PVM, Condor, etc.) do it to allow components to spawn new components on other hosts which communicate with other components that are already part of the application. Now here's the problem: If a component starts operation when the local network is in a disconnected state, it will only learn of the link-local address(es) of its host. If it advertises those addresses to other components, and the network subsequently transitions to a connected state, those addresses are likely to propgate to components for which they are not usable. This applies to both "smart" applications that explicitly select their source addresses, and "dumb" applications that simply use whatever source address they are bound to. A similar problem exists when the component starts operation when the local network is in a connected state - a "smart" application learns of all of the addresses of the host, including the link-local addresses. If it propagates those addresses to other components on other hosts, they will not be able to use those addresses. However, this is a more general problem with scoped addresses. It has been argued that link-local addresses have been supported on Windows and MacOS systems for a long time, with no known ill effects. However, according to the draft, both Windows and MacOS systems first try to configure an interface with DHCP and only fall back to link-local if that fails, and both systems discontinue use of the link-local address once a DHCP server is found and do not use link-local addresses thereafter. (presumably they also avoid using link-local addresses if an address is manually configured) This limits the applicability of link-local addresses on such systems (basically they're only good for isolated networks or for applications which have short-duration connections), but by minimizing the transitions that an application sees it also limits the harm that would otherwise be done by exposing link-local addresses to applications that aren't aware of them. This was a wise decision on the part of the Windows and MacOS developers which seems to have been disregarded by the working group. By contrast, this document proposes to make link-local addresses usable full-time, without really considering the impact on applications, and for what seem to be dubious reasons (e.g. providing a false sense of security). It's difficult to see how to remedy this problem while still allowing link-local addresses to be full-time. In earlier comments I made suggestions in an attempt to minimize the problem, e.g.: - that a link-local address should not be selected as a source address except when there is no routable source address, or when attempts to contact a device using a link-local destination and a routable source address have failed. - that in lists of interface addresses obtained from the OS that link-local addresses either be hidden, or distinguished from other addresses in a way that makes "smart" applications unlikely to choose those local addresses as source addresses. But these were just my earlier attempts to "fix" the protocol without changing it much. I don't think that these are sufficient by themselves. ------------------------------------------------------------------------------ Issue 2: Definition of "on the same link" is still flawed. It's simply bogus to define "on the same link" solely in terms of whether the link-layer payload is changed. Yes, IP routers should decrement TTL and thus cause the packet to be "not on the same link" by this definition, but if a router fails to decrement TTL then it still shouldn't be "on the same link". Having the link-layer payload be unchanged might be a necessary condition for "on the same link", but - at least if you want this definition to be useful for describing when link-local addresses are usable between two hosts - it's not a sufficient condition. Another necessary condition is that the hosts be able to receive each other's broadcasts. Actually it is probably better to define this not in terms of "two hosts" but as "a set of hosts": e.g. A set of hosts is considered to be "on the same link", if: - when any host A from that set sends a packet to any other host B in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified, and - a broadcast sent over that link by any host from that set of hosts can be received by every other host in that set This problem is easily fixed: just change the definition. ------------------------------------------------------------------------------ Issue 3: The address defense protocol appears to facilitate new kinds of attack A host supporting link-local addresses is expected to enable them at all times, and to support the address defense protocol at all times. So if an ARP packet arrives at a host which conflicts with one of the host's existing link-local addresses, the host is expected to either defend the existing address, or configure a new link-local address and defend that address. Either way, the host MUST send out multiple ARP probes (4 probe packets at 2-second intervals to claim the address, followed by 2 announcements, also at 2-second intervals), each using broadcast. This has a multiplier effect - one or two ARP packets sent by an attacker results in six ARP packets being sent in response, causing every host on the link to process each of those requests, and also breaking any connections that might be using the link-local address. If several hosts are attacked at once this can produce broadcast storms. While each of these storms should be limited in duration to about 16 seconds (due to the initial random delay, bounded number of transmissions, and the fixed 2-second interval), they can still be disruptive. And nothing stops the attacker from repeating this attack. A virus that infected several hosts on a link and which attacked the link in this way would take down the link. While the virus could just as easily take down the link by merely sending broadcast packets, an attack which caused *every* host on the link to send broadcast packets would be more difficult to diagnose. Widespread support for full-time defense of link-local addresses allows an attacker to exploit the packet-multiplication effect of this protocol. The security considerations section doesn't adequately address this attack (it claims that ARP is insecure, which is true, but this protocol facilitates a new kind of attack using ARP), and it doesn't provide any means of ameliorating this threat. Part of the problem is caused by link-local addresses being enabled at all times, even when there's no need for them, and even by hosts which don't need or want to talk to hosts which only have link-local addresses. Also, this problem is much less severe with existing MacOS and Windows implementations of link-local addresses because these disable use of such addresses for any link that supports DHCP. ------------------------------------------------------------------------------ Issue 4: The document (still) makes misleading claims about security Section 2.8 is still misleading. In part, it reads: The non-forwarding rule is important because it is expected that many link-local-only devices will be extremely simple devices of the kind that currently use X10 [X10], USB [USB] or FireWire [1394]. The designers of these devices currently assume that they will communicate only with other local devices, and this allows them to ------------------- produce cost-effective devices by implementing a degree of security ------------------------------------------------------------------- appropriate for that expected environment. ----------------------------------------- The underlined portion can be read either as a (bogus) assumption by the designers of such devices, or as a statement that use of link-local addresses really does provide some security. We need to be very clear about this. Use of link-local addresses is *not* an appropriate security mechanism. It is *not* reasonable for the designers of IP-based devices to assume that the link provides adequate security for any purpose - first because the designers of such devices know nothing about the networks to which their users connect; and second, because the security of other hosts on such networks cannot be assumed. and such hosts could be used as platforms from which to attack these devices and expose information from those devices to other hosts. The security considerations section (section 5) is also misleading: - It recognizes the potential for previously non-IP hosts to be attacked via IP if they acquire an IP interface (this wasn't obvious?) but it fails to recognize the potential for additional attacks on existing IP hosts if they implement link-local addresses. - It recognizes the existing insecurities of ARP but fails to recognize the additional insecurities resulting from this particular use of ARP. (Normally we expect the security considerations section to document the risks of *this* protocol rather than other protocols...) It also states that "the use of link-local addresses..." [presumably instead of routable addresses] "may reduce the breadth of attack to which a device may be subject" and then goes on to state (correctly) that "this is not a reason to ignore security issues." It should still be made even clearer that link-local addresses are not a security mechanism, and that *any* IP-capable host may potentially be attacked using IP even if it has no routable addresses - by other hosts on the same link that have been compromised or by unauthorized hosts which have obtained access to the link by some means (e.g. wireless links or wiretaps). ------------------------------------------------------------------------------ Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols) Section 2.9 reads as if it's reasonable to put link-local addresses in DNS if some constraints are followed. It seems to me that practical constraints on such use are so narrow and so difficult to define that it would be far better to simply say that link-local addresses SHOULD NOT be used in DNS and/or that mechanisms specifying link-local addresses in DNS are currently undefined and for further study. For instance, on a network where new hosts could join or leave, a DNS service returning link-local addresses would need to deal with possible address conflicts and changes. This could be addressed e.g. using DNS dynamic update, but then the host needs to authenticate to the DNS server. This defeats the very purpose of autoconfiguration. In such cases it would often be simpler to just assign a static IP address to the host. Similar concerns, of course, apply to any use of link-local addresses by higher-layer protocols - they're subject to change at a whim. ------------------------------------------------------------------------------ Issue 6: Hosts that have multiple interfaces The scenario described in section 3.3.2 will break applications, as it requires them to explicitly select a network interface when sending a packet, and to know which interface to select. For instance, if an application on host A wishes to send a message to an application on host B, it must explicitly send that packet through interface P. Even if the stack knows which interface to use for already-open TCP connections, this doesn't allow an application on host A to reliably open up a new connection to host B. It's hard to see how to fix this. IP is designed with the assumption that a host or service can be identified with sufficient precision (for the purpose of establishing a connection to that host) simply by specifying the host's or service's address and the port number of the service. And defending the addresses between separate links seems undesirable. ------------------------------------------------------------------------------ Conclusions: The document seems to envision a world where large numbers of (probably insecure) devices are capable of speaking IP using only link-local addresses, and where any IP-capable host (on the same link) can automatically talk to such devices. It's an interesting world to think about. But I don't think that the security problems have been adequately addressed. Also, it seems to be trying to solve two separate problems - address selection in ad hoc networks, and automatic configuration of limited-function devices. I suspect that these are better treated as separate problems, and that different solutions are needed for ad hoc networks vs. managed networks. M$ and Apple got that right in their early implementations. You really don't want this protocol being used on your network if you're supporting DHCP. Bluetooth devices, I've heard, have the capability of being taught which other devices to trust. This seems like an essential capability, and I doubt that any network device can potentially accept input from large numbers of other hosts and still provide adequate security without such a mechanism. "zero configuration" is probably not desirable as anything other than mechanism for initial configuration and bootstrapping. ------------------------------------------------------------------------------ Recommendations: - Provide a means for networks to disable use of link-local addresses for any host that is - capable of using routable addresses, and - not explicitly configured to use link-local addresses. This would still allow use of link-local addresses on ad hoc networks, and it would still allow hosts that needed to use link-local addresses in order to communicate with devices to do so. But it would not make them the default for all hosts. e.g. Any host that either has a routable address explicitly configured, or which receives an address from DHCP, ceases using link-local addresses for new connections, unless it was explicitly configured to be able to use link-local addresses. This would minimize the potential for "address defense protocol" attacks and for disruption of applications. - Explicitly and clearly state in positive terms that all IP-capable devices, including those using only link-local addresses, MUST implement security adequate to protect the device's resources those resources to which the device has access, and the network. such security almost certainly requires explicit configuration. and although link-local addresses may be useful during initial configuration, they are not a security mechanism. - Also, I wonder if this protocol be considered only applicable for use in ad hoc networks - in particular that it SHOULD NOT be considered a substitute for DHCP even for limited-function devices - it doesn't seem any more difficult for a limited-function device to implement DHCP than to implement this protocol. (though it is unfortunate that they need to implement two protocols, the subset of DHCP needed to configure the host address, netmask, and default route - if any - shouldn't be too bad. Either that or let the DHCP server respond to an ARP request for a link-local address with a RARP response to say "no, *this* is your address". The point is that you may want to avoid using these things in managed networks, even for limited-function devices. If that means that such networks need to learn how to disable link-local address defense, in order to lessen the burden on those devices, that's probably a reasonable tradeoff. - Beyond the suggestions I made above, I'm not sure how to keep link-local addresses from breaking distributed applications. But I think the potential can be minimized by only using link-local addresses on ad hoc networks or on hosts that are explicitly configured to use them, and with some of the other suggestions I made. -Keith From owner-zeroconf@merit.edu Tue May 14 19:41:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12310 for ; Tue, 14 May 2002 19:41:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC47091226; Tue, 14 May 2002 19:41:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C3E891234; Tue, 14 May 2002 19:41:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E6E291226 for ; Tue, 14 May 2002 19:41:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B35E5DF56; Tue, 14 May 2002 19:41:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from VENUS1 (203-31-216-54.amaze.net.au [203.31.216.54]) by segue.merit.edu (Postfix) with ESMTP id 3021B5DDA7 for ; Tue, 14 May 2002 19:41:18 -0400 (EDT) Received: from [10.1.0.83] by VENUS1 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.0.6)); Tue, 14 May 2002 16:39:11 -0700 Message-Id: <5.1.0.14.2.20020515093626.01def5d0@PostOffice.PacBell.net> X-Sender: Celeborn@PostOffice.PacBell.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 09:42:46 +1000 To: Zero Configuration From: Peter Johansson Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal In-Reply-To: <200205142302.g4EN26g13832@astro.cs.utk.edu> References: <200205021714.g42HEUs15622@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:02 PM 5/14/02, Keith Moore wrote: >The underlined portion can be read either as a (bogus) assumption by the >designers of such devices, or as a statement that use oflink-local >addresses really does provide some security. There's more than one problem with the text cited from clause 2.8: " ... or FireWire [1394]. The designers of these devices currently assume that they will communicate only with other local devices, and this allows them to produce cost-effective devices by implementing a degree of security appropriate for that expected environment." RFC 2734, IPv4 over IEEE 1394, is intended to provide full IP functionality with NO assumptions that the hosts communicate only with other local devices. Since IEEE 1394b is a suitable candidate for the backbone of a home network, there's no reason to assume the limited connectivity stated in clause 2.8 above. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Tue May 14 19:41:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12328 for ; Tue, 14 May 2002 19:41:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEB0691234; Tue, 14 May 2002 19:41:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1F9C9127B; Tue, 14 May 2002 19:41:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CE5891234 for ; Tue, 14 May 2002 19:41:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D39915DF52; Tue, 14 May 2002 19:41:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from VENUS1 (203-31-216-54.amaze.net.au [203.31.216.54]) by segue.merit.edu (Postfix) with ESMTP id 7D3BA5DF55 for ; Tue, 14 May 2002 19:41:20 -0400 (EDT) Received: from [10.1.0.83] by VENUS1 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.0.6)); Tue, 14 May 2002 16:39:11 -0700 Message-Id: <5.1.0.14.2.20020515093626.01def5d0@PostOffice.PacBell.net> X-Sender: Celeborn@PostOffice.PacBell.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 09:42:46 +1000 To: Zero Configuration From: Peter Johansson Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal In-Reply-To: <200205142302.g4EN26g13832@astro.cs.utk.edu> References: <200205021714.g42HEUs15622@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:02 PM 5/14/02, Keith Moore wrote: >The underlined portion can be read either as a (bogus) assumption by the >designers of such devices, or as a statement that use oflink-local >addresses really does provide some security. There's more than one problem with the text cited from clause 2.8: " ... or FireWire [1394]. The designers of these devices currently assume that they will communicate only with other local devices, and this allows them to produce cost-effective devices by implementing a degree of security appropriate for that expected environment." RFC 2734, IPv4 over IEEE 1394, is intended to provide full IP functionality with NO assumptions that the hosts communicate only with other local devices. Since IEEE 1394b is a suitable candidate for the backbone of a home network, there's no reason to assume the limited connectivity stated in clause 2.8 above. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Tue May 14 19:41:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12341 for ; Tue, 14 May 2002 19:41:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1988D91281; Tue, 14 May 2002 19:41:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4D959128D; Tue, 14 May 2002 19:41:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 056E191281 for ; Tue, 14 May 2002 19:41:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAD165DF55; Tue, 14 May 2002 19:41:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from VENUS1 (203-31-216-54.amaze.net.au [203.31.216.54]) by segue.merit.edu (Postfix) with ESMTP id 34A8E5DF51 for ; Tue, 14 May 2002 19:41:18 -0400 (EDT) Received: from [10.1.0.83] by VENUS1 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.0.6)); Tue, 14 May 2002 16:39:11 -0700 Message-Id: <5.1.0.14.2.20020515093626.01def5d0@PostOffice.PacBell.net> X-Sender: Celeborn@PostOffice.PacBell.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 09:42:46 +1000 To: Zero Configuration From: Peter Johansson Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal In-Reply-To: <200205142302.g4EN26g13832@astro.cs.utk.edu> References: <200205021714.g42HEUs15622@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:02 PM 5/14/02, Keith Moore wrote: >The underlined portion can be read either as a (bogus) assumption by the >designers of such devices, or as a statement that use oflink-local >addresses really does provide some security. There's more than one problem with the text cited from clause 2.8: " ... or FireWire [1394]. The designers of these devices currently assume that they will communicate only with other local devices, and this allows them to produce cost-effective devices by implementing a degree of security appropriate for that expected environment." RFC 2734, IPv4 over IEEE 1394, is intended to provide full IP functionality with NO assumptions that the hosts communicate only with other local devices. Since IEEE 1394b is a suitable candidate for the backbone of a home network, there's no reason to assume the limited connectivity stated in clause 2.8 above. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Tue May 21 09:13:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09098 for ; Tue, 21 May 2002 09:13:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39BA4912A1; Tue, 21 May 2002 09:13:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 073E6912A2; Tue, 21 May 2002 09:13:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5540912A1 for ; Tue, 21 May 2002 09:13:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E413C5DE36; Tue, 21 May 2002 09:13:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 96C795DD92 for ; Tue, 21 May 2002 09:13:39 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26874; Tue, 21 May 2002 06:13:29 -0700 (PDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4LDDQb18992; Tue, 21 May 2002 15:13:26 +0200 (MEST) Date: Tue, 21 May 2002 06:13:22 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: zeroconf@merit.edu Cc: Erik Guttman , cheshire@apple.com, aboba@internaut.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, Thanks for your clear review. I have suggestions which I think will satisfy your concerns and give us a path forward. I appreciate your constructive effort to ensure this protocol meets the needs of a diverse set of end-users. The challenges we face here is to supply something simple enough for consumer appliances but safe enough to be used on devices connected to any network. ------------------------------------------------------------------------------ Issue 1: This protocol will break distributed applications. Each component of the distributed application also needs to be able to send its address+port to other components. This is a common and reasonable thing to do - FTP has long allowed it for third-party mediated transfers, SIP does it for call setup, Gnutella does it to inform third parties about the locations of files, distributed computing and cluster computing applications (Globus, Legion, NetSolve, PVM, Condor, etc.) do it to allow components to spawn new components on other hosts which communicate with other components that are already part of the application. Now here's the problem: If a component starts operation when the local network is in a disconnected state, it will only learn of the link-local address(es) of its host. If it advertises those addresses to other components, and the network subsequently transitions to a connected state, those addresses are likely to propgate to components for which they are not usable. This applies to both "smart" applications that explicitly select their source addresses, and "dumb" applications that simply use whatever source address they are bound to. ERIK: We should add an applications considerations section to address this. It is an additional burden on the app. - that in lists of interface addresses obtained from the OS that link-local addresses either be hidden, or distinguished from other addresses in a way that makes "smart" applications unlikely to choose those local addresses as source addresses. ERIK: Such an interface which hides details of address changes would be much higher level than a socket interface - a kind of session API. I doubt whether we could really complete such an effort in the IETF, though some such has been proposed in IPng. ------------------------------------------------------------------------------ Issue 2: Definition of "on the same link" is still flawed. A set of hosts is considered to be "on the same link", if: - when any host A from that set sends a packet to any other host B in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified, and - a broadcast sent over that link by any host from that set of hosts can be received by every other host in that set ERIK: OK. We can adopt this definition. ------------------------------------------------------------------------------ Issue 3: The address defense protocol appears to facilitate new kinds of attack The security considerations section doesn't adequately address this attack (it claims that ARP is insecure, which is true, but this protocol facilitates a new kind of attack using ARP), and it doesn't provide any means of ameliorating this threat. ERIK: Keith makes a good point and this should be added to the security considerations section. ------------------------------------------------------------------------------ Issue 4: The document (still) makes misleading claims about security Section 2.8 is still misleading. In part, it reads: communicate only with other local devices, and this allows them to ------------------- produce cost-effective devices by implementing a degree of security ------------------------------------------------------------------- appropriate for that expected environment. ----------------------------------------- The underlined portion can be read either as a (bogus) assumption by the designers of such devices, or as a statement that use of link-local addresses really does provide some security. ERIK: This text should be replaced with wording that security cannot be assumed on the link in all situations by the protocol designers. Operators of course can make use of private links but that is distinct from what the protocol implementors and app implementors can assume. As ARP is insecure, too, we should mention that for security, (for authenticating the communicating endpoint) a higher layer protocol is needed - ie. ipsec, tls, s/mime, etc. ------------------------------------------------------------------------------ Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols) it would be far better to simply say that link-local addresses SHOULD NOT be used in DNS and/or that mechanisms specifying link-local addresses in DNS are currently undefined and for further study. ERIK: The use of link-local addresses in the DNS is not currently specified by any document except some in discussion in the DNSEXT working group. What you are proposing is an additional for ZEROCONF name resolution protocols. I agree that we should call attention to the difficulty of keeping link-local address to name mapping in the DNS consistent with the actual state of the network. Given addr autoconf, address assignments will change dynamicly. If autoconf addresses in A, AAAA, etc. RRs can be obtained from the DNS, secure dynamic update would be required, right? ------------------------------------------------------------------------------ Issue 6: Hosts that have multiple interfaces It's hard to see how to fix this. IP is designed with the assumption that a host or service can be identified with sufficient precision (for the purpose of establishing a connection to that host) simply by specifying the host's or service's address and the port number of the service. And defending the addresses between separate links seems undesirable. ERIK: Options - Use on only 1 link at a time. - Defend all addresses (that one has in one's cache?) on all connected links. - Propose an interface indexed socket interface that is also exposed by service discovery. That way, every time an address is selected, it will be explicitely destined for an unambiguous interface. discovery: find a service, get its address and interface id. bind: bind to an address and interface id. One would have to bind to each interface, or ANY. recvfrom: would indicate the source addr and incoming inter- face. sendto: would indicate the dest addr and outgoing interface. connect: would take dest addr and outgoing interface. gethostbyname() would indicate the interface for each addr in the hostent. This work has already been done for the IPv6 API. In fact, we could leverage this - by specifying that the behavior of these interfaces for IPv6 mapped IPv4 addresses in the LL range is ---. ------------------------------------------------------------------------------ Recommendations: - Provide a means for networks to disable use of link-local addresses for any host that is - capable of using routable addresses, and - not explicitly configured to use link-local addresses. ERIK: I disagree with Keith here. v4 LL autoconfiguration has been present in networks for four years. The DHCP option to 'turn off' autoconfiguration has never been implemented and no vendor I know of has the intention of doing so. As long as the other problems above (notably the multihomed autoconfiguration problem) is addressed, this extreme restriction *against current practice of the most popular client platforms* cannot be defended. - Explicitly and clearly state in positive terms that all IP-capable devices, including those using only link-local addresses, MUST implement security adequate to protect the device's resources those resources to which the device has access, and the network. ERIK: Yes - and specify that these must be done at a higher layer than the IP configuration interface, which is all we are defining in this document. - Also, I wonder if this protocol be considered only applicable for use in ad hoc networks - in particular that it SHOULD NOT be considered a substitute for DHCP even for limited-function devices - ERIK: This protocol is already being used in non-ad hoc networks. You are suggesting an applicablity statement which ignores the primary use of the protocol - namely unadministered local networking which works irrespective of which DHCP server comes up, and even if several do, without coordination. (!) - Beyond the suggestions I made above, I'm not sure how to keep link-local addresses from breaking distributed applications. But I think the potential can be minimized by only using link-local addresses on ad hoc networks or on hosts that are explicitly configured to use them, and with some of the other suggestions I made. ERIK: I agree an application considerations section should be added. There are issues which need to be presented. None are insoluble. The local address may change. Applications will need to detect this event and rebind or reconnect their sockets, etc. The remote address may change. Applications will need to perform service discovery in this case, to determine their peers new location. Multihomed hosts need to present the interface in the networking API if more than one interface exposes link local addresses (probably). All of these issues need to be discussed but none of them are showstoppers. Best regards, Erik From owner-zeroconf@merit.edu Tue May 21 09:45:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10337 for ; Tue, 21 May 2002 09:45:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5D2D912A3; Tue, 21 May 2002 09:45:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80DE6912A4; Tue, 21 May 2002 09:45:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DDA8912A3 for ; Tue, 21 May 2002 09:45:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86F6D5DE3E; Tue, 21 May 2002 09:44:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 0B82F5DD92 for ; Tue, 21 May 2002 09:44:59 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20345 for ; Tue, 21 May 2002 06:45:01 -0700 (PDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4LDixb20105 for ; Tue, 21 May 2002 15:45:00 +0200 (MEST) Date: Tue, 21 May 2002 06:44:55 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: zeroconf@merit.edu Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, One more note on Keith's comments on draft-ietf-zeroconf-ipv4-linklocal-05.txt follows. A host supporting link-local addresses is expected to enable them at all times, and to support the address defense protocol at all times. So if an ARP packet arrives at a host which conflicts with one of the host's existing link-local addresses, the host is expected to either defend the existing address, or configure a new link-local address and defend that address. Either way, the host MUST send out multiple ARP probes (4 probe packets at 2-second intervals to claim the address, followed by 2 announcements, also at 2-second intervals), each using broadcast. This has a multiplier effect - one or two ARP packets sent by an attacker results in six ARP packets being sent in response, causing every host on the link to process each of those requests, and also breaking any connections that might be using the link-local address. ERIK: I do not see the difference in kind between this attack and the preexisting one which simply sends garbage ARP replies to stomp on legitimate ones. An attacker's ARP reply will break connections. This forces higher layers to retry, which will imply additional ARP requests being broadcast repeatedly, etc. The difference is only one of magnitude. With v4LL autoconf, an attacker's ARP will cause an address reconfiguration event, which requires (a) a new claim to be established, (b) discovery of the new IP address (using service discovery or multicast based name resolution) and (c) ARP to obtain the L2 address associated new L3 address. Whether there are 3 cycles of broadcast request / reply or 1 cycle, an active ARP attack introduces traffic, distributed processing and cache poisoning, and delay. Best regards, Erik From owner-zeroconf@merit.edu Tue May 21 12:02:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15779 for ; Tue, 21 May 2002 12:02:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86921912AA; Tue, 21 May 2002 12:02:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 521B8912AC; Tue, 21 May 2002 12:02:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C9D9912AA for ; Tue, 21 May 2002 12:01:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EED555DE55; Tue, 21 May 2002 12:01:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6E76F5DE11 for ; Tue, 21 May 2002 12:01:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4LFDiG02977; Tue, 21 May 2002 08:13:44 -0700 Date: Tue, 21 May 2002 08:13:44 -0700 (PDT) From: Bernard Aboba To: Erik Guttman Cc: zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > ERIK: We should add an applications considerations section to > address this. It is an additional burden on the app. I agree. There *are* issues here -- but they can at least be articulated. > Recommendations: > > - Provide a means for networks to disable use of link-local addresses > for any host that is > > - capable of using routable addresses, and > - not explicitly configured to use link-local addresses. Note that the currently shipping IPv4 LL implementations don't work this way -- LL capability is always available. After some initial concern from customers (who were at first alarmed by the use of the 169.254/16 prefix), there does not seem to be much demand for disabling use of IPv4 LL. So while I do have some concerns about application behavior with LL addresses, I don't think that providing a mechanism to disable it is necessary. > - Explicitly and clearly state in positive terms that all IP-capable > devices, including those using only link-local addresses, MUST > implement security adequate to protect the device's resources > those resources to which the device has access, and the network. Sure, but keep in mind that this is an unfunded mandate. > ERIK: This protocol is already being used in non-ad hoc networks. > You are suggesting an applicablity statement which ignores > the primary use of the protocol - namely unadministered > local networking which works irrespective of which DHCP > server comes up, and even if several do, without coordination. > (!) Yes, this isn't just about adhoc. If it were, then we wouldn't have needed to do this work in the first place. From owner-zeroconf@merit.edu Tue May 21 14:42:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23910 for ; Tue, 21 May 2002 14:42:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 785EC9123C; Tue, 21 May 2002 14:42:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 483C39123D; Tue, 21 May 2002 14:42:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 012A49123C for ; Tue, 21 May 2002 14:42:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F18C85DE23; Tue, 21 May 2002 14:42:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 7DE4E5DE04 for ; Tue, 21 May 2002 14:42:29 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4LIgPl26042; Tue, 21 May 2002 14:42:25 -0400 (EDT) Message-Id: <200205211842.g4LIgPl26042@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: zeroconf@merit.edu, cheshire@apple.com, aboba@internaut.com, narten@us.ibm.com, erik.nordmark@sun.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-reply-to: (Your message of "Tue, 21 May 2002 06:13:22 PDT.") Date: Tue, 21 May 2002 14:42:25 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk [am cc'ing the ADs on my reply] > Date: Tue, 21 May 2002 06:13:22 -0700 (PDT) > From: Erik Guttman > To: zeroconf@merit.edu > Cc: Erik Guttman , cheshire@apple.com, > aboba@internaut.com, iesg@ietf.org > Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) > > > Keith, > > Thanks for your clear review. I have suggestions which I think will > satisfy your concerns and give us a path forward. I appreciate your > constructive effort to ensure this protocol meets the needs of a > diverse set of end-users. The challenges we face here is to supply > something simple enough for consumer appliances but safe enough to be > used on devices connected to any network. And thanks for your thoughtful response. Unfortunately there's still a significant gap here. I don't think the current protocol yet meets the challenge you cite - in its current form it's neither sufficiently versatile for consumer appliances nor safe enough to be used full-time on arbitrary devices. And I still don't think those challenges can be met with mere wording changes to the current document, or even with API changes - protocol changes are necessary. I would like to make clear that I do share that goal - I just don't think the current draft meets that goal. > ------------------------------------------------------------------------------ > Issue 1: This protocol will break distributed applications. > > > Each component of the distributed application also needs to be able to > send its address+port to other components. This is a common and > reasonable thing to do - FTP has long allowed it for third-party > mediated transfers, SIP does it for call setup, Gnutella does it to > inform third parties about the locations of files, distributed > computing and cluster computing applications (Globus, Legion, > NetSolve, PVM, Condor, etc.) do it to allow components to spawn new > components on other hosts which communicate with other components that > are already part of the application. > > Now here's the problem: If a component starts operation when the local > network is in a disconnected state, it will only learn of the > link-local address(es) of its host. If it advertises those addresses > to other components, and the network subsequently transitions to a > connected state, those addresses are likely to propgate to components > for which they are not usable. This applies to both "smart" > applications that explicitly select their source addresses, and "dumb" > applications that simply use whatever source address they are bound > to. > > ERIK: We should add an applications considerations section to > address this. It is an additional burden on the app. Additional text would help. In general application developers need to be made aware of the consequences of scoped addresses for their applications (and IMHO we should really discourage their use except in corner cases because there's no easy way for applications to fix the problems they cause) This is a larger architectural issue than just this draft - one that needs to be sorted out in the community, probably with IAB assistance. But it would help if this document at least mentioned these issues. However I do not think it's reasonable for linklocal to break existing applications if there's no way for the network to disable it. What is being proposed is to update every Internet host to support this, amounting to a fundamental change in the architecture of the v4 Internet. As such it needs to avoid breaking things as much as possible. > - that in lists of interface addresses obtained from the OS that > link-local addresses either be hidden, or distinguished from other > addresses in a way that makes "smart" applications unlikely to choose > those local addresses as source addresses. > > ERIK: Such an interface which hides details of address changes would > be much higher level than a socket interface - a kind of session > API. I doubt whether we could really complete such an effort in > the IETF, though some such has been proposed in IPng. I wasn't proposing an interface that hides details of address changes - actually I consider such proposals completely infeasible. By "smart" applications I was merely referring to apps that choose which local address to bind to a socket. These apps will break if they choose a link local address where a routable address is needed, or if the link local address is changed. > ------------------------------------------------------------------------------ > Issue 4: The document (still) makes misleading claims about security > > Section 2.8 is still misleading. In part, it reads: > > communicate only with other local devices, and this allows them to > ------------------- > produce cost-effective devices by implementing a degree of security > ------------------------------------------------------------------- > appropriate for that expected environment. > ----------------------------------------- > > The underlined portion can be read either as a (bogus) assumption > by the designers of such devices, or as a statement that use of > link-local addresses really does provide some security. > > ERIK: This text should be replaced with wording that security > cannot be assumed on the link in all situations by the > protocol designers. It would be better to say "cannot be assumed at all". or merely "cannot be assumed". Let's be as clear about this as possible. > Operators of course can make use of > private links but that is distinct from what the protocol > implementors and app implementors can assume. > > As ARP is insecure, too, we should mention that for security, > (for authenticating the communicating endpoint) a higher > layer protocol is needed - ie. ipsec, tls, s/mime, etc. > > ------------------------------------------------------------------------------ > Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols) > > it would be far better to simply say that link-local addresses SHOULD > NOT be used in DNS and/or that mechanisms specifying link-local > addresses in DNS are currently undefined and for further study. > > ERIK: The use of link-local addresses in the DNS is not currently > specified by any document except some in discussion in the > DNSEXT working group. What you are proposing is an additional > for ZEROCONF name resolution protocols. How so? I don't see this as proposing any additional work - I see it as removing the impression that the current draft gives that DNS is somehow suitable for advertising link local addresses. It's just not a good fit. Yes, additional work is needed to make link local devices accessible by name, but we knew that anyway. > I agree that we should call attention > to the difficulty of keeping link-local address to name mapping > in the DNS consistent with the actual state of the network. > Given addr autoconf, address assignments will change dynamicly. > If autoconf addresses in A, AAAA, etc. RRs can be obtained from > the DNS, secure dynamic update would be required, right? What would be the point? If the device can be configured to do secure dynamic update, surely it could more easily be configured with a static IP address. > ------------------------------------------------------------------------------ > Issue 6: Hosts that have multiple interfaces > > It's hard to see how to fix this. IP is designed with the assumption > that a host or service can be identified with sufficient precision > (for the purpose of establishing a connection to that host) simply by > specifying the host's or service's address and the port number of the > service. And defending the addresses between separate links seems > undesirable. > > ERIK: Options > - Use on only 1 link at a time. > - Defend all addresses (that one has in one's cache?) on all > connected links. > - Propose an interface indexed socket interface that is also > exposed by service discovery. That way, every time an address > is selected, it will be explicitely destined for an unambiguous > interface. > discovery: find a service, get its address and interface id. > bind: bind to an address and interface id. One would > have to bind to each interface, or ANY. > recvfrom: would indicate the source addr and incoming inter- > face. > sendto: would indicate the dest addr and outgoing interface. > connect: would take dest addr and outgoing interface. > gethostbyname() would indicate the interface for each addr in > the hostent. > This work has already been done for the IPv6 API. In fact, we > could leverage this - by specifying that the behavior > of these interfaces for IPv6 mapped IPv4 addresses in the LL > range is ---. Leveraging the v6 interface work doesn't solve the problem. First, because essentially every single app in existence expects that an IP address (without an interface identifier) is sufficiently precise to be able to identify a destination host. (the only exceptions that come to mind are diagnostic apps like ping, traceroute, tcpdump). Requiring apps to explicitly choose which network interface to use in order to reach a device that only has a link local address basically means that such devices can only reliably be reached from special-purpose apps - or that by Second, you are talking about changes to the v4 interface that will break apps. v6 has always supported link local addresses, so apps written for v6 have to deal with that interface. The same isn't true for v4 apps. Third, some of the API changes you are proposing would have far reaching effects, which are far beyond the ability of this group to consider. IMHO this problem illustrates a fundamental limit to the applicability of link local addresses. They are useful in ad hoc networks, or for initial configuration. But they are not a good general-purpose IP address configuration mechanism, not even for simple devices, because those addresses are only accessible from the local link, and this makes unwarranted assumptions about how the customer has configured his network and hosts - or alternately, this imposes undesirable constraints on how the customer must configure his network and hosts in order to use such devices. And even assuming the network is configured acceptably, devices that require link-local addresses may require special-purpose apps. > > ------------------------------------------------------------------------------ > Recommendations: > > - Provide a means for networks to disable use of link-local addresses > for any host that is > > - capable of using routable addresses, and > - not explicitly configured to use link-local addresses. > > ERIK: I disagree with Keith here. v4 LL autoconfiguration has been > present in networks for four years. The DHCP option to 'turn > off' autoconfiguration has never been implemented and no vendor > I know of has the intention of doing so. As long as the other > problems above (notably the multihomed autoconfiguration problem) > is addressed, this extreme restriction *against current practice > of the most popular client platforms* cannot be defended. Perhaps I simply misunderstand the current draft, because it seems to say that DHCP can effectively be used to "turn off" autoconfiguration: From section A.1 (MacOS 8.x and 9.x) "Once a new lease is obtained, [from DHCP] Mac OS will not allocate further connections using the autoconfigured IP address. From section A.2 (Windows 98/98SE) "Once a new lease is obtained, [from DHCP] Windows 98/98SE will not allocate further connections using the autoconfigured IP address." And I read A.3 as saying that Windows 2000 and ME have the same behavior except that the latter two have media sense. In effect, this seems to provide a way for network administrators to "turn off" use of link local addresses merely by supporting DHCP (or by configuring their hosts with static addresses). It's reasonable to assume, then, that for the vast majority of operational networks, link-local addresses are NOT currently in use, and therefore the experience from existing implementations is NOT a useful indicator of the safety of using link-local addresses as proposed in this document. So I stand by my recommendation - we need a way for networks to disable this. And we also need to clearly state that link local addresses are not a general-purpose address configuration mechanism. Devices that implement only link-local addressing may not be usable in existing networks. > - Also, I wonder if this protocol be considered only applicable for > use in ad hoc networks - in particular that it SHOULD NOT be > considered a substitute for DHCP even for limited-function devices - > > ERIK: This protocol is already being used in non-ad hoc networks. how so? according to the document, with existing implementations, if a DHCP server responds, the link local addresses stop working. presumably link local addresses aren't used either if there is a statically configured address. how many non-ad hoc networks don't use either DHCP, or static configuration, and don't have any Win98/ME/2000 or MacOS8/9 hosts? I wrote a script to ping every possible link-local address in my local subnet, which consists of several hundred machines running various operating systems, including several that are claimed to support link-local addresses. So far it's 25% through the address space, and not a single machine has answered. So I am unconvinced that the protocol is already being used in the way you say it is. > You are suggesting an applicablity statement which ignores > the primary use of the protocol - namely unadministered > local networking which works irrespective of which DHCP > server comes up, and even if several do, without coordination. > (!) I'm suggesting an applicability statement that recognizes the inherent limitations of the protocol. Yes, it may turn out that the protocol isn't as universally applicable as was hoped, or that it may require slightly more work and/or burden on hosts in order to make it generally applicable. But if that's reality, we need to recognize it. link-local addresses might sometimes be useful for maintenance/diagnostic purposes in cases where there are unauthorized or incorrectly configured DHCP servers. I don't claim that they're not useful, I only claim that they're not useful as general-purpose IP addresses (even for devices that you only want to be locally-accessible), and that the current draft doesn't specify enough to keep them from causing harm to applications or from introducing another means of denial-of-service attack. > - Beyond the suggestions I made above, I'm not sure how to keep > link-local addresses from breaking distributed applications. > But I think the potential can be minimized by only using > link-local addresses on ad hoc networks or on hosts that are > explicitly configured to use them, and with some of the other > suggestions I made. > > ERIK: I agree an application considerations section should be added. > There are issues which need to be presented. None are insoluble. > The local address may change. Applications will need to detect > this event and rebind or reconnect their sockets, etc. The > remote address may change. Applications will need to perform > service discovery in this case, to determine their peers new > location. Multihomed hosts need to present the interface in > the networking API if more than one interface exposes link local > addresses (probably). All of these issues need to be discussed > but none of them are showstoppers. none of them are general solutions either. at best they make link-local addresses special-purpose tools that are only useful in specific, fairly limited circumstances. there's nothing wrong with that, but the current draft implies that link local addresses are useful for simple devices that want net access. IMHO that's overselling them. Keith From owner-zeroconf@merit.edu Tue May 21 21:58:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10936 for ; Tue, 21 May 2002 21:58:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0996491217; Tue, 21 May 2002 21:58:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C77939121C; Tue, 21 May 2002 21:58:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C576B91217 for ; Tue, 21 May 2002 21:58:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD2485DE88; Tue, 21 May 2002 21:58:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 74D355DE79 for ; Tue, 21 May 2002 21:58:13 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4M1w7l28720; Tue, 21 May 2002 21:58:07 -0400 (EDT) Message-Id: <200205220158.g4M1w7l28720@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Erik Guttman , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-reply-to: (Your message of "Tue, 21 May 2002 08:13:44 PDT.") Date: Tue, 21 May 2002 21:58:07 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > ERIK: We should add an applications considerations section to > > address this. It is an additional burden on the app. > > I agree. There *are* issues here -- but they can at least be articulated. > > > Recommendations: > > > > - Provide a means for networks to disable use of link-local addresses > > for any host that is > > > > - capable of using routable addresses, and > > - not explicitly configured to use link-local addresses. > > Note that the currently shipping IPv4 LL implementations don't work this > way -- LL capability is always available. then please explain why, if on a win2k box I try to ping a 169.254/16 address, the box doesn't arp for that IP address on the link, but instead immediately sends a packet with the link-layer destination address set to the link-layer address of the default router? and also why not one single host in my network (including win2k and winxp hosts) responds to a ping for any address in 169.254/16? > After some initial concern from > customers (who were at first alarmed by the use of the 169.254/16 prefix), > there does not seem to be much demand for disabling use of IPv4 LL. maybe those customers aren't running distributed apps, or maybe the LL isn't enabled for some other reason (just as on my network) > > - Explicitly and clearly state in positive terms that all IP-capable > > devices, including those using only link-local addresses, MUST > > implement security adequate to protect the device's resources > > those resources to which the device has access, and the network. > > Sure, but keep in mind that this is an unfunded mandate. also keep in mind that secure hosts are cheaper than security holes. Keith From owner-zeroconf@merit.edu Wed May 22 00:05:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16100 for ; Wed, 22 May 2002 00:05:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFE47912AD; Wed, 22 May 2002 00:05:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86F7A912B1; Wed, 22 May 2002 00:05:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64EF1912AD for ; Wed, 22 May 2002 00:03:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 324ED5DE8B; Wed, 22 May 2002 00:03:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A50AA5DE82 for ; Wed, 22 May 2002 00:03:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4M3Fmg10582; Tue, 21 May 2002 20:15:48 -0700 Date: Tue, 21 May 2002 20:15:48 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: Erik Guttman , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-Reply-To: <200205220158.g4M1w7l28720@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > then please explain why, if on a win2k box I try to ping a 169.254/16 > address, the box doesn't arp for that IP address on the link, but > instead immediately sends a packet with the link-layer destination > address set to the link-layer address of the default router? I didn't say that the interface always has a linklocal address. If you read the Appendix of the draft, it describes how Windows and Mac OS 9.1 systems function. The point is that the behavior described in that Appendix can't be turned off. > > After some initial concern from > > customers (who were at first alarmed by the use of the 169.254/16 prefix), > > there does not seem to be much demand for disabling use of IPv4 LL. > > maybe those customers aren't running distributed apps, or maybe > the LL isn't enabled for some other reason (just as on my network) The LL address is indeed not enabled unless the DHCP server doesn't respond, as described in the Appendix. > > Sure, but keep in mind that this is an unfunded mandate. > > also keep in mind that secure hosts are cheaper than security holes. Not actionable, unless it is described exactly *how* those hosts should be secured on a small home network. From owner-zeroconf@merit.edu Wed May 22 00:29:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16430 for ; Wed, 22 May 2002 00:29:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAE6A9123E; Wed, 22 May 2002 00:29:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2A4E912B1; Wed, 22 May 2002 00:29:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A46199123E for ; Wed, 22 May 2002 00:29:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E93B5DE8C; Wed, 22 May 2002 00:29:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 259475DE8B for ; Wed, 22 May 2002 00:29:06 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4M4T5l29433; Wed, 22 May 2002 00:29:05 -0400 (EDT) Message-Id: <200205220429.g4M4T5l29433@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , Erik Guttman , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-reply-to: (Your message of "Tue, 21 May 2002 20:15:48 PDT.") Date: Wed, 22 May 2002 00:29:05 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > then please explain why, if on a win2k box I try to ping a 169.254/16 > > address, the box doesn't arp for that IP address on the link, but > > instead immediately sends a packet with the link-layer destination > > address set to the link-layer address of the default router? > > I didn't say that the interface always has a linklocal address. If you > read the Appendix of the draft, it describes how Windows and Mac OS 9.1 > systems function. The point is that the behavior described in that > Appendix can't be turned off. as I read the Appendix, link local addressing *can* be turned off for existing implementations - merely by arranging for DHCP requests to be answered. which means that in most of today's nontrivially sized networks link local addressing is turned off "by default". what am I missing? > > > Sure, but keep in mind that this is an unfunded mandate. > > > > also keep in mind that secure hosts are cheaper than security holes. > > Not actionable, unless it is described exactly *how* those hosts should be > secured on a small home network. there's no such thing as a one-size-fits-all security solution, because different hosts have different kinds of resources to protect, different threat models, different models for who can use them. that doesn't mean that such hosts can't be secured with a reasonable amount of effort and expense, it just means that it's infeasible to describe exactly how it should be done for all cases. Keith From owner-zeroconf@merit.edu Wed May 22 04:09:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16846 for ; Wed, 22 May 2002 04:09:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0289F91224; Wed, 22 May 2002 04:09:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C293591241; Wed, 22 May 2002 04:09:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC5E291224 for ; Wed, 22 May 2002 04:09:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 964735DE3D; Wed, 22 May 2002 04:09:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 3911C5DE32 for ; Wed, 22 May 2002 04:09:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02795; Wed, 22 May 2002 01:09:19 -0700 (PDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4M89Bb25670; Wed, 22 May 2002 10:09:11 +0200 (MEST) Date: Wed, 22 May 2002 01:09:07 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: zeroconf@merit.edu Cc: Erik Guttman , aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com Subject: Security issues in zeroconf-v4-linklocal-05 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, Bernard, > Keith wrote: > > Issue 4: The document (still) makes misleading claims about security > > Section 2.8 is still misleading. In part, it reads: > > > > communicate only with other local devices, and this allows them to > > ------------------- > > produce cost-effective devices by implementing a degree of security > > ------------------------------------------------------------------- > > appropriate for that expected environment. > > ----------------------------------------- > > > > ERIK: This text should be replaced with wording that security > > cannot be assumed on the link in all situations by the > > protocol designers. > > It would be better to say "cannot be assumed at all". > or merely "cannot be assumed". Let's be as clear about this as possible. I understand where you want to go with this and I believe it goes too far. A vendor creates a closed box with a single link (a bus) upon which v4LL autoconf is performed, and no other device except that supplied by the vendor will ever be attached. Why can't the vendor assume security? This is not a rhetorical argument. One of the goals of the v4LL work is to enable bus behavior without the creation of ever more non-IP solutions. If a particular link is secured with L2 security, why can't one then assume v4LL can be used securely? --------------------------------------------------------------------------- (I am resorting to dramatic dialog format for easy reading). Erik: Explicitly and clearly state in positive terms that all IP-capable devices, including those using only link-local addresses, MUST implement security adequate to protect the device's resources those resources to which the device has access, and the network. Bernard: Sure, but keep in mind that this is an unfunded mandate. Keith: also keep in mind that secure hosts are cheaper than security holes. Bernard: Not actionable, unless it is described exactly *how* those hosts should be secured on a small home network. Keith: there's no such thing as a one-size-fits-all security solution, because different hosts have different kinds of resources to protect, different threat models, different models for who can use them. that doesn't mean that such hosts can't be secured with a reasonable amount of effort and expense, it just means that it's infeasible to describe exactly how it should be done for all cases. Erik: OK. Let us delineate enough of a threat and of a use model that we can write a security consideration section which will inform vendors how to create secure equipment. Threat model: redirected and disrupted communication through injection of ARP ARP is insecure. A 'classic' ARP attack either redirects traffic to a new L2 address or simply disrupts communication. Eventually, the transport layer will require the L3 to L2 address resolution be repeated. The attacker can subvert this, too. Keith pointed out that an ARP attack against v4LL autoconf will do this and in addition require a new round of claim and defend. I claim that this is the same kind of attack, though a bit more severe (more time and packets involved). (1) a new address must be allocated (if the attacker allows this at all), (2) service discovery or multicast based name to address resolution must be used to find the new L3 address, (3) ARP must be used to find the new L2 address. Each require one or more broadcast (or link-local multicast) and one unicast (or broadcast, in the case of v4LL autoconf) reply. Exactly as in the classic ARP attack, an attacker can subvert communication totally through injection of ARP packets. The only difference is that instead of a repeated cycle of subversion / ARP resolution / subversion, there is a repeated cycle of subversion / claim & defend, discovery, ARP resolution / subversion. Conclusion: This protocol does not secure ARP. The same vulnerabilities exist for it and ARP. We do not tell vendors not to use ARP today. Therefore, it is unreasonable for the IETF to tell them not to use v4LL autoconfiguration. The risk (social, economic) of subverted networks increases if networks become more pervasive. This could occur if we are successful with this standard. I believe this is Keith's real concern. I agree we need to be very clear to both vendors and users what the risks are and also how they can be countered. Countering this threat model: Vendors should create products which can secure their use of the link layer. For example: - authenticating wireless access and allowing devices to operate in a mode where L2 authentication is possible - all networked components are attached in a sealed box Vendors who produce devices which are used in environments where a secured link layer is not necessarily available should: - enable higher layer authentication so that at the very least, redirected traffic can be detected and a user warned and communication halted. Use model: shared access media (wireless being an important example) - Users should be aware that use of v4LL autoconf without link-layer authentication is dangerous. Users should demand that wireless appliance products include link-layer authentication capabilities. Users should enable these features, which will likely require configuration. 'Be sure to read and follow safety instructions before plugging in the device.' unshared link (a bus in a sealed box being an important example) - Users should be aware that use of v4LL autoconf in some devices is secure to the extent that the device is used as the vendor intended. For instance, a car may use IP for internal communication, with no authentication. If the user connects such a device to a shared access medium, this will expose the device to attack - the most trivial of which disables communication in the device. 'Use only as directed.' This technology is present in the market place *without* guidance (to vendors and users, from the IETF) about how to use it safely. Erik From owner-zeroconf@merit.edu Wed May 22 09:01:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29339 for ; Wed, 22 May 2002 09:01:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49E7691247; Wed, 22 May 2002 09:00:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1585E912B6; Wed, 22 May 2002 09:00:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEF0691247 for ; Wed, 22 May 2002 09:00:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6511B5DE53; Wed, 22 May 2002 09:00:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2F0635DE32 for ; Wed, 22 May 2002 09:00:49 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4MD0ml18718; Wed, 22 May 2002 09:00:48 -0400 (EDT) Message-Id: <200205221300.g4MD0ml18718@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com Subject: Re: Security issues in zeroconf-v4-linklocal-05 In-reply-to: (Your message of "Wed, 22 May 2002 01:09:07 PDT.") Date: Wed, 22 May 2002 09:00:48 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > Keith wrote: > > > Issue 4: The document (still) makes misleading claims about security > > > Section 2.8 is still misleading. In part, it reads: > > > > > > communicate only with other local devices, and this allows them to > > > ------------------- > > > produce cost-effective devices by implementing a degree of security > > > ------------------------------------------------------------------- > > > appropriate for that expected environment. > > > ----------------------------------------- > > > > > > ERIK: This text should be replaced with wording that security > > > cannot be assumed on the link in all situations by the > > > protocol designers. > > > > It would be better to say "cannot be assumed at all". > > or merely "cannot be assumed". Let's be as clear about this as possible. > > I understand where you want to go with this and I believe it goes > too far. > > A vendor creates a closed box with a single link (a bus) upon which > v4LL autoconf is performed, and no other device except that supplied > by the vendor will ever be attached. Why can't the vendor assume > security? This is not a rhetorical argument. One of the goals of > the v4LL work is to enable bus behavior without the creation of ever > more non-IP solutions. > > If a particular link is secured with L2 security, why can't one then > assume v4LL can be used securely? Okay, *if* you have a point-to-point link layer (with only two possible attachment points) which is known to be *inherently* secure (certainly not true of any of the wireless technologies in use today) then it *might* be reasonable for the device to not implement security. Even then it's not axiomatically so - because it still leaves the possibliity that the device can be compromsied by the other host on that point-to-point link and if the device is then plugged into another network, it can compromise other hosts. It's a complicated world, it's very difficult to make reliable assurances about security, and most vendors/implementors (and for that matter most customers/users) don't do good threat analysis. But we shouldn't imply that that's okay :) So while "cannot be assumed at all" may be a tad bit too restrictive, "cannot be assumed in all situations" is really misleading. "can almost never be assumed" is as close as I know how to say it. > Threat model: > > redirected and disrupted communication through injection of ARP > > ARP is insecure. A 'classic' ARP attack either redirects > traffic to a new L2 address or simply disrupts communication. > Eventually, the transport layer will require the L3 to L2 > address resolution be repeated. The attacker can subvert > this, too. > > Keith pointed out that an ARP attack against v4LL autoconf > will do this and in addition require a new round of claim > and defend. > > I claim that this is the same kind of attack, though a bit > more severe (more time and packets involved). I agree that the difference is one of degree. I don't think this is a showstopper with the link-local protocol - I'm reasonably sure you can't have zero-knowlege address configuration and security at the same time anyway. But the problem does need to be documented in the security considerations section, and (for this and other reasons) there does need to be a way for networks to disable devices' use of link-local addressing (which itself introduces a security issue that needs to be documented). > We do not tell vendors not to use ARP today. Therefore, > it is unreasonable for the IETF to tell them not to use > v4LL autoconfiguration. no, and I didn't propose that we do so. > Countering this threat model: > > Vendors should create products which can secure their use of > the link layer. For example: > > - authenticating wireless access and allowing devices > to operate in a mode where L2 authentication is possible I'd be reluctant to recommend L2 authentication as a possible remedy, if for no other reason because many L2 authentication methods have known flaws (e.g. WEP). also, authenticating the device is not sufficient (even when it can be done reliably) if the device can be compromised. It's very difficult to make safe general statements about what security measures will work. > Use model: > > shared access media (wireless being an important example) > > - Users should be aware that use of v4LL autoconf without > link-layer authentication is dangerous. and probably *with* LL authenticaiton as well... > Users should > demand that wireless appliance products include > link-layer authentication capabilities. Users should > enable these features, which will likely require > configuration. which would largely defeat the purpose of autoconfiguration. but this might also have implications for the applicability of address autoconfiguration > This technology is present in the market place *without* guidance > (to vendors and users, from the IETF) about how to use it safely. indeed. though at least IETF is trying - not that many users read the security considerations sections of RFCs. Keith From owner-zeroconf@merit.edu Wed May 22 10:03:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02987 for ; Wed, 22 May 2002 10:03:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 261DD91229; Wed, 22 May 2002 10:03:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E21DD91249; Wed, 22 May 2002 10:03:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6D9E91229 for ; Wed, 22 May 2002 10:03:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 900E05DDA8; Wed, 22 May 2002 10:03:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 6D3035DD9A for ; Wed, 22 May 2002 10:03:01 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id C4DEA67103; Wed, 22 May 2002 10:34:55 -0400 (EDT) Date: Wed, 22 May 2002 10:03:01 -0400 Subject: Re: Security issues in zeroconf-v4-linklocal-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com To: Erik Guttman From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think the entire "security issue" assertion here is quite overblown and makes unreasonable demands on ZeroConf. I'm not sure why folks dander has been raised on that thread lately, but it seems quite misplaced. Ran rja@extremenetworks.com From owner-zeroconf@merit.edu Wed May 22 11:04:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06767 for ; Wed, 22 May 2002 11:04:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C9FD9121F; Wed, 22 May 2002 11:04:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4666B9124C; Wed, 22 May 2002 11:04:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 382549121F for ; Wed, 22 May 2002 11:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0886E5DE56; Wed, 22 May 2002 11:04:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 8DD3C5DE1C for ; Wed, 22 May 2002 11:04:25 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4MF4Fl05000; Wed, 22 May 2002 11:04:16 -0400 (EDT) Message-Id: <200205221504.g4MF4Fl05000@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Erik Guttman , zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com Subject: Re: Security issues in zeroconf-v4-linklocal-05 In-reply-to: (Your message of "Wed, 22 May 2002 10:03:01 EDT.") Date: Wed, 22 May 2002 11:04:15 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I think the entire "security issue" assertion here is quite > overblown and makes unreasonable demands on ZeroConf. I haven't seen anyone claiming that zeroconf needs to be made secure. I have recommended, and others have agreed, that - the security risks presented by zeroconf need to be documented, and - zeroconf should not claim that it *provides* any level of security, or that it removes any need for a device to provide security. Keith From owner-zeroconf@merit.edu Wed May 22 11:09:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07527 for ; Wed, 22 May 2002 11:09:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 711E9912BF; Wed, 22 May 2002 11:07:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44BC5912C7; Wed, 22 May 2002 11:07:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB6B7912BF for ; Wed, 22 May 2002 11:07:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD5945DE56; Wed, 22 May 2002 11:07:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 7A29E5DE1C for ; Wed, 22 May 2002 11:07:48 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01722; Wed, 22 May 2002 09:07:33 -0600 (MDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4MF7Ub11612; Wed, 22 May 2002 17:07:30 +0200 (MEST) Date: Wed, 22 May 2002 08:07:26 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: Keith Moore Cc: Erik Guttman , zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com Subject: Re: Security issues in zeroconf-v4-linklocal-05 In-Reply-To: <200205221300.g4MD0ml18718@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, To help make progress - I mark actions we've agreed on with ACTION and remaining disagreements with ISSUE. --------------------------------------------------------------- On Wed, 22 May 2002, Keith Moore wrote: > > A vendor creates a closed box with a single link (a bus) ... > > > > If a particular link is secured with L2 security, why can't one > > then assume v4LL can be used securely? > > Okay, *if* you have a point-to-point link layer (with only two possible > attachment points) which is known to be *inherently* secure (certainly > not true of any of the wireless technologies in use today) then it *might* > be reasonable for the device to not implement security. A shared access medium in an unopenable container is secure to the extent the container remains unopened. > Even then it's > not axiomatically so - because it still leaves the possibliity that the > device can be compromsied by the other host on that point-to-point link > and if the device is then plugged into another network, it can compromise > other hosts. There is no requirement or expectation of byzantine robustness for standards track protocols. If a device is multihomed, one interface in a secured (physically or using L2 authentication), there is the risk that it could become compromised, and then compromise the network. If we were to require that hosts (and routers) be uncompromisable before standardizing protocol, we would have to stop most of the work at the IETF. > It's a complicated world, it's very difficult to make > reliable assurances about security, and most vendors/implementors > (and for that matter most customers/users) don't do good threat analysis. > But we shouldn't imply that that's okay :) I agree. We have to explain the risks. > So while "cannot be assumed at all" may be a tad bit too restrictive, > "cannot be assumed in all situations" is really misleading. > "can almost never be assumed" is as close as I know how to say it. Let's get concrete. 'this allows them to produce cost-effective devices by implementing a degree of security appropriate for that expected environment.' Add: 'Implementors are advised that unless it is *impossible* to connect a device to a shared access medium, it is likely that it will be used in environments in which it is exposed to attack. For example, a bus used inside a factory-sealed container might be an appropriate environment for attached components to use link-layer autoconfiguration without concern for attack.' ISSUE: Is this sufficient? (If not, please suggest an alternative.) --------------------------------------------------------------- > > Threat model: > > > > redirected and disrupted communication through injection of ARP > > ARP is insecure. A 'classic' ARP attack either redirects [snip] > > I claim that this is the same kind of attack, though a bit > > more severe (more time and packets involved). > > I agree that the difference is one of degree. I don't think this is > a showstopper with the link-local protocol - I'm reasonably sure you > can't have zero-knowlege address configuration and security at the > same time anyway. But the problem does need to be documented in > the security considerations section, ACTION: Add text to address this point. --------------------------------------------------------------- > and (for this and other reasons) > there does need to be a way for networks to disable devices' use of > link-local addressing (which itself introduces a security issue > that needs to be documented). If we follow your argument ad absurdum we need a mechanism for networks to disable ARP :-) We need to discuss the 'way to disable' in a separate thread. For now let's note that we disagree. ISSUE: Keith argues for a mechanism to disable device's use of link-local addressing. What are the grounds (*apart from* ARP-derived security issues)? --------------------------------------------------------------- > > Countering this threat model: > > > > Vendors should create products which can secure their use of > > the link layer. For example: > > > > - authenticating wireless access and allowing devices > > to operate in a mode where L2 authentication is possible > > I'd be reluctant to recommend L2 authentication as a possible > remedy, if for no other reason because many L2 authentication > methods have known flaws (e.g. WEP). WEP has a bad rep because it is *actually deployed and used.* The same has happened with some cryptography suites used in GSM. The flaws are being addressed: They are not architectural problems with L2 security per se, rather with individual algorithms. Wouldn't it be great if IETF security protocols were widely used enough that had something to be embarrased about and fix :-) > also, authenticating > the device is not sufficient (even when it can be done reliably) > if the device can be compromised. We can't prevent devices from being compromised. Nor are you, I believe, claiming that v4LL authentication increases this risk. ISSUE: Keith disagrees that L2 authentication is sufficient (enough) to secure v4LL autoconfiguration that it (should) be mentioned as a remedy to ARP related threats. --------------------------------------------------------------- > It's very difficult to make safe general statements about what > security measures will work. > > > Use model: > > > > shared access media (wireless being an important example) > > > > - Users should be aware that use of v4LL autoconf without > > link-layer authentication is dangerous. > > and probably *with* LL authenticaiton as well... Bernard? > > Users should > > demand that wireless appliance products include > > link-layer authentication capabilities. Users should > > enable these features, which will likely require > > configuration. > > which would largely defeat the purpose of autoconfiguration. I believe Aidan Williams and Steve Hanna have initiated work on easily configured security parameters. I support efforts in this direction. ACTION: Describe use model in shared and closed-access media. Admonish vendors and users. Erik From owner-zeroconf@merit.edu Wed May 22 11:23:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09790 for ; Wed, 22 May 2002 11:23:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7D492913A7; Wed, 22 May 2002 11:22:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4402E913B8; Wed, 22 May 2002 11:22:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25AD2913A7 for ; Wed, 22 May 2002 11:22:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFC5F5DE61; Wed, 22 May 2002 11:22:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id A27845DE1C for ; Wed, 22 May 2002 11:22:27 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13914; Wed, 22 May 2002 08:22:28 -0700 (PDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4MFMPb12180; Wed, 22 May 2002 17:22:26 +0200 (MEST) Date: Wed, 22 May 2002 08:22:21 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: Keith Moore Cc: Bernard Aboba , Erik Guttman , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-Reply-To: <200205220429.g4M4T5l29433@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 22 May 2002, Keith Moore wrote: > > I didn't say that the interface always has a linklocal address. If you > > read the Appendix of the draft, it describes how Windows and Mac OS 9.1 > > systems function. The point is that the behavior described in that > > Appendix can't be turned off. > > as I read the Appendix, link local addressing *can* be turned off > for existing implementations - merely by arranging for DHCP requests > to be answered. which means that in most of today's nontrivially > sized networks link local addressing is turned off "by default". > > what am I missing? Though Windows and Mac OS (older versions) turned off link-local configuration when DHCP service became available, there is no requirement that they do so in the document. Later versions of Mac OS 9 and Mac OS X *do not* turn off link-local address configuration in this case. Erik From owner-zeroconf@merit.edu Wed May 22 12:08:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15293 for ; Wed, 22 May 2002 12:08:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D6BB912C4; Wed, 22 May 2002 12:07:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DD4C9131F; Wed, 22 May 2002 12:07:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73181912C4 for ; Wed, 22 May 2002 12:07:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A7D05DE61; Wed, 22 May 2002 12:07:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 06CEF5DE5F for ; Wed, 22 May 2002 12:07:01 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18848; Wed, 22 May 2002 10:07:38 -0600 (MDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4MG6pb14105; Wed, 22 May 2002 18:06:51 +0200 (MEST) Date: Wed, 22 May 2002 09:06:46 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: Keith Moore Cc: Erik Guttman , zeroconf@merit.edu, cheshire@apple.com, aboba@internaut.com, narten@us.ibm.com, erik.nordmark@sun.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-Reply-To: <200205211842.g4LIgPl26042@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, To follow up on non-security issues on this thread: ACTION suggests a remedy we can agree on. ISSUE suggest an action to take to come to agreement. On Tue, 21 May 2002, Keith Moore wrote: > > ------------------------------------------------------------------------------ > > Issue 1: This protocol will break distributed applications. > > > > > > Each component of the distributed application also needs to be able to > > send its address+port to other components. This is a common and > > reasonable thing to do [snip] > > Now here's the problem: If a component starts operation when the local > > network is in a disconnected state, it will only learn of the > > link-local address(es) of its host. If it advertises those addresses > > to other components, and the network subsequently transitions to a > > connected state, those addresses are likely to propgate to components > > for which they are not usable. If the component app starts onperation on a local network, how will it register to a host on a non-local network? > However I do not think it's reasonable for linklocal to break existing > applications if there's no way for the network to disable it. What is > being proposed is to update every Internet host to support this, amounting > to a fundamental change in the architecture of the v4 Internet. As such > it needs to avoid breaking things as much as possible. Address reconfiguration events can occur when - a dhcp lease expires and is not renewed - a dhcp reconfigure option is received (assuming its supported) - ipv6 link-local autoconfiguration is used and there is a collision - ipv6 RA indicates a different prefix - ... This problem is not unique to v4 LL autoconfiguration. > > - that in lists of interface addresses obtained from the OS that > > link-local addresses either be hidden, or distinguished from other > > addresses in a way that makes "smart" applications unlikely to choose > > those local addresses as source addresses. > > > > ERIK: Such an interface which hides details of address changes would > > be much higher level than a socket interface - a kind of session > > API. I doubt whether we could really complete such an effort in > > the IETF, though some such has been proposed in IPng. > > I wasn't proposing an interface that hides details of address changes - > actually I consider such proposals completely infeasible. By "smart" > applications I was merely referring to apps that choose which local > address to bind to a socket. These apps will break if they choose a > link local address where a routable address is needed, or if the link > local address is changed. So apps will have to be "really smart" and note the difference between different address scopes, preferring the global range. Its not pretty but we already have magic addresses - like in the multicast range, loopback, etc. ACTION: Admonish programmers not to cache link-local address values in their programs as their local address. Rather, check the *current* address. Further, be prepared for address change errors from relevant (i/o, socket, etc) calls. > > ------------------------------------------------------------------------------ > > Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols) > > > > it would be far better to simply say that link-local addresses SHOULD > > NOT be used in DNS and/or that mechanisms specifying link-local > > addresses in DNS are currently undefined and for further study. > > > > ERIK: The use of link-local addresses in the DNS is not currently > > specified by any document except some in discussion in the > > DNSEXT working group. What you are proposing is an additional > > for ZEROCONF name resolution protocols. > > How so? I don't see this as proposing any additional work - I see it > as removing the impression that the current draft gives that DNS is somehow > suitable for advertising link local addresses. It's just not a good fit. > > Yes, additional work is needed to make link local devices accessible by > name, but we knew that anyway. From draft-ietf-zeroconf-ipv4-linklocal-05.txt: 2.9 Higher-Layer Protocol Considerations For example, DNS Resource Records containing link-local addresses SHOULD NOT be sent to hosts ouside the link to which those link- local addresses apply. ACTION: Change the example to either omit the DNS example or provide a different one. Add text to indicate that storing link-local addresses in the DNS is not well understood or well advised. > > ------------------------------------------------------------------------------ > > Issue 6: Hosts that have multiple interfaces > > > > It's hard to see how to fix this. IP is designed with the assumption > > that a host or service can be identified with sufficient precision > > (for the purpose of establishing a connection to that host) simply by > > specifying the host's or service's address and the port number of the > > service. And defending the addresses between separate links seems > > undesirable. > > > > ERIK: Options > > - Use on only 1 link at a time. > > - Defend all addresses (that one has in one's cache?) on all > > connected links. > > - Propose an interface indexed socket interface that is also > > exposed by service discovery. > Leveraging the v6 interface work doesn't solve the problem. > > First, because essentially every single app in existence expects that > an IP address (without an interface identifier) is sufficiently precise > to be able to identify a destination host. (the only exceptions that > come to mind are diagnostic apps like ping, traceroute, tcpdump). > Requiring apps to explicitly choose which network interface to use in > order to reach a device that only has a link local address basically > means that such devices can only reliably be reached from special-purpose > apps - or that by > > Second, you are talking about changes to the v4 interface that will break > apps. v6 has always supported link local addresses, so apps written for > v6 have to deal with that interface. The same isn't true for v4 apps. > > Third, some of the API changes you are proposing would have far reaching > effects, which are far beyond the ability of this group to consider. Your points are well taken. There are two workable strategies then. 1. Establish that v4LL works for one configured interface. Clarify that if used for more than one it will break existing applications. Or 2. Establish that if a multihomed host uses v4LL on more than one interface it MUST defend all addresses it detects on any v4 auto- configured interface on all its v4 autoconfigured interface. Or 2 could limit the scalability of the v4LL protocol and expose other links to ARP attacks. So maybe we need to specifically limit the applicability of the protocol to a single interface. We should add that if, in the future, additional network APIs are developed to expose (or transparently manage) interface ids, disambiguating addresses, it would be possible to support multiple link-local address autoconfigured interfaces on a host. ISSUE: Add an applicability statement - only single interfaces can be autoconfigured unless the host supports an interface indexed API, and expose the addresses for additional interfaces' addresses only through this new API. > > ------------------------------------------------------------------------------ > Perhaps I simply misunderstand the current draft, because it seems to > say that DHCP can effectively be used to "turn off" autoconfiguration: Some existing implementations do turn off v4LL autoconfiguration, but this is not required. ISSUE: Clarify that this transition is not a requirement. (see below). > In effect, this seems to provide a way for network administrators to > "turn off" use of link local addresses merely by supporting DHCP > (or by configuring their hosts with static addresses). It's reasonable > to assume, then, that for the vast majority of operational networks, > link-local addresses are NOT currently in use, and therefore the > experience from existing implementations is NOT a useful indicator of > the safety of using link-local addresses as proposed in this document. > > So I stand by my recommendation - we need a way for networks to disable > this. And we also need to clearly state that link local addresses are > not a general-purpose address configuration mechanism. Devices that > implement only link-local addressing may not be usable in existing > networks. It is clear you disagree with the authors and me on this point. ISSUE: We need ZEROCONF WG mailing list feedback on this point. Erik From owner-zeroconf@merit.edu Wed May 22 12:08:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15317 for ; Wed, 22 May 2002 12:08:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53FC1912F1; Wed, 22 May 2002 12:08:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F103F91323; Wed, 22 May 2002 12:08:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B597912F1 for ; Wed, 22 May 2002 12:08:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E8D55DE61; Wed, 22 May 2002 12:08:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id C4D9B5DE5F for ; Wed, 22 May 2002 12:08:19 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4MG8Hl13772; Wed, 22 May 2002 12:08:17 -0400 (EDT) Message-Id: <200205221608.g4MG8Hl13772@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , Bernard Aboba , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-reply-to: (Your message of "Wed, 22 May 2002 08:22:21 PDT.") Date: Wed, 22 May 2002 12:08:17 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Though Windows and Mac OS (older versions) turned off link-local > configuration when DHCP service became available, there is no > requirement that they do so in the document. Later versions of > Mac OS 9 and Mac OS X *do not* turn off link-local address > configuration in this case. well, there's a couple of machines on our network running MacOS X, and they didn't respond to link local addresses either. I can only conclude that this is a *very* late change, and that therefore we don't have adequate experience to show that existing practice doesn't break anything. Keith From owner-zeroconf@merit.edu Wed May 22 13:09:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19550 for ; Wed, 22 May 2002 13:09:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5C0F91310; Wed, 22 May 2002 13:09:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88F6B91312; Wed, 22 May 2002 13:09:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97DE091310 for ; Wed, 22 May 2002 13:09:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 101FA5DE97; Wed, 22 May 2002 13:09:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id AECF15DE7D for ; Wed, 22 May 2002 13:09:30 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 266EF67103; Wed, 22 May 2002 13:41:26 -0400 (EDT) Date: Wed, 22 May 2002 13:09:31 -0400 Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Erik Guttman , Bernard Aboba , zeroconf@merit.edu, cheshire@apple.com To: Keith Moore From: RJ Atkinson In-Reply-To: <200205221608.g4MG8Hl13772@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, May 22, 2002, at 12:08 , Keith Moore wrote: >> Though Windows and Mac OS (older versions) turned off link-local >> configuration when DHCP service became available, there is no >> requirement that they do so in the document. Later versions of >> Mac OS 9 and Mac OS X *do not* turn off link-local address >> configuration in this case. > > well, there's a couple of machines on our network running MacOS X, > and they didn't respond to link local addresses either. > > I can only conclude that this is a *very* late change, and that > therefore we don't have adequate experience to show that existing > practice doesn't break anything. Keith, I disagree with a lot of what you are saying above and previously. I'd also suggest that there is not rough consensus behind your positions -- and that the IETF operates on rough consensus rather than unanimity. Please stop trying to unilaterally derail this. Ran From owner-zeroconf@merit.edu Wed May 22 13:36:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21122 for ; Wed, 22 May 2002 13:36:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C9CBE91223; Wed, 22 May 2002 13:36:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9182D9128F; Wed, 22 May 2002 13:36:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1C1791223 for ; Wed, 22 May 2002 13:36:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E21B5DE69; Wed, 22 May 2002 13:36:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 2D2825DDD2 for ; Wed, 22 May 2002 13:36:39 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4MHa7uF016344; Wed, 22 May 2002 10:36:07 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4MHaFab002020; Wed, 22 May 2002 10:36:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20020522132103.018c9008@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 May 2002 13:36:13 -0400 To: Keith Moore From: John Schnizlein Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) Cc: RJ Atkinson , zeroconf@merit.edu In-Reply-To: References: <200205221608.g4MG8Hl13772@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Yeah, Keith. Please get back in line with the rest of us who have realized that this train has left the station. :-) Once we all go quiet they can get on with the Host Requirements for ZeroConfig, neither a superset nor a subset of Internet Host Requirements, but suited to IP networks that are not interconnected. Although I do not understand the motivation, beyond bringing features from AppleTalk and Novell IPX/SPX into an IP world, stating concerns about ZeroConfig is really unpopular. Actually, I admire the way you have provided several detailed technical arguments that the current specification is not what it should be. I accept your claim that your intention is not sabotage, but clarification. John At 01:09 PM 5/22/2002, RJ Atkinson wrote: >Keith, > > I disagree with a lot of what you are saying above and previously. >I'd also suggest that there is not rough consensus behind your positions >-- and that the IETF operates on rough consensus rather than unanimity. > > Please stop trying to unilaterally derail this. From owner-zeroconf@merit.edu Wed May 22 14:23:18 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23387 for ; Wed, 22 May 2002 14:23:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7397591343; Wed, 22 May 2002 14:22:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 329FC91340; Wed, 22 May 2002 14:22:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDCD891343 for ; Wed, 22 May 2002 14:22:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9DA95DE6B; Wed, 22 May 2002 14:22:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 3B9085DE68 for ; Wed, 22 May 2002 14:22:10 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4MIMAl23988; Wed, 22 May 2002 14:22:10 -0400 (EDT) Message-Id: <200205221822.g4MIMAl23988@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com Subject: Re: Security issues in zeroconf-v4-linklocal-05 In-reply-to: (Your message of "Wed, 22 May 2002 08:07:26 PDT.") Date: Wed, 22 May 2002 14:22:10 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Wed, 22 May 2002, Keith Moore wrote: > > > A vendor creates a closed box with a single link (a bus) ... > > > > > > If a particular link is secured with L2 security, why can't one > > > then assume v4LL can be used securely? > > > > Okay, *if* you have a point-to-point link layer (with only two possible > > attachment points) which is known to be *inherently* secure (certainly > > not true of any of the wireless technologies in use today) then it *might* > > be reasonable for the device to not implement security. > > A shared access medium in an unopenable container is secure to the > extent the container remains unopened. The medium might be secure in such a case if it's physically protected. That doesn't imply that the *device* provides adequate security from whatever threats might be in that environment. Even assuming a secure medium, there may be threats that still require the host to provide security beyond that provided by the medium. Bottom line is that the responsibility for security cannot, in general, be expected to be delegated to the transmission medium. There are specific cases where this is probably adequate, but not so in general. > > Even then it's > > not axiomatically so - because it still leaves the possibliity that the > > device can be compromsied by the other host on that point-to-point link > > and if the device is then plugged into another network, it can compromise > > other hosts. > > There is no requirement or expectation of byzantine robustness for > standards track protocols. Neither is there any exemption for what you term "byzantine". We know, from long and frequent experience, that general-purpose hosts are quite often compromised through viruses and the like, and that a significant percentage of security violations originate from inside a trusted environment. We also know that there are severe limitations to using network topology as the sole means of providing security. > If a device is multihomed, one interface in a secured (physically or > using L2 authentication), there is the risk that it could become > compromised, and then compromise the network. If we were to require > that hosts (and routers) be uncompromisable before standardizing > protocol, we would have to stop most of the work at the IETF. > > > It's a complicated world, it's very difficult to make > > reliable assurances about security, and most vendors/implementors > > (and for that matter most customers/users) don't do good threat analysis. > > But we shouldn't imply that that's okay :) > > I agree. We have to explain the risks. > > > So while "cannot be assumed at all" may be a tad bit too restrictive, > > "cannot be assumed in all situations" is really misleading. > > "can almost never be assumed" is as close as I know how to say it. > > Let's get concrete. > > 'this allows them to produce cost-effective devices by implementing > a degree of security appropriate for that expected environment.' At best, the idea that zeroconf allows vendors to skimp on security is highly dubious - while it might be true on its face, this statement is very likely to be misread. The cases where a vendor can reasonably expect the environment to be secure are so rare in practice that even a nonspecific claim that zeroconf "might" help is probably misleading. > Add: > 'Implementors are advised that unless it is *impossible* to connect > a device to a shared access medium, it is likely that it will be > used in environments in which it is exposed to attack. For example, > a bus used inside a factory-sealed container might be an appropriate > environment for attached components to use link-layer > autoconfiguration without concern for attack.' > > ISSUE: Is this sufficient? (If not, please suggest an alternative.) Sigh. There are threats that exist even when it is impossible to connect the device to a shared access medium. So even though you say "*might* be an appropriate environment", I think this is too easily misread. A concrete example: Say you have a device that is supposed to implement public key cryptography - it's supposed to sign or encrypt things with a private key that is stored on the device. Such a device would be quite useful, no?. And let's further say that the device is designed to be used only in physically secure environments - it's recognized (and the customer is warned) that if the device is stolen or even removed and replaced then the key will be compromised, at least to the extent that the thief can sign and encrypt things as if he were the intended user. Now, if the device is supposed to protect that private key, and the device has a mechanism that lets that private key be exposed through its network interface, there's still a security risk with the device even though the network is assumed to be secure. The device has a valuable resource to protect. The entire reason for putting the private key on a separate device is to limit access to that key. If the key can easily be exposed to other hosts on the network, it would defeat the purpose of the device, and the fact that the network is secure doesn't change that fact. The point is that any kind of generalization to the effect that network security is adequate under some conditions is likely to be misleading. Even assuming a network that is perfectly secure from intrusion, the security of the host is only adequate if there is no partitioning of trust - if all hosts/devices in the the network are trusted to exactly the same degree. Yes, there are sometimes exceptions but it's very difficult to make reliable general statements about them. suggested alternative text: ] Implementors are advised that the Internet Protocol archirecture expects ] every networked device or host must implement security which is adequate ] to protect the resources to which the device or host has access, including ] the network itself, against known or credible threats. Even though use ] of link-local addresses may reduce the number of threats to which a device ] is exposed, implementors of devices supporting the Internet Protocol must ] not assume that a customer's local network is free from security risks. ] ] While there may be particular kinds of devices, or particular environments, ] for which the security provided by the network is adequate to protect ] the resources that are accessible by the device, it would be misleading to ] make a general statement to the effect that the requirement to provide ] security is reduced for devices using linklocal addresses as a sole means ] of access. ] ] IN ALL CASES, whether or not linklocal addresses are used, it is necessary ] for implementors of devices supporting the Internet Protocol to analyze ] the known and credible threats to which a specific host or device might be ] subjected, and to the extent that it is feasible, to provide security ] mechanisms which ameliorate or reduce the risks associated with such threats. > > and (for this and other reasons) > > there does need to be a way for networks to disable devices' use of > > link-local addressing (which itself introduces a security issue > > that needs to be documented). > > If we follow your argument ad absurdum we need a mechanism for > networks to disable ARP :-) perhaps, but ARP isn't in scope for this group :) and of course ARP is an old design. IPv6 does ND rather than ARP in order to avoid some of the problems associated with ARP. if this were the only problem associated with link local addressing then I would not argue that we need a mechanism to disable it. > We need to discuss the 'way to disable' in a separate thread. > For now let's note that we disagree. > > ISSUE: Keith argues for a mechanism to disable device's use of > link-local addressing. What are the grounds (*apart from* > ARP-derived security issues)? the other issue that comes to mind is harm to applications that expect such addresses to be usable outside the local link. > --------------------------------------------------------------- > > > > Countering this threat model: > > > > > > Vendors should create products which can secure their use of > > > the link layer. For example: > > > > > > - authenticating wireless access and allowing devices > > > to operate in a mode where L2 authentication is possible > > > > I'd be reluctant to recommend L2 authentication as a possible > > remedy, if for no other reason because many L2 authentication > > methods have known flaws (e.g. WEP). > > WEP has a bad rep because it is *actually deployed and used.* > The same has happened with some cryptography suites used in GSM. > The flaws are being addressed: WEP has a bad rep because it's *poorly designed* to the point of being irresponsible. It's not as if the threats couldn't have been anticipated - the designers simply failed to do their jobs. > They are not architectural problems > with L2 security per se, rather with individual algorithms. Agreed, however there are some more fundamental limitations with how much protection you can expect a network to provide. Even a perfectly secure network cannot prevent its hosts from being compromised and there are serious scaling problems associated with trying to make sure that all hosts on a network of any reasonable size are secure and trustworthy. And for many cases a 'host' is not the right granularity of trust, yet you don't want to expose finer-grained levels of detail to the network. In general, expecting the network (whether L2 or L3) to provide security from all threats is a dubious architectural choice. > > also, authenticating > > the device is not sufficient (even when it can be done reliably) > > if the device can be compromised. > > We can't prevent devices from being compromised. Nor are you, > I believe, claiming that v4LL authentication increases this risk. > > ISSUE: Keith disagrees that L2 authentication is sufficient > (enough) to secure v4LL autoconfiguration that it > (should) be mentioned as a remedy to ARP related > threats. I think this is getting somewhat distant from the real issues. IMO: - LL autoconfiguration increases the damage that can be done by DoS attacks to the network - LL autoconfiguration doesn't reliably provide any additional security for the host using LL addresses, even if it uses it as the only means of doing IP, and it shouldn't claim that it does. - regarding the possibility of impersonation, LL is approximately as insecure as ARP. - L2 authentication can't be relied on to remedy any of the above. If you are willing to distribute the information required to make use of L2 authentication, you may as well statically configure the IP addresses also. > --------------------------------------------------------------- > > > It's very difficult to make safe general statements about what > > security measures will work. > > > > > Use model: > > > > > > shared access media (wireless being an important example) > > > > > > - Users should be aware that use of v4LL autoconf without > > > link-layer authentication is dangerous. > > > > and probably *with* LL authenticaiton as well... > > Bernard? > > > > Users should > > > demand that wireless appliance products include > > > link-layer authentication capabilities. Users should > > > enable these features, which will likely require > > > configuration. > > > > which would largely defeat the purpose of autoconfiguration. > > I believe Aidan Williams and Steve Hanna have initiated work on > easily configured security parameters. I support efforts in this > direction. > > ACTION: Describe use model in shared and closed-access media. > Admonish vendors and users. It's not my intention to insist that devices intended for use in sealed boxes - say integrated circuits with wave-solderable packages - should implement the same degree of security as devices with Ethernet or 802.11 or USB interfaces which were clearly meant to be able to be plugged in to random networks. Rather, it's my intention to avoid giving implementors of the latter kinds of devices the impression that they can slack off on security. I don't know of a good way to draw the line at which "it's okay to slack off on security" - but I don't think "factory-sealed box" is adequate. I keep coming back to the idea that you can't make general statements about what kind of security is adequate. There's no substitute for doing an analysis of the risks for a specific device and the environments in which it's going to operate. Keith From owner-zeroconf@merit.edu Wed May 22 15:07:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25816 for ; Wed, 22 May 2002 15:07:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2462B912CF; Wed, 22 May 2002 15:07:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBBC6912D0; Wed, 22 May 2002 15:07:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72A74912CF for ; Wed, 22 May 2002 15:07:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B1155DE1C; Wed, 22 May 2002 15:06:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E818F5DDC6 for ; Wed, 22 May 2002 15:06:58 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4MJ6xl24079; Wed, 22 May 2002 15:06:59 -0400 (EDT) Message-Id: <200205221906.g4MJ6xl24079@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , zeroconf@merit.edu, cheshire@apple.com, aboba@internaut.com, narten@us.ibm.com, erik.nordmark@sun.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-reply-to: (Your message of "Wed, 22 May 2002 09:06:46 PDT.") Date: Wed, 22 May 2002 15:06:59 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > Now here's the problem: If a component starts operation when the local > > > network is in a disconnected state, it will only learn of the > > > link-local address(es) of its host. If it advertises those addresses > > > to other components, and the network subsequently transitions to a > > > connected state, those addresses are likely to propgate to components > > > for which they are not usable. > > If the component app starts onperation on a local network, how will > it register to a host on a non-local network? The component app starts operation when the network is disconnected for some reason. when the network's external link comes back up, the app fails to operate as it is intended. LL addressing creates a new failure mode that apps aren't prepared to deal with - having bound to an LL address, the app isn't able to communicate with its nonlocal peers even when it has network connectivity to them. > > However I do not think it's reasonable for linklocal to break existing > > applications if there's no way for the network to disable it. What is > > being proposed is to update every Internet host to support this, amounting > > to a fundamental change in the architecture of the v4 Internet. As such > > it needs to avoid breaking things as much as possible. > > Address reconfiguration events can occur when > - a dhcp lease expires and is not renewed This is not inherent in DHCP - if you run a DHCP server that doesn't renew leases indefinitely (read: as long as possible) then you assume the risk that applications will break. The failure of DHCP to renew an active address lease should be considered a failure of the network (or perhaps, a failure of the DHCP design, though it's hard to see how it could have been avoided) Or to put it another way: DHCP provided temporary leases on an IP address in order to garbage-collect addresses from crash-prone PCs. The resulting ability of the DHCP protocol to deny a lease renewal is an (at the time) unintended/unexamined consequence of DHCP's design. It is NOT a general license for the network to change addresses at a whim, nor is it a justification for LL addresses to increase this kind of failure. If a DHCP server fails to renew an active lease from a host that has promptly defended that lease, this should be viewed as a network failure. > - a dhcp reconfigure option is received (assuming its supported) see above. > - ipv6 link-local autoconfiguration is used and there is a collision > - ipv6 RA indicates a different prefix First of all, IPv6 is irrelevant to applications written for IPv4. Second, though v6 LL addresses are clearly useful for corner cases like ND/RD, and perhaps for specialized apps like network management, that doesn't mean that they're suitable as a normal means of access for hosts or applications. linklocal-05 is making greater claims of applicability for v4 LL addresses than I've seen made for v6 LL addresses. Third, nobody has demonstrated a way to make applications in general survive renumbering - and more generally, nobody has demonstrated technology that would allow renumbering of a network of significant size to be anything less than a carefully-planned and managed event. RA's ability to change prefixes needs to be viewed as an experimental and highly dubious feature of IPv6. Just because it's a feature of IPv6 doesn't mean it's a good idea. (some other features of IPv6 are already falling into disfavor - e.g. A6 records, bit fields in DNS, mapped IPv4 addresses.) > This problem is not unique to v4 LL autoconfiguration. Perhaps not, but there's a difference between imposing a burden on v6 apps that are written to expect a v6 environment, and imposing a burden on v4 apps that weren't written to expect linklocal addresses. > > > - that in lists of interface addresses obtained from the OS that > > > link-local addresses either be hidden, or distinguished from other > > > addresses in a way that makes "smart" applications unlikely to choose > > > those local addresses as source addresses. > > > > > > ERIK: Such an interface which hides details of address changes would > > > be much higher level than a socket interface - a kind of session > > > API. I doubt whether we could really complete such an effort in > > > the IETF, though some such has been proposed in IPng. > > > > I wasn't proposing an interface that hides details of address changes - > > actually I consider such proposals completely infeasible. By "smart" > > applications I was merely referring to apps that choose which local > > address to bind to a socket. These apps will break if they choose a > > link local address where a routable address is needed, or if the link > > local address is changed. > > So apps will have to be "really smart" and note the difference between > different address scopes, preferring the global range. Its not pretty > but we already have magic addresses - like in the multicast range, > loopback, etc. Yes but this is a *new* set of magic addresses that existing apps don't know how to deal with. It's an incompatible change which would be imposed on all hosts (and all apps that run on those hosts) without providing any way to disable it. > ACTION: Admonish programmers not to cache link-local address values > in their programs as their local address. Rather, check > the *current* address. Further, be prepared for address > change errors from relevant (i/o, socket, etc) calls. Even for newly written or updated apps, it takes *much* more than that to fix the problem. Scoped addresses are a major headache for apps. In general, expecting apps to know which addresses to use in which cases is really poor architecture - apps are not in a position to know these things. > > > Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols) > > > > > > it would be far better to simply say that link-local addresses SHOULD > > > NOT be used in DNS and/or that mechanisms specifying link-local > > > addresses in DNS are currently undefined and for further study. > > > > > > ERIK: The use of link-local addresses in the DNS is not currently > > > specified by any document except some in discussion in the > > > DNSEXT working group. What you are proposing is an additional > > > for ZEROCONF name resolution protocols. > > > > How so? I don't see this as proposing any additional work - I see it > > as removing the impression that the current draft gives that DNS is somehow > > suitable for advertising link local addresses. It's just not a good fit. > > > > Yes, additional work is needed to make link local devices accessible by > > name, but we knew that anyway. > > >From draft-ietf-zeroconf-ipv4-linklocal-05.txt: > 2.9 Higher-Layer Protocol Considerations > > For example, DNS Resource Records containing link-local addresses > SHOULD NOT be sent to hosts ouside the link to which those link- > local addresses apply. The problem with this statement is that it implies that it's reasonable to use DNS at all - which is a big stretch. > ACTION: Change the example to either omit the DNS example or provide > a different one. Add text to indicate that storing link-local > addresses in the DNS is not well understood or well advised. I recommend omitting the DNS example entirely. The latter sentence sounds good. > > > Issue 6: Hosts that have multiple interfaces > > > > > > It's hard to see how to fix this. IP is designed with the assumption > > > that a host or service can be identified with sufficient precision > > > (for the purpose of establishing a connection to that host) simply by > > > specifying the host's or service's address and the port number of the > > > service. And defending the addresses between separate links seems > > > undesirable. > > > > > > ERIK: Options > > > - Use on only 1 link at a time. > > > - Defend all addresses (that one has in one's cache?) on all > > > connected links. > > > - Propose an interface indexed socket interface that is also > > > exposed by service discovery. > > Leveraging the v6 interface work doesn't solve the problem. > > > > First, because essentially every single app in existence expects that > > an IP address (without an interface identifier) is sufficiently precise > > to be able to identify a destination host. (the only exceptions that > > come to mind are diagnostic apps like ping, traceroute, tcpdump). > > Requiring apps to explicitly choose which network interface to use in > > order to reach a device that only has a link local address basically > > means that such devices can only reliably be reached from special-purpose > > apps - or that by > > > > Second, you are talking about changes to the v4 interface that will break > > apps. v6 has always supported link local addresses, so apps written for > > v6 have to deal with that interface. The same isn't true for v4 apps. > > > > Third, some of the API changes you are proposing would have far reaching > > effects, which are far beyond the ability of this group to consider. > > Your points are well taken. There are two workable strategies then. > > 1. Establish that v4LL works for one configured interface. Clarify that > if used for more than one it will break existing applications. Or > > 2. Establish that if a multihomed host uses v4LL on more than one > interface it MUST defend all addresses it detects on any v4 auto- > configured interface on all its v4 autoconfigured interface. Or > > 2 could limit the scalability of the v4LL protocol and expose other > links to ARP attacks. So maybe we need to specifically limit the > applicability of the protocol to a single interface. > > We should add that if, in the future, additional network APIs > are developed to expose (or transparently manage) interface ids, > disambiguating addresses, it would be possible to support > multiple link-local address autoconfigured interfaces on a host. > > ISSUE: Add an applicability statement - only single interfaces > can be autoconfigured unless the host supports an interface > indexed API, and expose the addresses for additional > interfaces' addresses only through this new API. Rather than imposing restrictions on hosts, I think it's better to simply document this as a fundamental limitation of LL addressing - you can't reliably expect LL addresses to be accessible from multihomed hosts if more than one interface on that host is configured to support LL addresses. (unless the host acts as an L2 bridge - which is too ugly to suggest) But this just further illustates the need to be able to disable LL addressing (at least from a per-interface basis) - because there certainly will be multi-interface hosts set up for the sole purpose of mediating between devices that only support LL addressing and the rest of the net. > > Perhaps I simply misunderstand the current draft, because it seems to > > say that DHCP can effectively be used to "turn off" autoconfiguration: > > Some existing implementations do turn off v4LL autoconfiguration, but > this is not required. > > ISSUE: Clarify that this transition is not a requirement. (see below). Being able to disable LL needs to be a requirement, because of application compatability issues and because of problems with multihomed hosts. > > In effect, this seems to provide a way for network administrators to > > "turn off" use of link local addresses merely by supporting DHCP > > (or by configuring their hosts with static addresses). It's reasonable > > to assume, then, that for the vast majority of operational networks, > > link-local addresses are NOT currently in use, and therefore the > > experience from existing implementations is NOT a useful indicator of > > the safety of using link-local addresses as proposed in this document. > > > > So I stand by my recommendation - we need a way for networks to disable > > this. And we also need to clearly state that link local addresses are > > not a general-purpose address configuration mechanism. Devices that > > implement only link-local addressing may not be usable in existing > > networks. > > It is clear you disagree with the authors and me on this point. > > ISSUE: We need ZEROCONF WG mailing list feedback on this point. I suspect the root problem is trying too hard to make LL addresses into a general-purpose mechanism for address configuration of simple hosts. They're just not suitable for that - even presuming that the only other hosts that need to access the host in question are on the same link is a big stretch - and it threatens to impose the highly undesirable requirement that all devices on some kinds of networks (say, home networks) be effectively on the same link in order to interoperate at all. If you get past insisting that LL addresses be a general-purpose mechanism, and/or provide a simple way to for simple devices to obtain addresses that aren't necessarily LL (the only real issue here is claim/defend/discover protocol implementation overhead because LL doesn't provide security anyway) then you no longer have a need to insist that all GP hosts must have LL addressing turned on at all times. *then* you can solve the problem of configuring ad hoc networks and configuring simple devices in a way that doesn't prevent such devices from being used on some kinds of networks, and which also minimizes breakage for existing apps and networks. But the current proposal doesn't quite get there. Keith From owner-zeroconf@merit.edu Wed May 22 15:27:36 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26854 for ; Wed, 22 May 2002 15:27:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A034912D2; Wed, 22 May 2002 15:26:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFACC91321; Wed, 22 May 2002 15:26:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0848912D2 for ; Wed, 22 May 2002 15:26:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AA4B5DDC6; Wed, 22 May 2002 15:26:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E34285DE6E for ; Wed, 22 May 2002 15:26:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4MJPtl24220; Wed, 22 May 2002 15:25:55 -0400 (EDT) Message-Id: <200205221925.g4MJPtl24220@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , Erik Guttman , Bernard Aboba , zeroconf@merit.edu, cheshire@apple.com Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd) In-reply-to: (Your message of "Wed, 22 May 2002 13:09:31 EDT.") Date: Wed, 22 May 2002 15:25:55 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I disagree with a lot of what you are saying above and previously. > I'd also suggest that there is not rough consensus behind your positions > -- and that the IETF operates on rough consensus rather than unanimity. I don't know if I can get rough consensus from this group or not. But I do expect the group to meet the requirements of RFC 2026 for PS status - one of which says that "A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it." This isn't the case yet, not by a long shot. Either the protocol needs some beefing up, or it needs to make fewer claims of applicability, or both. I've tried to make constructive suggestions as to the minimum changes necessary to solve these problems. > Please stop trying to unilaterally derail this. I'm not trying to derail this; I'm trying to make it better and to minimize the harm that it seems likely to cause in its current form. Keith From owner-zeroconf@merit.edu Thu May 23 06:35:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03485 for ; Thu, 23 May 2002 06:35:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 359749125C; Thu, 23 May 2002 06:35:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0546391311; Thu, 23 May 2002 06:35:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFBDC9125C for ; Thu, 23 May 2002 06:35:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 875CD5DE8E; Thu, 23 May 2002 06:35:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 54F755DDA4 for ; Thu, 23 May 2002 06:35:47 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02546; Thu, 23 May 2002 04:35:46 -0600 (MDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4NAZgb21863; Thu, 23 May 2002 12:35:42 +0200 (MEST) Date: Thu, 23 May 2002 03:35:37 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: zeroconf@merit.edu Cc: cheshire@apple.com, Erik Guttman , erik.nordmark@sun.com, moore@cs.utk.edu Subject: ACTION STARTED: revision of draft-ietf-zeroconf-ipv4-linklocal-05.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Everyone, REMINDER: This document has gone through WG and IETF last call. We are currently evaluating the last outstanding issues which arose during IETF last call. Keith has brought up a number of issues I have proposed resolution of. We need to evaluate the working group consensus on these matters and take action. * This is a formal call for comments. At the end of two * * weeks the chairs will evaluate consensus on the basis of * * discussion, revise the WG document and submit the final * * result to the IESG for advancement to proposed standard. * -------------------------------------------------------------- [1] Proposed Action: Add a section "Application Programming Considerations" Use of IPv4 link-layer autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing. - New subsection: Address changes, failure and recovery IPv4 link-local addresses used by an application may change over time. Current application software encountering an address change will likely completely fail. For example, client TCP connections will fail, servers whose addresses change will have to be rediscovered, blocked reads and writes will exit with an error condition, and so on. Vendors producing application software which will be used on IP implementations supporting IPv4 link-local address configuration SHOULD detect and cope with address change events. Vendors producing IP implementations supporting IPv4 link-local address configuration SHOULD expose address change events to applications. - New subsection: Limited forwarding of locators IPv4 link-layer addresses MUST NOT be forwarded via an application protocol (for example in a URL), to a destination which is not link-local, on the same link. This is discussed further in Section 2.9 and 3. Existing distributed application software which forwards address information may fail. For example, FTP [RFC 959] passive mode transmits the IP address of the client. Assume a client starts up and obtains its *passive* IP configuration at a time when the host has only an link-local address. Later, the client gets a global IP address configuration (for one of its interfaces). It uses this global IP address to contact an FTP server off of the local link for which it had (or still has) a link-local address configured. If the ftp client transmits its passive IP configuration to the FTP server, the FTP server will be unable to reach the FTP client. The passive FTP operation will fail. - New subsection: Address ambiguity Application software run on a multihomed IP host which supports IPv4 link-layer address configuration on more than one interface may fail. This is because application software assumes that an IP address is unambiguous, that it can refer to only one host. IPv4 link-layer addresses are unique only on a single link. A host attached to multiple links can easily encounter a situation where the same address is present on more than one interface, or first on one interface, later on another; in any case associated with more than one host. Existing software is not prepared for this ambiguity. In the future, application programming interfaces could be developed to prevent this problem. This issue is discussed in Section 3. [2] Proposed Action: Revise "Security Considerations" - The address allocation algorithm using ARP exposes an attack. It is of the same kind as the common ARP DOS or redirecting attack, but it is of greater severity as it generates more traffic as a result. - Change text from: The use of link-local addresses may somewhat reduce the breadth of attack to which a device may be subject, from the entire Internet to only attackers who have access to the local link, but that should not be seen as a reason to ignore security issues. Developments such as wireless networking mean that an attacker does not necessarily need to be inside the building to have access to the local link. Even a device using only link-local addresses should still implement end-to-end cryptographic security at a level appropriate to that device and its intended operating environment. To: Implementors are advised that the Internet Protocol archirecture expects every networked device or host must implement security which is adequate to protect the resources to which the device or host has access, including the network itself, against known or credible threats. Even though use of link-local addresses may reduce the number of threats to which a device is exposed, implementors of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks. While there may be particular kinds of devices, or particular environments, for which the security provided by the network is adequate to protect the resources that are accessible by the device, it would be misleading to make a general statement to the effect that the requirement to provide security is reduced for devices using linklocal addresses as a sole means of access. In all cases, whether or not linklocal addresses are used, it is necessary for implementors of devices supporting the Internet Protocol to analyze the known and credible threats to which a specific host or device might be subjected, and to the extent that it is feasible, to provide security mechanisms which ameliorate or reduce the risks associated with such threats. [3] Proposed Action: Revise Section 1.1, "Conventions and Terminology Used in this Document" Change definition of "same link" from Two hosts are considered to be on the same link if, when one host sends packets to the other, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified. to: A set of hosts is considered to be "on the same link", if: - when any host A from that set sends a packet to any other host B in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified, and - a broadcast sent over that link by any host from that set of hosts can be received by every other host in that set [4] Proposed Action: Revise Section 2.9 "Higher-Layer Protocol Considerations" Remove text: For example, DNS Resource Records containing link-local addresses SHOULD NOT be sent to hosts outside the link to which those link-local addresses apply. Since DNS treats Resource Record Sets [RFC 2181] as indivisible units (e.g. for generating DNS reply packets, signatures, etc.), RRSets SHOULD only contain A records where all the addresses have the same scope. Link-local and routable addresses SHOULD NOT be mixed in a single set. Modify text: Designers of Web pages (including automatically generated web pages) SHOULD NOT contain links with embedded link-local addresses if those pages are viewable from hosts outside the local link where the addresses are valid. To: For example, designers of Web pages ... (as above). Add: As link-local addresses may change at any time and have limited scope, storing link-layer addresses in the DNS is not well understood and it is NOT RECOMMENDED. [5] Proposed Action: Reject Suggestion: Require support of a mechanism to disable use of IPv4 link-layer address configuration (on configued links). Comment: The rationale for this requirement are issues which are considered above. The WG must decide whether the issues are sufficiently addressed that it is reasonable to reject Kieth's suggestion. -------------------------------------------------------------- I want to thank Keith for the persistent and thoughtful attention he has paid to the quality of this document. We are making every reasonable attempt to address his concerns. If the above is an incomplete list of issues, I will augment it. To remind working group members: The IETF working group process does allow for objections of individuals to be overridden as a roughness in the arrived at consensus. It should be your goal to help us arrive at the right answer. Do not be concerned to necessarily arrive at a unanimous one. I appreciate your comments. Erik Guttman ZEROCONF cochair From owner-zeroconf@merit.edu Thu May 23 06:51:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03712 for ; Thu, 23 May 2002 06:51:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6259691311; Thu, 23 May 2002 06:51:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 337F391312; Thu, 23 May 2002 06:51:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A4EC91311 for ; Thu, 23 May 2002 06:51:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7EE45DE95; Thu, 23 May 2002 06:51:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (unknown [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id AA3575DDA4 for ; Thu, 23 May 2002 06:51:24 -0400 (EDT) Received: from procyon (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id D32DD59881 for ; Thu, 23 May 2002 11:51:26 +0100 (BST) Message-ID: <002c01c20247$c81be4c0$5801a8c0@localdomain> From: "Philip Nye" To: "Zeroconf Working Group" References: <200205221906.g4MJ6xl24079@astro.cs.utk.edu> Subject: Link Local addresses break existing applications? Date: Thu, 23 May 2002 11:51:23 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, On Keith's concern about LL addresses breaking existing apps and at the risk of repetition. Can somebody summarise for me the thinking behind the change that recommends retaining LL addresses alongside a static or DHCP allocated address, rather than the earlier behaviour of using LL addresses only when nothing else is present? Philip Nye From owner-zeroconf@merit.edu Thu May 23 07:22:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04302 for ; Thu, 23 May 2002 07:22:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96A7291312; Thu, 23 May 2002 07:23:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BE4F91314; Thu, 23 May 2002 07:23:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CD2E91312 for ; Thu, 23 May 2002 07:23:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1212E5DE06; Thu, 23 May 2002 07:22:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id A02B45DDA4 for ; Thu, 23 May 2002 07:22:55 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11301; Thu, 23 May 2002 05:22:58 -0600 (MDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4NBMub23314; Thu, 23 May 2002 13:22:56 +0200 (MEST) Date: Thu, 23 May 2002 04:22:51 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: Philip Nye Cc: Zeroconf Working Group Subject: Re: Link Local addresses break existing applications? In-Reply-To: <002c01c20247$c81be4c0$5801a8c0@localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 23 May 2002, Philip Nye wrote: > Can somebody summarise for me the thinking behind the change > that recommends retaining LL addresses alongside a static or DHCP allocated > address, rather than the earlier behaviour of using LL addresses only when > nothing else is present? Please see section 1.5 of http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-05.txt Erik From owner-zeroconf@merit.edu Sun May 26 21:03:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00047 for ; Sun, 26 May 2002 21:03:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A7269122A; Sun, 26 May 2002 21:01:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A1B19122F; Sun, 26 May 2002 21:01:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2DB399122A for ; Sun, 26 May 2002 21:01:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA5FB5DDCE; Sun, 26 May 2002 21:00:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 986825DD92 for ; Sun, 26 May 2002 21:00:56 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA18920; Sun, 26 May 2002 18:00:48 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id SAA29535; Sun, 26 May 2002 18:00:41 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g4R10Yjd000891; Mon, 27 May 2002 11:00:36 +1000 (EST) Message-ID: <3CF18532.E2DE6A54@motorola.com> Date: Mon, 27 May 2002 11:00:34 +1000 From: Aidan Williams Reply-To: Aidan_Williams-A15677@email.mot.com Organization: aidan@arc.corp.mot.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore Cc: Erik Guttman , zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com, Steve Hanna Subject: Re: Security issues in zeroconf-v4-linklocal-05 References: <200205221822.g4MIMAl23988@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik Guttman writes: > I believe Aidan Williams and Steve Hanna have initiated work on > easily configured security parameters. I support efforts in this > direction. > Yes, we have. Steve and I spent some time at the last IETF talking about how to configure and apply shared secrets in zeroconf networks. As has been pointed out many, many times, the configuration of the secret isn't "zeroconf". We're shooting for "simple". Steve has a draft on secret sharing techniques: http://www.ietf.org/internet-drafts/draft-hanna-zeroconf-seccfg-00.txt I have half a draft on how the secret could be applied, not (yet) published. We are hoping to have a document describing a simple key exchange protocols (over a secure link), and both out by Yokohama. Keith Moore writes: > I don't know of a good way to draw the line at which "it's okay > to slack off on security" - but I don't think "factory-sealed box" > is adequate. > > I keep coming back to the idea that you can't make general statements > about what kind of security is adequate. There's no substitute > for doing an analysis of the risks for a specific device and the > environments in which it's going to operate. > Keith, I basically agree with you that security depends critically on environment. The zeroconf wg needs to think about the environment in which ZC protocols will be deployed, understand and document any security issues, and specify the use of appropriate mechanism to ameliorate threats. Consideration of what are believed to be reasonable deployment scenarios (ie the configuration cable, the home network, and an adhoc group at a conference) has produced the idea that zeroconf protocol security mechanisms must at least allow a group of devices to implent a basic "in/out policy". I have tried to summarise the approach in the requirements document, sections: http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-10.txt 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 4.1 The Basic in/out Security Policy . . . . . . . . . . . . . . 16 4.2 Security Scenarios . . . . . . . . . . . . . . . . . . . . . 17 4.2.1 Use on an isolated, secure network link . . . . . . . . . . 17 4.2.2 Use on a shared (insecure) link . . . . . . . . . . . . . . 17 4.2.3 Use in conjunction with configured protocols . . . . . . . . 17 This is not intended to be a one-size-fits-all approach. Rather, it is an attempt to discuss appropriate security measures for what we believe are likely deployment scenarios. Given that the above is pretty much a re-write of the requirement document security considerations section, any suggestions as to how to improve it would be most welcome. - aidan From owner-zeroconf@merit.edu Thu May 30 20:06:19 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22484 for ; Thu, 30 May 2002 20:06:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 670B8912A2; Thu, 30 May 2002 20:04:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C431912AA; Thu, 30 May 2002 20:04:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B05E912A2 for ; Thu, 30 May 2002 20:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CBF05DDB2; Thu, 30 May 2002 20:04:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id AF70F5DD8F for ; Thu, 30 May 2002 20:04:23 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA25985; Thu, 30 May 2002 17:04:13 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA01612; Thu, 30 May 2002 17:04:18 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g4V046jd009497; Fri, 31 May 2002 10:04:06 +1000 (EST) Message-ID: <3CF6BDF5.C7DEE7BA@motorola.com> Date: Fri, 31 May 2002 10:04:05 +1000 From: Aidan Williams Reply-To: Aidan_Williams-A15677@email.mot.com Organization: aidan@arc.corp.mot.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Busse Cc: Aidan_Williams-A15677@email.mot.com, Keith Moore , Erik Guttman , zeroconf@merit.edu, aboba@internaut.com, erik.nordmark@sun.com, cheshire@apple.com, narten@us.ibm.com, Steve Hanna Subject: Re: Security issues in zeroconf-v4-linklocal-05 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim Busse wrote: > I've read over the drafts again, and I have a slightly different view > regarding the securing of a Zeroconf network. Please consider these > comments: > Thank you. > I was always of the opinion that some pre-configuration and perhaps some > "session" layer interaction was necessary (very contrary to the "Zero" in > "Zeroconf"). But I think as was pointed out in some other emails, that 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. > The nub of the issue is: which risks should we clarify. I re-wrote the security section from the point of view that the requirements document should highlight what are the security issues that arise merely because you are using zeroconf protocols. That's why it talks about the relationship to configured protocols -- e.g. are we introducing new threats just because we are using a ZC name resolution protocols in combination with the DNS. I realise that the security section is currently pretty light on w.r.t mechanism. For a requirements document, that may not be a bad thing since I'm not convinced that it could specify a solution that would cover every possible zeroconf protocol. My expectation is that each zeroconf protocol should describe specific security threats and countermeasures relevant to each protocol. The requirements document needs to describe and perhaps address the security issues that are "zeroconf-architectural" in nature. Would it help to provide some references to L2, L3 and L4 security mechansisms, with perhaps brief examples on how to authenticate messages? > 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. > So here I've tried to identify the security categories with hopes that > certain protocols can be assigned to "fix" those areas, and identify the > areas where the Zeroconf protocols do nothing. This list may not be > complete, but after working on firewalls and securing networks for awhile, > maybe the list is a fair start. > > Network/Device Attack Categorization > > 1. Physical > a. Theft > b. Isolation > c. Revision (modification) > 2. Logical > a. Denial of service > b. Theft of service > c. Modification of service > d. Denial of control flow > e. Theft of control flow > f. Modification of control flow > g. Denial of data flow > h. Theft of data flow > i. Modification of data flow > > Device Security considerations > 1. Authorization > 2. Authentication > 3. Accounting > 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. > Since "secure" means "trustworthy, dependable, free from fear of loss", > maybe "secret" for a Zeroconf network is not "secure". I'm thinking that > public disclosure may cause a Zeroconf network to be more "secure". That > is, in the event of an attack, or the joining of a network or device, or the > unauthorized removal of a device, there may be some client-based (maybe > Radius-like) AAA protocol run on every device. Then each device would have > the opportunity to either let the new device join, or prevent it, or perhaps > shut itself down to protect itself. > "Secret" was meant in the sense of "shared cryptographic secret", not in the "don't tell the world that the network exists" sense. Even using radius, groups of devices that want to authenticate each other must share some information that identifies them. Steve Hanna's draft is about how to agree on a shared secret, that could then be used to bootstrap authentication, privacy, etc (perhaps even using protcol like radius). regards aidan ____ :wq! From owner-zeroconf@merit.edu Thu May 30 20:30:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22862 for ; Thu, 30 May 2002 20:30:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3BED4912A3; Thu, 30 May 2002 20:30:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B909912A5; Thu, 30 May 2002 20:30:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DCAF912A3 for ; Thu, 30 May 2002 20:30:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A96525DDC7; Thu, 30 May 2002 20:30:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by segue.merit.edu (Postfix) with ESMTP id 6E7B75DD8F for ; Thu, 30 May 2002 20:30:27 -0400 (EDT) Received: from 192.168.1.248 ([144.135.24.81]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15 mta04bw Apr 29 2002 13:22:02) with SMTP id GWY9ER00.3LV for ; Fri, 31 May 2002 10:30:27 +1000 Received: from CPE-203-51-24-230.nsw.bigpond.net.au ([203.51.24.230]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0m 38/3374626); 31 May 2002 10:30:27 From: Brad Hards To: zeroconf@merit.edu Subject: Thoughts on security for zeroconf Date: Fri, 31 May 2002 10:28:51 +1000 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200205311028.52585.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Just some idle thoughts - not for inclusion in the drafts, but perhaps for discussion or at least personal thought. If you consider that there may be malicious hosts on your link local network, then there is no system that can avoid DoS. Examples. Static IP: Malicious host assigns address that is the same as another statically assigned IP. OR Malicious host just floods network. Dynamic IP: Malicious host just cycles through a range of hw addresses, claiming all available IPs from DHCP server. OR Malicious host just floods network. Zeroconf: Malicious host answers all ARP probes, denying new users an IP. OR Malicious host just floods network. In some ways the zeroconf case is better, because you can recover it more easily (you only need to find the malicious host, where DHCP requires finding the malicious host, rebooting the DHCP server, and reconfiguring all users). If you trust your local link (eg, it is a usb to usb networking cable that looks like virtual ethernet, and you can see both ends, and you can thump the guy on the other end if necessary), then you don't need to secure the _link_. If you don't trust your local link (for some value of trust that is commensurate with the consequences of it failing), then you open yourself up to a denial of service attack of many kinds. It doesn't matter how you assign the IP address, you'll still be toast. And it won't help to put a lot of detail in any particular RFC. If implementers don't really understand security, they are doomed to be frequently listed on bugtraq, no matter how much guidance is provided. Thanks for your time. Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.