From owner-zeroconf@merit.edu Tue Nov 19 05:21:55 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 FAA00785 for ; Tue, 19 Nov 2002 05:21:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6332D9127B; Tue, 19 Nov 2002 05:23:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94EEF91285; Tue, 19 Nov 2002 05:23:53 -0500 (EST) 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 B41A19127B for ; Tue, 19 Nov 2002 05:23:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id A22B55DE4D; Tue, 19 Nov 2002 05:23:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail.cit.ie (unknown [157.190.14.15]) by segue.merit.edu (Postfix) with ESMTP id 6C1D85DDB5 for ; Tue, 19 Nov 2002 05:23:42 -0500 (EST) Received: from eeb253w2kjpg (unverified [157.190.41.56]) by cit.ie (Rockliffe SMTPRA 5.2.3) with SMTP id for ; Tue, 19 Nov 2002 10:18:04 +0000 Message-ID: <005d01c28fb5$ad0b32c0$3829be9d@eeb253w2kjpg> From: "John Paul O Grady" To: Subject: ad hoc networks Date: Tue, 19 Nov 2002 10:23:14 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C28FB5.AB56F310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C28FB5.AB56F310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello I am doing some research on mobile ad hoc networks (manets). A mobile=20 ad hoc network consists of a set of identical mobile nodes communicating = with each other via wireless links. The networks topology may change = rapidly and unpredictably. I am looking at the problem of dynamic configuration of IP addresses in = the absence of a DHCP server. Beacuse the network is a multi hop network, the use of link local = addresses is not possible, the address has to be unique within the network. There are different proposals on = how to provide dynamic IP address allocations in such a environment, generally in the proposals a node = chooses a address from a pre defined pool of available addresses and it then uses broadscasts in order to = detect whether or not a node exists with the same address in the network. There are other proposals that use hierarchical structures, where a node acts as a leader node, this node is responsible then for the allocation of IP addresses to new nodes as they enter the network. I was really just interested in the kind of proposals the zero config = work group was coming up with. Regards John Paul O Grady CIT Ireland = -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_005A_01C28FB5.AB56F310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
I am doing some research on mobile ad hoc networks (manets). A = mobile=20
ad hoc network consists of a set of identical mobile nodes = communicating=20
with each other via wireless links. The networks topology may = change=20 rapidly and
unpredictably.
 
I am looking at the problem of dynamic configuration of IP = addresses in=20 the
absence of a DHCP server.

Beacuse the network is a = multi hop=20 network, the use of link local addresses
is not possible, the = address
has=20 to be unique within the network. There are different proposals on how=20 to
provide dynamic IP address
allocations in such a environment, = generally=20 in the proposals a node chooses
a address from a pre defined
pool = of=20 available addresses and it then uses broadscasts in order to = detect
whether=20 or not a node exists with
the same address in the = network.

There are=20 other proposals that use hierarchical structures, where a node
acts = as a=20 leader node, this node is responsible
then for the allocation of IP = addresses=20 to new nodes as they enter the
network.

I was really just = interested=20 in the kind of proposals the zero config work group was
coming up=20 with.

Regards
 
