Subject: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Nov 2002 13:02:12 -0500

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: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 13:36:01 -0500

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Nov 2002 13:51:07 -0500

Hi Ran.

> 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!

> 	- 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.

> 		link-local packets but knob MUST default to only accept

This is even stronger than the current wording in the document.

> and lets the rest of us migrate in a more useful direction 

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: Brian Haberman <[email-masked]>
Date: Tue, 26 Nov 2002 14:01:14 -0500

> there will be no configuration possible. The default settings will

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: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 14:25:40 -0500

>   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: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 14:32:45 -0500

On Tuesday, Nov 26, 2002, at 13:51 America/Montreal, Thomas Narten 
wrote:
> to 1,

My typo.  Your correction is what I intended...

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Nov 2002 14:34:42 -0500

> it's for operational sanity.   (any claim that LL provides security is 

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: "Jay A. Kreibich" <[email-masked]>
Date: Tue, 26 Nov 2002 13:47:21 -0600

>   security in practice to be useful.

  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.
                        [email-masked] | Campus IT & Edu. Svcs.
          <http://www.uiuc.edu/~jak> | University of Illinois at U/C

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 14:48:35 -0500

> So let's be clear about what problems the 255 check is addressing and

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 

> 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: Daniel Senie <[email-masked]>
Date: Tue, 26 Nov 2002 14:58:59 -0500

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: Brad Hards <[email-masked]>
Date: Wed, 27 Nov 2002 07:35:56 +1100

> So let's be clear about what problems the 255 check is addressing and
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?

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 15:49:41 -0500

> Whether it defaults on or off is a trade-off between ease-of-use and security,

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: Brad Hards <[email-masked]>
Date: Wed, 27 Nov 2002 08:13:02 +1100

> 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

- --

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 26 Nov 2002 17:35:45 -0500

> 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.

> currently deployed devices.

Then those devices aren't following LL spec anyway, and need to be updated.
Vendor software/firmware updates should handle this.

> This is even stronger than the current wording in the document.

And it's a better idea.

> there will be no configuration possible. The default settings will

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: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 17:35:30 -0500

> 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: "John C. Welch" <[email-masked]>
Date: Tue, 26 Nov 2002 17:38:03 -0500

> inter-operability given the environment that zeroconf networks will

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: "John C. Welch" <[email-masked]>
Date: Tue, 26 Nov 2002 17:49:10 -0500

> 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: Erik Guttman <[email-masked]>
Date: Wed, 27 Nov 2002 10:52:17 +0100 (MET)

> number of comments -- I hope the WG starts working on revising the

OK, let's wrap this up.
 
>   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: Vincent Lubet <[email-masked]>
Date: Wed, 27 Nov 2002 09:15:50 -0800

> and see new versions of Windows and MacOS fail to interoperate with

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: "Jim Fleming" <[email-masked]>
Date: Wed, 27 Nov 2002 11:19:46 -0600

----- Original Message ----- 
From: "Vincent Lubet" <[email-masked]>
To: "Erik Guttman" <[email-masked]>
Cc: "Thomas Narten" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 27, 2002 11:15 AM
Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt

> 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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 12:24:06 -0500

> 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: "Jim Fleming" <[email-masked]>
Date: Wed, 27 Nov 2002 11:31:49 -0600

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "Vincent Lubet" <[email-masked]>
Cc: "Erik Guttman" <[email-masked]>; "Thomas Narten" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 27, 2002 11:24 AM
Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt 

> 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: Vincent Lubet <[email-masked]>
Date: Wed, 27 Nov 2002 09:38:41 -0800

> what's your best technical judgement about the right thing for the

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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 12:48:48 -0500

> 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

agreed; I wish we'd focus attention of the real problems with zeroconf.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 27 Nov 2002 11:50:04 -0600

----- Original Message ----- 
From: "Vincent Lubet" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 27, 2002 11:38 AM
Subject: Re: TTL treatment in draft-ietf-zeroconf-ipv4-linklocal-07.txt

> constantly changing the specifications about non essential aspect of 

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Nov 2002 14:54:48 -0500

>   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: Thomas Narten <[email-masked]>
Date: Wed, 27 Nov 2002 15:11:23 -0500

> maybe we should not use TTL at all anywhere, since it's evidently a bad idea

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.

> 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?

> 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: "John C. Welch" <[email-masked]>
Date: Wed, 27 Nov 2002 16:00:18 -0500

> So I really don't follow the logic that the TTL can't be used per

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. 
> horrible statistics on (for example) how many Windows 95 boxes are

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.

> 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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 16:14:37 -0500

> horrible statistics on (for example) how many Windows 95 boxes are

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: Joshua Graessley <[email-masked]>
Date: Wed, 27 Nov 2002 13:20:16 -0800

> 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: Brad Hards <[email-masked]>
Date: Thu, 28 Nov 2002 08:24:14 +1100

> TTL is mostly irrelevant to breakage of things already using LL.
I note that Thomas' posting kicking this thread off was about 
interoperability. 

> 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

- --

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 16:41:42 -0500

> 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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 16:45:41 -0500

> 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: Brad Hards <[email-masked]>
Date: Thu, 28 Nov 2002 08:55:28 +1100

> 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
- --

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 27 Nov 2002 14:11:29 -0800

> 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: "Bill Rees" <[email-masked]>
Date: Wed, 27 Nov 2002 14:36:37 -0800

----- Original Message -----
From: "Joshua Graessley" <[email-masked]>
> packets originating from off the link.

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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 17:42:37 -0500

> Windows box, and how often they need to be updated in any event because they

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: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 17:43:35 -0500

> packets originating from off the link.

of course it would also be fine for hosts to insist that TTL were 1.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 17:49:10 -0500

> 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: Joshua Graessley <[email-masked]>
Date: Wed, 27 Nov 2002 15:57:26 -0800

> 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: Joshua Graessley <[email-masked]>
Date: Wed, 27 Nov 2002 16:02:48 -0800

> 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: Brad Hards <[email-masked]>
Date: Thu, 28 Nov 2002 12:15:19 +1100

> 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

- --

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 28 Nov 2002 11:10:26 +0900

>>>>> On Wed, 27 Nov 2002 14:54:48 -0500, 
>>>>> Thomas Narten <[email-masked]> said:

> general requirement to check when LLs are used for protocols other

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.
					[email-masked]

---

From: "Jay A. Kreibich" <[email-masked]>
Date: Wed, 27 Nov 2002 22:18:31 -0600

> 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.

> 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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 28 Nov 2002 14:21:58 -0500

>   prescribed for *all* link-local traffic.  There is no reason it

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.

>   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.

>   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: Erik Nordmark <[email-masked]>
Date: Fri, 29 Nov 2002 11:39:29 +0100 (CET)

>   prescribed for *all* link-local traffic.  There is no reason it

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