John Paul O Grady
CIT
Ireland
= -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_005A_01C28FB5.AB56F310-- From owner-zeroconf@merit.edu Tue Nov 26 13:00:40 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 NAA13652 for ; Tue, 26 Nov 2002 13:00:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F51291248; Tue, 26 Nov 2002 13:03:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E90639124D; Tue, 26 Nov 2002 13:03:14 -0500 (EST) 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 E9D0D91248 for ; Tue, 26 Nov 2002 13:02:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id C395A5DE8B; Tue, 26 Nov 2002 13:02:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 7F8E45DE32 for ; Tue, 26 Nov 2002 13:02:51 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAQI2oNp238288 for ; Tue, 26 Nov 2002 13:02:50 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-221-77.mts.ibm.com [9.65.221.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAQI2mVO004546 for ; Tue, 26 Nov 2002 13:02:48 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAQI2Cu07879 for ; Tue, 26 Nov 2002 13:02:12 -0500 Message-Id: <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> To: zeroconf@merit.edu Subject: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Tue, 26 Nov 2002 13:02:12 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk One more issue with this document (the IESG has already sent back a number of comments -- I hope the WG starts working on revising the document soon!) The document has the following text with regards to TTLs: > 2.7 Link-Local Packets Are Not Forwarded > > Any host sending an IPv4 packet with a source and/or destination > address in the 169.254/16 prefix MUST set the TTL in the IP header > to 255. This includes multicast and broadcast packets with a source > address in the 169.254/16 prefix. > > This allows hosts to guard against misconfigured routers, which may > allow packets to leak in from outside the local link. Since even the > most dysfunctional router will decrement the TTL in the IP header, a > host can know with reasonable certainty that any packet received with > a TTL of 255 did come from another host on the local link. A host > receiving a packet with a source and/or destination address in the > 169.254/16 prefix and a TTL less than 255, MAY choose to consider > such packets as potentially having been generated by a malicious > attacker outside the local link, and MAY choose to silently discard > such packets. [See Appendix for details of current implementations.] I have received some private comments (with which I happen to agree) that the above paragraph essentially blesses non-interoperability, or makes it much more likely that non-interoperability will result from this spec. That is, there are currently deployed boxes that use LL addresses, but that don't set the TTL to 255. Consequently, any check of the TTL in received packets will result in failed communication with some boxes. The IETF traditionally takes a dim view of having specs encourage behavior that is non-backwards compatable, unless there is compelling benefit. In the case here, it seems like the 255 check provides a small security benefit, with the emphasis on small. It is not clear that the potential benefts outweigh the downsides. I can imagine several ways to address this issue: - allow the above MAY, but require that the default setting be to disable the check, so that folks need to explicitely enable it, in which case they are making the choice to be non-interoperable with some devices. - get rid of the idea of the check at all, as it provides too little security in practice to be useful. and so forth. Comments? Thomas From owner-zeroconf@merit.edu Tue Nov 26 13:33:44 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 NAA14557 for ; Tue, 26 Nov 2002 13:33:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49DD99124D; Tue, 26 Nov 2002 13:36:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 116EE9125C; Tue, 26 Nov 2002 13:36:14 -0500 (EST) 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 E94DD9124D for ; Tue, 26 Nov 2002 13:36:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFCA95DE8B; Tue, 26 Nov 2002 13:36:13 -0500 (EST) 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 C8D075DE32 for ; Tue, 26 Nov 2002 13:36:12 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id 95C0567103; Tue, 26 Nov 2002 10:00:22 -0500 (EST) Date: Tue, 26 Nov 2002 13:36:01 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Thomas Narten From: RJ Atkinson In-Reply-To: <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think the benefit to having the TTL check is an operational one, not especially a security one. Operationally it is strongly desirable for link-local packets to not exit the link. This significantly reduces the probability of a link-local packet exiting the link. So I'd prefer language like this: - MUST set TTL == 255 on transmission of a link-local packet - SHOULD check TTL == 255 on receipt of a link-local packet - MAY have a configuration knob to allow receipt of TTL != 255 link-local packets but knob MUST default to only accept TTL == 255 This permits the operator to enable a broken mode for compatibility, and lets the rest of us migrate in a more useful direction operationally. Ran On Tuesday, Nov 26, 2002, at 13:02 America/Montreal, Thomas Narten wrote: > One more issue with this document (the IESG has already sent back a > number of comments -- I hope the WG starts working on revising the > document soon!) > > The document has the following text with regards to TTLs: > >> 2.7 Link-Local Packets Are Not Forwarded >> >> Any host sending an IPv4 packet with a source and/or destination >> address in the 169.254/16 prefix MUST set the TTL in the IP header >> to 255. This includes multicast and broadcast packets with a source >> address in the 169.254/16 prefix. >> >> This allows hosts to guard against misconfigured routers, which may >> allow packets to leak in from outside the local link. Since even >> the >> most dysfunctional router will decrement the TTL in the IP header, >> a >> host can know with reasonable certainty that any packet received >> with >> a TTL of 255 did come from another host on the local link. A host >> receiving a packet with a source and/or destination address in the >> 169.254/16 prefix and a TTL less than 255, MAY choose to consider >> such packets as potentially having been generated by a malicious >> attacker outside the local link, and MAY choose to silently discard >> such packets. [See Appendix for details of current >> implementations.] > > I have received some private comments (with which I happen to agree) > that the above paragraph essentially blesses non-interoperability, or > makes it much more likely that non-interoperability will result from > this spec. That is, there are currently deployed boxes that use LL > addresses, but that don't set the TTL to 255. Consequently, any check > of the TTL in received packets will result in failed communication > with some boxes. The IETF traditionally takes a dim view of having > specs encourage behavior that is non-backwards compatable, unless > there is compelling benefit. In the case here, it seems like the 255 > check provides a small security benefit, with the emphasis on > small. It is not clear that the potential benefts outweigh the > downsides. > > I can imagine several ways to address this issue: > > - allow the above MAY, but require that the default setting be to > disable the check, so that folks need to explicitely enable it, in > which case they are making the choice to be non-interoperable with > some devices. > > - get rid of the idea of the check at all, as it provides too little > security in practice to be useful. > > and so forth. > > Comments? > > Thomas > From owner-zeroconf@merit.edu Tue Nov 26 13:49:24 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 NAA15249 for ; Tue, 26 Nov 2002 13:49:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18F5291221; Tue, 26 Nov 2002 13:51:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCEEC9125C; Tue, 26 Nov 2002 13:51:55 -0500 (EST) 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 D930091221 for ; Tue, 26 Nov 2002 13:51:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9F365DED2; Tue, 26 Nov 2002 13:51:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by segue.merit.edu (Postfix) with ESMTP id 4E2635DDFA for ; Tue, 26 Nov 2002 13:51:54 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAQIpqfw009482; Tue, 26 Nov 2002 13:51:52 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-221-77.mts.ibm.com [9.65.221.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAQIpnVO044556; Tue, 26 Nov 2002 13:51:49 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAQIp8w08690; Tue, 26 Nov 2002 13:51:13 -0500 Message-Id: <200211261851.gAQIp8w08690@cichlid.adsl.duke.edu> To: RJ Atkinson Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message from RJ Atkinson of "Tue, 26 Nov 2002 13:36:01 EST." Date: Tue, 26 Nov 2002 13:51:07 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Ran. > I think the benefit to having the TTL check is an operational one, > not especially a security one. Operationally it is strongly desirable > for link-local packets to not exit the link. This significantly > reduces the probability of a link-local packet exiting the link. Huh? If you don't want a LL packet to exit a local link, set the TTL to 1, and/or have routers be configured to never forward them. The latter requirement is already in the spec. The former is a step that will help if the router doesn't know to filter LL packets. A LL is much more likely to get forwarded off link if the TTL is 255! > So I'd prefer language like this: > - MUST set TTL == 255 on transmission of a link-local packet > - SHOULD check TTL == 255 on receipt of a link-local packet Meaning, if TTL != 255, discard the packet? The concern I'm asking about is that with this behavior, we get non-interoperability with currently deployed devices. > - MAY have a configuration knob to allow receipt of TTL != 255 > link-local packets but knob MUST default to only accept > TTL == 255 This is even stronger than the current wording in the document. > This permits the operator to enable a broken mode for compatibility, > and lets the rest of us migrate in a more useful direction > operationally. In a home network, where grandma is the operator, seems to me like there will be no configuration possible. The default settings will rule. Thomas From owner-zeroconf@merit.edu Tue Nov 26 13:53:17 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 NAA15509 for ; Tue, 26 Nov 2002 13:53:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0CB7D9125D; Tue, 26 Nov 2002 13:55:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA6519125E; Tue, 26 Nov 2002 13:55:48 -0500 (EST) 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 EFB109125D for ; Tue, 26 Nov 2002 13:55:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id D37515DF2C; Tue, 26 Nov 2002 13:55:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 915F05DFC9 for ; Tue, 26 Nov 2002 13:55:46 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gAQItiS07928 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 26 Nov 2002 13:55:45 -0500 Message-Id: <5.2.0.9.2.20021126135506.029cd798@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 13:55:32 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 01:02 PM 11/26/2002, you wrote: >One more issue with this document (the IESG has already sent back a >number of comments -- I hope the WG starts working on revising the >document soon!) > >The document has the following text with regards to TTLs: > > > 2.7 Link-Local Packets Are Not Forwarded > > > > Any host sending an IPv4 packet with a source and/or destination > > address in the 169.254/16 prefix MUST set the TTL in the IP header > > to 255. This includes multicast and broadcast packets with a source > > address in the 169.254/16 prefix. > > > > This allows hosts to guard against misconfigured routers, which may > > allow packets to leak in from outside the local link. Since even the > > most dysfunctional router will decrement the TTL in the IP header, a > > host can know with reasonable certainty that any packet received with > > a TTL of 255 did come from another host on the local link. A host > > receiving a packet with a source and/or destination address in the > > 169.254/16 prefix and a TTL less than 255, MAY choose to consider > > such packets as potentially having been generated by a malicious > > attacker outside the local link, and MAY choose to silently discard > > such packets. [See Appendix for details of current implementations.] > >I have received some private comments (with which I happen to agree) >that the above paragraph essentially blesses non-interoperability, or >makes it much more likely that non-interoperability will result from >this spec. That is, there are currently deployed boxes that use LL >addresses, but that don't set the TTL to 255. Two comments: 1. I had to read this paragraph 3 times before I got your proper meaning. Mostly due to sentence structure and length. 2. I see no compatability problem in requiring SETTING the TTL to 255. There is a concern about the check, however. My personal take is it'd be better to SET the TTL to 1, and thereby solve the issue at the sending node. > Consequently, any check >of the TTL in received packets will result in failed communication >with some boxes. The IETF traditionally takes a dim view of having >specs encourage behavior that is non-backwards compatable, unless >there is compelling benefit. > In the case here, it seems like the 255 >check provides a small security benefit, with the emphasis on >small. Given the requirements on zeroconf being discussed, it may represent the ONLY security available to some devices. I know there are companies who are insisting link local be used with gateways and nat boxes, a practice I feel undermines the whole point of link local and will create massive problems. > It is not clear that the potential benefts outweigh the >downsides. > >I can imagine several ways to address this issue: > >- allow the above MAY, but require that the default setting be to > disable the check, so that folks need to explicitely enable it, in > which case they are making the choice to be non-interoperable with > some devices. I'd suggest the SET be to 255 regardless. This doesn't hurt ANYTHING. I'd like the receive side to be a SHOULD, but with a caveat that for some time this will cause compatability issues. The setting of the recommended behavior (setting of switches) should be discussed further. Configuration switches and zeroconf certainly could be seen as being at odds with one another. >- get rid of the idea of the check at all, as it provides too little > security in practice to be useful. Doesn't get my vote. Ultimately, it's a question on how certain you want to be that I can't reach into your house and randomly activate your light switches. Those are likely the kind of devices which will have limited stacks and need the level of protection this issue addresses. From owner-zeroconf@merit.edu Tue Nov 26 13:54:06 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 NAA15534 for ; Tue, 26 Nov 2002 13:54:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE0139125E; Tue, 26 Nov 2002 13:56:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 858B29125F; Tue, 26 Nov 2002 13:56:32 -0500 (EST) 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 7D9889125E for ; Tue, 26 Nov 2002 13:56:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6D2D75DED2; Tue, 26 Nov 2002 13:56:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by segue.merit.edu (Postfix) with ESMTP id EBA0B5DDFA for ; Tue, 26 Nov 2002 13:56:30 -0500 (EST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id gAQItoij024185; Tue, 26 Nov 2002 13:55:58 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 26 Nov 2002 13:56:32 -0500 Message-ID: <3DE3C4FA.4060209@nc.rr.com> Date: Tue, 26 Nov 2002 14:01:14 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: RJ Atkinson , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt References: <200211261851.gAQIp8w08690@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > Hi Ran. > > >>I think the benefit to having the TTL check is an operational one, >>not especially a security one. Operationally it is strongly desirable >>for link-local packets to not exit the link. This significantly >>reduces the probability of a link-local packet exiting the link. > > > Huh? If you don't want a LL packet to exit a local link, set the TTL > to 1, and/or have routers be configured to never forward them. The > latter requirement is already in the spec. The former is a step that > will help if the router doesn't know to filter LL packets. > > A LL is much more likely to get forwarded off link if the TTL is 255! > > >>So I'd prefer language like this: > > >> - MUST set TTL == 255 on transmission of a link-local packet >> - SHOULD check TTL == 255 on receipt of a link-local packet > > > Meaning, if TTL != 255, discard the packet? The concern I'm asking > about is that with this behavior, we get non-interoperability with > currently deployed devices. > > >> - MAY have a configuration knob to allow receipt of TTL != 255 >> link-local packets but knob MUST default to only accept >> TTL == 255 > > > This is even stronger than the current wording in the document. > > >>This permits the operator to enable a broken mode for compatibility, >>and lets the rest of us migrate in a more useful direction >>operationally. > > > In a home network, where grandma is the operator, seems to me like > there will be no configuration possible. The default settings will > rule. This scenario is exactly why I like the idea of making the proposed change. I don't think we can justify losing the backwards inter-operability given the environment that zeroconf networks will exist. Brian From owner-zeroconf@merit.edu Tue Nov 26 14: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 OAA16390 for ; Tue, 26 Nov 2002 14:09:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF2C99124B; Tue, 26 Nov 2002 14:11:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4B5E9125F; Tue, 26 Nov 2002 14:11:56 -0500 (EST) 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 ACFC49124B for ; Tue, 26 Nov 2002 14:11:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E8615DF6B; Tue, 26 Nov 2002 14:11:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by segue.merit.edu (Postfix) with ESMTP id 2DFB65DED2 for ; Tue, 26 Nov 2002 14:11:55 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAQJBsfw070922; Tue, 26 Nov 2002 14:11:54 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-221-77.mts.ibm.com [9.65.221.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAQJBpVO048300; Tue, 26 Nov 2002 14:11:52 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAQJBAX09302; Tue, 26 Nov 2002 14:11:10 -0500 Message-Id: <200211261911.gAQJBAX09302@cichlid.adsl.duke.edu> To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message from Daniel Senie of "Tue, 26 Nov 2002 13:55:32 EST." <5.2.0.9.2.20021126135506.029cd798@mail.amaranth.net> Date: Tue, 26 Nov 2002 14:11:10 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Daniel Senie writes: > 1. I had to read this paragraph 3 times before I got your proper meaning. > Mostly due to sentence structure and length. Sorry about that... > 2. I see no compatability problem in requiring SETTING the TTL to 255. Agree. > There is a concern about the check, however. My personal take is it'd be > better to SET the TTL to 1, and thereby solve the issue at the > sending node. note that setting the TTL to 1 doesn't "solve" the issue completely. If the concern is that LL packets stay on the local link, there are two different pieces: - if the sender sets the TTL to 1, it can ensure that the packet stays locally. - if the receiver wants to verify that a packet didn't originate off link, all it sees is the TTL when it reaches the recipient. It could have a TTL of 1 because it started with a TTL of 10, but went through 9 routers... But if one verifies that that the TTL is 255, that's a pretty good sign the packet didn't travel through any routers. One can assume that Bad Guys will set the TTL to something other than 1 if they are trying to cause problems... Thomas From owner-zeroconf@merit.edu Tue Nov 26 14:23:17 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 OAA16889 for ; Tue, 26 Nov 2002 14:23:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B3C99125F; Tue, 26 Nov 2002 14:25:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0F5D91260; Tue, 26 Nov 2002 14:25:46 -0500 (EST) 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 AE9319125F for ; Tue, 26 Nov 2002 14:25:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 931095DED2; Tue, 26 Nov 2002 14:25:45 -0500 (EST) 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 677905DD91 for ; Tue, 26 Nov 2002 14:25:45 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQJPel21965; Tue, 26 Nov 2002 14:25:40 -0500 (EST) Message-Id: <200211261925.gAQJPel21965@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Tue, 26 Nov 2002 13:02:12 EST.") <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> Date: Tue, 26 Nov 2002 14:25:40 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > I have received some private comments (with which I happen to agree) > that the above paragraph essentially blesses non-interoperability, or > makes it much more likely that non-interoperability will result from > this spec. That is, there are currently deployed boxes that use LL > addresses, but that don't set the TTL to 255. Consequently, any check > of the TTL in received packets will result in failed communication > with some boxes. The IETF traditionally takes a dim view of having > specs encourage behavior that is non-backwards compatable, unless > there is compelling benefit. In the case here, it seems like the 255 > check provides a small security benefit, with the emphasis on > small. It is not clear that the potential benefts outweigh the > downsides. > > I can imagine several ways to address this issue: > > - allow the above MAY, but require that the default setting be to > disable the check, so that folks need to explicitely enable it, in > which case they are making the choice to be non-interoperable with > some devices. > > - get rid of the idea of the check at all, as it provides too little > security in practice to be useful. > If we don't have the TTL check then we need some other way to prevent LL packets from leaking outside of networks, and it's hard to imagine what other check would work as well. This check isn't for security, it's for operational sanity. (any claim that LL provides security is bogus) But it seems like an odd idea to compromise the operational sanity between conforming implementations for the sake of interoperability with pre-existing implementations - especially when most pre-existing implementations are disabled in the presence of DHCP or explicit address configuration - which probably means that in practice that LLs are disabled on most deployed machines, on any network that has a router. So I think the concerns about backward compatibility are misplaced in this instance. Keith [*] as they should be - the current spec is broken in this regard From owner-zeroconf@merit.edu Tue Nov 26 14:28: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 OAA17056 for ; Tue, 26 Nov 2002 14:28:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 251CB91260; Tue, 26 Nov 2002 14:30:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6F7791261; Tue, 26 Nov 2002 14:30:19 -0500 (EST) 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 E508391260 for ; Tue, 26 Nov 2002 14:30:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E8A35DED2; Tue, 26 Nov 2002 14:30:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id EEB8E5DD91 for ; Tue, 26 Nov 2002 14:30:17 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gAQJUGS09534 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 26 Nov 2002 14:30:17 -0500 Message-Id: <5.2.0.9.2.20021126142814.02999660@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 14:30:07 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200211261911.gAQJBAX09302@cichlid.adsl.duke.edu> References: <5.2.0.9.2.20021126135506.029cd798@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 02:11 PM 11/26/2002, Thomas Narten wrote: >Daniel Senie writes: > > > 1. I had to read this paragraph 3 times before I got your proper meaning. > > Mostly due to sentence structure and length. > >Sorry about that... > > > 2. I see no compatability problem in requiring SETTING the TTL to 255. > >Agree. > > > There is a concern about the check, however. My personal take is it'd be > > better to SET the TTL to 1, and thereby solve the issue at the > > sending node. > >note that setting the TTL to 1 doesn't "solve" the issue >completely. If the concern is that LL packets stay on the local link, >there are two different pieces: > >- if the sender sets the TTL to 1, it can ensure that the packet stays > locally. Whis was my area of concern. >- if the receiver wants to verify that a packet didn't originate off > link, all it sees is the TTL when it reaches the recipient. It could > have a TTL of 1 because it started with a TTL of 10, but went > through 9 routers... But if one verifies that that the TTL is 255, > that's a pretty good sign the packet didn't travel through any > routers. One can assume that Bad Guys will set the TTL to something > other than 1 if they are trying to cause problems... Very true. Another reason to not have routers touch link local packets at all. Perhaps another short document updating RFC 1812 is in order. From owner-zeroconf@merit.edu Tue Nov 26 14:30: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 OAA17182 for ; Tue, 26 Nov 2002 14:30:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB17591261; Tue, 26 Nov 2002 14:33:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78BFC91262; Tue, 26 Nov 2002 14:33:02 -0500 (EST) 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 0B39191261 for ; Tue, 26 Nov 2002 14:32:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAC945DD91; Tue, 26 Nov 2002 14:32:49 -0500 (EST) 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 665BC5DE47 for ; Tue, 26 Nov 2002 14:32:49 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id 7114D67103; Tue, 26 Nov 2002 10:57:07 -0500 (EST) Date: Tue, 26 Nov 2002 14:32:45 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Thomas Narten From: RJ Atkinson In-Reply-To: <200211261851.gAQIp8w08690@cichlid.adsl.duke.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Nov 26, 2002, at 13:51 America/Montreal, Thomas Narten wrote: >> I think the benefit to having the TTL check is an operational one, >> not especially a security one. Operationally it is strongly desirable >> for link-local packets to not exit the link. This significantly >> reduces the probability of a link-local packet exiting the link. > > Huh? If you don't want a LL packet to exit a local link, set the TTL > to 1, My typo. Your correction is what I intended... From owner-zeroconf@merit.edu Tue Nov 26 14:32:57 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 OAA17289 for ; Tue, 26 Nov 2002 14:32:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D485791262; Tue, 26 Nov 2002 14:35:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C0EC91263; Tue, 26 Nov 2002 14:35:28 -0500 (EST) 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 9E43991262 for ; Tue, 26 Nov 2002 14:35:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 869F45DED2; Tue, 26 Nov 2002 14:35:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by segue.merit.edu (Postfix) with ESMTP id 283DC5DE47 for ; Tue, 26 Nov 2002 14:35:27 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAQJZL8g195492; Tue, 26 Nov 2002 14:35:21 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-221-77.mts.ibm.com [9.65.221.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAQJZIVO029278; Tue, 26 Nov 2002 14:35:19 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAQJYgl09628; Tue, 26 Nov 2002 14:34:43 -0500 Message-Id: <200211261934.gAQJYgl09628@cichlid.adsl.duke.edu> To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message from Keith Moore of "Tue, 26 Nov 2002 14:25:40 EST." <200211261925.gAQJPel21965@astro.cs.utk.edu> Date: Tue, 26 Nov 2002 14:34:42 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > If we don't have the TTL check then we need some other way to prevent > LL packets from leaking outside of networks, and it's hard to imagine > what other check would work as well. This check isn't for security, > it's for operational sanity. (any claim that LL provides security is > bogus) To be clear, the TTL check DOES NOT prevent LL packets from leaking outside of networks. In fact, it can only make leakage worse, since it requires using a TTL of 255. If you want to limit (unintentional) leakage, the TTL ought to be set to 1 by the sender. So let's be clear about what problems the 255 check is addressing and what it can't address. > But it seems like an odd idea to compromise the operational sanity > between conforming implementations for the sake of interoperability > with pre-existing implementations - especially when most > pre-existing implementations are disabled in the presence of DHCP or > explicit address configuration - which probably means that in > practice that LLs are disabled on most deployed machines, on any > network that has a router. This is a valid point, though folk might argue that there are implementations shipping and in the pipeline that will keep using the LL address even when DHCP gives them a global address. Thomas From owner-zeroconf@merit.edu Tue Nov 26 14:45: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 OAA17785 for ; Tue, 26 Nov 2002 14:45:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1DA1F91264; Tue, 26 Nov 2002 14:48:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C064391263; Tue, 26 Nov 2002 14:47:43 -0500 (EST) 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 89E6591264 for ; Tue, 26 Nov 2002 14:47:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id C24EB5DF87; Tue, 26 Nov 2002 14:47:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from staff3.cso.uiuc.edu (staff3.cso.uiuc.edu [128.174.5.54]) by segue.merit.edu (Postfix) with ESMTP id 94AF95DF2C for ; Tue, 26 Nov 2002 14:47:22 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by staff3.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gAQJlL203324; Tue, 26 Nov 2002 13:47:21 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gAQJlLT06729; Tue, 26 Nov 2002 13:47:21 -0600 (CST) Date: Tue, 26 Nov 2002 13:47:21 -0600 From: "Jay A. Kreibich" To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Message-ID: <20021126194721.GI5973@uiuc.edu> Reply-To: jak@uiuc.edu References: <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, Nov 26, 2002 at 01:02:12PM -0500, Thomas Narten scratched on the wall: > One more issue with this document (the IESG has already sent back a > number of comments -- I hope the WG starts working on revising the > document soon!) > > The document has the following text with regards to TTLs: > > > 2.7 Link-Local Packets Are Not Forwarded > > > > Any host sending an IPv4 packet with a source and/or destination > > address in the 169.254/16 prefix MUST set the TTL in the IP header > > to 255. This includes multicast and broadcast packets with a source > > address in the 169.254/16 prefix. > > > > This allows hosts to guard against misconfigured routers, which may > > allow packets to leak in from outside the local link. Since even the > > most dysfunctional router will decrement the TTL in the IP header, a > > host can know with reasonable certainty that any packet received with > > a TTL of 255 did come from another host on the local link. A host > > receiving a packet with a source and/or destination address in the > > 169.254/16 prefix and a TTL less than 255, MAY choose to consider > > such packets as potentially having been generated by a malicious > > attacker outside the local link, and MAY choose to silently discard > > such packets. [See Appendix for details of current implementations.] > > I have received some private comments (with which I happen to agree) > that the above paragraph essentially blesses non-interoperability, or > makes it much more likely that non-interoperability will result from > this spec. That is, there are currently deployed boxes that use LL > addresses, but that don't set the TTL to 255. Consequently, any check > of the TTL in received packets will result in failed communication > with some boxes. The IETF traditionally takes a dim view of having > specs encourage behavior that is non-backwards compatable, unless > there is compelling benefit. In the case here, it seems like the 255 > check provides a small security benefit, with the emphasis on > small. It is not clear that the potential benefts outweigh the > downsides. > > I can imagine several ways to address this issue: > > - allow the above MAY, but require that the default setting be to > disable the check, so that folks need to explicitely enable it, in > which case they are making the choice to be non-interoperable with > some devices. > > - get rid of the idea of the check at all, as it provides too little > security in practice to be useful. > > and so forth. > > Comments? Yes. First, as I'm sure many of you know, this is the exact scheme used by IPv6 to keep link-local packets "local". There was a lot of thought put into the need for this double-check in IPv6, and it works out quite well. If anyone is to question the wisdom of this check, I would suggest you do some heavy research into the development of IPv6 and how & why this check came about in that standard. I'm not saying it is all good and obvious, but there was a great deal of thought put into this question for IPv6, and the only real difference is that in the case of IPv6, the requirements were in the final spec from day one. That said, here are a few points to consider behind the thought of this check: 1) There are many routers out there that will never understand IPv4 link-local addresses in any special way. Link local addresses can only be managed by ACLs or static routes or some other manually configured system. The chance these routers will be misconfigured-- especially in the home/SOHO/small-business market where zeroconf is likely to be a critical technology-- is extremely high. In other words, the routers cannot be trusted to do anything right with IPv4 link-local addresses. 2) Link-local and "real" addresses often share the same subnet. IP transactions between a "real" IP address and a link-local address on the same link are valid and can be common. Using source/dest addresses for double-checks is not a good option, especially for a machine that *only* has a link-local address and has no idea what, if any, "real" addresses are valid on the link local. In short, if a link-local and a non-link-local address are having a conversation, it is very difficult for the link-local machine to tell where the other machine is, especially if the router is doing proxy-ARPs. It is also difficult for the "real" address machine to tell where the link-local machine is if we assume the router may not be blocking packets correctly. 3) The use of TTL=1 on sending will prevent link-local packets from leaving a subnet, but it will not prevent them from entering a subnet (assuming the attacker does not worry about following standards). Setting the TTL to 1 on send will prevent your packets from leaking onto some other network, which is all good an nice, but if your network was perfect and didn't have anyone doing anything naughty, the routers would be perfectly configured and this would never happen anyways. If we use the TTL=1 scheme, I can raise my TTL and send packets from another network. For example, use a "real" IP address as the dest and a faked link-local source address and the source. The routers will pass the packet to the host (assuming poor/no reverse-route checks). If I adjust the TTL just right, I can get all the packets to arrive with a TTL of 1. This will cause the "real" address machine to reply to a link-local machine. This can be used for DoS or other interesting attacks on machines "protected" by having link-local only addresses from another network (I know that is a bogus assumption, but it shouldn't be). 4) Using a TTL=255 on any packets that involve link-local addresses allows packets to move across poorly configured networks, but the host will not accept them. While it is possible for packets to get off-network, this is the fault of the router config, not the sending host. The worst you can do to an off-link machine is send a bunch of packets the machine will quickly recognize as invalid, and that's easy to do no matter what. But more importantly, if you use the TTL-255 scheme, it is IMPOSSIBLE to make packets that were generated off-network look like they came from on-link. Now it is true that if we assume there are a number of poorly config'ed routers out there, a lot of these packets are going to get dumped into default routes. It would be nice if we could keep this invalid traffic of your network-- and the good news is that there is: just config your routers correctly to not pass it. So all in all, the question comes down to this: What is better: A) a system that (assuming the hosts *ARE* following the standards) protect against leakage of stray packets by routers that *ARE NOT* following the standards. B) a system that allows receivers to detect stray packets (forwarded by routers that *ARE NOT* following the standards) even if those packets are generated by a host that *IS NOT* following the standard. In BOTH cases, if any router *IS* following the standard, neither condition applies. Yes, "B" allows for a bit more resource consumption, but that can be limited by correctly configing the routers, and provides defense against an outside attack. "A" only solves a problem when one set of devices *is* following the standard and one set is NOT. If you take into account which device is likely to generate attacks (routers or hosts), it seems to be trusting the wrong set of devices. As the IPv6 people decided, 'B' seems the way to go. It is more defensive, but that's a Good Thing in today's Internet. Which brings us back around to the problem of retro-fitting this into IPv4. I don't have a real real strong opinion on this, beyond thinking that the IPv6 people thought about this long and hard, and I'm going to assume they made a wise choice in asserting that: A) setting the TTL=255 is the right way to deal with this, and B) this double-check has value. The only question is how much value, and if that value is worth the problems of updating older systems. I think the "MUST" of setting outgoing link-local packets to TTL=255 should stay, as should the "MAY" of checking this on the receiver end. I would personally set the default to "check" as there aren't THAT many devices using these types of services, but we can assume more will be when Zeroconf and the sub-parts it depends on becomes more popular. Also, since Zeroconf will likely require a number of other changes, updates to the IP stack to get this one fixed don't won't be too unreasonable, and for those rare situations when the update doesn't happen, the knowledgeable user can turn if off. I think it is reasonalbe to assume that most users likely to find themselves in this situation are going to be somewhat knowledgeable ones. I also like things that default to the more secure model. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Tue Nov 26 14:46: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 OAA17825 for ; Tue, 26 Nov 2002 14:46:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 457B691263; Tue, 26 Nov 2002 14:48:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 152A291265; Tue, 26 Nov 2002 14:48:53 -0500 (EST) 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 D4B2291263 for ; Tue, 26 Nov 2002 14:48:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC3995DF87; Tue, 26 Nov 2002 14:48:51 -0500 (EST) 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 8F6FD5DF6B for ; Tue, 26 Nov 2002 14:48:51 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQJmZl22016; Tue, 26 Nov 2002 14:48:35 -0500 (EST) Message-Id: <200211261948.gAQJmZl22016@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Tue, 26 Nov 2002 14:34:42 EST.") <200211261934.gAQJYgl09628@cichlid.adsl.duke.edu> Date: Tue, 26 Nov 2002 14:48:35 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > If we don't have the TTL check then we need some other way to prevent > > LL packets from leaking outside of networks, and it's hard to imagine > > what other check would work as well. This check isn't for security, > > it's for operational sanity. (any claim that LL provides security is > > bogus) > > To be clear, the TTL check DOES NOT prevent LL packets from leaking > outside of networks. In fact, it can only make leakage worse, since it > requires using a TTL of 255. If you want to limit (unintentional) > leakage, the TTL ought to be set to 1 by the sender. > > So let's be clear about what problems the 255 check is addressing and > what it can't address. fair enough. if setting TTL to 1 would solve the problem we should seriously consider putting *that* in the spec. having it be 255 has always seemed odd to me > > But it seems like an odd idea to compromise the operational sanity > > between conforming implementations for the sake of interoperability > > with pre-existing implementations - especially when most > > pre-existing implementations are disabled in the presence of DHCP or > > explicit address configuration - which probably means that in > > practice that LLs are disabled on most deployed machines, on any > > network that has a router. > > This is a valid point, though folk might argue that there are > implementations shipping and in the pipeline that will keep using the > LL address even when DHCP gives them a global address. personally it wouldn't bother me if we completely broke compatibility with those implementations - I suspect this is one of those cases where we got confused because of failure to resolve conflicting goals - trying to do the right thing on one hand and being compatible with existing implementations on the other. that and I'm fairly annoyed that my new laptop is spewing useless LL traffic on our local network. (especially when that traffic contains my name in the form of keith-moores-computer.local or some such) Keith From owner-zeroconf@merit.edu Tue Nov 26 15:03: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 PAA18487 for ; Tue, 26 Nov 2002 15:03:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E428891265; Tue, 26 Nov 2002 15:06:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABB1F91266; Tue, 26 Nov 2002 15:06:27 -0500 (EST) 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 C02C791265 for ; Tue, 26 Nov 2002 15:06:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id A513C5DE13; Tue, 26 Nov 2002 15:06:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 689465DDF9 for ; Tue, 26 Nov 2002 15:06:26 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gAQK6PQ10980 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 26 Nov 2002 15:06:25 -0500 Message-Id: <5.2.0.9.2.20021126145457.0285a200@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 14:58:59 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <20021126194721.GI5973@uiuc.edu> References: <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Thank you Jay for your explanation of the TTL=255 rationale. Brings back more of the context of the discussion of this issue, and I concur that TTL=255 is the right approach. I withdraw my suggestion of TTL=1. That said, I think it important that LL stations MUST send TTL=255. I would prefer to see stations also check this. As others have said, I question the degree to which a MUST on the receive would truly break interoperability in the real world (since existing implementations tend to jump to DHCP and NOT retain their LL address). My preference would be for a MUST check TTL=255, with a second clause "MAY have a configuration option to disable this in the event compatability issues arise." I think it is important that the default behavior is to ensure TTL=255, though. From owner-zeroconf@merit.edu Tue Nov 26 15:22: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 PAA19085 for ; Tue, 26 Nov 2002 15:22:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5BDA91266; Tue, 26 Nov 2002 15:24:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D46991267; Tue, 26 Nov 2002 15:24:40 -0500 (EST) 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 8927191266 for ; Tue, 26 Nov 2002 15:24:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A3BC5DE6F; Tue, 26 Nov 2002 15:24:39 -0500 (EST) 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 1DBE55DDF9 for ; Tue, 26 Nov 2002 15:24:39 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQKObl22290; Tue, 26 Nov 2002 15:24:37 -0500 (EST) Message-Id: <200211262024.gAQKObl22290@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Tue, 26 Nov 2002 13:55:32 EST.") <5.2.0.9.2.20021126135506.029cd798@mail.amaranth.net> Date: Tue, 26 Nov 2002 15:24:37 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > In the case here, it seems like the 255 > >check provides a small security benefit, with the emphasis on > >small. > > Given the requirements on zeroconf being discussed, it may represent the > ONLY security available to some devices. in my mind, that argues for requiring TTL=1. companies shipping product that depend on LL as a security mechanism deserve to lose. > Doesn't get my vote. Ultimately, it's a question on how certain you want to > be that I can't reach into your house and randomly activate your light > switches. if you use IP, you need to be able to accept traffic from anywhere. relying on LL to provide security is simply unacceptable, and IETF should not endorse the practice. Keith From owner-zeroconf@merit.edu Tue Nov 26 15:42:18 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 PAA19687 for ; Tue, 26 Nov 2002 15:42:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0D6B91267; Tue, 26 Nov 2002 15:44:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A86F191268; Tue, 26 Nov 2002 15:44:49 -0500 (EST) 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 8C22691267 for ; Tue, 26 Nov 2002 15:44:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74B895DE6F; Tue, 26 Nov 2002 15:44:48 -0500 (EST) 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 094885DDF9 for ; Tue, 26 Nov 2002 15:44:48 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQKill22544; Tue, 26 Nov 2002 15:44:47 -0500 (EST) Message-Id: <200211262044.gAQKill22544@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: zeroconf@merit.edu Subject: use of LL by light switches Cc: moore@cs.utk.edu From: Keith Moore Date: Tue, 26 Nov 2002 15:44:47 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk you know, I don't see anything in zeroconf's charter that says that it is supposed to make IP usable by stupid light switches. zeroconf's problems were difficult enough to solve without extending its scope far beyond that which was intended. Keith From owner-zeroconf@merit.edu Tue Nov 26 15:44: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 PAA19723 for ; Tue, 26 Nov 2002 15:44:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A85DD91268; Tue, 26 Nov 2002 15:46:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69E1A91269; Tue, 26 Nov 2002 15:46:39 -0500 (EST) 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 436D491268 for ; Tue, 26 Nov 2002 15:46:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0D1A95DEFB; Tue, 26 Nov 2002 15:46:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta08bw.bigpond.com (unknown [144.135.24.137]) by segue.merit.edu (Postfix) with ESMTP id DF6475DE6F for ; Tue, 26 Nov 2002 15:46:34 -0500 (EST) Received: from pc-00045 ([144.135.24.72]) by mta08bw.bigpond.com (Netscape Messaging Server 4.15 mta08bw Jul 16 2002 22:47:55) with SMTP id H67B1J00.DUN; Wed, 27 Nov 2002 06:46:31 +1000 Received: from CPE-203-51-31-27.nsw.bigpond.net.au ([203.51.31.27]) by bwmam02.mailsvc.email.bigpond.com(MailRouter V3.0n 17/8378398); 27 Nov 2002 06:46:31 From: Brad Hards To: Thomas Narten , Keith Moore Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 07:35:56 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <200211261934.gAQJYgl09628@cichlid.adsl.duke.edu> In-Reply-To: <200211261934.gAQJYgl09628@cichlid.adsl.duke.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200211270735.57625.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Nov 2002 06:34, Thomas Narten wrote: > > If we don't have the TTL check then we need some other way to prevent > > LL packets from leaking outside of networks, and it's hard to imagine > > what other check would work as well. This check isn't for security, > > it's for operational sanity. (any claim that LL provides security is > > bogus) > > To be clear, the TTL check DOES NOT prevent LL packets from leaking > outside of networks. In fact, it can only make leakage worse, since it > requires using a TTL of 255. If you want to limit (unintentional) > leakage, the TTL ought to be set to 1 by the sender. > > So let's be clear about what problems the 255 check is addressing and > what it can't address. There are three cases: If you SET 255 on sending, and CHECK 255 on receipt, then you know that the packet originated on the local link, but there in the presence of broken routing, may leave the local link. If you SET 1 on sending, then you do not know if the packet originated on the local link, but you do know that, even in the presence of pretty broken routing, the packet is unlikely to leave the local link. There is no point in checking on receipt. If you SET 128 on sending, and CHECK 128 on receipt, then you do not know if the packet originated on the local link, and in the presence of broken routing, the packet may leave the local link. In effect, doing the check on anything except 255 is a waste of time, because it isn't getting you anything. This is essentially about choosing the lesser of two threats: Threat 1. That you have broken routing that forward link-local packets, so that you get packets that originated off-link congesting your link. Threat 2. That you have broken routing that forwards link-local packets, and you believe the (potentially malicious) content. Setting TTL=1 solves the first problem, setting and checking TTL=255 solves the second problem. Now all you have to do is choose which problem you want to solve. I personally am not worried about Threat 1, because if your routing is broken, you likely have a lot of congestion anyway. So I'd like to stick with TTL=255. Whether it defaults on or off is a trade-off between ease-of-use and security, and I'm not going there! Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE949stW6pHgIdAuOMRAjvwAJ9L8j3BXhimp/QzmQERhc1YzSslqACgxAx5 q5o+jzHJVaf/zV48S1jljiw= =cxIy -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Nov 26 15:47:24 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 PAA19805 for ; Tue, 26 Nov 2002 15:47:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8B9791269; Tue, 26 Nov 2002 15:49:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E3AA9126A; Tue, 26 Nov 2002 15:49:55 -0500 (EST) 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 F063D91269 for ; Tue, 26 Nov 2002 15:49:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id D47955DEFB; Tue, 26 Nov 2002 15:49:53 -0500 (EST) 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 786555DE17 for ; Tue, 26 Nov 2002 15:49:53 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQKnfl22604; Tue, 26 Nov 2002 15:49:45 -0500 (EST) Message-Id: <200211262049.gAQKnfl22604@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Thomas Narten , Keith Moore , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 07:35:56 +1100.") <200211270735.57625.bhards@bigpond.net.au> Date: Tue, 26 Nov 2002 15:49:41 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > This is essentially about choosing the lesser of two threats: > Threat 1. That you have broken routing that forward link-local packets, so > that you get packets that originated off-link congesting your link. > Threat 2. That you have broken routing that forwards link-local packets, and > you believe the (potentially malicious) content. > > Setting TTL=1 solves the first problem, setting and checking TTL=255 solves > the second problem. > > Now all you have to do is choose which problem you want to solve. I personally > am not worried about Threat 1, because if your routing is broken, you likely > have a lot of congestion anyway. > > So I'd like to stick with TTL=255. > > Whether it defaults on or off is a trade-off between ease-of-use and security, > and I'm not going there! thanks for a good summary. it makes the choice easy. link locals are not a security mechanism. therefore the correct choice is to set TTL=1. Keith From owner-zeroconf@merit.edu Tue Nov 26 16:21: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 QAA21428 for ; Tue, 26 Nov 2002 16:21:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E95709126B; Tue, 26 Nov 2002 16:23:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4EF39126C; Tue, 26 Nov 2002 16:23:42 -0500 (EST) 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 A6E6E9126B for ; Tue, 26 Nov 2002 16:23:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85FC05DF4B; Tue, 26 Nov 2002 16:23:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta01bw.bigpond.com (mta01bw.bigpond.com [139.134.6.78]) by segue.merit.edu (Postfix) with ESMTP id 1F7D65DE13 for ; Tue, 26 Nov 2002 16:23:40 -0500 (EST) Received: from pc-00045 ([144.135.24.81]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Jul 16 2002 22:47:55) with SMTP id H67CRD00.3HE; Wed, 27 Nov 2002 07:23:37 +1000 Received: from CPE-203-51-31-27.nsw.bigpond.net.au ([203.51.31.27]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0n 44/8367443); 27 Nov 2002 07:23:37 From: Brad Hards To: Keith Moore Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 08:13:02 +1100 User-Agent: KMail/1.4.5 Cc: Thomas Narten , zeroconf@merit.edu References: <200211262049.gAQKnfl22604@astro.cs.utk.edu> In-Reply-To: <200211262049.gAQKnfl22604@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200211270813.02905.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Nov 2002 07:49, Keith Moore wrote: > link locals are not a security mechanism. > therefore the correct choice is to set TTL=1. I'm not so sure. I agree that it is Evil and Wrong to not consider security. But security is a relative thing. And only accepting packets from the local link (whether you do this on an interface with a link-loal address, or a DHCP address, or a static address) _is_ reducing the threat. It might or might not be secure enough for any particular purpose, but it is more secure than accepting packets from any location. If every link has IPSEC (or CIPE, whatever), then that would be more secure. But I don't see it happening in a zeroconf environment, so we are back to what is practical. If we switch to TTL=1, then the threat opportunity goes up. So this would need to be compensated for by some other threat reduction that has about the same ease-of-use. I don't know of any, but this is worth examining. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE94+PeW6pHgIdAuOMRApA9AJ4tcmGe/bWfK+Vj2I40ySm/qDULvQCeJdiK JpWEUbnLL6dGPUwmxUEDVpc= =2iLR -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Nov 26 16:33: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 QAA21859 for ; Tue, 26 Nov 2002 16:33:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9ABF89126A; Tue, 26 Nov 2002 16:35:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 665F39126C; Tue, 26 Nov 2002 16:35:37 -0500 (EST) 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 585209126A for ; Tue, 26 Nov 2002 16:35:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39AC05DEFD; Tue, 26 Nov 2002 16:35:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta01bw.bigpond.com (mta01bw.bigpond.com [139.134.6.78]) by segue.merit.edu (Postfix) with ESMTP id C5AC25DE93 for ; Tue, 26 Nov 2002 16:35:34 -0500 (EST) Received: from pc-00045 ([144.135.24.78]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Jul 16 2002 22:47:55) with SMTP id H67DB800.041; Wed, 27 Nov 2002 07:35:32 +1000 Received: from CPE-203-51-31-27.nsw.bigpond.net.au ([203.51.31.27]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 35/7735351); 27 Nov 2002 07:35:55 From: Brad Hards To: "Jeb R. Linton" , Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 08:24:58 +1100 User-Agent: KMail/1.4.5 References: <015401c29590$9c3fc790$6400a8c0@laptop2> In-Reply-To: <015401c29590$9c3fc790$6400a8c0@laptop2> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200211270824.58693.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Nov 2002 08:12, Jeb R. Linton wrote: > > From: owner-zeroconf@merit.edu On Behalf Of Brad Hards > > > > If you SET 1 on sending, then you do not know if the packet > > originated on the local link, but you do know that, even > > in the presence of pretty broken routing, the packet is > > unlikely to leave the local link. There is no point in > > checking on receipt. > > Not necessarily true, IMHO. If compatibility rather than security is to > be the default behavior, the standard could be to set TTL=1. This would > allow potentially useful TTL=1 checking as a user option in order to > catch the majority of script-kiddie DoS attacks. As was pointed out > earlier, an attacker would have to match the TTL to the true number of > hops in order to defeat this, so it seems likely that this would offer > protection from a good percentage of attacks. traceroute(8) will make the script automatic. I agree with your point about checking TTL causing breakage. If you are going to check for anything, then it has to be TTL=255. Anything else is just pain for no real benefit. The other issue that I should have brought up before is the real need for interoperability. Link-local addresses aren't really that useful in most of the current implementations. It is possible to fix the current implementations with some admin work (registry hacks, updating to better operating system), so how much pain are we talking about by enforcing TTL checks from the day of the RFC issue? Brad Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE94+aqW6pHgIdAuOMRAlUwAKCdrIZkje+hq9UUhDmgCzV+1n5DpwCfb4xg a70Czg/dWunFkLCZat/kM6o= =7pyX -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Nov 26 17:17:31 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 RAA23371 for ; Tue, 26 Nov 2002 17:17:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AFC291225; Tue, 26 Nov 2002 17:20:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64B9F9126C; Tue, 26 Nov 2002 17:20:02 -0500 (EST) 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 1FB6E91225 for ; Tue, 26 Nov 2002 17:20:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02F565DFCB; Tue, 26 Nov 2002 17:20:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from staff1.cso.uiuc.edu (staff1.cso.uiuc.edu [128.174.5.59]) by segue.merit.edu (Postfix) with ESMTP id 9DCF35DFCA for ; Tue, 26 Nov 2002 17:20:00 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by staff1.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gAQMK0k21685; Tue, 26 Nov 2002 16:20:00 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gAQMJxI07392; Tue, 26 Nov 2002 16:19:59 -0600 (CST) Date: Tue, 26 Nov 2002 16:19:59 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: Daniel Senie , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Message-ID: <20021126221959.GA6931@uiuc.edu> Reply-To: jak@uiuc.edu References: <5.2.0.9.2.20021126135506.029cd798@mail.amaranth.net> <200211262024.gAQKObl22290@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211262024.gAQKObl22290@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, Nov 26, 2002 at 03:24:37PM -0500, Keith Moore scratched on the wall: > > > In the case here, it seems like the 255 > > >check provides a small security benefit, with the emphasis on > > >small. > > > > Given the requirements on zeroconf being discussed, it may represent the > > ONLY security available to some devices. > > in my mind, that argues for requiring TTL=1. companies shipping > product that depend on LL as a security mechanism deserve to lose. You want to design something that is intentionally easy to break and generate bogus packets for? Just to force people to fix their routers? Isn't that kind of like designing a connection protocol that prevents passwords just to force you to setup your firewall correctly? > if you use IP, you need to be able to accept traffic from anywhere. This is simply not true. How may 10.x.x.x hosts are there connected, in some way, to the Internet? Several thousand? million? How many should I be able to reach? Exactly one (or zero). Not everything is globally routed. Link-local addresses are the essence of this idea. Having a system in place that can verifies correct routing (TTL=255), even if it does not PREVENT incorrect routing, is of great value-- especially in an environment where most of the address space is automatically setup and don't inherently depend on any or on a correct routing infrastructure. Having a system that cannot prevent incorrect routing since the sender can override the checked value (TTL=1+) NOR can it verify correct routing has no value at all. > relying on LL to provide security is simply unacceptable, and IETF > should not endorse the practice. This isn't a question of security beyond the basic idea of A) make sure the packets are correctly routed and B) prevent a script-kiddie from being able to make the system eat itself. Link-local addresses should be link-local. That's the whole point. If you choose to use that condition as part of your bigger data-security plan, that is somewhat questionable, but that doesn't change the fact that "link-local is link-local" should be a routing invariant. Since the whole point of link-local is that it is, well, local, that should ultimately be enforced by the hosts, not the router. TTL=255 gives the hosts the power to check for valid routing. TTL=1 gives you nothing that can't be faked. I would consider the TTL=255 check more of an operational "sanity check" then one having to do with true security. It is really like the idea of "Don't respond to ICMP echo requests that don't have a desk address equal to your unicast address (e.g. not broadcasts)." No, it doesn't keep the packets from getting there, and yes, the host still has to process and discard the packet, but it also keeps the network from killing itself when some outsider tries a simple attack like sending a ICMP echo request to a large subnet's broadcast address. Getting back to the 10.x.x.x example, one of the key ideas in routing is that if machine A (w/ the address 10.0.0.1) sends me a packet from 10.0.0.1 to my address of 128.128.128.128, and I send a packet from 128.128.128.128 to 10.0.0.1, it should go to the same machine the original packet came from. This is a really basic and core fundamental assumption of IP routing. TTL=255 allows hosts (the key "routing" systems in link-local addresses) to enforce this and recognize bogus packets. No other test does. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Tue Nov 26 17:33:20 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 RAA23871 for ; Tue, 26 Nov 2002 17:33:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BDE69126E; Tue, 26 Nov 2002 17:35:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7A8A9126F; Tue, 26 Nov 2002 17:35:50 -0500 (EST) 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 B74C39126E for ; Tue, 26 Nov 2002 17:35:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B84A5DF4B; Tue, 26 Nov 2002 17:35:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 325A45DEB9 for ; Tue, 26 Nov 2002 17:35:49 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA06757 for ; Tue, 26 Nov 2002 17:35:48 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA09809 for ; Tue, 26 Nov 2002 17:35:48 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA13162 for ; Tue, 26 Nov 2002 17:35:47 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 26 Nov 2002 17:35:45 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211261851.gAQIp8w08690@cichlid.adsl.duke.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/26/2002 13:51, "Thomas Narten" wrote: > >> I think the benefit to having the TTL check is an operational one, >> not especially a security one. Operationally it is strongly desirable >> for link-local packets to not exit the link. This significantly >> reduces the probability of a link-local packet exiting the link. > > Huh? If you don't want a LL packet to exit a local link, set the TTL > to 1, and/or have routers be configured to never forward them. The > latter requirement is already in the spec. The former is a step that > will help if the router doesn't know to filter LL packets. Then the router is misconfigured, since the addresses used for LL addressing should preclude them getting routed at all. Routers shouldn't be forwarding that address range anyway, so the TTL is just an extra step to help ensure this > > A LL is much more likely to get forwarded off link if the TTL is 255! If the router's not working right, the TTL can be completely ignored too, so maybe we should not use TTL at all anywhere, since it's evidently a bad idea to rely on it. > >> So I'd prefer language like this: > >> - MUST set TTL == 255 on transmission of a link-local packet >> - SHOULD check TTL == 255 on receipt of a link-local packet > > Meaning, if TTL != 255, discard the packet? The concern I'm asking > about is that with this behavior, we get non-interoperability with > currently deployed devices. Then those devices aren't following LL spec anyway, and need to be updated. Vendor software/firmware updates should handle this. > >> - MAY have a configuration knob to allow receipt of TTL != 255 >> link-local packets but knob MUST default to only accept >> TTL == 255 > > This is even stronger than the current wording in the document. And it's a better idea. > >> This permits the operator to enable a broken mode for compatibility, >> and lets the rest of us migrate in a more useful direction >> operationally. > > In a home network, where grandma is the operator, seems to me like > there will be no configuration possible. The default settings will > rule. In a home network, the chances of using LL in this fashion are highly slim. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Nov 26 17:33:45 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 RAA23894 for ; Tue, 26 Nov 2002 17:33:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9DBF19126F; Tue, 26 Nov 2002 17:36:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B01E91270; Tue, 26 Nov 2002 17:36:06 -0500 (EST) 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 6F3CB9126F for ; Tue, 26 Nov 2002 17:36:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BBAF5DF4D; Tue, 26 Nov 2002 17:36:02 -0500 (EST) 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 F33A55DF4B for ; Tue, 26 Nov 2002 17:36:01 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQMZUl23013; Tue, 26 Nov 2002 17:35:30 -0500 (EST) Message-Id: <200211262235.gAQMZUl23013@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , Thomas Narten , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 08:13:02 +1100.") <200211270813.02905.bhards@bigpond.net.au> Date: Tue, 26 Nov 2002 17:35:30 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > link locals are not a security mechanism. > > therefore the correct choice is to set TTL=1. > > I'm not so sure. > > I agree that it is Evil and Wrong to not consider security. But security is a > relative thing. And only accepting packets from the local link (whether you > do this on an interface with a link-loal address, or a DHCP address, or a > static address) _is_ reducing the threat. you don't know that without knowing where the threats are coming from, and that's not something a vendor can reliably predict. I like to say that address filtering simplifies the threat analysis, but it doesn't necessariy reduce the threat to any significant degree. > If we switch to TTL=1, then the threat opportunity goes up. So this would > need to be compensated for by some other threat reduction that has about > the same ease-of-use. no. first of all, security for light switches is not in scope for zeroconf's charter. second, imposing an arbitrary constraint on security like "as easy to use as something that requires no setup" is meaningless. what you seem to be trying to do is insist that IETF standardize a security mechanism that provides no assurance of security. Keith From owner-zeroconf@merit.edu Tue Nov 26 17:35:44 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 RAA24024 for ; Tue, 26 Nov 2002 17:35:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 216C091270; Tue, 26 Nov 2002 17:38:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCDB191271; Tue, 26 Nov 2002 17:38:08 -0500 (EST) 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 C8F8C91270 for ; Tue, 26 Nov 2002 17:38:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3A2A5DF4B; Tue, 26 Nov 2002 17:38:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 4B7015DEB9 for ; Tue, 26 Nov 2002 17:38:07 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA07598 for ; Tue, 26 Nov 2002 17:38:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA06073 for ; Tue, 26 Nov 2002 17:38:06 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA13956 for ; Tue, 26 Nov 2002 17:38:05 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 26 Nov 2002 17:38:03 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3DE3C4FA.4060209@nc.rr.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/26/2002 14:01, "Brian Haberman" wrote: > >> In a home network, where grandma is the operator, seems to me like >> there will be no configuration possible. The default settings will >> rule. > > This scenario is exactly why I like the idea of making the proposed > change. I don't think we can justify losing the backwards > inter-operability given the environment that zeroconf networks will > exist. There are almost no zeroconf networks now to begin with, outside of random iChat circles, so we do have a fairly clean slate. If you don't think that setting TTL to 255 is reliable, then setting it to 1 is no better. A bad configuration can ignore a small number as easily as a larger one. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Nov 26 17:38:15 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 RAA24127 for ; Tue, 26 Nov 2002 17:38:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B85191272; Tue, 26 Nov 2002 17:40:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D43691273; Tue, 26 Nov 2002 17:40:54 -0500 (EST) 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 58A1991272 for ; Tue, 26 Nov 2002 17:40:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 451825DF4B; Tue, 26 Nov 2002 17:40:51 -0500 (EST) 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 DD7DF5DEB9 for ; Tue, 26 Nov 2002 17:40:50 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQMeil23068; Tue, 26 Nov 2002 17:40:44 -0500 (EST) Message-Id: <200211262240.gAQMeil23068@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , Daniel Senie , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Tue, 26 Nov 2002 16:19:59 CST.") <20021126221959.GA6931@uiuc.edu> Date: Tue, 26 Nov 2002 17:40:44 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Tue, Nov 26, 2002 at 03:24:37PM -0500, Keith Moore scratched on the wall: > > > > In the case here, it seems like the 255 > > > >check provides a small security benefit, with the emphasis on > > > >small. > > > > > > Given the requirements on zeroconf being discussed, it may represent the > > > ONLY security available to some devices. > > > > in my mind, that argues for requiring TTL=1. companies shipping > > product that depend on LL as a security mechanism deserve to lose. > > You want to design something that is intentionally easy to break and > generate bogus packets for? Just to force people to fix their > routers? Nope. I want to design something that allows ad hoc networks to be self-configuring (as described in the group's charter), but which makes absolutely no claims about providing security. Trying to make this into a security mechanism just won't fly. > > if you use IP, you need to be able to accept traffic from anywhere. > > This is simply not true. How may 10.x.x.x hosts are there connected, > in some way, to the Internet? Several thousand? million? How many > should I be able to reach? Exactly one (or zero). You're asking the wrong question. Try this: for how many of those hosts is the use of 1918 addresses a sufficiently effective security mechanism by itself to prevent attacks on those hosts? answer: not many, because it's too easy to tunnel, and there are too many threats are from inside. Keith From owner-zeroconf@merit.edu Tue Nov 26 17:38:18 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 RAA24145 for ; Tue, 26 Nov 2002 17:38:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B70B691271; Tue, 26 Nov 2002 17:40:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86B3091272; Tue, 26 Nov 2002 17:40:38 -0500 (EST) 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 4C8F591271 for ; Tue, 26 Nov 2002 17:40:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 362C85DF4B; Tue, 26 Nov 2002 17:40:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id C05FF5DEB9 for ; Tue, 26 Nov 2002 17:40:35 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA08715 for ; Tue, 26 Nov 2002 17:40:35 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA06410 for ; Tue, 26 Nov 2002 17:40:34 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA14647 for ; Tue, 26 Nov 2002 17:40:34 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 26 Nov 2002 17:40:32 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <5.2.0.9.2.20021126142814.02999660@mail.amaranth.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/26/2002 14:30, "Daniel Senie" wrote: > >> - if the receiver wants to verify that a packet didn't originate off >> link, all it sees is the TTL when it reaches the recipient. It could >> have a TTL of 1 because it started with a TTL of 10, but went >> through 9 routers... But if one verifies that that the TTL is 255, >> that's a pretty good sign the packet didn't travel through any >> routers. One can assume that Bad Guys will set the TTL to something >> other than 1 if they are trying to cause problems... > > Very true. Another reason to not have routers touch link local packets at > all. Perhaps another short document updating RFC 1812 is in order. This would be the most logical idea, and a more reliable solution. But then again, wouldn't you have the same problems with backwards compatibility with this solution as well. being too slavish to backwards compatibility results in nothing getting done. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Nov 26 17: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 RAA24237 for ; Tue, 26 Nov 2002 17:42:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6245691273; Tue, 26 Nov 2002 17:44:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DEBD91274; Tue, 26 Nov 2002 17:44:52 -0500 (EST) 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 23E6A91273 for ; Tue, 26 Nov 2002 17:44:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DF615DFC9; Tue, 26 Nov 2002 17:44:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 98A785DEB9 for ; Tue, 26 Nov 2002 17:44:50 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA10379 for ; Tue, 26 Nov 2002 17:44:49 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA06966 for ; Tue, 26 Nov 2002 17:44:49 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA15895 for ; Tue, 26 Nov 2002 17:44:49 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 26 Nov 2002 17:44:47 -0500 Subject: Re: use of LL by light switches From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211262044.gAQKill22544@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/26/2002 15:44, "Keith Moore" wrote: > you know, I don't see anything in zeroconf's charter that says that > it is supposed to make IP usable by stupid light switches. > > zeroconf's problems were difficult enough to solve without extending > its scope far beyond that which was intended. Keith's got a point here...let's keep the spec as simple as possible, without getting into arguments on possible permutations of future configurations that may create the possibility that you might lose power just as the winner of "Survivor: Atlantis" was announced. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Nov 26 17:46:21 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 RAA24330 for ; Tue, 26 Nov 2002 17:46:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB1D191274; Tue, 26 Nov 2002 17:48:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72AE091275; Tue, 26 Nov 2002 17:48:49 -0500 (EST) 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 8B30291274 for ; Tue, 26 Nov 2002 17:48:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 782185DEB9; Tue, 26 Nov 2002 17:48:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 09FDA5DE2A for ; Tue, 26 Nov 2002 17:48:48 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gAQMmkQ16479 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 26 Nov 2002 17:48:47 -0500 Message-Id: <5.2.0.9.2.20021126174501.02a30248@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 17:46:54 -0500 To: Zeroconf From: Daniel Senie Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: References: <5.2.0.9.2.20021126142814.02999660@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 05:40 PM 11/26/2002, John C. Welch wrote: >On 11/26/2002 14:30, "Daniel Senie" wrote: > > > > >> - if the receiver wants to verify that a packet didn't originate off > >> link, all it sees is the TTL when it reaches the recipient. It could > >> have a TTL of 1 because it started with a TTL of 10, but went > >> through 9 routers... But if one verifies that that the TTL is 255, > >> that's a pretty good sign the packet didn't travel through any > >> routers. One can assume that Bad Guys will set the TTL to something > >> other than 1 if they are trying to cause problems... > > > > Very true. Another reason to not have routers touch link local packets at > > all. Perhaps another short document updating RFC 1812 is in order. > >This would be the most logical idea, and a more reliable solution. But then >again, wouldn't you have the same problems with backwards compatibility with >this solution as well. being too slavish to backwards compatibility results >in nothing getting done. There is always that tradeoff. RFC 2644 updates 1812. I'm sure it took a while before it was implemented. Was it worth doing, though? I think so. I see no reason why such a document couldn't be generated to complement the LL draft. I'd be happy to whip this up and submit it, if the chairs would like. From owner-zeroconf@merit.edu Tue Nov 26 17:46:47 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 RAA24355 for ; Tue, 26 Nov 2002 17:46:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 784FF91275; Tue, 26 Nov 2002 17:49:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47F7891276; Tue, 26 Nov 2002 17:49:15 -0500 (EST) 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 420D491275 for ; Tue, 26 Nov 2002 17:49:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F9965DEB9; Tue, 26 Nov 2002 17:49:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id BAA085DE2A for ; Tue, 26 Nov 2002 17:49:13 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA25115 for ; Tue, 26 Nov 2002 17:49:13 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA11574 for ; Tue, 26 Nov 2002 17:49:12 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17162 for ; Tue, 26 Nov 2002 17:49:12 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 26 Nov 2002 17:49:10 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211262235.gAQMZUl23013@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/26/2002 17:35, "Keith Moore" wrote: > > what you seem to be trying to do is insist that IETF standardize a > security mechanism that provides no assurance of security. It's not a security mechanism, unless you think that hiding your eyes means people can't see you. It's a fairly simple way to prevent packets from going places they shouldn't. If you consider that a security mechanism, it still isn't. It's more of a nuisance prevention device. I don't see any particular advantage to setting the TTL to 1 over 255, or vice versa, so I vote for inertia, and leave it where it is at 255. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Nov 27 04:48: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 EAA04615 for ; Wed, 27 Nov 2002 04:48:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 835829122C; Wed, 27 Nov 2002 04:50:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40E8B91276; Wed, 27 Nov 2002 04:50:44 -0500 (EST) 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 227689122C for ; Wed, 27 Nov 2002 04:50:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 087DB5DE1A; Wed, 27 Nov 2002 04:50:43 -0500 (EST) 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 A2E325DE06 for ; Wed, 27 Nov 2002 04:50:42 -0500 (EST) 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 CAA19348; Wed, 27 Nov 2002 02:50:41 -0700 (MST) Received: from track (track [129.157.142.2]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAR9odl16956; Wed, 27 Nov 2002 10:50:39 +0100 (MET) Date: Wed, 27 Nov 2002 10:52:17 +0100 (MET) From: Erik Guttman X-Sender: erikg@track To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200211261802.gAQI2Cu07879@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 26 Nov 2002, Thomas Narten wrote: > One more issue with this document (the IESG has already sent back a > number of comments -- I hope the WG starts working on revising the > document soon!) OK, let's wrap this up. > The document has the following text with regards to TTLs: > > > 2.7 Link-Local Packets Are Not Forwarded > > > > Any host sending an IPv4 packet with a source and/or destination > > address in the 169.254/16 prefix MUST set the TTL in the IP header > > to 255. This includes multicast and broadcast packets with a source > > address in the 169.254/16 prefix. > > > > This allows hosts to guard against misconfigured routers, which may > > allow packets to leak in from outside the local link. Since even the > > most dysfunctional router will decrement the TTL in the IP header, a > > host can know with reasonable certainty that any packet received with > > a TTL of 255 did come from another host on the local link. A host > > receiving a packet with a source and/or destination address in the > > 169.254/16 prefix and a TTL less than 255, MAY choose to consider > > such packets as potentially having been generated by a malicious > > attacker outside the local link, and MAY choose to silently discard > > such packets. [See Appendix for details of current implementations.] > > I have received some private comments (with which I happen to agree) > that the above paragraph essentially blesses non-interoperability, or > makes it much more likely that non-interoperability will result from > this spec. That is, there are currently deployed boxes that use LL > addresses, but that don't set the TTL to 255. Consequently, any check > of the TTL in received packets will result in failed communication > with some boxes. The IETF traditionally takes a dim view of having > specs encourage behavior that is non-backwards compatable, unless > there is compelling benefit. In the case here, it seems like the 255 > check provides a small security benefit, with the emphasis on > small. It is not clear that the potential benefts outweigh the > downsides. > > I can imagine several ways to address this issue: > > - allow the above MAY, but require that the default setting be to > disable the check, so that folks need to explicitely enable it, in > which case they are making the choice to be non-interoperable with > some devices. > > - get rid of the idea of the check at all, as it provides too little > security in practice to be useful. --- Discussion on the list indicates that there are good reasons for requiring senders MUST send TTL=255. These arguments have stood up to scrutiny, has passed several last calls and are not put in question by Thomas's email. The discussion of using TTL=255 as a security precaution leads nowhere. Let us focus on the real problem: This is an operational issue. It enables receivers to accomodate routers which do forward link-local packets by discarding off-link packets. Proposed action: Change the v4 LL document to reflect that this is an *operational* not a *security* consideration. The only open question is how to handle the case of existing hosts which send LL datagrams with TTL=1. Currently receivers MAY discard such packets. Hosts conforming with this spec that send TTL=255, coupled with routers not explicitely configured to 'not forward 169.254', will *exacerbate* the operational problem. The best thing would be to state that hosts MUST drop datagrams from 169.254 with TTL != 255. Here there are no options, no configuration required, no variations in behavior. This would certainly make life easier for operators and users - since they could expect that their link-local devices would only ever operate link-local. This does not address the installed base, however. Stuart, Bernard, would it be feasible for Microsoft and Apple to agree this as a MUST and see new versions of Windows and MacOS fail to interoperate with deployed ones? I suspect not. Therefore, my suggestion is to change MAY to a SHOULD, and to state in strong terms that the SHOULD is only to support legacy systems shipped from 1998-2001 and that failing to discard these packets will likely lead to operational problems. Proposed action: Change MAY to SHOULD and add admonishments. Taken together, my proposals amount to: A host receiving a packet with a source and/or destination address in the 169.254/16 prefix and a TTL less than 255, MAY choose to consider such packets as potentially having been generated by a malicious attacker outside the local link, and MAY choose to silently discard such packets. [See Appendix for details of current implementations.] becomes -> A host SHOULD silently discard all packets it receives which have a source and/or destination address in the 169.254/16 prefix and a TTL less than 255. The only justification for not silently discarding such packets is backwards compatibility with current implementations. [See Appendix for details of current implementations.] This justification for failing to discard packets will diminish with time. Implementors of this specification are strongly advised that failure to discard packets will likely result in the following operational difficulty. * Many routers improperly forward packets with a 169.254/16 prefix destination. * Hosts conforming to this specification will send with TTL=255. * Therefore, non-discarding hosts will receive and accept packets from senders who are not on the same link. This will lead to unexpected behavior and failure modes which are likely to be difficult to diagnose. Erik From owner-zeroconf@merit.edu Wed Nov 27 06:50: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 GAA06325 for ; Wed, 27 Nov 2002 06:50:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1754291279; Wed, 27 Nov 2002 06:52:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCE199127A; Wed, 27 Nov 2002 06:52:34 -0500 (EST) 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 6593791279 for ; Wed, 27 Nov 2002 06:52:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47D225E016; Wed, 27 Nov 2002 06:52:33 -0500 (EST) 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 AFC2B5DEB2 for ; Wed, 27 Nov 2002 06:52:32 -0500 (EST) 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 EAA29557; Wed, 27 Nov 2002 04:52:31 -0700 (MST) Received: from track (track [129.157.142.2]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gARBqTl21556; Wed, 27 Nov 2002 12:52:29 +0100 (MET) Date: Wed, 27 Nov 2002 12:54:06 +0100 (MET) From: Erik Guttman X-Sender: erikg@track Reply-To: Erik Guttman To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200210041911.g94JB5l15100@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Thomas, As we iron out points, I will see to it that a new draft comes out. Hopefully, we will polish the issues off quickly. - - - On Fri, 4 Oct 2002, Thomas Narten wrote: > The IESG discussed this document recently, and has the following > comments. > > DISCUSS: > ======== > Harald: > > Three objections, based on a quick scan: > > 1) > > The document gives no (zero) examples of applications that can > successfully and safely be used with link-local addresses. I think a > list of applications would serve two purposes: > > - document the motivation for this feature > - serve as target for people arguing that this application has > serious failure modes when used with link-local addresses Application examples: Tha classic peer to peer applications are 'File sharing' - NFS and ONC RPC based protocols, SMB 'Local printing' - LPD Let's add 'Local web browsing' - FTP, HTTP 'Local administration' - telnet Caveats: General - This does not describe how a link-local address is configured with the application. This could be done using LLMNR, SLP, etc. This implies that 'link-local locators' (names and addresses that have only link- local significance) can obtained service queries (SLP), or name lookups (LLMNR), etc. Since link local addresses may change over time (unlikely, but possible), it is best to obtain them dynamically (using SLP or LLMNR, etc.) Link-local local locators which are forwarded off-link are worthless. Therefore, some protocols, such as conferencing or those which build session based directories to forward locators would fail. An example of how a protocol which supports forwarding of locators can be made to work in a scoped address environment is in RFC 3111, SLP modifications for IPv6. The only trick is to keep information which is received using a scoped address separate, and to only forward it to others in the same scope as it was received. The following comments apply equally to any use of these protocols in scoped or private address spaces. HTTP - Redirects [RFC 2616, Section 10.3] and the Content-Location header in general [RFC 2616, Section 14.14] will have to be link-local locators in order for a client configured with a link-local address to make use of it. HTML - URIs refered to in anchors, etc. must be link-local locators in order for a a client configured with a link-local address to make use of it. > 2) > > The following section: > > > 2.10 Higher-Layer Protocol Considerations > > > > Similar considerations apply at layers above IP. > > > > For example, 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. > > > > 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. > > is not sufficiently draconian. > > It should probably say something like: > > The following set of protocols: > > - FTP > - DNS > - NFS > - IPSEC using IPv4 as an identifier > - BGP > - OSPF > - RTP/RTCP > <<>> > > will fail if applications use a link-local address instead of a > globally unique address when sending the address of its interface in > a protocol packet. In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK. Why is this the case with FTP, DNS, NFS, RTP/RTCP? If the sender and receiver are both on the same link these protocols should work fine, I believe. Argument why link-local traffic will stay link-local: If they are not on the same link, theneither the router should prevent the message from reaching the link-local destination or from leaving the link-local source. In any case, link-local receivers will silently discard packets unless TTL=255 (modulo discussion in another thread). > 3) > > Security consideration, section 2.8: > > > 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. Any network gateway device > > that blindly forwards the contents of link-local IP packets off the > > local link (or onto the local link) exposes simple link-local-only > > devices to a much greater degree of risk than their designers may > > have planned for. > > In the world of wireless LANs, this seems to be an extremely stupid > idea. (not that it was a smart move before.....for kicks, try plugging > an X10 controller into your neighbour's outdoor electrical socket and > start playing....) > I would suggest to add a NOTE: > > NOTE: The existence of local links without physical security, such as > LANs with attached wireless base stations, means that expecting all > local links to be secure enough that normal precautions can be dispensed > with is an extremely dangerous practice, which will expose users to > considerable risks. OK. > Steve: > How do current hosts behave with respect to this: > > All ARP packets (*replies* as well as requests) that contain a > link-local 'sender IP address' MUST be sent using link-level > broadcast instead of link-level unicast. This aids timely > detection of duplicate addresses. An example illustrating how this > helps is given in Section 4. > > (I understand the necessity, but is it done? I suspect not. This > suggests that there be a warning that link-local addresses SHOULD NOT > be manually configured.) This is already in the text. 1.4. 169.254/16 Not To Be Used for Other Purposes Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually or by a DHCP server. Manual or DHCP configuration may cause a host to use an address in the 169.254/16 prefix without following the special rules regarding duplicate detection and automatic configuration that pertain to addresses in this prefix. > I have vague recollections of an RFC that permits hosts to ignore > spontaneous ARP replies, i.e., those not in response to a query, in an > effort to block connection hijacking. I think that some hosts actually > do this. That would interfere with the claim-and-defend mechanism, and > with renumbering, I believe. I assume that this RFC is an elective standard. Hosts which support claim-and-defend will require new code. If the upgraded stacks contain old code which conflicts with this new code, the implementor must decide which standards to implement. > What use is link-local security in a world of wireless bridges? I think that this point is addressed in the NOTE proposed in section 2. > The Security Considerations section should note that address-based IKE > certificates [RFC2409, I think] MUST NOT be issued for link-local > addresses. OK. > How does Windows XP behave? Windows XP uses the machine name in certificates issued for use with IPsec. > Alex: > Seems to me that a "routing considerations" section is required. > Some things that should be described: My opinions follow. > - should a route be installed in the routing table based > on the link-local address on an interface? This depends on the host implementation, right? > - should/can the 169.254/16 prefix be announced by dynamic > routing protocols? Section 2.7 An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IP header. No. Datagrams whose source or destination address is in this prefix MUST NOT be forwarded. > - if received from a routing protocol, should the prefix > be installed in the RT? No, see above. > - what the behavior should be if the prefix somehow > made it to the RT (static route, old routing proto)? The host MUST NOT send packets to routers for forwarding. This is unambiguous. > Erik: > > The abstract and first paragraph in the introduction can easily be > read as these addresses being a full-fledged replacement of DHCP > assigned addresses. Having the text explicitly say that such > addresses can not be used for communication outside a single link > would make sense. OK. > In the applicability section it would make sense to add explicit > warnings about issues for applications. One issue is the addresses > are of limited scope which might cause problems for multi-party > applications that pass IP addresses between parties. > The other issue is that these addresses might have much shorter and > unpredictable lifetime, which would have an impact on applications > using them on the link. (This is true especially given the > suggestions in section 2.5 to pick a new address when a conflict is > detected after the address has been used for a while.) Are Sections 7. 1 and 7.2 insufficient? > The text in section 2.5 says that in some cases the host MUST cease > using the address. Since it is easy for an on-link attacker to spoof > the ARP packets it can cause the host to break all its connections by > switching to a new address. The document should at least warn against > this in section 2.5, and presumably also discuss it in the security > considerations section. We can add this to Section 5: The ARP protocol [RFC 826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with replies giving its own hardware address, thereby claiming ownership of every address on the network. add -> It would also be possible for an on-link attacker to spoof ARP packets which would cause a host to break all its connections by switching to a new address. Please note that there are similar attacks which exist against hosts which use global addresses. An on-link attacker could spoof ARP packets which would cause a packets destined for a host to be redirected to the attacker, who could discard them, etc. > And here is a "bonus" I didn't mention on the call: > The time values specified above are intended for use on > technologies such as Ethernet, where switches that implement > Spanning Tree [802.1d] often silently discard all packets for > several seconds. The time values specified above result in a > delay of 8-10 seconds before a chosen IP address may be used. > For a desktop machine on Ethernet, > > FWIW when 802.1d is enabled on the port I plug in my laptop at the > office, the delay before the switch starts forwarding packets is 45 > seconds. (I think the 802.1d spec indicates a default time of around > 30 seconds.) So 10 seconds don't seem to do much good. 2.3 Shorter Timeouts on Appropriate Network Technologies The time values specified above are intended for use on technologies such as Ethernet, where switches that implement Spanning Tree [802.1d] often silently discard all packets for several seconds. The time values specified above result in a delay of 8-10 seconds before a chosen IP address may be used. add --> In some cases, the delay can be considerably longer due to other networking infrastructure. The purpose of this section is to give some guidance to implementors to set appropriate values for their timers, not to definitively answer what those settings should be. > If the destination address is the 255.255.255.255 broadcast > address or a multicast address, then the host may use either > its link-local source address or a routable address, as > appropriate. > > OK for a link-local multicast destination. But for other multicast > destinations I assume it SHOULD use any routable address instead of > the link-local. OK. > section 3.2: > Some operating systems have networking APIs that allow > applications to specify network interfaces by name, index value, > or other local identifier, and to identify interfaces this way > both for incoming and outgoing packets/connections. For operating > systems that have this capability (and have application software > that makes use of it) it is sufficient to configure all interfaces > with a single common IPv4 link-local address, and defend that > address on all interfaces. > > Add warning that uses the same address on all interfaces makes the host > more suceptible to attacks and other reasons for duplicate addresses > being detected late, resulting in a shorter lifetime for the link-local > addresses. Using a separate address per interface limits the "damage" > in such a case to a single link. OK. This can be added to Section 5. > section 3.3 > In addition, this kind of host should probe for, and defend, all > of its link-local addresses on all of its active interfaces that > are using link-local addresses. > > When bringing up a new interface, the host SHOULD first probe > for all of its existing link-local addresses on that new interface. > If any of the addresses are found to be already in use by some > other host on that new link, then the interfaces in question MUST > be reconfigured to select new unique link-local addresses. > The > host should then select a link-local address for the new interface, > and probe on all of its active interfaces to verify that this new > address is unique on all the links that the host has connections to. > The above breaks if multiple interfaces on the host are connected > to the same link. It also isn't clear to me why this is needed; > presumably the interfaces can be managed indepdently as long as the host > ensures that it doesn't assign the same link-local address to more than > one interface. This paragraph assumes the right thing to do is configure all interfaces with the same link-local address. Either (a) The paragraph must be augmented with the following: Host must consider the case where more than one interface is connected to the same link. Say the list of link-layer addresses for a given host is L. The claim-defend algorithm MUST consider the case when arp sender link-layer address is in L. In this case, the IP sender address field in the arp message *does not* constitute a conflict necessitating the host to select another address for any interface in the list L. (b) Each interface should be assigned a different v4LL address and can then operate independently. (b) is simpler, and as you state above, it is less instable due to address reconfiguration events and has fewer security consequences. Further, (a) relies upon all link-layer addresses being unique, which is not necessarily true and not required for (b). Proposal: (b) > Thomas: > > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host SHOULD use its link- > local source address, if it has one. If the host does not have a > link-local source address, then it MAY choose to ARP for the > destination address and then send its packet, with a routable source > IP address and a link-local destination IP address, directly to its > destination on the same physical link. The host MUST NOT send the > packet to any router for forwarding. > > The above wording suggests that if host has no LL address, but it does > have a global address, it is not required to use that global address > to talk to a device that only has a LL address. This seems > broken. I.e, it will result in communication failure that is hard to > diagnose. Two nodes, both with legitimate addresses that should work, > for some strange reason won't talk to each other. Seems to me like the > MAY should really be a MUST. You can't NOT use the global address, if > it's the only address you have. Or, if there are legitimate reasons > why an implementation might not want to use its global address in this > case (knowing that communication will fail as a result) please include > some background explaining why this might be a reasonable approach. > > COMMENT > ------- > Scott: notes: > references not split > this can get fixed when Harald's discuss is delt with > OK. Erik From owner-zeroconf@merit.edu Wed Nov 27 07:18:00 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 HAA07041 for ; Wed, 27 Nov 2002 07:17:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4246A9127A; Wed, 27 Nov 2002 07:20:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DDE89127D; Wed, 27 Nov 2002 07:20:32 -0500 (EST) 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 0C0D19127A for ; Wed, 27 Nov 2002 07:20:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A69F15DEB2; Wed, 27 Nov 2002 07:20:31 -0500 (EST) 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 63D325DE19 for ; Wed, 27 Nov 2002 07:20:31 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id C2A4767103; Wed, 27 Nov 2002 03:44:50 -0500 (EST) Date: Wed, 27 Nov 2002 07:20:21 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Erik Guttman From: RJ Atkinson In-Reply-To: Message-Id: <991245F4-0202-11D7-9C68-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Nov 27, 2002, at 06:54 America/Montreal, Erik Guttman wrote: >> is not sufficiently draconian. >> >> It should probably say something like: >> >> The following set of protocols: >> >> - FTP >> - DNS >> - NFS >> - IPSEC using IPv4 as an identifier >> - BGP >> - OSPF >> - RTP/RTCP >> <<>> >> >> will fail if applications use a link-local address instead of a >> globally unique address when sending the address of its interface in >> a protocol packet. > > In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK. With respect to AH/ESP, the original claim (from IESG ?) is utter nonsense. A correct statement would be something like this: If one has a Security Association between a pair of hosts (A, B) on a common link, AH/ESP will work only if the IP addresses used in the packet are consistent with the IP addresses that are part of the Security Association in use. This means that if the Security Association uses link-local addresses, then the packets MUST use those same link-local addresses. This also means that if the Security Association uses global IP addresses, then the packets MUST use those same global IP addresses. I also do not believe that some of the protocols claimed as broken-by-link-local by the IESG (e.g. NFS) do NOT necessarily break just because link-local addresses are used. In fact, I might have an NFS server at home (that works fine using link-local IP addresses) as an existence proof counter-example. If the IESG want to say that an NFS server cannot be contacted from off-link by using the NFS server's link-local address, then yes that is true and a bit of a tautology. But an NFS server that is on-link most assuredly can be contacted from on-link using link-local addressing. The IESG appear to be behaving religiously about this and seem to have lost the needed technical precision in their claims. Not good. Ran From owner-zeroconf@merit.edu Wed Nov 27 07:30:15 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 HAA07341 for ; Wed, 27 Nov 2002 07:30:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89EED9127D; Wed, 27 Nov 2002 07:32:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BA609127E; Wed, 27 Nov 2002 07:32:50 -0500 (EST) 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 70C199127D for ; Wed, 27 Nov 2002 07:32:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 418805DE19; Wed, 27 Nov 2002 07:32:42 -0500 (EST) 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 1B3C45DDE0 for ; Wed, 27 Nov 2002 07:32:42 -0500 (EST) Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 3919767103 for ; Wed, 27 Nov 2002 03:57:10 -0500 (EST) Date: Wed, 27 Nov 2002 07:32:40 -0500 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Link-local TTL From: RJ Atkinson To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit Message-Id: <51BE7366-0204-11D7-9C68-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1) This TTL check thing is an operational consideration, NOT a security consideration. 2) The best technical approach is probably actually this one, which I typo'd earlier this week, but maybe got right this morning: A) Receivers MUST drop incoming link-local packets where (TTL != 1). B) Senders MUST set (TTL = 1) on all outbound link-local packets. Rationale: - This is fully backwards-compatible with the deployed systems. - This prevents a link-local from being forwarded off-link, even if the router is misconfigured or unaware of link-local addressing. - This prevents a receiver from accepting (most) bogus link-local packets. Ran rja@extremenetworks.com From owner-zeroconf@merit.edu Wed Nov 27 08:31:07 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 IAA08871 for ; Wed, 27 Nov 2002 08:31:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E852791282; Wed, 27 Nov 2002 08:33:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6E5A91283; Wed, 27 Nov 2002 08:33:39 -0500 (EST) 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 56B9A91282 for ; Wed, 27 Nov 2002 08:33:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 42A6B5DE4C; Wed, 27 Nov 2002 08:33:38 -0500 (EST) 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 E56755DE31 for ; Wed, 27 Nov 2002 08:33:37 -0500 (EST) 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 FAA17418; Wed, 27 Nov 2002 05:33:36 -0800 (PST) Received: from sun.com (vpn-129-159-0-112.EMEA.Sun.COM [129.159.0.112]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id gARDXSl25827; Wed, 27 Nov 2002 14:33:33 +0100 (MET) Message-ID: <3DE4C81B.10301@sun.com> Date: Wed, 27 Nov 2002 14:26:51 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Thomas Narten Cc: zeroconf@merit.edu, Erik Guttman Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, Here is a little bit more. Erik Guttman wrote: >>2) >> >>The following section: >> >> > 2.10 Higher-Layer Protocol Considerations >> > >> > Similar considerations apply at layers above IP. >> > >> > For example, 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. >> > >> > 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. >> >>is not sufficiently draconian. >> >>It should probably say something like: >> >>The following set of protocols: >> >>- FTP >>- DNS >>- NFS >>- IPSEC using IPv4 as an identifier >>- BGP >>- OSPF >>- RTP/RTCP >> <<>> >> >>will fail if applications use a link-local address instead of a >>globally unique address when sending the address of its interface in >>a protocol packet. > > > In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK. > > Why is this the case with FTP, DNS, NFS, RTP/RTCP? I meant to include DNS in the not-ok category. >Thomas: > > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host SHOULD use its link- > local source address, if it has one. If the host does not have a > link-local source address, then it MAY choose to ARP for the > destination address and then send its packet, with a routable source > IP address and a link-local destination IP address, directly to its > destination on the same physical link. The host MUST NOT send the > packet to any router for forwarding. > >The above wording suggests that if host has no LL address, but it does >have a global address, it is not required to use that global address >to talk to a device that only has a LL address. The paragraph says a) if a destination is link-local *and* a host has a link-local address configured, it SHOULD use the link-local address. (Was this unclear to you in the first sentence of the paragraph?) b) otherwise - the host MAY resolve the link-local destination address to a mac address and send the packet directly from the host's address to the destination address. c) otherwise - the host will not be able to send the packet at all. This is because the packet MUST NOT be sent to a router for forwarding. The reason for b and c in the paragraph is to call out that if a host wishes to send to a link-local destination, it cannot do this by simply sending the packet to a router for forwarding (c). The host will need to send the packet directly (b), which is maybe different than the way its IP forwarding algorithm operates today. >This seems >broken. I.e, it will result in communication failure that is hard to >diagnose. Two nodes, both with legitimate addresses that should work, >for some strange reason won't talk to each other. Seems to me like the >MAY should really be a MUST. You can't NOT use the global address, if >it's the only address you have. Or, if there are legitimate reasons >why an implementation might not want to use its global address in this >case (knowing that communication will fail as a result) please include >some background explaining why this might be a reasonable approach. If your problem is that the text above leaves open the possibility of a host's policy falling through the cracks of a's SHOULD and b's MAY into 'c'? If so, I agree with your concern. Proposal: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link- local source address, if it has one. If the host does not have a link-local source address, then it MAY choose to ARP for the destination address and then send its packet, with a routable source IP address and a link-local destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. becomes -> If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link- local source address, if it has one. If the host does not have a link-local source address, then it MUST resolve the destination address using ARP and then send its packet, with a routable source IP address and a link-local destination IP address, directly to its destination on the same physical link. This is the only way a host with a global address would not be able to send to a link-local destination, as the host MUST NOT send the packet to any router for forwarding. Erik From owner-zeroconf@merit.edu Wed Nov 27 11:31:24 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 LAA17601 for ; Wed, 27 Nov 2002 11:31:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8DCC9128E; Wed, 27 Nov 2002 11:33:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8869F91290; Wed, 27 Nov 2002 11:33:50 -0500 (EST) 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 601809128E for ; Wed, 27 Nov 2002 11:33:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 437715DDF6; Wed, 27 Nov 2002 11:33:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by segue.merit.edu (Postfix) with ESMTP id F2D7B5DDE2 for ; Wed, 27 Nov 2002 11:33:48 -0500 (EST) Received: from DF-YURI.platinum.corp.microsoft.com ([10.197.0.60]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.5255); Wed, 27 Nov 2002 08:34:23 -0800 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 27 Nov 2002 08:33:47 -0800 Received: from 10.197.0.48 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Nov 2002 08:33:48 -0800 Received: from DF-DINKY.platinum.corp.microsoft.com ([10.197.0.58]) by DF-STIMPY.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 27 Nov 2002 08:33:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Link-local TTL Date: Wed, 27 Nov 2002 08:33:47 -0800 Message-ID: <01C133474E27D04FABA48D02078CF41D8177AF@df-dinky.dogfood> Thread-Topic: Link-local TTL Thread-Index: AcKWER03FgK8FExMSji21LAkv/fNHgAHajBA From: "Peter Ford" To: "RJ Atkinson" , X-OriginalArrivalTime: 27 Nov 2002 16:33:47.0675 (UTC) FILETIME=[C29326B0:01C29632] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17601 Ran, It is not clear to me setting link local TTL to 1 is a good or necessary idea. Sure, layer 2 bridges are perfect active devices wrt taking packets off one wire and putting them onto another. But wouldn't it be better for all active devices lifting a packet from one wire and putting it onto another wire to actually use the IP TTL as an IP router does? Unfortunately, it is a little late to change 802, it is not too late for IP to help the guys who build 802 devices for IP networks. The IP TTL is a simple, almost elegant, safety net to help prevent the network from getting into a sustained failure mode. (I already hear: "exception - multicast!") It is not clear changing the use of TTL based on what kind of IP subnet you are on improves the safety characteristics of the network. The goal for preventing packets from traversing out of or into a link local subnet to anywhere else is a router's responsibility based on data already in the packet, not on the TTL. Does the router really need to do more here? Now, point 1 reflects the bias of someone who believes zero conf networks will most likely end up in homes where a bridged network across several media types with no routers except an Internet access router is the common case. (e.g. no subnets in the home, AT ALL). It would be a sad result of an effort to get to zero configurations for consumer networks to end up with IP subnetting within a consumer's network as part of the solution. It would prove that when confronted with driving in a nail, the IETF would use an IP Router to do the job. I won't even delve into screwing. Experience on the Internet has tended to show that it was a mistake to set the TTL low in the first place. Regards, peterf -----Original Message----- From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, November 27, 2002 4:33 AM To: zeroconf@merit.edu Subject: Link-local TTL 1) This TTL check thing is an operational consideration, NOT a security consideration. 2) The best technical approach is probably actually this one, which I typo'd earlier this week, but maybe got right this morning: A) Receivers MUST drop incoming link-local packets where (TTL != 1). B) Senders MUST set (TTL = 1) on all outbound link-local packets. Rationale: - This is fully backwards-compatible with the deployed systems. - This prevents a link-local from being forwarded off-link, even if the router is misconfigured or unaware of link-local addressing. - This prevents a receiver from accepting (most) bogus link-local packets. Ran rja@extremenetworks.com From owner-zeroconf@merit.edu Wed Nov 27 12:05:55 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 MAA19320 for ; Wed, 27 Nov 2002 12:05:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2E70591292; Wed, 27 Nov 2002 12:08:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9FAE91293; Wed, 27 Nov 2002 12:08:28 -0500 (EST) 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 AD64991292 for ; Wed, 27 Nov 2002 12:08:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 947EC5DF92; Wed, 27 Nov 2002 12:08:27 -0500 (EST) 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 67ABE5DDA4 for ; Wed, 27 Nov 2002 12:08:27 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARH8Ol00995; Wed, 27 Nov 2002 12:08:24 -0500 (EST) Message-Id: <200211271708.gARH8Ol00995@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Peter Ford" Cc: "RJ Atkinson" , zeroconf@merit.edu Subject: Re: Link-local TTL In-reply-to: (Your message of "Wed, 27 Nov 2002 08:33:47 PST.") <01C133474E27D04FABA48D02078CF41D8177AF@df-dinky.dogfood> Date: Wed, 27 Nov 2002 12:08:24 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Sure, layer 2 bridges are perfect active devices wrt taking packets off > one wire and putting them onto another. But wouldn't it be better for > all active devices lifting a packet from one wire and putting it onto > another wire to actually use the IP TTL as an IP router does? Why? It seems far better to have a clean separation between what happens at layer 2 and what happens at layer 3, than to legislate an architecture that expects layer 2 devices to know about layer 3 protocols and constraints the layer 3 protocols that layer 2 devices can support. > Unfortunately, it is a little late to change 802, it is not too late for > IP to help the guys who build 802 devices for IP networks. > IIRC, the LL draft specifically states that bridges should propagate LLs. so the fact that bridges don't decrement TTL is a feature even if hosts use TTL=1 when generating LL packets. > The IP TTL is a simple, almost elegant, safety net to help prevent the > network from getting into a sustained failure mode. (I already hear: > "exception - multicast!") It is not clear changing the use of TTL based > on what kind of IP subnet you are on improves the safety characteristics > of the network. Well, that's not what is being proposed. Use of LL vs routable is not a property of the subnet, it's a property of the destination address. And having already used TTL=1 for this purpose in multicast, I don't see why using it for this purpose in LL is a significant deviation from existing practice. > The goal for preventing packets from traversing out of or into a link > local subnet to anywhere else is a router's responsibility based on data > already in the packet, not on the TTL. Are you really saying that the router's job is to decide whether to forward a packet based on its payload, but NOT on its TTL? That seems exactly opposite from the way that IP was designed to work. > Does the router really need to > do more here? Setting TTL=1 is not asking the router to do more than it already does (and always has). That's the beauty of it - it does exactly the right thing. > Now, point 1 reflects the bias of someone who believes zero conf > networks will most likely end up in homes where a bridged network across > several media types with no routers except an Internet access router is > the common case. Again, there's no distinction between a zero conf network, and a managed newtork. LL as proposed will be imposed on nearly every host on the Internet by virtue of being included in macos and windows*, and because of the lack of any provision to allow a network to disable it. So it will be enabled on every network that supports such hosts (which is to say essentially every IPv4 network in the world). So we can't analyze the effect of this just based on what happens when it's used in a small, relatively isolated network. We also need to consider the effect of LL on large bridged/l2-switched networks with thousands of hosts, and several points in between these extremes. Keith From owner-zeroconf@merit.edu Wed Nov 27 12:14:28 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 MAA19869 for ; Wed, 27 Nov 2002 12:14:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5147091294; Wed, 27 Nov 2002 12:15:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1051F91298; Wed, 27 Nov 2002 12:15:44 -0500 (EST) 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 5172F91294 for ; Wed, 27 Nov 2002 12:15:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 61B225DFE1; Wed, 27 Nov 2002 12:15:37 -0500 (EST) 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 94B4F5DFCD for ; Wed, 27 Nov 2002 12:15:36 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gARHFZI17740 for ; Wed, 27 Nov 2002 09:15:36 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 27 Nov 2002 09:15:33 -0800 Received: from apple.com (lubet1.apple.com [17.202.40.146]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gARHFWp19758; Wed, 27 Nov 2002 09:15:32 -0800 (PST) Date: Wed, 27 Nov 2002 09:15:50 -0800 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Thomas Narten , zeroconf@merit.edu To: Erik Guttman From: Vincent Lubet In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 01:52 AM, Erik Guttman wrote: > The best thing would be to state that hosts MUST drop datagrams from > 169.254 with TTL != 255. Here there are no options, no configuration > required, no variations in behavior. This would certainly make life > easier for operators and users - since they could expect that their > link-local devices would only ever operate link-local. > > This does not address the installed base, however. Stuart, Bernard, > would it be feasible for Microsoft and Apple to agree this as a MUST > and see new versions of Windows and MacOS fail to interoperate with > deployed ones? Talking on behalf of Apple, we consider that dropping datagrams from 169.254 with TTL != 255 is a MUST. All recent versions of Mac OS 9 and Mac OS X do implement this behavior and we've already accepted the fact that we may fail to interoperate with older version of Mac OS. The reason is that older routers may not know about the special requirements of the 169.254 range so they may forward those packet AND decrease the TTL. Vincent Lubet Apple Manager, OS Networking Team From owner-zeroconf@merit.edu Wed Nov 27 12:16:45 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 MAA19949 for ; Wed, 27 Nov 2002 12:16:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E2D291295; Wed, 27 Nov 2002 12:19:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29F0D91296; Wed, 27 Nov 2002 12:19:13 -0500 (EST) 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 C8D4C91295 for ; Wed, 27 Nov 2002 12:19:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B13BC5DDEB; Wed, 27 Nov 2002 12:19:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by segue.merit.edu (Postfix) with ESMTP id 96AE25DDD3 for ; Wed, 27 Nov 2002 12:19:11 -0500 (EST) Received: from repligate ([67.37.186.205]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021127171909.QTTS3135.mail1-0.chcgil.ameritech.net@repligate>; Wed, 27 Nov 2002 11:19:09 -0600 Message-ID: <077201c29639$2f3fd550$cdba2543@repligate> From: "Jim Fleming" To: "Erik Guttman" , "Vincent Lubet" Cc: "Thomas Narten" , References: Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 11:19:46 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Vincent Lubet" To: "Erik Guttman" Cc: "Thomas Narten" ; Sent: Wednesday, November 27, 2002 11:15 AM Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt > > On Wednesday, November 27, 2002, at 01:52 AM, Erik Guttman wrote: > > > The best thing would be to state that hosts MUST drop datagrams from > > 169.254 with TTL != 255. Here there are no options, no configuration > > required, no variations in behavior. This would certainly make life > > easier for operators and users - since they could expect that their > > link-local devices would only ever operate link-local. > > > > This does not address the installed base, however. Stuart, Bernard, > > would it be feasible for Microsoft and Apple to agree this as a MUST > > and see new versions of Windows and MacOS fail to interoperate with > > deployed ones? > > Talking on behalf of Apple, we consider that dropping datagrams from > 169.254 with TTL != 255 is a MUST. All recent versions of Mac OS 9 and > Mac OS X do implement this behavior and we've already accepted the fact > that we may fail to interoperate with older version of Mac OS. > > The reason is that older routers may not know about the special > requirements of the 169.254 range so they may forward those packet AND > decrease the TTL. > > Vincent Lubet > Apple > Manager, OS Networking Team > > Do you do that on the AM and FM Internets ? 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("AM/FM") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt IPv8 0QQQQGGGSSSSSSSS[32-bits][Port] IPv16 0QQQQGGGSSSSSSSS[32-bits][Port] 1WWWWWWWSSSSSSSS[32-bits][Port] Jim Fleming 128-bit DNS is closer than you think... IPv16...COM...NET...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...PR...ST...UZ http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee From owner-zeroconf@merit.edu Wed Nov 27 12:21:40 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 MAA20256 for ; Wed, 27 Nov 2002 12:21:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5914291296; Wed, 27 Nov 2002 12:24:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAC8791297; Wed, 27 Nov 2002 12:24:13 -0500 (EST) 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 B9C0A91296 for ; Wed, 27 Nov 2002 12:24:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id A14695DEC9; Wed, 27 Nov 2002 12:24:12 -0500 (EST) 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 4528E5DDD3 for ; Wed, 27 Nov 2002 12:24:12 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHO6l01238; Wed, 27 Nov 2002 12:24:06 -0500 (EST) Message-Id: <200211271724.gARHO6l01238@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: Erik Guttman , Thomas Narten , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 09:15:50 PST.") Date: Wed, 27 Nov 2002 12:24:06 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Talking on behalf of Apple, we consider that dropping datagrams from sorry, IETF doesn't recognize representatives of organizations. what's your best technical judgement about the right thing for the Internet as a whole? From owner-zeroconf@merit.edu Wed Nov 27 12:29:21 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 MAA20465 for ; Wed, 27 Nov 2002 12:29:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A3C291298; Wed, 27 Nov 2002 12:31:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6CB1912A3; Wed, 27 Nov 2002 12:31:26 -0500 (EST) 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 C7F0E91298 for ; Wed, 27 Nov 2002 12:31:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id C6CCD5E02C; Wed, 27 Nov 2002 12:31:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by segue.merit.edu (Postfix) with ESMTP id AB0B25DDD3 for ; Wed, 27 Nov 2002 12:31:14 -0500 (EST) Received: from repligate ([67.37.186.205]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021127173113.RAHV3135.mail1-0.chcgil.ameritech.net@repligate>; Wed, 27 Nov 2002 11:31:13 -0600 Message-ID: <078a01c2963a$dec50a80$cdba2543@repligate> From: "Jim Fleming" To: "Keith Moore" , "Vincent Lubet" Cc: "Erik Guttman" , "Thomas Narten" , References: <200211271724.gARHO6l01238@astro.cs.utk.edu> Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 11:31:49 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "Vincent Lubet" Cc: "Erik Guttman" ; "Thomas Narten" ; Sent: Wednesday, November 27, 2002 11:24 AM Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt > > Talking on behalf of Apple, we consider that dropping datagrams from > > sorry, IETF doesn't recognize representatives of organizations. > http://www.iana.org/assignments/ipv4-address-space 003/8 May 94 General Electric Company 004/8 Dec 92 Bolt Beranek and Newman Inc. 005/8 Jul 95 IANA - Reserved 006/8 Feb 94 Army Information Systems Center 007/8 Apr 95 IANA - Reserved 008/8 Dec 92 Bolt Beranek and Newman Inc. 009/8 Aug 92 IBM 010/8 Jun 95 IANA - Private Use See [RFC1918] 011/8 May 93 DoD Intel Information Systems 012/8 Jun 95 AT&T Bell Laboratories 013/8 Sep 91 Xerox Corporation 014/8 Jun 91 IANA - Public Data Network 015/8 Jul 94 Hewlett-Packard Company 016/8 Nov 94 Digital Equipment Corporation 017/8 Jul 92 Apple Computer Inc. From owner-zeroconf@merit.edu Wed Nov 27 12:35:53 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 MAA20842 for ; Wed, 27 Nov 2002 12:35:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B76A191299; Wed, 27 Nov 2002 12:38:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EE079129A; Wed, 27 Nov 2002 12:38:26 -0500 (EST) 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 7F69291299 for ; Wed, 27 Nov 2002 12:38:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F1C45DFE3; Wed, 27 Nov 2002 12:38:25 -0500 (EST) 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 226A45DEC9 for ; Wed, 27 Nov 2002 12:38:25 -0500 (EST) 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 gARHcOw03123 for ; Wed, 27 Nov 2002 09:38:24 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 09:38:03 -0800 Received: from apple.com (lubet1.apple.com [17.202.40.146]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gARHcNu21552; Wed, 27 Nov 2002 09:38:23 -0800 (PST) Date: Wed, 27 Nov 2002 09:38:41 -0800 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Keith Moore From: Vincent Lubet In-Reply-To: <200211271724.gARHO6l01238@astro.cs.utk.edu> Message-Id: <11EF8A18-022F-11D7-9C40-0003937AD75C@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 09:24 AM, Keith Moore wrote: > what's your best technical judgement about the right thing for the > Internet as a whole? The right thing for the Internet as a whole is for zeroconf solution to be deployed now and be interoperable. This is never going to happen by constantly changing the specifications about non essential aspect of the protocols. Vincent From owner-zeroconf@merit.edu Wed Nov 27 12:46:19 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 MAA21342 for ; Wed, 27 Nov 2002 12:46:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B37B9129A; Wed, 27 Nov 2002 12:48:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8D199129C; Wed, 27 Nov 2002 12:48:53 -0500 (EST) 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 C6D419129A for ; Wed, 27 Nov 2002 12:48:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id B438C5DFCD; Wed, 27 Nov 2002 12:48:52 -0500 (EST) 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 57DB05DDEC for ; Wed, 27 Nov 2002 12:48:52 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHmmj00541; Wed, 27 Nov 2002 12:48:48 -0500 (EST) Message-Id: <200211271748.gARHmmj00541@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: Keith Moore , zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 09:38:41 PST.") <11EF8A18-022F-11D7-9C40-0003937AD75C@apple.com> Date: Wed, 27 Nov 2002 12:48:48 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > what's your best technical judgement about the right thing for the > > Internet as a whole? > > The right thing for the Internet as a whole is for zeroconf solution to > be deployed now and be interoperable. that sounds good but it's kind of nonspecific. and it leaves open the question of how to deploy zeroconf without it interfering with the interoperation of existing apps and networks, as it currently does. > This is never going to happen by > constantly changing the specifications about non essential aspect of > the protocols. agreed; I wish we'd focus attention of the real problems with zeroconf. Keith From owner-zeroconf@merit.edu Wed Nov 27 12:47: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 MAA21361 for ; Wed, 27 Nov 2002 12:47:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D7039129C; Wed, 27 Nov 2002 12:49:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AF579129E; Wed, 27 Nov 2002 12:49:30 -0500 (EST) 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 46F099129C for ; Wed, 27 Nov 2002 12:49:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35CB05DFCD; Wed, 27 Nov 2002 12:49:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by segue.merit.edu (Postfix) with ESMTP id 1BF095DDEC for ; Wed, 27 Nov 2002 12:49:29 -0500 (EST) Received: from repligate ([67.37.186.205]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021127174928.RJRM3135.mail1-0.chcgil.ameritech.net@repligate>; Wed, 27 Nov 2002 11:49:28 -0600 Message-ID: <07b401c2963d$6b239260$cdba2543@repligate> From: "Jim Fleming" To: "Keith Moore" , "Vincent Lubet" Cc: References: <11EF8A18-022F-11D7-9C40-0003937AD75C@apple.com> Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 11:50:04 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Vincent Lubet" To: "Keith Moore" Cc: Sent: Wednesday, November 27, 2002 11:38 AM Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt > > On Wednesday, November 27, 2002, at 09:24 AM, Keith Moore wrote: > > > what's your best technical judgement about the right thing for the > > Internet as a whole? > > The right thing for the Internet as a whole is for zeroconf solution to > be deployed now and be interoperable. This is never going to happen by > constantly changing the specifications about non essential aspect of > the protocols. > Yes...that is called a NetWork....as opposed to a NotWork.... ...the code has to work.... NSD has a BSD Flavor http://www.nlnetlabs.nl/nsd/index.en.html http://wuarchive.wustl.edu/mirrors/NetBSD/NetBSD-current/pkgsrc/net/nsd/DESCR http://wuarchive.wustl.edu/mirrors/NetBSD/NetBSD-current/pkgsrc/net/nsd/ http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-dnr-nsd/tsld008.html LameD is derived from DNRD which has a Linux Flavor. http://dnrd.nevalabs.org/ It looks like it will be best to have a PK Flavor and a GK Flavor with Linux for the GK and BSD for the PK. The TLD search and cache code can be added to both, with the GK having the only IPv16 access. Jim Fleming 128-bit DNS is closer than you think... IPv16...COM...NET...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...PR...ST...UZ http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee From owner-zeroconf@merit.edu Wed Nov 27 14:30: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 OAA25339 for ; Wed, 27 Nov 2002 14:30:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0121D912A0; Wed, 27 Nov 2002 14:33:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA471912A1; Wed, 27 Nov 2002 14:33:09 -0500 (EST) 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 F2E47912A0 for ; Wed, 27 Nov 2002 14:32:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD8755DF54; Wed, 27 Nov 2002 14:32:26 -0500 (EST) 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 8353C5DF47 for ; Wed, 27 Nov 2002 14:32:26 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gARJWQw07241 for ; Wed, 27 Nov 2002 11:32:26 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 27 Nov 2002 11:32:25 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gARJWP908067; Wed, 27 Nov 2002 11:32:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v548) In-Reply-To: <51BE7366-0204-11D7-9C68-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: zeroconf@merit.edu From: Joshua Graessley Subject: Re: Link-local TTL Date: Wed, 27 Nov 2002 11:32:24 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 04:32 AM, RJ Atkinson wrote: > > 1) This TTL check thing is an operational consideration, NOT a > security consideration. > 2) The best technical approach is probably actually this one, which I > typo'd > earlier this week, but maybe got right this morning: > > A) Receivers MUST drop incoming link-local packets where (TTL != 1). > B) Senders MUST set (TTL = 1) on all outbound link-local packets. > > Rationale: > - This is fully backwards-compatible with the deployed systems. Actually, this will break compatibility with current shipping Macs. Macs implement the check for TTL = 255 upon reception of packets with an IPv4 link-local address and will silently discard any packets where the TTL is not 255. > - This prevents a link-local from being forwarded off-link, > even if the router is misconfigured or unaware of link-local > addressing. > - This prevents a receiver from accepting (most) bogus link-local > packets. This does nothing to prevent the receiver from accepting bogus link-local packets. The receiver is relying on routers not forwarding packets. -josh From owner-zeroconf@merit.edu Wed Nov 27 14:53: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 OAA25941 for ; Wed, 27 Nov 2002 14:53:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCCA9912A1; Wed, 27 Nov 2002 14:56:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A637F912A2; Wed, 27 Nov 2002 14:56:09 -0500 (EST) 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 B0B06912A1 for ; Wed, 27 Nov 2002 14:56:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8FA4F5DF81; Wed, 27 Nov 2002 14:56:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id 1A0CB5DF79 for ; Wed, 27 Nov 2002 14:56:08 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gARJu6LV096062; Wed, 27 Nov 2002 14:56:07 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gARJu6a8055278; Wed, 27 Nov 2002 12:56:06 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gARJsm630389; Wed, 27 Nov 2002 14:54:48 -0500 Message-Id: <200211271954.gARJsm630389@rotala.raleigh.ibm.com> To: jak@uiuc.edu Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message from "Jay A. Kreibich" of "Tue, 26 Nov 2002 13:47:21 CST." <20021126194721.GI5973@uiuc.edu> Date: Wed, 27 Nov 2002 14:54:48 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "Jay A. Kreibich" writes: > Yes. First, as I'm sure many of you know, this is the exact scheme > used by IPv6 to keep link-local packets "local". There was a lot of > thought put into the need for this double-check in IPv6, and it works > out quite well. If anyone is to question the wisdom of this check, I > would suggest you do some heavy research into the development of IPv6 > and how & why this check came about in that standard. I'm not saying > it is all good and obvious, but there was a great deal of thought put > into this question for IPv6, and the only real difference is that in > the case of IPv6, the requirements were in the final spec from day one. It sure sounds to me like you are saying above that the IPv6 specs require all recieved LL packets with a Hop Limit != 255 be dropped. I challenge you to find such a statement in the IPv6 specs. Neighbor Discovery, RFC 2461, is a specific IPv6 application that uses LL addresses, and that *specific* application has chosen to require that ND packets received with a Hop Limit other than 255 be dropped. I am aware of no other IPv6 applications that require such a check (but could imagine it might make sense in some cases), and there is no general requirement to check when LLs are used for protocols other than ND. Thomas From owner-zeroconf@merit.edu Wed Nov 27 15:10: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 PAA26320 for ; Wed, 27 Nov 2002 15:10:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24461912A3; Wed, 27 Nov 2002 15:12:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC0D2912A4; Wed, 27 Nov 2002 15:12:43 -0500 (EST) 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 F0611912A3 for ; Wed, 27 Nov 2002 15:12:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5FFA5DF58; Wed, 27 Nov 2002 15:12:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 99C655DF49 for ; Wed, 27 Nov 2002 15:12:42 -0500 (EST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gARKCgNp273380; Wed, 27 Nov 2002 15:12:42 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gARKCdWQ055110; Wed, 27 Nov 2002 15:12:39 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gARKBNh30485; Wed, 27 Nov 2002 15:11:23 -0500 Message-Id: <200211272011.gARKBNh30485@rotala.raleigh.ibm.com> To: "John C. Welch" Cc: Zeroconf Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message from "John C. Welch" of "Tue, 26 Nov 2002 17:35:45 EST." Date: Wed, 27 Nov 2002 15:11:23 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "John C. Welch" writes: > > A LL is much more likely to get forwarded off link if the TTL is 255! > If the router's not working right, the TTL can be completely ignored too, so > maybe we should not use TTL at all anywhere, since it's evidently a bad idea > to rely on it. What is your definition of a router that is "not working right"? The vast majority of deployed routers today don't understand about LL prefixes, and won't know to filter them (unless they are configured to do so, either via a filter, because they have LL prefix assigned to a local interface, etc.). Thus, packets sent to LL addresses could get sucked up through default routes and other ways "that aren't supposed to happen" through no fault of the router. This is the type of operational headache some are concerned about. In contrast, the vast majority of deployed routers decrement the TTL of packets they forward properly. Thus, in practice, one can assume with an extermely high degree of certainty that normal routers will process the TTL correctly and will drop received packets that have a TTL of 1. So I really don't follow the logic that the TTL can't be used per above. > > > >> So I'd prefer language like this: > > > >> - MUST set TTL == 255 on transmission of a link-local packet > >> - SHOULD check TTL == 255 on receipt of a link-local packet > > > > Meaning, if TTL != 255, discard the packet? The concern I'm asking > > about is that with this behavior, we get non-interoperability with > > currently deployed devices. > Then those devices aren't following LL spec anyway, and need to be updated. > Vendor software/firmware updates should handle this. The reality is that its really hard to upgrade the installed base. In a lot of cases, one has to wait until those devices are replaced. One can talk about getting software upgrades and such, but aren't there horrible statistics on (for example) how many Windows 95 boxes are still around and in use? > >> This permits the operator to enable a broken mode for compatibility, > >> and lets the rest of us migrate in a more useful direction > >> operationally. > > > > In a home network, where grandma is the operator, seems to me like > > there will be no configuration possible. The default settings will > > rule. > In a home network, the chances of using LL in this fashion are highly slim. I don't understand what "this fashion" refers to, thus I can't tell whether you are agreeing or disagreeing. Thomas From owner-zeroconf@merit.edu Wed Nov 27 15:16:04 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 PAA26590 for ; Wed, 27 Nov 2002 15:16:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5709991208; Wed, 27 Nov 2002 15:18:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1ABDE912A4; Wed, 27 Nov 2002 15:18:31 -0500 (EST) 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 1496891208 for ; Wed, 27 Nov 2002 15:18:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 039DC5DDA1; Wed, 27 Nov 2002 15:18:30 -0500 (EST) 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 8C8155DD9A for ; Wed, 27 Nov 2002 15:18:29 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARKIPj01218; Wed, 27 Nov 2002 15:18:25 -0500 (EST) Message-Id: <200211272018.gARKIPj01218@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: RJ Atkinson , zeroconf@merit.edu Subject: Re: Link-local TTL In-reply-to: (Your message of "Wed, 27 Nov 2002 11:32:24 PST.") Date: Wed, 27 Nov 2002 15:18:25 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Actually, this will break compatibility with current shipping Macs. > Macs implement the check for TTL = 255 upon reception of packets with > an IPv4 link-local address and will silently discard any packets where > the TTL is not 255. that's what you get for shipping product before the standard was approved. From owner-zeroconf@merit.edu Wed Nov 27 15:58: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 PAA27674 for ; Wed, 27 Nov 2002 15:58:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 992FA9120A; Wed, 27 Nov 2002 16:00:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F2379121D; Wed, 27 Nov 2002 16:00:26 -0500 (EST) 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 2A15E9120A for ; Wed, 27 Nov 2002 16:00:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id B48D75DFCD; Wed, 27 Nov 2002 16:00:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 1F1E35DD9A for ; Wed, 27 Nov 2002 16:00:23 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06263 for ; Wed, 27 Nov 2002 16:00:22 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08295 for ; Wed, 27 Nov 2002 16:00:22 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08974 for ; Wed, 27 Nov 2002 16:00:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 27 Nov 2002 16:00:18 -0500 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211272011.gARKBNh30485@rotala.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/27/2002 15:11, "Thomas Narten" wrote: >> If the router's not working right, the TTL can be completely ignored too, so >> maybe we should not use TTL at all anywhere, since it's evidently a bad idea >> to rely on it. > > What is your definition of a router that is "not working right"? > > The vast majority of deployed routers today don't understand about LL > prefixes, and won't know to filter them (unless they are configured to > do so, either via a filter, because they have LL prefix assigned to a > local interface, etc.). Thus, packets sent to LL addresses could get > sucked up through default routes and other ways "that aren't supposed > to happen" through no fault of the router. This is the type of > operational headache some are concerned about. > > In contrast, the vast majority of deployed routers decrement the TTL > of packets they forward properly. Thus, in practice, one can assume > with an extermely high degree of certainty that normal routers will > process the TTL correctly and will drop received packets that have a > TTL of 1. > > So I really don't follow the logic that the TTL can't be used per > above. I didn't say it can't be used, but to assume that a TTL of 1 is somehow immune to improper routing, or even less likely to be incorrectly routed than a TTL of 255 is an erroneous assumption. But, since a LL network should be ignoring routed packets, then a packet that does get routed into a LL network incorrectly, either inadvertently, or deliberately, could have a TTL of 1, and be incorrectly accepted, whereas it's *less* likely that the same packet will get routed and have a TTL of 255. My point was, if you are looking for foolproof, then TTL isn't that, and if you want foolproof, then using TTL is silly. However, a TTL of 255 is most likely a better idea than a TTL of 1. > > >> Then those devices aren't following LL spec anyway, and need to be updated. >> Vendor software/firmware updates should handle this. > > The reality is that its really hard to upgrade the installed base. In > a lot of cases, one has to wait until those devices are replaced. One > can talk about getting software upgrades and such, but aren't there > horrible statistics on (for example) how many Windows 95 boxes are > still around and in use? How many Macs running System 7? Do you propose we pull an Intel, and be backwards compatible back to the beginnings of TCP/IP? Backwards compatibility can quickly become a straightjacket that will prevent progress. Better to say, "If you want Zeroconf then for Y OS, you need to be running version Z." You will *never* satisfy everyone, because there will always be an edge case that gets hosed by the change. But at some point, you have to draw a line. Finally, not too many Windows 95 boxes can even use LL addressing anyway. Upgrades happen in greater numbers *today* because they are easier to apply, and outside of devices that keep this code in firmware, it's a service pack/patch for the OS. With one notable exception, these happen all the time, and cause little, if any problems. >>> In a home network, where grandma is the operator, seems to me like >>> there will be no configuration possible. The default settings will >>> rule. > >> In a home network, the chances of using LL in this fashion are highly slim. > > I don't understand what "this fashion" refers to, thus I can't tell > whether you are agreeing or disagreeing. Home networks tend to be upgraded based on convenience and need. If they want/need the convenience, then they'll upgrade. if it isn't compelling, they won't. But if you are going to let upgrade probabilities determine standards settings, you're in a deep pit that will only get deeper. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Nov 27 16:04: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 QAA27841 for ; Wed, 27 Nov 2002 16:04:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1C6149121D; Wed, 27 Nov 2002 16:06:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D20D09121F; Wed, 27 Nov 2002 16:06:56 -0500 (EST) 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 C9D7F9121D for ; Wed, 27 Nov 2002 16:06:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id B52995DFCD; Wed, 27 Nov 2002 16:06:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 4BFDF5DF81 for ; Wed, 27 Nov 2002 16:06:55 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08774 for ; Wed, 27 Nov 2002 16:06:54 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA01245 for ; Wed, 27 Nov 2002 16:06:54 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10697 for ; Wed, 27 Nov 2002 16:06:54 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 27 Nov 2002 16:06:52 -0500 Subject: Re: Link-local TTL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211272018.gARKIPj01218@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/27/2002 15:18, "Keith Moore" wrote: >> Actually, this will break compatibility with current shipping Macs. >> Macs implement the check for TTL = 255 upon reception of packets with >> an IPv4 link-local address and will silently discard any packets where >> the TTL is not 255. > > that's what you get for shipping product before the standard was approved. Well, if you wait for the standards to get around to getting their act together and make a bloody decision, then you don't change anything, nothing new gets done, and computing progress stands still. Maybe if the standards bodies spent less time arguing minor points, and more time getting work done, then this wouldn't be an issue. In the commercial world, (read, the people who spend most of the money on new technology), there is nothing more agonizing that making the decision to delay needed technology purchases because you *hope* that a standard that is due out in a given *year* will actually be out that year. People need to get work done, and they'll happily ignore standards to get work done. not to pick on any company here, but face it, any company delaying a Zeroconf implementation for the standards bodies to get around to agreeing on something is foolish. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Nov 27 16:12: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 QAA28003 for ; Wed, 27 Nov 2002 16:12:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3DFD29121F; Wed, 27 Nov 2002 16:14:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0982991224; Wed, 27 Nov 2002 16:14:40 -0500 (EST) 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 E33409121F for ; Wed, 27 Nov 2002 16:14:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC9525DFCD; Wed, 27 Nov 2002 16:14:39 -0500 (EST) 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 9FE945DF81 for ; Wed, 27 Nov 2002 16:14:39 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARLEbj01712; Wed, 27 Nov 2002 16:14:38 -0500 (EST) Message-Id: <200211272114.gARLEbj01712@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Zeroconf Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 15:11:23 EST.") <200211272011.gARKBNh30485@rotala.raleigh.ibm.com> Date: Wed, 27 Nov 2002 16:14:37 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > Then those devices aren't following LL spec anyway, and need to be updated. > > Vendor software/firmware updates should handle this. > > The reality is that its really hard to upgrade the installed base. In > a lot of cases, one has to wait until those devices are replaced. One > can talk about getting software upgrades and such, but aren't there > horrible statistics on (for example) how many Windows 95 boxes are > still around and in use? To me insisting that standards-track LL be compatible with existing deployed LL implementations is not an appropriate goal. If it happens to work with them, great. If not, boxes that need to speak LL will need to upgrade. That's life. Since we'll probably be stuck with LL for the rest of the life of v4, which might be a couple of decades, the most important things for the IETF spec to do are - make sure that the end-state is desirable, and - minimize breakage during the transition Note that the choice of TTL doesn't affect ad hoc networks at all, and these were supposed to be the use case that justified standardizing LL in the first place. And since for most currently deployed implementations LL only works on ad hoc networks (which presumably don't have routers), the choice of TTL is mostly irrelevant to breakage of things already using LL. (That choice might be relevant to those using recent platforms that support LL on managed networks, some of whom might be using LL now or in the near future. But I also suspect that upgrading the recent platforms for which LL works on managed networks to support TTL=1 is relatively easy - internet- connected macos and xp users already have plenty of incentive to upgrade for other reasons, and fairly effective mechanisms for doing so. Allowing TTL to be 1 is what, a change to one line of code? Surely the fix could be included fairly easily in SP4 or 10.2.3? Keith From owner-zeroconf@merit.edu Wed Nov 27 16:12: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 QAA28017 for ; Wed, 27 Nov 2002 16:12:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF24091224; Wed, 27 Nov 2002 16:14:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 765C3912A4; Wed, 27 Nov 2002 16:14:53 -0500 (EST) 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 1029E91224 for ; Wed, 27 Nov 2002 16:14:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id F11155DF81; Wed, 27 Nov 2002 16:14:49 -0500 (EST) 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 76A475E013 for ; Wed, 27 Nov 2002 16:14:49 -0500 (EST) 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 gARLEmI27080 for ; Wed, 27 Nov 2002 13:14:48 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 13:14:27 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gARLEmu27672; Wed, 27 Nov 2002 13:14:48 -0800 (PST) Date: Wed, 27 Nov 2002 13:14:47 -0800 Subject: Re: Link-local TTL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: RJ Atkinson , zeroconf@merit.edu To: Keith Moore From: Joshua Graessley In-Reply-To: <200211272018.gARKIPj01218@astro.cs.utk.edu> Message-Id: <41FEF328-024D-11D7-AF74-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 12:18 PM, Keith Moore wrote: >> Actually, this will break compatibility with current shipping Macs. >> Macs implement the check for TTL = 255 upon reception of packets with >> an IPv4 link-local address and will silently discard any packets where >> the TTL is not 255. > > that's what you get for shipping product before the standard was > approved. My point is that compatibility with currently deployed devices should not be used as a reason to change the spec to require that the TTL be set to 255. I thought we already went through this debate some time ago and decided that TTL 255 was the most desirable solution. Is there a reason we're rehashing this yet again? The original question that started this thread was one about whether the TTL 255 check would break currently deployed products. We've been shipping Macs for a while now with the check in and we haven't had any reports of problems with interoperability with other link-local devices. -josh From owner-zeroconf@merit.edu Wed Nov 27 16:17:47 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 QAA28105 for ; Wed, 27 Nov 2002 16:17:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3681A912A4; Wed, 27 Nov 2002 16:20:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03FE6912A5; Wed, 27 Nov 2002 16:20:19 -0500 (EST) 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 189D2912A4 for ; Wed, 27 Nov 2002 16:20:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA2DD5DFCD; Wed, 27 Nov 2002 16:20:18 -0500 (EST) 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 A218B5DF0B for ; Wed, 27 Nov 2002 16:20:18 -0500 (EST) 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 gARLKHw03211 for ; Wed, 27 Nov 2002 13:20:17 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 13:19:56 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gARLKGu01720; Wed, 27 Nov 2002 13:20:17 -0800 (PST) Date: Wed, 27 Nov 2002 13:20:16 -0800 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Thomas Narten , Zeroconf To: Keith Moore From: Joshua Graessley In-Reply-To: <200211272114.gARLEbj01712@astro.cs.utk.edu> Message-Id: <06092B12-024E-11D7-AF74-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 01:14 PM, Keith Moore wrote: > Allowing TTL to be 1 is what, a change to one line of code? > Surely the fix could be included fairly easily in SP4 or 10.2.3? You are assuming that everyone agrees that the TTL 1 solution is more desirable than TTL 255 and check at the receiving end. We've had this debate before. We decided TTL 255 was more desirable. I haven't seen any new information presented here, except the concern for existing devices. You've repeatedly suggested we ignore the issue of existing devices, so I don't see why we would consider changing the draft. -josh From owner-zeroconf@merit.edu Wed Nov 27 16:32: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 QAA28431 for ; Wed, 27 Nov 2002 16:32:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C610912A6; Wed, 27 Nov 2002 16:34:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59D69912A7; Wed, 27 Nov 2002 16:34:59 -0500 (EST) 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 5E40F912A6 for ; Wed, 27 Nov 2002 16:34:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4238B5DF0B; Wed, 27 Nov 2002 16:34:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by segue.merit.edu (Postfix) with ESMTP id CE8705DE16 for ; Wed, 27 Nov 2002 16:34:56 -0500 (EST) Received: from pc-00045 ([144.135.25.78]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15 mta06ps May 23 2002 23:53:28) with SMTP id H697Y600.HAN; Thu, 28 Nov 2002 07:34:54 +1000 Received: from CPE-203-51-30-180.nsw.bigpond.net.au ([203.51.30.180]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0n 98/10284777); 28 Nov 2002 07:34:53 From: Brad Hards To: Keith Moore , Thomas Narten Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Thu, 28 Nov 2002 08:24:14 +1100 User-Agent: KMail/1.4.5 Cc: Zeroconf References: <200211272114.gARLEbj01712@astro.cs.utk.edu> In-Reply-To: <200211272114.gARLEbj01712@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200211280824.14715.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 28 Nov 2002 08:14, Keith Moore wrote: > And since for most currently deployed implementations LL only works > on ad hoc networks (which presumably don't have routers), the choice of > TTL is mostly irrelevant to breakage of things already using LL. I note that Thomas' posting kicking this thread off was about interoperability. > Allowing TTL to be 1 is what, a change to one line of code? > Surely the fix could be included fairly easily in SP4 or 10.2.3? Its a no brainer for capable hosts. Should be a configuration variable. However, part of the point of zeroconf was to make it easy for network appliances to be deployed. It won't be a happy user experience if your new, Rendezvous compatible printer needs a firmware upgrade (which might be back to the factory) before it will work with in the supposed zeroconf. There doesn't seem to be much operational difference between setting TTL=1 and setting TTL=255 and checking TTL=255, so I suggest that we just leave the draft as it is, and get back to work. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE95Tf+W6pHgIdAuOMRApMqAJ41oD4oX/zzvbJ+KWqvCmYtjiWRbwCgwk/H yIhVSR57xs5Bn5T+mPndSuY= =CUfs -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Wed Nov 27 16:38:19 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 QAA28734 for ; Wed, 27 Nov 2002 16:38:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B8A8912A7; Wed, 27 Nov 2002 16:40:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16FF3912A9; Wed, 27 Nov 2002 16:40:54 -0500 (EST) 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 E4DD0912A7 for ; Wed, 27 Nov 2002 16:40:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id C285F5DFE1; Wed, 27 Nov 2002 16:40:52 -0500 (EST) 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 676755DFCD for ; Wed, 27 Nov 2002 16:40:52 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARLekj01776; Wed, 27 Nov 2002 16:40:46 -0500 (EST) Message-Id: <200211272140.gARLekj01776@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , RJ Atkinson , zeroconf@merit.edu Subject: Re: Link-local TTL In-reply-to: (Your message of "Wed, 27 Nov 2002 13:14:47 PST.") <41FEF328-024D-11D7-AF74-000393760260@apple.com> Date: Wed, 27 Nov 2002 16:40:46 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > My point is that compatibility with currently deployed devices should > not be used as a reason to change the spec to require that the TTL be > set to 255. similarly it should not be used as a reason to not change the spec to require that TTL be set to 1. > I thought we already went through this debate some time ago and decided > that TTL 255 was the most desirable solution. Is there a reason we're > rehashing this yet again? yes, IESG review. this is a normal part of the process. Keith From owner-zeroconf@merit.edu Wed Nov 27 16:39:16 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 QAA28786 for ; Wed, 27 Nov 2002 16:39:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5920912A9; Wed, 27 Nov 2002 16:41:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 930F4912AA; Wed, 27 Nov 2002 16:41:49 -0500 (EST) 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 811A1912A9 for ; Wed, 27 Nov 2002 16:41:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7035A5DFE1; Wed, 27 Nov 2002 16:41:48 -0500 (EST) 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 14D0B5DFCD for ; Wed, 27 Nov 2002 16:41:48 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARLfgj01799; Wed, 27 Nov 2002 16:41:42 -0500 (EST) Message-Id: <200211272141.gARLfgj01799@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Thomas Narten , Zeroconf Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 13:20:16 PST.") <06092B12-024E-11D7-AF74-000393760260@apple.com> Date: Wed, 27 Nov 2002 16:41:42 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > Allowing TTL to be 1 is what, a change to one line of code? > > Surely the fix could be included fairly easily in SP4 or 10.2.3? > > You are assuming that everyone agrees that the TTL 1 solution is more > desirable than TTL 255 and check at the receiving end. no, I'm not assuming that. I'm asserting that there aren't any valid technical arguments in favor of requiring TTL to be 255. Keith From owner-zeroconf@merit.edu Wed Nov 27 16:44:21 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 QAA28959 for ; Wed, 27 Nov 2002 16:44:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 962E3912BA; Wed, 27 Nov 2002 16:46:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D190B912B8; Wed, 27 Nov 2002 16:46:30 -0500 (EST) 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 2244E912B3 for ; Wed, 27 Nov 2002 16:46:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 516255DFCD; Wed, 27 Nov 2002 16:45:51 -0500 (EST) 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 E60DE5DE16 for ; Wed, 27 Nov 2002 16:45:50 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARLjfj01822; Wed, 27 Nov 2002 16:45:42 -0500 (EST) Message-Id: <200211272145.gARLjfj01822@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , Thomas Narten , Zeroconf Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Thu, 28 Nov 2002 08:24:14 +1100.") <200211280824.14715.bhards@bigpond.net.au> Date: Wed, 27 Nov 2002 16:45:41 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > However, part of the point of zeroconf was to make it easy for network > appliances to be deployed. where is that in the charter? I don't see it mentioned at all. > There doesn't seem to be much operational difference between setting > TTL=1 and setting TTL=255 routers will forward the latter, and not the former. this seems like an operational difference to me. Keith From owner-zeroconf@merit.edu Wed Nov 27 17:03: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 RAA29591 for ; Wed, 27 Nov 2002 17:03:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 99E519127F; Wed, 27 Nov 2002 17:06:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B885912AE; Wed, 27 Nov 2002 17:06:12 -0500 (EST) 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 6FCB89127F for ; Wed, 27 Nov 2002 17:06:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A9FE5E013; Wed, 27 Nov 2002 17:06:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by segue.merit.edu (Postfix) with ESMTP id 237565DF64 for ; Wed, 27 Nov 2002 17:06:10 -0500 (EST) Received: from pc-00045 ([144.135.25.75]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15 mta01ps Jul 16 2002 22:47:55) with SMTP id H699E700.CSI; Thu, 28 Nov 2002 08:06:07 +1000 Received: from CPE-203-51-30-180.nsw.bigpond.net.au ([203.51.30.180]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0n 89/10206667); 28 Nov 2002 08:06:07 From: Brad Hards To: Keith Moore Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Thu, 28 Nov 2002 08:55:28 +1100 User-Agent: KMail/1.4.5 Cc: Thomas Narten , Zeroconf References: <200211272145.gARLjfj01822@astro.cs.utk.edu> In-Reply-To: <200211272145.gARLjfj01822@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200211280855.28304.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 28 Nov 2002 08:45, Keith Moore wrote: > > However, part of the point of zeroconf was to make it easy for network > > appliances to be deployed. > > where is that in the charter? I don't see it mentioned at all. "The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train. " That says, to me, that we need to consider more than just my iMac and your Windows box, and how often they need to be updated in any event because they are full of bugs. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE95T9QW6pHgIdAuOMRAj81AJ92vb2gPf+sNirO5GVNeBM+VstHEQCgiXy+ noSLaTSvS9AlsU6oKyyggSE= =UQMR -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Wed Nov 27 17:08:59 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 RAA29726 for ; Wed, 27 Nov 2002 17:08:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49DEF912AE; Wed, 27 Nov 2002 17:11:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19636912AF; Wed, 27 Nov 2002 17:11:31 -0500 (EST) 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 23DC4912AE for ; Wed, 27 Nov 2002 17:11:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FE7C5E01B; Wed, 27 Nov 2002 17:11:31 -0500 (EST) 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 892DA5E018 for ; Wed, 27 Nov 2002 17:11:30 -0500 (EST) 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 gARMBUI07232 for ; Wed, 27 Nov 2002 14:11:30 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 14:11:09 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gARMBTu05256; Wed, 27 Nov 2002 14:11:29 -0800 (PST) Date: Wed, 27 Nov 2002 14:11:29 -0800 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Thomas Narten , Zeroconf To: Keith Moore From: Joshua Graessley In-Reply-To: <200211272141.gARLfgj01799@astro.cs.utk.edu> Message-Id: <2D88026A-0255-11D7-AF74-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 01:41 PM, Keith Moore wrote: >>> Allowing TTL to be 1 is what, a change to one line of code? >>> Surely the fix could be included fairly easily in SP4 or 10.2.3? >> >> You are assuming that everyone agrees that the TTL 1 solution is more >> desirable than TTL 255 and check at the receiving end. > > no, I'm not assuming that. I'm asserting that there aren't any valid > technical arguments in favor of requiring TTL to be 255. Alright, I'll argue against that assertion. Sending nodes should set the TTL to 255. The receiving node should discard packets where the TTL is not 255. This ensures that packets forwarded by misconfigured routers will be ignored. If you set the TTL to 1, you enforce that packets you send will not go off the link but you don't do anything to enforce that you ignore packets originating from off the link. -josh From owner-zeroconf@merit.edu Wed Nov 27 17:34: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 RAA00624 for ; Wed, 27 Nov 2002 17:34:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFEF491237; Wed, 27 Nov 2002 17:36:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3D4491238; Wed, 27 Nov 2002 17:36:41 -0500 (EST) 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 996FC91237 for ; Wed, 27 Nov 2002 17:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B2AC5DDE3; Wed, 27 Nov 2002 17:36:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unknown [64.115.0.82]) by segue.merit.edu (Postfix) with SMTP id 0B3BA5DDDE for ; Wed, 27 Nov 2002 17:36:40 -0500 (EST) Received: (qmail 10304 invoked from network); 27 Nov 2002 22:36:39 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 27 Nov 2002 22:36:39 -0000 Message-ID: <006d01c29665$73884950$6401a8c0@kabilla> From: "Bill Rees" To: "Joshua Graessley" , "Keith Moore" Cc: "Thomas Narten" , "Zeroconf" References: <2D88026A-0255-11D7-AF74-000393760260@apple.com> Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 14:36:37 -0800 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.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joshua Graessley" > > On Wednesday, November 27, 2002, at 01:41 PM, Keith Moore wrote: > > >>> Allowing TTL to be 1 is what, a change to one line of code? > >>> Surely the fix could be included fairly easily in SP4 or 10.2.3? > >> > >> You are assuming that everyone agrees that the TTL 1 solution is more > >> desirable than TTL 255 and check at the receiving end. > > > > no, I'm not assuming that. I'm asserting that there aren't any valid > > technical arguments in favor of requiring TTL to be 255. > > Alright, I'll argue against that assertion. Sending nodes should set > the TTL to 255. The receiving node should discard packets where the TTL > is not 255. This ensures that packets forwarded by misconfigured > routers will be ignored. > > If you set the TTL to 1, you enforce that packets you send will not go > off the link but you don't do anything to enforce that you ignore > packets originating from off the link. > > -josh > > Following this discussion for awhile I notice that there seems to be no attention to intentially configured routers to allow outside packets into the LL net and internal packets out. Is this something to preclude people from doing? This requies that someone provide a gateway between the LL and any outside agents which is an architecture statement that seems implicit in all the discussions. Is this true? If so, then why isn't the gateway tasked with handling all of the routing issues instead of forcing the LL implementations themselves to do this? b From owner-zeroconf@merit.edu Wed Nov 27 17:40:24 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 RAA00769 for ; Wed, 27 Nov 2002 17:40:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9944591238; Wed, 27 Nov 2002 17:42:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6919D912AF; Wed, 27 Nov 2002 17:42:57 -0500 (EST) 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 4697A91238 for ; Wed, 27 Nov 2002 17:42:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 220595DDE3; Wed, 27 Nov 2002 17:42:56 -0500 (EST) 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 BAA265DD9A for ; Wed, 27 Nov 2002 17:42:55 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARMgbj02290; Wed, 27 Nov 2002 17:42:37 -0500 (EST) Message-Id: <200211272242.gARMgbj02290@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , Thomas Narten , Zeroconf Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Thu, 28 Nov 2002 08:55:28 +1100.") <200211280855.28304.bhards@bigpond.net.au> Date: Wed, 27 Nov 2002 17:42:37 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > "The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to > enable networking in the absence of configuration and administration. Zero > configuration networking is required for environments where administration is > impractical or impossible, such as in the home or small office, embedded > systems 'plugged together' as in an automobile, or to allow impromptu > networks as between the devices of strangers on a train. " > > That says, to me, that we need to consider more than just my iMac and your > Windows box, and how often they need to be updated in any event because they > are full of bugs. maybe. but extending that to say that the LL standard needs to be backward compatible with pre-existing printers seems like a big stretch. basically it seems to me that zeroconf has drastically exceeded its charter, and in some cases violated it, for instance by insisting that LL be a security mechanism when the charter specifically disclaims this. Ketih From owner-zeroconf@merit.edu Wed Nov 27 17:41: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 RAA00796 for ; Wed, 27 Nov 2002 17:41:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12F01912AF; Wed, 27 Nov 2002 17:43:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D488B912B0; Wed, 27 Nov 2002 17:43:45 -0500 (EST) 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 C8B40912AF for ; Wed, 27 Nov 2002 17:43:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id B669C5DF64; Wed, 27 Nov 2002 17:43:44 -0500 (EST) 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 5A1BC5DE16 for ; Wed, 27 Nov 2002 17:43:44 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARMhZj02305; Wed, 27 Nov 2002 17:43:35 -0500 (EST) Message-Id: <200211272243.gARMhZj02305@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Thomas Narten , Zeroconf Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 14:11:29 PST.") <2D88026A-0255-11D7-AF74-000393760260@apple.com> Date: Wed, 27 Nov 2002 17:43:35 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Alright, I'll argue against that assertion. Sending nodes should set > the TTL to 255. The receiving node should discard packets where the TTL > is not 255. This ensures that packets forwarded by misconfigured > routers will be ignored. > > If you set the TTL to 1, you enforce that packets you send will not go > off the link but you don't do anything to enforce that you ignore > packets originating from off the link. of course it would also be fine for hosts to insist that TTL were 1. Keith From owner-zeroconf@merit.edu Wed Nov 27 17:46: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 RAA01127 for ; Wed, 27 Nov 2002 17:46:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3BEA912B0; Wed, 27 Nov 2002 17:49:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3293912B1; Wed, 27 Nov 2002 17:49:28 -0500 (EST) 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 935E3912B0 for ; Wed, 27 Nov 2002 17:49:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CC715DE16; Wed, 27 Nov 2002 17:49:27 -0500 (EST) 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 1E2E25DDE3 for ; Wed, 27 Nov 2002 17:49:27 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARMnAj02396; Wed, 27 Nov 2002 17:49:10 -0500 (EST) Message-Id: <200211272249.gARMnAj02396@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bill Rees" Cc: "Joshua Graessley" , "Keith Moore" , "Thomas Narten" , "Zeroconf" Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Wed, 27 Nov 2002 14:36:37 PST.") <006d01c29665$73884950$6401a8c0@kabilla> Date: Wed, 27 Nov 2002 17:49:10 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Following this discussion for awhile I notice that there seems to be no > attention to intentially configured routers to allow outside packets into > the LL net and internal packets out. Is this something to preclude people > from doing? at the very least it seems like something that needs a lot of exploration before anybody does it. my opinion is that LL is not sufficient for anything besides ad hoc networks and initial configuration of appliances that don't have keyboards and displays. all hosts need to be able to support some means of configuring a real address and a default route. at a minimum. there's no need to gateway traffic to and from LL addresses. we already have an IP network that solves the problem in a better way. Keith From owner-zeroconf@merit.edu Wed Nov 27 18:57: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 SAA03247 for ; Wed, 27 Nov 2002 18:57:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D4F8C912B2; Wed, 27 Nov 2002 18:57:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9810D912B5; Wed, 27 Nov 2002 18:57:48 -0500 (EST) 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 40F2D912B2 for ; Wed, 27 Nov 2002 18:57:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FDAE5DE79; Wed, 27 Nov 2002 18:57:44 -0500 (EST) 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 AAFA85DDBF for ; Wed, 27 Nov 2002 18:57:43 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gARNvgI21858 for ; Wed, 27 Nov 2002 15:57:43 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 27 Nov 2002 15:57:27 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gARNvRp06934; Wed, 27 Nov 2002 15:57:27 -0800 (PST) Date: Wed, 27 Nov 2002 15:57:26 -0800 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Thomas Narten , Zeroconf To: Keith Moore From: Joshua Graessley In-Reply-To: <200211272243.gARMhZj02305@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 02:43 PM, Keith Moore wrote: >> Alright, I'll argue against that assertion. Sending nodes should set >> the TTL to 255. The receiving node should discard packets where the >> TTL >> is not 255. This ensures that packets forwarded by misconfigured >> routers will be ignored. >> >> If you set the TTL to 1, you enforce that packets you send will not go >> off the link but you don't do anything to enforce that you ignore >> packets originating from off the link. > > of course it would also be fine for hosts to insist that TTL were 1. This check does not ensure that the packet did not originate from beyond the link. If I'm 5 hops away and I and send a packet with a TTL of 6, the TTL will be 1 when it reaches the remote node. If a packet originated from another network, the TTL will be decremented (even the lamest gateways decrement the TTL). This means checking for a TTL of 255 ensures that the packet originated on the local link. -josh From owner-zeroconf@merit.edu Wed Nov 27 19:00:19 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 TAA03292 for ; Wed, 27 Nov 2002 19:00:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FA83912B4; Wed, 27 Nov 2002 19:02:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F430912B5; Wed, 27 Nov 2002 19:02:52 -0500 (EST) 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 37A83912B4 for ; Wed, 27 Nov 2002 19:02:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 108D15DF00; Wed, 27 Nov 2002 19:02:51 -0500 (EST) 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 BBF7C5DDBF for ; Wed, 27 Nov 2002 19:02:50 -0500 (EST) 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 gAS02nw28277 for ; Wed, 27 Nov 2002 16:02:50 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 16:02:28 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gAS02nu09097; Wed, 27 Nov 2002 16:02:49 -0800 (PST) Date: Wed, 27 Nov 2002 16:02:48 -0800 Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Keith Moore , Thomas Narten , Zeroconf To: Bill Rees From: Joshua Graessley In-Reply-To: <006d01c29665$73884950$6401a8c0@kabilla> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 27, 2002, at 02:36 PM, Bill Rees wrote: > Following this discussion for awhile I notice that there seems to be no > attention to intentially configured routers to allow outside packets > into > the LL net and internal packets out. Is this something to preclude > people > from doing? This requies that someone provide a gateway between the > LL and > any outside agents which is an architecture statement that seems > implicit in > all the discussions. Is this true? If so, then why isn't the gateway > tasked with handling all of the routing issues instead of forcing the > LL > implementations themselves to do this? Link Local addresses are only valid on the local link. Configuring a router to forward these packets off of the local link would lead to a number of problems and is beyond the scope of this working group. Gateways must never forward packets with LL addresses. Most gateways know nothing of link-local so some burden is placed on the nodes implementing LL to avoid communicating with hosts off the local link using link-local addresses. -josh From owner-zeroconf@merit.edu Wed Nov 27 19:05: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 TAA03392 for ; Wed, 27 Nov 2002 19:05:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 158E791210; Wed, 27 Nov 2002 19:04:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77C8E91235; Wed, 27 Nov 2002 19:04:05 -0500 (EST) 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 48F09912B5 for ; Wed, 27 Nov 2002 19:03:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2CC595DF00; Wed, 27 Nov 2002 19:03:32 -0500 (EST) 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 D70B35DE79 for ; Wed, 27 Nov 2002 19:03:31 -0500 (EST) 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 gAS03Vw28373 for ; Wed, 27 Nov 2002 16:03:31 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Nov 2002 16:03:10 -0800 Received: from [17.219.194.222] (vpn-scv-x4-222.apple.com [17.219.194.222]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gAS03U912757 for ; Wed, 27 Nov 2002 16:03:31 -0800 (PST) Message-Id: <200211280003.gAS03U912757@scv3.apple.com> Subject: Security discussion for TTL=255 now out of scope Date: Wed, 27 Nov 2002 16:03:31 -0800 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 Thomas Narten made the following comment: >In the case here, it seems like the 255 check provides >a small security benefit, with the emphasis on small. Erik Guttman and I have discussed this matter and have agreed that in the interests of reaching a conclusion on this document, it is necessary to declare that: ANY FURTHER DEBATE ON WHETHER THE SECURITY BENEFIT OF CHECKING THE RECEIVED TTL IS TINY/SMALL/MEDIUM/LARGE/ETC. IS OUT OF SCOPE FOR FURTHER DISCUSSION ON THE LIST. All discussion in this area has proved religious and fruitless. What we can all agree is that if you receive an IP packet with a TTL of 255, it is safe to assume it originated from another host on the same link. What the receiver decides to do with this knowledge (with respect to security or anything else) is up to the receiver. The point is that TTL=255 gives the receiver some (small) piece of information about origin of the packet. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Nov 27 19:17:55 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 TAA03600 for ; Wed, 27 Nov 2002 19:17:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C646E91226; Wed, 27 Nov 2002 19:20:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E01E91235; Wed, 27 Nov 2002 19:20:30 -0500 (EST) 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 83D9391226 for ; Wed, 27 Nov 2002 19:20:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A10B5DE79; Wed, 27 Nov 2002 19:20:29 -0500 (EST) 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 E6D285DDBF for ; Wed, 27 Nov 2002 19:20:28 -0500 (EST) 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 gAS0KSI24445 for ; Wed, 27 Nov 2002 16:20:28 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Nov 2002 16:20:07 -0800 Received: from [17.219.194.222] (vpn-scv-x4-222.apple.com [17.219.194.222]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gAS0KRu16174 for ; Wed, 27 Nov 2002 16:20:27 -0800 (PST) Message-Id: <200211280020.gAS0KRu16174@scv1.apple.com> Subject: Where did this TTL=255 idea come from? Date: Wed, 27 Nov 2002 16:20:28 -0800 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 Several people have privately accused Apple (or me personally) of trying to force "Apple's way" of doing things on Microsoft (and the rest of the world). Several people have asserted that instead of being willing to update Apple's software, Apple is trying to force the group concensus to comply with the software that Apple has already shipped. Just for the record, let me set things straight. We're in the current mess because Apple's DID update its software to comply with the Zeroconf group concensus. I originally advocated TTL=1. On 4th April 2001, Dave Thaler send the email below, arguing why the TTL should be 255. I read his arguments and was swayed by them. As a result, the draft was updated to include the current text about setting and checking TTL, and Apple immediately shipped a software update to set the TTL correctly. Now, a year and a half later, we're having these discussions about interoperability because Apple did acceed to a suggestion received from a Microsoft employee, and Apple did update its software to comply, and Microsoft didn't. I still agree with the arguments made by Van Jacobson and Dave Thaler, and I still think the correct technical decision is to set and check TTL=255. >Subject: RE: IPv4 linklocal security >Date: 4 Apr 2001 7:18 pm >From: Dave Thaler, dthaler@Exchange.Microsoft.com >To: Stuart Cheshire, cheshire@apple.com >CC: zeroconf@merit.edu > >However, the discussion of TTL=1 vs TTL=255 basically repeats a >discussion that occurred in the MBoneD WG at IETF 38 (Memphis). >The meeting notes don't say much, but are at >http://www.ietf.org/proceedings/97apr/97apr-final/xrtftr65.htm > >The essence of the discussion is that Ross Finlayson gave a presentation >in which he asked what the best TTL was, for each multicast scope. He >suggested publishing a list of recommended TTLs for each scope. >Van Jacobson and I both argued that TTL=255 should always be used, so >the meeting minutes skip to the conclusion which was "The final >recommendation was to abolish the use of TTL as a boundary mechanism", >and as a result no list of TTLs per scope were published (and any >old lists on web pages were removed). > >One of the arguments that Van and I made was that using TTL=255 >provides two things: >1) an incentive for ISPs to do the right thing >by configuring routers to fix "holes" in scopes (in the zeroconf >context this translates to not forwarding 169.254/16), or even >better, an incentive for router vendors to do this automatically, and >2) (less importantly) a way to easily detect offenders. > >In contrast TTL=1 provides no incentive for ISPs/router vendors to >do the right thing. > >Whether this argument is strong enough to use TTL=255 in the >Zeroconf scenarios is up to this WG to decide, but it was >good enough for the MBoneD WG in 1997. > >The two rules at the top of this email are orthogonal to the >TTL decision. Even with the two rules on address checking, >I'd still prefer TTL=255. > >-Dave From owner-zeroconf@merit.edu Wed Nov 27 19:25: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 TAA03724 for ; Wed, 27 Nov 2002 19:25:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03D6691235; Wed, 27 Nov 2002 19:28:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9D77912B5; Wed, 27 Nov 2002 19:28:07 -0500 (EST) 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 DA13191235 for ; Wed, 27 Nov 2002 19:28:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA9CC5DE79; Wed, 27 Nov 2002 19:28:06 -0500 (EST) 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 3CF335DF3C for ; Wed, 27 Nov 2002 19:28:06 -0500 (EST) 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 gAS0S5w01773 for ; Wed, 27 Nov 2002 16:28:05 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Nov 2002 16:27:44 -0800 Received: from [17.219.194.222] (vpn-scv-x4-222.apple.com [17.219.194.222]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gAS0S4u19225 for ; Wed, 27 Nov 2002 16:28:05 -0800 (PST) Message-Id: <200211280028.gAS0S4u19225@scv1.apple.com> Subject: Re: Link-local TTL Date: Wed, 27 Nov 2002 16:28:06 -0800 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 RJ Atkinson wrote: >1) This TTL check thing is an operational consideration, NOT a security >consideration. >2) The best technical approach is probably actually this one, which I >typo'd > earlier this week, but maybe got right this morning: > > A) Receivers MUST drop incoming link-local packets where (TTL != 1). > B) Senders MUST set (TTL = 1) on all outbound link-local packets. > >Rationale: > - This is fully backwards-compatible with the deployed systems. This is backwards. Checking for TTL=1 would be fully INCOMPATIBLE with every current deployed system. Mac OS 9 and X sets TTL=255. Windows by default sets TTL=128 (but this can be changed). If there's any argument based on compatibility with deployed systems, it has be be a choice between checking TTL=128 (for compatibility with existing Windows machines where the default hasn't been changed) or TTL=255 (for compatibility with existing Macs). I don't think we should make decisions based on compatibility with deployed systems, but if we do, checking for TTL=128 or checking for TTL=255 are the two available choices. > - This prevents a link-local from being forwarded off-link, > even if the router is misconfigured or unaware of link-local >addressing. This is not necessary -- compliant hosts never send packets to a router for forwarding anyway. (Having the document try to prescribe the TTL-setting behaviour of non-compliant hosts is self-contradictory nonsense.) Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Nov 27 19:30:24 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 TAA03830 for ; Wed, 27 Nov 2002 19:30:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C7DC912B6; Wed, 27 Nov 2002 19:32:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37EA0912B8; Wed, 27 Nov 2002 19:32:14 -0500 (EST) 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 D7269912B6 for ; Wed, 27 Nov 2002 19:32:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFB3E5DF78; Wed, 27 Nov 2002 19:32:12 -0500 (EST) 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 771DE5DDBF for ; Wed, 27 Nov 2002 19:32:12 -0500 (EST) 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 gAS0WCw02271 for ; Wed, 27 Nov 2002 16:32:12 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Nov 2002 16:31:51 -0800 Received: from [17.219.194.222] (vpn-scv-x4-222.apple.com [17.219.194.222]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gAS0WBu20670 for ; Wed, 27 Nov 2002 16:32:11 -0800 (PST) Message-Id: <200211280032.gAS0WBu20670@scv1.apple.com> Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Wed, 27 Nov 2002 16:32:12 -0800 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 >Talking on behalf of Apple, we consider that dropping datagrams from >169.254 with TTL != 255 is a MUST. All recent versions of Mac OS 9 and >Mac OS X do implement this behavior and we've already accepted the fact >that we may fail to interoperate with older version of Mac OS. Let me add a correction: Since 2001, Mac OS 9 and X machines have set the TTL to 255, but not checked the TTL on inbound packets. This was done to provide a one-year "grace period" where Macs emit correct packets, but remain compatible with older systems that don't. Starting in August 2002, the one-year "grace period" was over, and Mac OS X 10.2 started enforcing the check on inbound packets. We felt that one year should be enough time for other vendors to ship software updates to bring their products in-line with what the working group had agreed. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Nov 27 20:06: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 UAA04348 for ; Wed, 27 Nov 2002 20:06:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4E1F912B9; Wed, 27 Nov 2002 20:09:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 846B8912BB; Wed, 27 Nov 2002 20:09:20 -0500 (EST) 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 74759912B9 for ; Wed, 27 Nov 2002 20:09:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5CF7B5DDCA; Wed, 27 Nov 2002 20:09:19 -0500 (EST) 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 D8C485DDBF for ; Wed, 27 Nov 2002 20:09:18 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gAS19II29715 for ; Wed, 27 Nov 2002 17:09:18 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 27 Nov 2002 17:09:18 -0800 Received: from [17.219.194.222] (vpn-scv-x4-222.apple.com [17.219.194.222]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id gAS19Gp03683 for ; Wed, 27 Nov 2002 17:09:16 -0800 (PST) Message-Id: <200211280109.gAS19Gp03683@scv2.apple.com> Subject: Summary of alternatives Date: Wed, 27 Nov 2002 17:09:17 -0800 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 There are four practical alternatives for the Working Group to choose between: 1. Always check TTL=255 2. Always check TTL=1 3. Don't check TTL at all 4. Have an optional (user configured) check for TTL=255 The three metrics to examine are: (Mac) Always compatible with existing Macs (Win) Always compatible with existing Windows boxes (Orig) Always able to determine if packet originated on the local link The scores: (Mac) (Win) (Orig) 1. Always check TTL=255 + - + 2. Always check TTL=1 - - - 3. Don't check TTL at all + + - 4. User configured TTL=255 + - - Option 1 works with Macs. Option 1 tells you the origin of the packet. Option 1 works with Windows, but only after you've changed the registry key as described in Appendix A.3. (This registry change doesn't have to be done manually by the user -- we're recommending to printer vendors that their printer driver software should automatically make the registry change so that Windows will automatically work properly with their Zeroconf printers.) Option 2 works with nothing today. It tells you nothing about the origin of the packet. It may limit forwarding of the packet, but this is a moot point because compliant hosts don't send LL packets to routers for forwarding anyway. Option 3 works with today's Macs and Windows boxes, but doesn't tell you the origin on the packet. Option 4 lets the user configure whether they want their printer to guard against off-link packets, or whether they want their printer to be compatible with the old version of Windows they are using. If the user configures it to check, it might not work with old Windows boxes, generating expensive support calls, so it fails the "Always works with Windows" test. If the user configures it to not check, then it might accept off-link packets, so it fails the "Always able to determine if packet originated on the local link" test. I have only one further comment to make on this topic: Which part of "Zero" and "Configuration" did you not understand? If we have to configure something to make it all work properly, lets configure the Registry key on last-year's Windows boxes to make them work better, not force the customer who buys next year's Zeroconf devices to understand and change some configuration setting to make them work worse. Of the four, options 1 and 3 get two points each. Option 1 has the benefit that receivers know the origin of the packet. Option 3 has the benefit that it saves Microsoft the hassle of having to change its software. My vote goes for option 1, because it gives the bigger long-term benefit. Some people have suggested a policy where we require senders to set the TTL to 255, but not check the TTL on reception, and then in future, after Windows has been updated, we update the specification to require the check too. This simply doesn't work. The fact is that there is no incentive for vendors to set the TTL correctly if no one is checking. The longer time goes on, the more non-conformant devices there will be, and it will become impossible to enforce the check later. We have to decide now. In the interest of maintaining a good signal-to-noise ratio, I ask everyone to send a BRIEF email saying BRIEFLY which of the four options they support (or optionally, an email describing some new option I haven't thought of). Happy Thanksgiving. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Nov 27 20:23: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 UAA04657 for ; Wed, 27 Nov 2002 20:23:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 814DE912B5; Wed, 27 Nov 2002 20:26:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 465A1912B8; Wed, 27 Nov 2002 20:26:09 -0500 (EST) 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 4CB0E912B5 for ; Wed, 27 Nov 2002 20:26:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 359A15DDCA; Wed, 27 Nov 2002 20:26:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta02bw.bigpond.com (unknown [144.135.24.138]) by segue.merit.edu (Postfix) with ESMTP id B6B175DDBC for ; Wed, 27 Nov 2002 20:26:06 -0500 (EST) Received: from pc-00045 ([144.135.24.81]) by mta02bw.bigpond.com (Netscape Messaging Server 4.15 mta02bw Jul 16 2002 22:47:55) with SMTP id H69ING00.6ZB; Thu, 28 Nov 2002 11:26:04 +1000 Received: from CPE-203-51-30-180.nsw.bigpond.net.au ([203.51.30.180]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0n 44/10943345); 28 Nov 2002 11:26:03 From: Brad Hards To: Joshua Graessley , Bill Rees Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Thu, 28 Nov 2002 12:15:19 +1100 User-Agent: KMail/1.4.5 Cc: Zeroconf References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200211281215.19633.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 28 Nov 2002 11:02, Joshua Graessley wrote: > Link Local addresses are only valid on the local link. Configuring a > router to forward these packets off of the local link would lead to a > number of problems and is beyond the scope of this working group. > Gateways must never forward packets with LL addresses. Most gateways > know nothing of link-local so some burden is placed on the nodes > implementing LL to avoid communicating with hosts off the local link > using link-local addresses. I'm not sure how many people here agree, but I consider that if you only have IPv4 link-local addresses, then the only way of safely communicating off the local link is with an application level gateway. You could NAT, but shouldn't. For example, if you need to view a web-site at http://zeroconf.sf.net, and there is some internet connectivity, then it should be possible to view that page. One possible implementation would be mDNS lookup of the address, a http proxy located via wpad (SLP, mDNS, DNS-SD, whatever), and a browser that is wpad aware. I really wish the zeroconf WG had codified this, and indicated how it should be done. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE95W4nW6pHgIdAuOMRAqL/AKCqsZJBNu1Q9+g/uXZshMgZrqhxJwCdEj9P YOaursPHDLLVDMdu3V3LuaI= =JmYP -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Wed Nov 27 20:35: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 UAA04873 for ; Wed, 27 Nov 2002 20:35:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 912B9912B8; Wed, 27 Nov 2002 20:38:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5850B912BB; Wed, 27 Nov 2002 20:38:18 -0500 (EST) 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 3A2DE912B8 for ; Wed, 27 Nov 2002 20:38:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 192745DEE6; Wed, 27 Nov 2002 20:38:17 -0500 (EST) 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 AE0975DE77 for ; Wed, 27 Nov 2002 20:38:16 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAS1cDj02895; Wed, 27 Nov 2002 20:38:13 -0500 (EST) Message-Id: <200211280138.gAS1cDj02895@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Security discussion for TTL=255 now out of scope In-reply-to: (Your message of "Wed, 27 Nov 2002 16:03:31 PST.") <200211280003.gAS03U912757@scv3.apple.com> Date: Wed, 27 Nov 2002 20:38:13 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Erik Guttman and I have discussed this matter and have agreed that in the > interests of reaching a conclusion on this document, it is necessary to > declare that: > > ANY FURTHER DEBATE ON WHETHER THE SECURITY BENEFIT OF > CHECKING THE RECEIVED TTL IS TINY/SMALL/MEDIUM/LARGE/ETC. > IS OUT OF SCOPE FOR FURTHER DISCUSSION ON THE LIST. > let me get this straight. you are forbidding discussion on an issue of fundamental technical importance, one which an area director has brought up as part of IESG review, one which you are required to discuss in every RFC, one which the charter specifically states is not a primary goal of zeroconf - in order to prevent any changes to the document which might bring it in line with reasonable expectations and the working group's charter? I just want to be sure I understand. because frankly, I don't think that is the perogative of a WG chair. Keith From owner-zeroconf@merit.edu Wed Nov 27 20:41:21 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 UAA04954 for ; Wed, 27 Nov 2002 20:41:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE1DE912BB; Wed, 27 Nov 2002 20:43:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89943912BC; Wed, 27 Nov 2002 20:43:53 -0500 (EST) 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 71881912BB for ; Wed, 27 Nov 2002 20:43:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 58BB85DEE6; Wed, 27 Nov 2002 20:43:52 -0500 (EST) 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 EE4665DE77 for ; Wed, 27 Nov 2002 20:43:51 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAS1hnj02929; Wed, 27 Nov 2002 20:43:49 -0500 (EST) Message-Id: <200211280143.gAS1hnj02929@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Where did this TTL=255 idea come from? In-reply-to: (Your message of "Wed, 27 Nov 2002 16:20:28 PST.") <200211280020.gAS0KRu16174@scv1.apple.com> Date: Wed, 27 Nov 2002 20:43:49 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Just for the record, let me set things straight. We're in the current > mess because Apple's DID update its software to comply with the Zeroconf > group concensus. The WG consensus is only one step, and only one requirement. Technical soundness is also a requirement, independent of WG consensus. Also, WG consensus is not sufficient to determine technical soundness. Community-wide review also plays a part. So does IESG review. All of this is documented in RFC 2026. I find it entirely inappropriate that you have been attempting to force the WG to conform to a specification that has serious technical flaws, and dismmissing significant technical objections out-of-hand, in order to protect your employer from the risk that it exposed itself to by shipping code that implemented a preliminary version of the spec. I think that's a serious conflict of interest for a WG chair. Keith From owner-zeroconf@merit.edu Wed Nov 27 20:56:21 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 UAA05432 for ; Wed, 27 Nov 2002 20:56:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1634912BC; Wed, 27 Nov 2002 20:58:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90E81912BD; Wed, 27 Nov 2002 20:58:53 -0500 (EST) 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 813C0912BC for ; Wed, 27 Nov 2002 20:58:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65DA65DFF2; Wed, 27 Nov 2002 20:58:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id F18F35DE77 for ; Wed, 27 Nov 2002 20:58:51 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA27177 for ; Wed, 27 Nov 2002 20:58:51 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA18382 for ; Wed, 27 Nov 2002 20:58:50 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA19754 for ; Wed, 27 Nov 2002 20:58:50 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 27 Nov 2002 20:58:46 -0500 Subject: Re: Where did this TTL=255 idea come from? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211280143.gAS1hnj02929@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/27/2002 20:43, "Keith Moore" wrote: > > I find it entirely inappropriate that you have been attempting to force > the WG to conform to a specification that has serious technical flaws, > and dismmissing significant technical objections out-of-hand, in order > to protect your employer from the risk that it exposed itself to by > shipping code that implemented a preliminary version of the spec. > I think that's a serious conflict of interest for a WG chair. > By that standard, every WG chair using any computer system at all is conflicted. We all have preferences, and will attempt, even unconsciously, to make sure, "our side" comes out ahead. To avoid any possible conflict, the WG chair would have to not be a computer user at any level. This of course, would be ridiculous. At least if Stuart's biased, we know where, how, and why. This insistence that the commercial industry be ignored or even chastised for having anything to do with standards is unrealistic, and antithetical to getting the standards used. It is psychologically impossible for a human being to be objective about anything, so let's not apply an impossible standard to Stuart. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Nov 27 21:07: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 VAA05610 for ; Wed, 27 Nov 2002 21:07:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23177912BD; Wed, 27 Nov 2002 21:10:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6C05912BE; Wed, 27 Nov 2002 21:10:31 -0500 (EST) 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 05742912BD for ; Wed, 27 Nov 2002 21:10:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE1E65DFE1; Wed, 27 Nov 2002 21:10:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by segue.merit.edu (Postfix) with ESMTP id E4AB85DEE6 for ; Wed, 27 Nov 2002 21:10:29 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:e5d5:6b:6f5a:1eaf]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAS2AKd90565; Thu, 28 Nov 2002 11:10:20 +0900 (JST) Date: Thu, 28 Nov 2002 11:10:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200211271954.gARJsm630389@rotala.raleigh.ibm.com> References: <20021126194721.GI5973@uiuc.edu> <200211271954.gARJsm630389@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-zeroconf@merit.edu Precedence: bulk >>>>> On Wed, 27 Nov 2002 14:54:48 -0500, >>>>> Thomas Narten said: > It sure sounds to me like you are saying above that the IPv6 specs > require all recieved LL packets with a Hop Limit != 255 be dropped. > I challenge you to find such a statement in the IPv6 specs. > Neighbor Discovery, RFC 2461, is a specific IPv6 application that uses > LL addresses, and that *specific* application has chosen to require > that ND packets received with a Hop Limit other than 255 be dropped. > I am aware of no other IPv6 applications that require such a check > (but could imagine it might make sense in some cases), and there is no > general requirement to check when LLs are used for protocols other > than ND. A minor followup: RIPng is another example that requires 255 hop limit, whereas it also requires link-local source addresses. (I personally don't understand the intention of the hop limit requirement and do think the requirement is actually redundant.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-zeroconf@merit.edu Wed Nov 27 21:19: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 VAA05780 for ; Wed, 27 Nov 2002 21:19:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D5E9912BE; Wed, 27 Nov 2002 21:22:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46CCE912BF; Wed, 27 Nov 2002 21:22:02 -0500 (EST) 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 20CE0912BE for ; Wed, 27 Nov 2002 21:22:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 093CA5DEC2; Wed, 27 Nov 2002 21:22:01 -0500 (EST) 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 CFD6B5DDCC for ; Wed, 27 Nov 2002 21:22:00 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAS2Lvj03050; Wed, 27 Nov 2002 21:21:57 -0500 (EST) Message-Id: <200211280221.gAS2Lvj03050@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Summary of alternatives In-reply-to: (Your message of "Wed, 27 Nov 2002 17:09:17 PST.") <200211280109.gAS19Gp03683@scv2.apple.com> Date: Wed, 27 Nov 2002 21:21:57 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > There are four practical alternatives for the Working Group to choose > between: > > 1. Always check TTL=255 > 2. Always check TTL=1 > 3. Don't check TTL at all > 4. Have an optional (user configured) check for TTL=255 Seems incomplete. I find several alternatives worth considering: 1. set TTL=255 on transmit, check TTL==255 on receipt 2. set TTL=1 on transmit, check TTL==1 on receipt 3a. set TTL=255 on transmit, don't check on receipt 3b. set TTL=1 on transmit, don't check on receipt 4a. set TTL=255 on transmit, optionally check TTL==255 on receipt 4b. set TTL=1 on transmit, optionally check TTL==1 on receipt There appear to be other options for receipt checking - in particular, checking to see if TTL is one of 2 or 3 discrete values on receipt. Setting TTL=1 on transmit has the desirable property that routers will automagically filter traffic going outside the local link. This makes it unlikely that LL packets will consume bandwidth from adjacent networks and also unlikely that apps using LL will be confused by traffic from adjacent networks. Checking TTL==1 || TTL==255 || TTL==128 would allow receivers to accept LL packets from both legacy Windows and legacy MacOS implementations. You could do away with the TTL check entirely, but there's probably some value in doing a minimal TTL check (just like it is useful to check for packets with a broadcast source address) as long as you don't trust it to block all outside traffic. So this pair of constraints provides the greatest assurance that a) conforming implementations don't emit packets into adjacent networks, and b) conforming implementations can interoperate equally well with legacy implementations from different vendors Deliberately generated packets with inappropriate TTLs, and leaked LL packets from legacy implementations could confuse apps. So it would be necessary for hosts and apps using LL to behave gracefully when receiving LL packets that could not be replied to. Ordinary measures for thwarting SYN attacks should suffice for TCP. Of course apps should not assume that LL packets are trustworthy or have any authorization associated with them by virtue of their being LL packets, regardless of what the TTL value is. Keith From owner-zeroconf@merit.edu Wed Nov 27 22:45: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 WAA07780 for ; Wed, 27 Nov 2002 22:45:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F382912C0; Wed, 27 Nov 2002 22:48:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7CAF912C1; Wed, 27 Nov 2002 22:47:46 -0500 (EST) 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 CB057912C0 for ; Wed, 27 Nov 2002 22:47:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id A21985DE0C; Wed, 27 Nov 2002 22:47:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id AD31C5DDCC for ; Wed, 27 Nov 2002 22:47:00 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAS3kvNp052942; Wed, 27 Nov 2002 22:46:57 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-193-212.mts.ibm.com [9.65.193.212]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAS3krkk062290; Wed, 27 Nov 2002 22:46:53 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAS3kHm04374; Wed, 27 Nov 2002 22:46:17 -0500 Message-Id: <200211280346.gAS3kHm04374@cichlid.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Security discussion for TTL=255 now out of scope In-Reply-To: Message from Stuart Cheshire of "Wed, 27 Nov 2002 16:03:31 PST." <200211280003.gAS03U912757@scv3.apple.com> Date: Wed, 27 Nov 2002 22:46:17 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > Erik Guttman and I have discussed this matter and have agreed that in the > interests of reaching a conclusion on this document, it is necessary to > declare that: > ANY FURTHER DEBATE ON WHETHER THE SECURITY BENEFIT OF > CHECKING THE RECEIVED TTL IS TINY/SMALL/MEDIUM/LARGE/ETC. > IS OUT OF SCOPE FOR FURTHER DISCUSSION ON THE LIST. > All discussion in this area has proved religious and fruitless. If security benefits (or non-benefits) of the check for TTL of 255 on received packets is out of scope, please explain why the receiver would ever want to do such a check. What problem does such a check solve? I'm dead serious. I think there is much agreement that we need to keep LLs on the attached link. If that is the sole criteria, seems to me that: - all senders should set the TTL to 1. This ensures that routers won't forward them off link. This includes all existing deployed routers, with no special configuration needed. They do this today. Sure, buggy or compromised routers might not, but in such environments one has much bigger problems to worry about. - setting the TTL to anything other than 1 (and especially 255) seems nuts, as it makes it much more likely that LL packets will leak to places where they don't belong. And what would be the benefit of using a higher TTL? - the only reason I can think of to set the TTL to 255 on send is if you want the receiver to check for that value. But why would anyone care to do that? (remember, I (and others) can't site security arguments...) > What we can all agree is that if you receive an IP packet with a TTL of > 255, it is safe to assume it originated from another host on the same > link. What the receiver decides to do with this knowledge (with respect > to security or anything else) is up to the receiver. The point is that > TTL=255 gives the receiver some (small) piece of information about origin > of the packet. And what information does "origin of the packet" communicate and under what conditions would it be appropriate to use that information to silently discard *ALL* traffic from a particular? If the WG can't articulate that, I have a hard time understanding why the TTL shouldn't just be set to 1 for the above reasons. Thomas From owner-zeroconf@merit.edu Wed Nov 27 23:16:07 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 XAA08470 for ; Wed, 27 Nov 2002 23:16:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B7DB912C1; Wed, 27 Nov 2002 23:18:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCB56912C2; Wed, 27 Nov 2002 23:18:33 -0500 (EST) 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 AE7D0912C1 for ; Wed, 27 Nov 2002 23:18:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CE6F5E02B; Wed, 27 Nov 2002 23:18:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from staff3.cso.uiuc.edu (staff3.cso.uiuc.edu [128.174.5.54]) by segue.merit.edu (Postfix) with ESMTP id 4BA415E02A for ; Wed, 27 Nov 2002 23:18:32 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by staff3.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gAS4IVj19816; Wed, 27 Nov 2002 22:18:31 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gAS4IVD13214; Wed, 27 Nov 2002 22:18:31 -0600 (CST) Date: Wed, 27 Nov 2002 22:18:31 -0600 From: "Jay A. Kreibich" To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt Message-ID: <20021128041831.GA12535@uiuc.edu> Reply-To: jak@uiuc.edu References: <20021126194721.GI5973@uiuc.edu> <200211271954.gARJsm630389@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211271954.gARJsm630389@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, Nov 27, 2002 at 02:54:48PM -0500, Thomas Narten scratched on the wall: > It sure sounds to me like you are saying above that the IPv6 specs > require all recieved LL packets with a Hop Limit != 255 be dropped. > > I challenge you to find such a statement in the IPv6 specs. Indeed, you are correct. It has been some time since I've looked at the RFCs themselves, and the last IPv6 book I recently read didn't make this distinction very clear. Unfortunately, that is what was most fresh in my mind. > Neighbor Discovery, RFC 2461, is a specific IPv6 application that uses > LL addresses, and that *specific* application has chosen to require > that ND packets received with a Hop Limit other than 255 be dropped. Yes, as you pointed out, parts of the IPv6 suite uses the "hop limit == 255" verification for internal "applications" within the protocol, such as Neighbor Discovery (which is critical for the IPv6 protocol suite as a whole to work, and makes the assumption that traffic is link-local only), but it is true that this verification is not actually prescribed for *all* link-local traffic. There is no reason it couldn't be, however. It is also worth considering that this operational verification is less critical in IPv6 since the concept of link-local addresses is "native" to the IPv6 standard and *all* routers that understand IPv6 understand the link-local address scheme used by it, and know not to to forward packets that use link-local addresses. IIRC (but don't quote me on this because all my documents are at the office but I'm not), the reason the Neighbor Discovery protocol uses this extra check is because some of the conversations use global addresses for both source and dest, but there still needs to be some way to verify packets are really link-local. The hop limit/TTL max value check is perfect for this situation when the addresses alone cannot be used for verification and allows the protocol to resist accidental misconfiguration or intentional tampering. Given that many IPv4 devices don't/won't understand the IPv4 LL address scheme, I feel that making the same system mandatory (using the maximum value) has great value. In a sense, the link-local addresses cannot be trusted to be a "good enough" barrier in themselves if the devices that operate on these addresses don't understand their significance. The max TTL limit allows the protocol to be robust enough that hosts can verify invalid packets and resist protocol tampering or misconfiguration. While there is a chance for delivery of inappropriate traffic (and the consumption of local resources associated with that delivery of traffic), as others have pointed out, this just provides motivation for correctly configured and/or upgraded routers. Given that the IPv4 standard also says a host should never send these packets to a router to start with, the "prevent packets from going off-line" seems like a much less problematic issue then the "prevent packets from coming on-link" issue, which the TTL check waters down to "reject packets that are not from on-link." -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Thu Nov 28 14:20:07 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 OAA02820 for ; Thu, 28 Nov 2002 14:20:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3205991228; Thu, 28 Nov 2002 14:22:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBDFB912D3; Thu, 28 Nov 2002 14:22:42 -0500 (EST) 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 C386991228 for ; Thu, 28 Nov 2002 14:22:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAB955DF1D; Thu, 28 Nov 2002 14:22:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 355F85DE5A for ; Thu, 28 Nov 2002 14:22:41 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gASJMeNP184710; Thu, 28 Nov 2002 14:22:40 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-193-212.mts.ibm.com [9.65.193.212]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gASJMbV3036772; Thu, 28 Nov 2002 14:22:37 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gASJLwv06951; Thu, 28 Nov 2002 14:21:58 -0500 Message-Id: <200211281921.gASJLwv06951@cichlid.adsl.duke.edu> To: jak@uiuc.edu Cc: zeroconf@merit.edu Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message from "Jay A. Kreibich" of "Wed, 27 Nov 2002 22:18:31 CST." <20021128041831.GA12535@uiuc.edu> Date: Thu, 28 Nov 2002 14:21:58 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > Yes, as you pointed out, parts of the IPv6 suite uses the "hop limit > == 255" verification for internal "applications" within the protocol, > such as Neighbor Discovery (which is critical for the IPv6 protocol > suite as a whole to work, and makes the assumption that traffic is > link-local only), but it is true that this verification is not actually > prescribed for *all* link-local traffic. There is no reason it > couldn't be, however. Except that the IPv6 WG has never thought that the 255-on-receipt verification should be done for all packets. I'd be surprised if there would be consensus for such a requirement. AFAIK, the topic hasn't been discussed in a very long time in that forum. > It is also worth considering that this operational verification is > less critical in IPv6 since the concept of link-local addresses is > "native" to the IPv6 standard and *all* routers that understand IPv6 > understand the link-local address scheme used by it, and know not to > to forward packets that use link-local addresses. There have been concerns since day one in IPv6, that even though the specs say don't forward LL packets, implementors will take shortcuts as part of "optimizing" forwarding and such. See below for more on this. > IIRC (but don't quote me on this because all my documents are at the > office but I'm not), the reason the Neighbor Discovery protocol > uses this extra check is because some of the conversations use global > addresses for both source and dest, but there still needs to be some > way to verify packets are really link-local. The hop limit/TTL max > value check is perfect for this situation when the addresses alone > cannot be used for verification and allows the protocol to resist > accidental misconfiguration or intentional tampering. My recollection of the motivation for putting in the 255-on-receipt check in ND was as follows. In IPv4, address resolution uses ARP, which runs directly over the Ethernet. One can't forward ARP through routers. It just doesn't happen. But in IPv6, since ND runs on top of IP, routers could in theory forward ND packets. Consequently, it might make ND vulnerable to certain types of attacks (i.e., from off-link attackers) that ARP was immune too. There was concern that we didn't want IPv6's ND to be viewed as less secure than ARP. Thus, in the specifice case of ND, where it was known and required that ND only be used between nodes connected to the same link, the 255-on-receipt check made sense. Note the logic above. It applies to ND specfically. The same logic would not lead one to conclude that all LL traffic should be subject to the 255-on-receipt test. If one is using telnet, ssh, http, etc. on a LL address, does the application care that the endpoint is supposed to be on the same link? Almost certainly not. Thus, there is no point in enforcing such a check _IN ALL CASES_. If applications want to require such checks, that's fine. Applications presumably know more about what they are doing and whether such a check actually makes sense. Thomas From owner-zeroconf@merit.edu Thu Nov 28 14:44: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 OAA03086 for ; Thu, 28 Nov 2002 14:44:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D6E3C912D6; Thu, 28 Nov 2002 14:46:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98095912D7; Thu, 28 Nov 2002 14:46:39 -0500 (EST) 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 8E58C912D6 for ; Thu, 28 Nov 2002 14:46:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95DEE5E06A; Thu, 28 Nov 2002 14:46:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 2BD715E063 for ; Thu, 28 Nov 2002 14:46:36 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gASJkWNp182622; Thu, 28 Nov 2002 14:46:32 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-193-212.mts.ibm.com [9.65.193.212]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gASJkSV3037356; Thu, 28 Nov 2002 14:46:29 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gASJjn707151; Thu, 28 Nov 2002 14:45:49 -0500 Message-Id: <200211281945.gASJjn707151@cichlid.adsl.duke.edu> To: Keith Moore Cc: Stuart Cheshire , zeroconf@merit.edu Subject: Re: Where did this TTL=255 idea come from? In-Reply-To: Message from Keith Moore of "Wed, 27 Nov 2002 20:43:49 EST." <200211280143.gAS1hnj02929@astro.cs.utk.edu> Date: Thu, 28 Nov 2002 14:45:49 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > The WG consensus is only one step, and only one requirement. > Technical soundness is also a requirement, independent of WG > consensus. Also, WG consensus is not sufficient to determine > technical soundness. Community-wide review also plays a part. > So does IESG review. All of this is documented in RFC 2026. yep. > I find it entirely inappropriate that you have been attempting to force > the WG to conform to a specification that has serious technical flaws, > and dismmissing significant technical objections out-of-hand, in order > to protect your employer from the risk that it exposed itself to by > shipping code that implemented a preliminary version of the spec. > I think that's a serious conflict of interest for a WG chair. Let's please keep the vendor bashing off this list. The work we need to do is hard enough as it is. Let's also not make assumptions about other people's motives. As we all know (and some of us know this more than others), implementing from an ID is risky, as things for which their may well have been concensus at one point in time later get removed or outright reversed. In this case one vendor implemented something in an ID assuming that it would end up in the final spec. Other vendors may have chosen not to implement that feature yet, for among other reasons, knowing that it is better to wait for the final standard before doing the implementation, just to be sure. There are pros and cons to both approaches, and I don't think you can say one is right and the other wrong. What this WG needs to decide is what it wants to do _NOW_ based on the reality that exists _today_. That reality includes understanding what current vendors are doing and what is deployed and trying to come up with a recommendation that makes the best engineering trade off based on a number of different considerations. What is currently deployed is one such consideration. But it is not the only one. Thomas From owner-zeroconf@merit.edu Fri Nov 29 01:28: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 BAA12676 for ; Fri, 29 Nov 2002 01:28:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 463969122D; Fri, 29 Nov 2002 01:31:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 161E2912E0; Fri, 29 Nov 2002 01:31:27 -0500 (EST) 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 7F2739122D for ; Fri, 29 Nov 2002 01:31:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 522A15E05C; Fri, 29 Nov 2002 01:31:05 -0500 (EST) 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 D060D5E049 for ; Fri, 29 Nov 2002 01:31:04 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAT6V0j12191; Fri, 29 Nov 2002 01:31:00 -0500 (EST) Message-Id: <200211290631.gAT6V0j12191@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , Stuart Cheshire , zeroconf@merit.edu Subject: Re: Where did this TTL=255 idea come from? In-reply-to: (Your message of "Thu, 28 Nov 2002 14:45:49 EST.") <200211281945.gASJjn707151@cichlid.adsl.duke.edu> Date: Fri, 29 Nov 2002 01:31:00 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > What this WG needs to decide is what it wants to do _NOW_ based on the > reality that exists _today_. That reality includes understanding what > current vendors are doing and what is deployed and trying to come up > with a recommendation that makes the best engineering trade off based > on a number of different considerations. What is currently deployed is > one such consideration. But it is not the only one. I guess I would still say that the end state is more important than the transition state, so what exists _today_ isn't as important as what will exist _tomorrow_. But I freely admit that dealing with transition issues is often crucial to success of a protocol. Keith From owner-zeroconf@merit.edu Fri Nov 29 05:30:59 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 FAA25807 for ; Fri, 29 Nov 2002 05:30:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA9B29122A; Fri, 29 Nov 2002 05:32:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E4A3912E2; Fri, 29 Nov 2002 05:32:00 -0500 (EST) 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 1E5DA9122A for ; Fri, 29 Nov 2002 05:31:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 03FA65DE10; Fri, 29 Nov 2002 05:31:59 -0500 (EST) 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 5E8BC5DE0F for ; Fri, 29 Nov 2002 05:31:57 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28196; Fri, 29 Nov 2002 03:31:52 -0700 (MST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gATAVnH21810; Fri, 29 Nov 2002 11:31:49 +0100 (MET) Date: Fri, 29 Nov 2002 11:28:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt To: Erik Guttman Cc: Thomas Narten , zeroconf@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > In the applicability section it would make sense to add explicit > > warnings about issues for applications. One issue is the addresses > > are of limited scope which might cause problems for multi-party > > applications that pass IP addresses between parties. > > The other issue is that these addresses might have much shorter and > > unpredictable lifetime, which would have an impact on applications > > using them on the link. (This is true especially given the > > suggestions in section 2.5 to pick a new address when a conflict is > > detected after the address has been used for a while.) > > Are Sections 7. 1 and 7.2 insufficient? Three issues with those: - They don't explicitly mention that the stability of the addresses is affected by late collisions i.e. when the address has been in use for a while - They are written as "all applications SHOULD be fixed to be usable in this environment" - it is more realistic for people deploying this technology to turn this around and instead issue a warning that link-locals should not be used unless all applications used in the network are known to not depend on X, Y, Z. - Warnings about limitations of the applicability makes sense up front in the document - not towards the end. > add -> > > It would also be possible for an on-link attacker to spoof ARP > packets which would cause a host to break all its connections by > switching to a new address. OK, but you need to point out that this is a new threat added by link-local - and not just bundle if with the current "arp is insecure" threats. > Please note that there are similar attacks which exist against hosts > which use global addresses. An on-link attacker could spoof ARP > packets which would cause a packets destined for a host to be > redirected to the attacker, who could discard them, etc. That is a different threat - MiTM can be done with current ARP vs. the new "IP address invalidation" attack with is possible with this draft. RFC 826 isn't subject to a threat were an on-link attacker can get a host to change its address thereby, as a result of receiving a single ARP packet, will break all its existing communication. This distinction should be made clear. > > FWIW when 802.1d is enabled on the port I plug in my laptop at the > > office, the delay before the switch starts forwarding packets is 45 > > seconds. (I think the 802.1d spec indicates a default time of around > > 30 seconds.) So 10 seconds don't seem to do much good. > > 2.3 Shorter Timeouts on Appropriate Network Technologies > > The time values specified above are intended for use on technologies > such as Ethernet, where switches that implement Spanning Tree > [802.1d] often silently discard all packets for several seconds. The > time values specified above result in a delay of 8-10 seconds before > a chosen IP address may be used. > > add --> > > In some cases, the delay can be considerably longer due to other > networking infrastructure. > > The purpose of this section is to give some guidance to implementors > to set appropriate values for their timers, not to definitively answer > what those settings should be. Thanks for the attempt, but I think this addition is insufficient. Deleting text might be a better approach. > (a) The paragraph must be augmented with the following: > Host must consider the case where more than one interface is > connected to the same link. Say the list of link-layer addresses > for a given host is L. The claim-defend algorithm MUST consider > the case when arp sender link-layer address is in L. In this case, > the IP sender address field in the arp message *does not* constitute > a conflict necessitating the host to select another address for any > interface in the list L. Wouldn't this result in the two (or more) interfaces attached to the same link on the node to have the same v4LL address? While it might be possible to get such a configuration to work, I suspect it requires additional things. > > (b) Each interface should be assigned a different v4LL address and > can then operate independently. > > (b) is simpler, and as you state above, it is less instable due to > address reconfiguration events and has fewer security consequences. > Further, (a) relies upon all link-layer addresses being unique, > which is not necessarily true and not required for (b). > > Proposal: (b) Which of the two b's? :-) Erik From owner-zeroconf@merit.edu Fri Nov 29 05:40: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 FAA25899 for ; Fri, 29 Nov 2002 05:40:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 494C2912E2; Fri, 29 Nov 2002 05:42:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18A6E912E3; Fri, 29 Nov 2002 05:42:47 -0500 (EST) 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 EAC3E912E2 for ; Fri, 29 Nov 2002 05:42:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id D12A05DE12; Fri, 29 Nov 2002 05:42:45 -0500 (EST) 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 413DE5DE0F for ; Fri, 29 Nov 2002 05:42:45 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00305; Fri, 29 Nov 2002 03:42:43 -0700 (MST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gATAggH23006; Fri, 29 Nov 2002 11:42:42 +0100 (MET) Date: Fri, 29 Nov 2002 11:39:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt To: jak@uiuc.edu Cc: Thomas Narten , zeroconf@merit.edu In-Reply-To: "Your message with ID" <20021128041831.GA12535@uiuc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Yes, as you pointed out, parts of the IPv6 suite uses the "hop limit > == 255" verification for internal "applications" within the protocol, > such as Neighbor Discovery (which is critical for the IPv6 protocol > suite as a whole to work, and makes the assumption that traffic is > link-local only), but it is true that this verification is not actually > prescribed for *all* link-local traffic. There is no reason it > couldn't be, however. I believe this is incorrect. While some Neighbor Discovery packets use a link-local address in the source and/or destination address field, hence would be filtered by routers, it is not always the case. For instance, the (unicast) Neighbor Solicitation and Neighbor Advertisement messages can have global scope address as source and destination, which is necessary in order to create an IP address->L2 address mapping for the global scope address. If you look at the sections named "Verification of ..." in RFC 2461 you'll see that only the router advertisement and the redirect message will be dropped if the source is not a link-local address. Hence the check for TTL 255 is necessary for neighbor discovery. But that doesn't mean it is necessary for other protocols. Erik From owner-zeroconf@merit.edu Fri Nov 29 14:25: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 OAA06109 for ; Fri, 29 Nov 2002 14:25:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D0E5691232; Fri, 29 Nov 2002 14:28:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0CA5912EC; Fri, 29 Nov 2002 14:28:34 -0500 (EST) 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 B509A91232 for ; Fri, 29 Nov 2002 14:28:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E6C25DE72; Fri, 29 Nov 2002 14:28:33 -0500 (EST) 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 572145DE52 for ; Fri, 29 Nov 2002 14:28:33 -0500 (EST) 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 gATJSWw00333 for ; Fri, 29 Nov 2002 11:28:32 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 29 Nov 2002 11:28:11 -0800 Received: from [17.219.194.50] (vpn-scv-x3-50.apple.com [17.219.194.50]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gATJSWu23628 for ; Fri, 29 Nov 2002 11:28:32 -0800 (PST) Message-Id: <200211291928.gATJSWu23628@scv1.apple.com> Subject: Re: Where did this TTL=255 idea come from? Date: Fri, 29 Nov 2002 11:28:39 -0800 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 >I find it entirely inappropriate that you have been attempting to force >the WG to conform to a specification that has serious technical flaws, >and dismmissing significant technical objections out-of-hand, in order >to protect your employer from the risk that it exposed itself to by >shipping code that implemented a preliminary version of the spec. >I think that's a serious conflict of interest for a WG chair. Keith, I wish you would try to remember from one day to the next which side of the argument you are on. Right now it seems that every comment you send is simply disagreeing with whatever the previous person said, as if you just want to keep fueling the fire and keep this four-year debate going on into its fifth, sixth and seventh years. Please remember that the current topic of discussion was initiated by Thomas Narten saying: >The IETF traditionally takes a dim view of having specs encourage behavior >that is non-backwards compatable, unless there is compelling benefit. The question before us is whether the working group wants to modify its specification to accomodate *Microsoft*, not Apple. Apple has always been willing to update its software to comply with Working Group consensus, and has done so in the past, and as far as I know will continue to do so in the future. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Nov 29 14:28:34 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 OAA06165 for ; Fri, 29 Nov 2002 14:28:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB457912EC; Fri, 29 Nov 2002 14:30:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40F35912EE; Fri, 29 Nov 2002 14:30:18 -0500 (EST) 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 4CF56912EC for ; Fri, 29 Nov 2002 14:30:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id C78825DDF8; Fri, 29 Nov 2002 14:30:15 -0500 (EST) 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 A76BB5DD8D for ; Fri, 29 Nov 2002 14:30:14 -0500 (EST) 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 gATJUEI19100 for ; Fri, 29 Nov 2002 11:30:14 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 29 Nov 2002 11:29:52 -0800 Received: from [17.219.194.50] (vpn-scv-x3-50.apple.com [17.219.194.50]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gATJUDu23971 for ; Fri, 29 Nov 2002 11:30:13 -0800 (PST) Message-Id: <200211291930.gATJUDu23971@scv1.apple.com> Subject: Re: Summary of alternatives Date: Fri, 29 Nov 2002 11:30:20 -0800 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 At 6:21 pm 27th Nov 2002 Keith Moore wrote: >Checking TTL==1 || TTL==255 || TTL==128 would allow receivers to >accept LL packets from both legacy Windows and legacy MacOS >implementations. You could do away with the TTL check entirely, >but there's probably some value in doing a minimal TTL check Having three allowable TTL values instead of just one complicates and confuses the specification and gives no technical benefit. The *only* reason to do that would be for the benefit of vendors who have already shipped code. Just 38 minutes earlier, at 5:43 pm, Keith Moore wrote: >I find it entirely inappropriate that you have been attempting to force >the WG to conform to a specification that has serious technical flaws, >and dismmissing significant technical objections out-of-hand, in order >to protect your employer from the risk that it exposed itself to by >shipping code that implemented a preliminary version of the spec. So, which is it to be Keith? Is it appropriate to modify the spec for the benefit of existing implementations, or not? My position is, and has always been, and will continue to be, that arguments concerning technical merit should be given significantly greater weight than arguments concerning compatibility with existing deployed implementations. Now let me move to the second part of what Keith said: >You could do away with the TTL check entirely, >but there's probably some value in doing a minimal TTL check Is everyone clear on that? Keith says: THERE'S PROBABLY SOME VALUE IN DOING A MINIMAL TTL CHECK Keith, I hope you can stick to this position and not reverse it later. This appears to be in agreement with the overall consensus of the rest of the working group. The question now is what value the TTL check should be checking for, in order to deliver the greatest benefit. What does the receiver learn by checking TTL=1? What does the receiver learn by checking TTL=128? What does the receiver learn by checking TTL=255? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Nov 29 14:40:53 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 OAA06405 for ; Fri, 29 Nov 2002 14:40:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A980912F5; Fri, 29 Nov 2002 14:41:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 153F0912F9; Fri, 29 Nov 2002 14:36:21 -0500 (EST) 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 45936912F2 for ; Fri, 29 Nov 2002 14:35:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F7685DD94; Fri, 29 Nov 2002 14:35:07 -0500 (EST) 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 AE0045DE99 for ; Fri, 29 Nov 2002 14:35:06 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gATJZ6w01057 for ; Fri, 29 Nov 2002 11:35:06 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 29 Nov 2002 11:35:06 -0800 Received: from [17.219.194.50] (vpn-scv-x3-50.apple.com [17.219.194.50]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gATJZ5905539 for ; Fri, 29 Nov 2002 11:35:06 -0800 (PST) Message-Id: <200211291935.gATJZ5905539@scv3.apple.com> Subject: Re: Security discussion for TTL=255 now out of scope Date: Fri, 29 Nov 2002 11:35:12 -0800 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 >- all senders should set the TTL to 1. This ensures that routers won't > forward them off link. Unnecessary. Not sending LL packets to the router in the first place ensures that the router won't forward them off link. >- setting the TTL to anything other than 1 (and especially 255) seems > nuts, as it makes it much more likely that LL packets will leak to > places where they don't belong. And what would be the benefit of > using a higher TTL? > >- the only reason I can think of to set the TTL to 255 on send is if > you want the receiver to check for that value. But why would anyone > care to do that? (remember, I (and others) can't site security > arguments...) That's not what I said. I said that that we should halt the endless debate about whether the security benefit is small or large. If you want to make the qualitative (not quantitative) argument that there is ZERO security benefit to knowing that the packet originated on-link, then I suppose we can start that debate, but it would seem that every company, organization, and individual around the world who has installed a firewall has spoken with their dollars and disagrees with that position. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Nov 29 14:53: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 OAA06665 for ; Fri, 29 Nov 2002 14:53:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44167912F2; Fri, 29 Nov 2002 14:56:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F5E0912F3; Fri, 29 Nov 2002 14:56:04 -0500 (EST) 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 EDAE2912F2 for ; Fri, 29 Nov 2002 14:56:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0CE75E0B9; Fri, 29 Nov 2002 14:56:03 -0500 (EST) 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 73FA85E0B8 for ; Fri, 29 Nov 2002 14:56:03 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gATJtxj19357; Fri, 29 Nov 2002 14:56:00 -0500 (EST) Message-Id: <200211291956.gATJtxj19357@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Security discussion for TTL=255 now out of scope In-reply-to: (Your message of "Fri, 29 Nov 2002 11:35:12 PST.") <200211291935.gATJZ5905539@scv3.apple.com> Date: Fri, 29 Nov 2002 14:55:59 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > I said that that we should halt the endless debate about whether the > security benefit is small or large. this supposed benefit is being used to justify a dubious design decision. what you seem to be trying to do is stifle debate about the merits of that design decision. From owner-zeroconf@merit.edu Fri Nov 29 15:02: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 PAA06878 for ; Fri, 29 Nov 2002 15:02:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03DEF912F3; Fri, 29 Nov 2002 15:05:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE53F912F4; Fri, 29 Nov 2002 15:05:06 -0500 (EST) 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 9425E912F3 for ; Fri, 29 Nov 2002 15:05:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 532675DE3F; Fri, 29 Nov 2002 15:05:05 -0500 (EST) 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 E94BC5DDF8 for ; Fri, 29 Nov 2002 15:05:04 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gATK51j19380; Fri, 29 Nov 2002 15:05:01 -0500 (EST) Message-Id: <200211292005.gATK51j19380@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Where did this TTL=255 idea come from? In-reply-to: (Your message of "Fri, 29 Nov 2002 11:28:39 PST.") <200211291928.gATJSWu23628@scv1.apple.com> Date: Fri, 29 Nov 2002 15:05:01 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Keith, I wish you would try to remember from one day to the next which > side of the argument you are on. I'm trying to understand and argue for what seems best for the Internet as a whole. Which side are *you* on? > >The IETF traditionally takes a dim view of having specs encourage behavior > >that is non-backwards compatable, unless there is compelling benefit. Yes, but that has to be understood with a context. The IETF also has a long tradition of trying to produce a desirable end-state even when it means compromising backward compatibility. And the IETF traditionally places more value on backward compatibility with standards than on backward compatibility with pre-standardization practice. > The question before us is whether the working group wants to modify its > specification to accomodate *Microsoft*, not Apple. No, that's your interpretation of the question. There are proposals on the table which would accomodate neither, but are arguably technically superior. Are you attempting to avoid the question of whether Apple should be compelled to change its code also? > Apple has always been willing to update its software to comply with > Working Group consensus, and has done so in the past, and as far as I > know will continue to do so in the future. Actually I hope that Apple would update its software to follow the standards as published, rather than merely the consensus of the working group. They are not necessarily the same thing. Keith From owner-zeroconf@merit.edu Fri Nov 29 15:17: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 PAA07262 for ; Fri, 29 Nov 2002 15:17:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4EFBB912F4; Fri, 29 Nov 2002 15:20:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A403912F7; Fri, 29 Nov 2002 15:20:25 -0500 (EST) 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 DE77C912F4 for ; Fri, 29 Nov 2002 15:20:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id C33575DE3F; Fri, 29 Nov 2002 15:20:23 -0500 (EST) 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 96CC35DE00 for ; Fri, 29 Nov 2002 15:20:23 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gATKKKj19403; Fri, 29 Nov 2002 15:20:20 -0500 (EST) Message-Id: <200211292020.gATKKKj19403@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Summary of alternatives In-reply-to: (Your message of "Fri, 29 Nov 2002 11:30:20 PST.") <200211291930.gATJUDu23971@scv1.apple.com> Date: Fri, 29 Nov 2002 15:20:20 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > At 6:21 pm 27th Nov 2002 Keith Moore wrote: > >Checking TTL==1 || TTL==255 || TTL==128 would allow receivers to > >accept LL packets from both legacy Windows and legacy MacOS > >implementations. You could do away with the TTL check entirely, > >but there's probably some value in doing a minimal TTL check > > Having three allowable TTL values instead of just one complicates and > confuses the specification and gives no technical benefit. uh, it's one line of prose that directly and unambiguously translates to source code in every programming language with which I'm familiar. if that one line confuses the implementors then I have little faith that they'll implement the rest of the specification correctly. maybe we should just drop the whole thing for the sake of these poor programmers. > The *only* reason to do that would be for the benefit of vendors who > have already shipped code. of course it is useful to be able to be compatible with existing implementations if that can be done without seriously harming the end-state of protocol deployments. and yes, this is a "technical" consideration. > So, which is it to be Keith? Is it appropriate to modify the spec for the > benefit of existing implementations, or not? as far as I'm concerned, the spec is still on the table to be modified, there are several reasons why the spec needs modification, and there are a number of factors that need to be considered. compatibility with existing implementations is IMHO a minor factor, but it is a factor. > Keith says: THERE'S PROBABLY SOME VALUE IN DOING A MINIMAL TTL CHECK The question is whether it's enough value to outweigh the disadvantage of doing so. As I see it there are three reasonable options: You can check for the single specific value that the standard says to emit, and then the receiver will accept only packets that happen to have that value. Depending on what value you pick, this either favors Apple, favors Microsoft, or ensures that routers will automagically filter LL packets going off the net. I think you have a good point that hosts shouldn't be sending LL packets through routers anyway, so maybe that argument for TTL=1 isn't compelling. You can check for any of two or three discrete values, one of which is the 'standard' TTL value, with the others chosen to be compatible with existing implementations. It's a simple check, and provides some filtering. You can omit the check entirely, and then the receiver will accept all packets and pass them to applications. What I'm still trying to understand is *how much* value is provided by each kind of TTL check. Keith From owner-zeroconf@merit.edu Fri Nov 29 15:21:24 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 PAA07327 for ; Fri, 29 Nov 2002 15:21:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 615D4912F7; Fri, 29 Nov 2002 15:24:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AA14912F8; Fri, 29 Nov 2002 15:24:00 -0500 (EST) 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 2B1CC912F7 for ; Fri, 29 Nov 2002 15:23:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E9015DDEA; Fri, 29 Nov 2002 15:23:59 -0500 (EST) 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 890635DD94 for ; Fri, 29 Nov 2002 15:23:58 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gATKNwI25736 for ; Fri, 29 Nov 2002 12:23:58 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 29 Nov 2002 12:23:57 -0800 Received: from [17.219.194.50] (vpn-scv-x3-50.apple.com [17.219.194.50]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gATKNv913784 for ; Fri, 29 Nov 2002 12:23:57 -0800 (PST) Message-Id: <200211292023.gATKNv913784@scv3.apple.com> Subject: Responses so far Date: Fri, 29 Nov 2002 12:24:04 -0800 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 It's Thanksgiving, so most people are off work, but here is a summary of the responses I've received so far: People willing to argue in support of Option 1 (Set TTL=255 on transmit, check TTL==255 on receipt) Stuart Cheshire Jay A. Kreibich Daniel Senie Martin Layley Joshua Graessley Brad Hards Vincent Lubet Erik Guttman People willing to argue in support of Option 2 (Set TTL=1 on transmit, check TTL==1 on receipt) RJ Atkinson People willing to argue in support of Option 3 (Set TTL=anything on transmit, don't check TTL on receipt) Thomas Narten People willing to argue in support of Option 4 (User-configuration for "Zero Configuration" devices) (None) If your name is not listed, and you feel you have a technical opinion you'd be willing to support, please send mail to the list or to me privately. Please try to keep your email short and to-the-point. For example, Keith Moore has written a great volume of email, but I can't tell which of these positions (if any) he is advocating. Don't assume the decision is already made; it's not. This is not a vote. I'd like to try to get all interested parties involved here, and show that an IETF Working Group is still able to arrive at a decision when it has to. If anyone is wondering why I listed Thomas Narten's name under option 3 (don't check) instead of option 2 (Set TTL=1), that's because if no one is checking the TTL, it doesn't matter what you set it to. The RFC can say what it likes about what the TTL "MUST" be set to, but it is irrelevant if no one is checking. Vendors will get it wrong, and their products will work fine because no one is checking the TTL, and they will ship those products. Even if someone complains to the vendor that the TTL is wrong, they'll just laugh. Few vendors of $100 devices are willing to waste engineering resources fixing a "bug" that has no effect on how well their product works. In many cases, the firmware for a device was written by a contractor, so the company couldn't fix the bug even if they wanted to. In some cases, products remain in use long after the company that made them has gone bankrupt, so there's no one to even complain to. In short, any discussion of what the TTL should be set to is only of practical value if we've already decided that receivers are checking that value. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Nov 29 15:56: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 PAA07791 for ; Fri, 29 Nov 2002 15:56:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F5429123B; Fri, 29 Nov 2002 15:59:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6E4E912F9; Fri, 29 Nov 2002 15:59:24 -0500 (EST) 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 A04499123B for ; Fri, 29 Nov 2002 15:59:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 853535DE7A; Fri, 29 Nov 2002 15:59:23 -0500 (EST) 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 593535DD9D for ; Fri, 29 Nov 2002 15:59:23 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gATKxKj19682; Fri, 29 Nov 2002 15:59:20 -0500 (EST) Message-Id: <200211292059.gATKxKj19682@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Responses so far In-reply-to: (Your message of "Fri, 29 Nov 2002 12:24:04 PST.") <200211292023.gATKNv913784@scv3.apple.com> Date: Fri, 29 Nov 2002 15:59:19 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > It's Thanksgiving, so most people are off work, but here is a summary of > the responses I've received so far: > > People willing to argue in support of Option 1 > (Set TTL=255 on transmit, check TTL==255 on receipt) > Stuart Cheshire > Jay A. Kreibich > Daniel Senie > Martin Layley > Joshua Graessley > Brad Hards > Vincent Lubet > Erik Guttman > > People willing to argue in support of Option 2 > (Set TTL=1 on transmit, check TTL==1 on receipt) > RJ Atkinson > > People willing to argue in support of Option 3 > (Set TTL=anything on transmit, don't check TTL on receipt) > Thomas Narten > > People willing to argue in support of Option 4 > (User-configuration for "Zero Configuration" devices) > (None) > > If your name is not listed, and you feel you have a technical opinion > you'd be willing to support, please send mail to the list or to me > privately. Please try to keep your email short and to-the-point. For > example, Keith Moore has written a great volume of email, but I can't > tell which of these positions (if any) he is advocating. That's because you're trying to make me support one of three positions that you've arbitrarily chosen, and I don't think the set of alternatives you've proposed adequately covers the solution space. Also you seem to be trying to address a deficiency in the spec that was identified by IESG by appealing to group consensus. An answer of the form "we have consensus on TTL=255" without justification is not useful - what is required is a response to IESG's concerns. Trying to appeal to WG consensus is in some sense dodging IESG's question. > If anyone is wondering why I listed Thomas Narten's name under option 3 > (don't check) instead of option 2 (Set TTL=1), that's because if no one > is checking the TTL, it doesn't matter what you set it to. Routers check. Whether it's relevant for routers to check is a different question, but let's not gloss over the fact that the reason for suggesting TTL=1 on transmit is so that routers will refuse to forward them. Keith From owner-zeroconf@merit.edu Fri Nov 29 16:18:55 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 QAA08359 for ; Fri, 29 Nov 2002 16:18:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC869912FA; Fri, 29 Nov 2002 16:21:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DE9D912FB; Fri, 29 Nov 2002 16:21:28 -0500 (EST) 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 56267912FA for ; Fri, 29 Nov 2002 16:21:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 353DA5DE92; Fri, 29 Nov 2002 16:21:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id E7CB25DE7A for ; Fri, 29 Nov 2002 16:21:26 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gATLLNNp120136; Fri, 29 Nov 2002 16:21:24 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-208-211.mts.ibm.com [9.65.208.211]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gATLLLal025108; Fri, 29 Nov 2002 16:21:21 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gATLKYO15731; Fri, 29 Nov 2002 16:20:35 -0500 Message-Id: <200211292120.gATLKYO15731@cichlid.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Where did this TTL=255 idea come from? In-Reply-To: Message from Stuart Cheshire of "Fri, 29 Nov 2002 11:28:39 PST." <200211291928.gATJSWu23628@scv1.apple.com> Date: Fri, 29 Nov 2002 16:20:34 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, > The question before us is whether the working group wants to modify its > specification to accomodate *Microsoft*, not Apple. Casting this discussion as an Apple vs. Microsoft discussion is most unhelpful, and is exactly the type of thing that will get this group nowhere. Especially, since your note implies that Apple is doing right and Microsoft is doing wrong. Please think *very* hard about how your words might be interpreted by others. All, can we please stop this sort of name calling and focus on the technical issues? > Apple has always been willing to update its software to comply with > Working Group consensus, and has done so in the past, and as far as I > know will continue to do so in the future. Good. Then lets figure out what the best thing to do is and update the spec (if needed). Vendors can figure out themselves what they will do with their implementations. I'm personally extremely frustrated by this thread because there is a lot of heat and not much light. There are technical issues to consider that the WG should evaluate and weight. But a lot of postings so far seem to focus on one issue (while ignoring others) and then conclude that the "obvious" outcome is X. There are at least three issues to consider here, and they need to be considered *together* as they all must be weighed relative to each other. The way I understand the issues: Enforcing the 255-on-receipt check is non-backwards compatable. Indeed, it occurred to me today that its non-backwards compatable with nodes that don't even implement LL addressing. Consider a node A, on the same link with B. A has a global address, B has a LL address. If A attempts to communicate with B, but B notices that the dest address is LL, and then checks for a TTL of 255 (following the recommendation in the current ID), communication will likely fail. So here we have a case where two nodes with valid addresses can't communicate for non-obvious reasons. Neither implementation is violating a Standard. Note the A has not implemented LL at all, so it can't be violating any LL standard. Is this not a potential interoperability problem that we shouldn't knowingly encourage? However, now that Apple does this check, setting the TTL to anything other than 255 is also problematic. That might argue for setting it to 255 (and explaining in the document why), but also saying SHOULD NOT or MUST NOT do the check on receipt since we know it also causes problems with existing implementations that don't set the TTL this way. (Note we could say that the test might be changed in a future standard once the deployed base is upgraded/junked, but it is too early to say that today if one wants to avoid interoperability problems today). But setting the TTL to 255 (rather than 1) also will lead to more LL packets going off link then if the TTL is set to 1. Sure, hosts aren't *supposed* to forward them to routers, but some leakage will inevitably happen as a result of misconfigurations, and other things that are "not supposed to happen". This may cause operational problems. How much? Hard to say. Depends on how many (and which) routers do filtering. I don't believe we need 100% compliance here in order to get enough filtering in practice to keep LL traffic from leaking in horrible ways. For a home site, for example, does it care if its LL traffic goes off link? Probably not. What it cares about is that it doesn't go across the DSL link to its ISP (or that packets from the ISP come in with LL addresses). But that is something the ISP probably cares about enough to ensure that filters are fairly likely to get put at that boundary. Etc. So, could we please have a discussion of the overall pros and cons of these (or any other relevant) issues, so that the WG understands the list of issues that need to be weighed and balanced? Note: I'm personally not that concerned *which* approach the WG adopts. However, I really want (and need) to be able to defend the WG's decision when people tell me that the spec is broken because it codifies known interoperability problems into a standard. Thomas From owner-zeroconf@merit.edu Fri Nov 29 16:58:28 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 QAA09126 for ; Fri, 29 Nov 2002 16:58:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77A1F912FF; Fri, 29 Nov 2002 16:59:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0412C91301; Fri, 29 Nov 2002 16:59:18 -0500 (EST) 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 4828B912FF for ; Fri, 29 Nov 2002 16:59:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35BCC5DE56; Fri, 29 Nov 2002 16:59:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id BE1165DE34 for ; Fri, 29 Nov 2002 16:59:12 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA00048 for ; Fri, 29 Nov 2002 16:59:12 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA18243 for ; Fri, 29 Nov 2002 16:59:11 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17868 for ; Fri, 29 Nov 2002 16:56:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Nov 2002 16:56:34 -0500 Subject: Re: Responses so far From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211292023.gATKNv913784@scv3.apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/29/2002 15:24, "Stuart Cheshire" wrote: > If your name is not listed, and you feel you have a technical opinion > you'd be willing to support, please send mail to the list or to me > privately. Please try to keep your email short and to-the-point. For > example, Keith Moore has written a great volume of email, but I can't > tell which of these positions (if any) he is advocating. I'll go with 255, it's already in the proposal, I haven't seen any real validity to changing it other than a minor routing issue which is handled better in other ways. Inertia's a physical law, that works for me. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Nov 29 17:00:57 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 RAA09212 for ; Fri, 29 Nov 2002 17:00:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A7EA91300; Fri, 29 Nov 2002 17:03:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A268E91302; Fri, 29 Nov 2002 17:03:20 -0500 (EST) 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 A59A291300 for ; Fri, 29 Nov 2002 17:03:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E6BE5DE34; Fri, 29 Nov 2002 17:03:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 150945DD9D for ; Fri, 29 Nov 2002 17:03:18 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00860 for ; Fri, 29 Nov 2002 17:03:17 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA11820 for ; Fri, 29 Nov 2002 16:59:12 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17638 for ; Fri, 29 Nov 2002 16:53:26 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Nov 2002 16:53:21 -0500 Subject: Re: Where did this TTL=255 idea come from? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211292005.gATK51j19380@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/29/2002 15:05, "Keith Moore" wrote: >> Apple has always been willing to update its software to comply with >> Working Group consensus, and has done so in the past, and as far as I >> know will continue to do so in the future. > > Actually I hope that Apple would update its software to follow the > standards as published, rather than merely the consensus of the > working group. They are not necessarily the same thing. If they were to do that, then there would be no way to test anything, since there is no standard, and we'd all be sitting on our hands for another decade or so dreaming of easily configured IP settings. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Nov 29 17:02: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 RAA09266 for ; Fri, 29 Nov 2002 17:02:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B14191303; Fri, 29 Nov 2002 17:05:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C4F391301; Fri, 29 Nov 2002 17:05:14 -0500 (EST) 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 4D79891302 for ; Fri, 29 Nov 2002 17:04:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3343E5DE56; Fri, 29 Nov 2002 17:04:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id BD5595DE55 for ; Fri, 29 Nov 2002 17:04:11 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01074 for ; Fri, 29 Nov 2002 17:04:11 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA11902 for ; Fri, 29 Nov 2002 17:04:11 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA18016 for ; Fri, 29 Nov 2002 16:58:53 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Nov 2002 16:58:51 -0500 Subject: Re: Responses so far From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211292059.gATKxKj19682@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/29/2002 15:59, "Keith Moore" wrote: > Routers check. Whether it's relevant for routers to check is a different > question, but let's not gloss over the fact that the reason for suggesting > TTL=1 on transmit is so that routers will refuse to forward them. But that's a router issue, not a LL issue. The question is, is 255 or 1 better for LL. If 1 is better, then why? The router issue is irrelevant, as they can be updated for Zeroconf along with everything else. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Nov 29 17:02:52 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 RAA09292 for ; Fri, 29 Nov 2002 17:02:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9789991304; Fri, 29 Nov 2002 17:03:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EB5091303; Fri, 29 Nov 2002 17:03:21 -0500 (EST) 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 4C2AE91301 for ; Fri, 29 Nov 2002 17:03:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CD7A5DE34; Fri, 29 Nov 2002 17:03:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id A7CB75DD9D for ; Fri, 29 Nov 2002 17:03:18 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00876 for ; Fri, 29 Nov 2002 17:03:18 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA11662 for ; Fri, 29 Nov 2002 16:54:12 -0500 (EST) Received: from [10.0.0.14] (245-8-189-66.wo.cpe.charter-ne.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17560 for ; Fri, 29 Nov 2002 16:52:05 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Nov 2002 16:52:04 -0500 Subject: Re: Security discussion for TTL=255 now out of scope From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200211291956.gATJtxj19357@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 11/29/2002 14:55, "Keith Moore" wrote: >> I said that that we should halt the endless debate about whether the >> security benefit is small or large. > > this supposed benefit is being used to justify a dubious design decision. > what you seem to be trying to do is stifle debate about the merits of > that design decision. > There is *no* security in watching a TTL value. Let me say that again: There is NO security in the TTL value The TTL value in no way shape or form protects your network/nodes/data, it doesn't prevent other people from getting to that. It has only one purpose WRT to LL...to make sure that LL packets do not get out of the local link. That's it. If you want to make TTL a security feature, then I recommend another WG start up that looks at ways of verifying that the TTL is correct, if there isn't one already. To drag security into what is purely an operational/administrative decision serves no purpose other than dragging this process out still further. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM