Subject: specific comments on draft-ietf-zeroconf-ipv4-linklocal-07

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 17:44:03 -0400

yeah, I know.  this is a lot of text.  In some cases I quoted 
text from the existing document to make it clear exactly what
kinds of changes I recommend.  I have tried to mark existing
text with ">" and suggested new text with "]".
 
unlike my earlier LC comments, these comments relate specifically
to the text in linklocal-07 and need to be considered separately.
most of these suggested changes are orthogonal to those suggested 
in my earlier comments.  

these changes by themselves do not suffice to fix all of the 
problems in the document, but I think they should be made anyway.

Keith

section 1.4:

>  Administrators wishing to configure their own local addresses
>  (using manual configuration, a DHCP server, or any other mechanism
>  not described in this document) should use one of the existing
>  private address prefixes [RFC 1918], not the 169.254/16 prefix.

this is slightly overbroad, as RFC 1918 is intended for disconnected
networks only.  suggest it be changed to:

]  Administrators of networks that are isolated from the Internet, 
]  who wish to configure their own local addresses (using manual 
]  configuration, a DHCP server, or any other mechanism not 
]  described in this document) SHOULD use one of the existing
]  private address prefixes [RFC 1918], rather than the 169.254/16 
]  prefix or any other prefix not assigned to that network.

section 2.6, 3rd pp (nit):

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

change to:

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

section 2.6, last pp (nit):

>  In the case where two hosts on the same link each have both a link-
>  local address and another address configured via some other means,
>  the host may use either its link-local source address or a routable

change to:

]  In the case where two hosts on the same link each have both a link-
]  local address and another address configured via some other means,
]  the host MAY use either its link-local source address or a routable

section 2.8:

the section is still misleading.  devices may assume that link-local
packets are originated from the local link, but this does not imply
_anything_ in terms of security.  for instance, it doesn't mean that 
the packet payloads originated from the local link, nor does it 
mean that the packets were generated by a trusted source.
(especially in a wireless network)

it is not reasonable for a device vendor to assume that the LL 
environment is "safer" or "more secure" than a configured environment.

nor is it reasonable to recommend that a device designer rely
on outside controls to implement security.

here's an attempt to rewrite this section:

]2.8 Devices MUST NOT assume Link-Local traffic is trustworthy
]
]  The non-forwarding rule means that hosts may assume that all
]  169.254/16 destination addresses are "on-link" and directly
]  reachable. The 169.254/16 address prefix MUST NOT be subnetted.
]  This specification utilizes ARP-based address collision detection,
]  which functions by broadcasting on the local subnet. Since such
]  broadcasts are not forwarded, were subnetting to be allowed then
]  address conflicts could remain undetected.  To some degree this
]  limits the set of hosts which can originate link-local traffic.
]
]  Designers of many kinds of devices, in particular simple network 
]  appliances, wish for a protected network environment in which 
]  security threats are diminished and which therefore reduces the 
]  burden to implement security within the device.  Link-local addressing
]  DOES NOT inherently reduce that burden, and (especially in the
]  case of a wireless network or a wired network bridge to a wireless
]  network) may even expose devices to threats which are not present 
]  in an explicitly configured network.  Such threats may be presented 
]  either directly from attackers or indirectly via other hosts on the 
]  local network which have been compromised.

some more on this: I don't know of any way for a protocol that
allows a device to accept traffic to _reduce_ the threats
to which that device might be subjected.  any additional input
to the device is a potential threat that wasn't present before
the device could accept that input.  

what the WG seems to want, and what I think is inherently untenable, 
is a general-purpose LL protocol that can be expected to be implemented 
on (almost) *every* host, potentially allowing (almost) *any* host 
(whatever its purpose or security level) to be attached to a network 
along with LL devices, and *which somehow makes those other hosts 
trustworthy*. 

that's just not going to happen.  if you want to assume that all 
hosts that speak LL are trustworthy then you need at a minimum
to impose some fairly serious constraints on those hosts - 
constraints which clearly cannot be applied to the wide range of 
hosts which are likely to support LL.

section 2.9 seems incomplete.  here's an attempt at a rewrite:

] 2.9 Higher-Layer Protocol Considerations
]
]  Similar considerations apply at layers above IP.
]
]  Any application which uses IP addresses to in referrals that are
]  sent to other hosts will fail if link-local IP addresses are 
]  sent to hosts that are unable to use them.  This could happen 
]  for a variety of reasons: (a) the host receiving the address does
]  not have access to the same link, (b) the host receiving the address
]  has multiple interfaces supporting link-local addressing, causing 
]  the link-local address to be ambiguous, or (c) the host receiving
]  the address does not support link-local addressing.
]
]  For example, if web pages (including automatically generated web 
]  pages) contain links with embedded link-local addresses, those
]  links will fail if those pages are accessible from (perhaps via
]  a cache or proxy) hosts outside the local link where the addresses 
]  are valid, or if the host migrates outside that local link.
]
]  Applications that are aware of link-local addressing SHOULD 
]  avoid using them in referrals to other hosts.  In general it
]  is difficult for an application to know whether an address
]  means the same thing to another host as it means to the local
]  host - even if the other host is on the same link - and thus
]  it is difficult for an application to determine whether it
]  is safe to use link-local addresses in referrals.   In addition,
]  there is always a chance that a link-local address-to-host
]  binding will be revoked due to an address conflict.
]
]  It should be noted that DNS is an example of an application
]  that performs address referrals.  For these reasons storing 
]  use of DNS to return link-local addresses is NOT RECOMMENDED.

section 3, 2nd pp:

>  For applications that send packets (or initiate outgoing
>  connections) without identifying a desired source interface, by
>  interface identifier, source IP address, or any other means, an
>  operating system that configures link-local addresses on multiple
>  interfaces has two choices. It can either restrict such
>  applications to using link-local addresses on only one default
>  interface, or it can ARP for the given destination address on all
>  interfaces, and use the first reply it gets. While clearly sub-
>  optimal, in most cases this heuristic approach will successfully
>  establish communication with the desired correspondent host.

change to:

]  For applications that send packets (or initiate outgoing
]  connections) without identifying a desired source interface, by
]  interface identifier, source IP address, or any other means, an
]  operating system that configures link-local addresses on multiple
]  interfaces has two choices. It can either restrict such
]  applications to using link-local addresses on only one default
]  interface, or it can ARP for the given destination address on all
]  interfaces, and use the first reply it gets.  In most cases this 
]  heuristic approach will successfully establish communication 
]  with the desired correspondent host.  However, it does have the
]  potential to establish communications with the wrong host.
   
section 3.3, 4th pp:

>  This uniqueness requirement simplifies host software layers above
>  IP (application software and transport protocols) by allowing them
>  to identify connections using only the source and destination IP
>  addresses, without also needing interface identifiers. Since link-
>  local addresses are only unique per-link, hosts on different links
>  could be using the same link-local address. Uniqueness of source
>  addresses on the multi-homed host allows connections to the same
>  destination address on different links to be disambiguated by their
>  different source addresses.

this certainly doesn't "simplify" host software - it makes it more
complex by increasing the burden on apps - it's no longer sufficient
for an app to just specify a destination IP address to reach a host,
it now has to specify a source,destination pair.  suggested rewrite:

]  This uniqueness requirement allows host software layers above 
]  IP  (application software and transport protocols) to identify
]  connections using both the source and destination IP addresses.
]  While this does increase the complexity of such software, it
]  also facilitates more reliable use of link-local addresses which 
]  might otherwise be ambiguous.  

section 5, 1st pp:

>  The use of IPv4 Link-Local Addresses may open a network host to new
>  attacks. In particular, a host that previously did not have an IP
>  address, and no IP stack running, was not susceptible to IP-based
>  attacks. By configuring a working address, the host may now be
>  vulnerable to IP-based attacks.

add at the end: 

]  Similarly, a host which was protected (to whatever degree)
]  from threats from other hosts via an external filter or firewall 
]  may be exposed to new and different threats as a consequence of
]  link-local addressing.

2nd pp:

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

suggested improvement:

]   Link-local address negotiation uses the ARP protocol [RFC 826] which
]   is known to be 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 some or 
]   all ARP requests with replies giving its own hardware address, thereby 
]   claiming ownership of those addresses, causing their traffic to be
]   mis-directed, and generally denying use of the network to those hosts.  
]   These threats exist for any use of unsecured ARP, whether for link-local 
]   addresses or routable addresses. 

3rd pp:

>  Implementers are advised that the Internet Protocol architecture
>  expects every networked device or host must implement security
>  which is adequate to protect the resources to which the device
>  or host has access, including the network itself, against known
>  or credible threats. Even though use of link-local addresses
>  may reduce the number of threats to which a device is exposed,
>  implementers of devices supporting the Internet Protocol must
>  not assume that a customer's local network is free from security
>  risks.

change to:

]   Implementers are advised that the Internet Protocol architecture
]   expects every networked device or host must implement security  
]   which is adequate to protect the resources to which the device 
]   or host has access, including the network itself, against known
]   or credible threats. Use of link-local addresses cannot be assumed
]   to reduce the number of threats to which a device is exposed,
]   and in fact it may expose such devices to new threats - particularly 
]   if the devices are attached (directly or through a bridge) to
]   unsecured wireless networks.  Implementers of devices supporting the 
]   Internet Protocol therefore MUST NOT assume that a customer's local 
]   network is free from security risks.

section 7.1, 2nd pp:

this is onerous, as it tries to apply to all applications whether
it is appropriate or not.  delete

>   Vendors producing application software which will be used on IP
>   implementations supporting IPv4 link-local address configuration
>   SHOULD detect and cope with address change events. Vendors
>   producing IP implementations supporting IPv4 link-local address
>   configuration SHOULD expose address change events to applications.

and replace with

]   Because the probability of, and the consequences of, such failures 
]   will differ from one application to another, no single remedy is 
]   appropriate for all applications.  Some applications (for instance,
]   those whose communications with other hosts are typically brief)
]   may be able to simply accept an increased failure rate.  Other 
]   applications may be able to detect and recover from address changes.  
]   Others may elect to avoid using link-local addresses, or to use 
]   them only as a last resort.  

section 7.2, change entire section to:

]   IPv4 link-local addresses SHOULD NOT be forwarded via an application
]   protocol (for example in a URL, or some other referral using IP 
]   addresses), to a destination which is not link-local, on the same link.   
]   However in general there is no way for an application to know whether the 
]   destination (or some other party to which the address is subsequently
]   forwarded) can make use of a link-local address being forwarded.  
]
]   Applications that are aware of link-local addresses SHOULD NOT 
]   assume that a link-local address is valid for any other host, 
]   even another host on the same link.  Similarly, because link-local
]   addresses are inherently ambiguous, applications that are aware of
]   link-local addresses MUST NOT treat a link-local address by itself
]   as any kind of identity for a host.  Such applications MAY attempt 
]   to contact a host at a link-local address and subsequently verify 
]   that host's (perhaps application-specific) identity via other means.
]
]   This issue is discussed further in Section 2.9 and 3.

section 7.3, change entire section to:

]   Application software run on a multihomed IP host which supports
]   IPv4 link-local address configuration on more than one interface
]   may fail. This is because application software assumes that an IP
]   address is unambiguous, that it can refer to only one host. IPv4
]   link-local addresses are unique only on a single link. A host
]   attached to multiple links can easily encounter a situation where
]   the same address is present on more than one interface, or first on
]   one interface, later on another; in any case associated with more
]   than one host.  This is similar to the problem with forwarding
]   addresses from one host to another - in either case the address
]   is potentially being used on a link on which it is invalid or
]   associated with a different host.
]
]   This is a significant departure from the Internet Protocol v4
]   architecture that assumes uniqueness of addresses.  Most existing 
]   software is therefore not prepared for this ambiguity.  Some
]   of the problems can be addressed by increased complexity in 
]   applications software and by changes to application programming
]   interfaces, but in general the lack of a global address space
]   makes many operations difficult or infeasible.

---

From: Erik Guttman <[email-masked]>
Date: Thu, 26 Sep 2002 11:33:10 +0200 (CEST)

There are specific areas where Keith suggests wording changes which
improve the draft (may to MAY, for example.)  In many cases, I believe
the changes would detract from the clarity or intent of the document. 
This is my interpretation of WG (rough) consensus.  If I am
misrepresenting the WG, please disagree, please express this on the
list. 

> problems in the document, but I think they should be made anyway.

Keith, 

Do you intend to send more comments at a later time?

> ]  prefix or any other prefix not assigned to that network.

The SHOULD is OK.  The bit about disconnected networks is not OK. 

This document does not describe network address assignment policy, that
is on which sort of networks an administrator might assign whatever
addresses he or she decides to configure.  This paragraph says only that
if there is such a policy, the addresses SHOULD be from the RFC 1918
range not from the LL range.

> ]  source address or a routable address, as appropriate.

OK.
 
> ]  the host MAY use either its link-local source address or a routable

OK.
 
> section 2.8:

Stuart, please take this up with Keith.

> ]  Similar considerations apply at layers above IP.

Similar to what?

> ]  the address does not support link-local addressing.

(c) is false.  The host receiving the LL address reference does not need
to *have* a LL address to know how to receive from a LL source or send
to a LL destination.

(a) and (b) are covered in section 7 as are the next two paragraphs.

> ]  binding will be revoked due to an address conflict.

---

> ]  use of DNS to return link-local addresses is NOT RECOMMENDED.

This text is much stronger than that which is in the current draft.
The current text, BTW, was crafted with your assistance, Keith.

> ]  potential to establish communications with the wrong host.

OK.

> ]  might otherwise be ambiguous.  

OK, except your suggested text lacks the final sentence of the preceding
paragraph, which clarifies the intent and mechanism and cannot be
dropped.  The resulting paragraph would be:

   This uniqueness requirement allows host software layers above
   IP  (application software and transport protocols) to identify
   connections using both the source and destination IP addresses.
   While this does increase the complexity of such software, it
   also facilitates more reliable use of link-local addresses which
   might otherwise be ambiguous.   Uniqueness of source addresses on 
   the multi-homed host allows connections to the same destination 
   address on different links to be disambiguated by their different 
   source addresses.
 
> ]  may be exposed to new and different threats as a consequence of

'New and different' here means something like 'previously prevented'
right?  The threats are not new or different.  If the firewall/filter
were to fail or be improperly configured, the *same* threats would
arise.

The hidden assumption:  LL is being used on a link which is more
accessible than the link protected by the firewall/filter.   This
may be the case, but it is just as likely as the host being attached to
an insecure link using non-LL configuration.  There is nothing specific
to LL which adds or exposes new threats, except that 

a - an attacker may subvert LL configuration in the first place

b - hosts may communicate where before they would fail to, lacking
    configuration

An attacker wishing to deny service, could use ARP to accomplish
this just as easily as the attack (a).

The ad absurdum conclusion of your text and (b) above are that any
network configuration which enables communication exposes a host to new
and different (previously prevented) threats.  While this is true, it is
hardly worth pointing out.

If any text is to be added (and let's not), it should be this:

   "Once a host is configured and can operate on an IP network, it 
    may be exposed to previously prevented threats."

> ]   addresses or routable addresses. 

OK.

> ]   network is free from security risks.

Keith, you are revising your own verbatim text submitted after the 
preceding IETF last call!

The wordsmithing of this security section has gone on for three years.

> ]   them only as a last resort.  

An application which can accept an increased failure rate can detect
and cope with address change events already.  Exposing address
change events doesn't *require* applications to take heed of them, it
simply *enables* them to do so, if this is required.  The section is
fine.
 
> ]   IPv4 link-local addresses SHOULD NOT be forwarded via an application
                                ^^^^^^^^^^
This was MUST NOT.  Changing this text to to SHOULD NOT invites failure
but does enable much more interaction (ie. with hosts which do not
support LL configuration).

> ]   forwarded) can make use of a link-local address being forwarded.  

If LL locators are forwarded only to LL addresses on the same link, one
can be pretty sure the recipient can make use of the locator.

I believe we should reject this change until such a time that
applications are more aware of scoped addresses.  RFC 3111, Service
Location Protocol Modifications for IPv6 is an example of protocol
modifications required to accomodate scoping rules. 

> ]   even another host on the same link.  

What does this mean? Of course applications must assume that the address
of their peer is valid.  Otherwise what is the point of communication?
The application may determine it was wrong - but in this case it needs
to find the address again (using service discovery or name resolution)
and attempt to resume communication.  

Yes - this is a change from the current practice.  But it is a very
useful change.  Appletalk works this way.  

> ]   Similarly, because link-local
> ]   addresses are inherently ambiguous, 

LL addresses may be ambiguous outside of their scope, or for very short
intervals on the same link, but your statement goes further.  We already
suggest that applications support renumbering and peers which renumber. 

> ]   applications that are aware of

It is inappropriate to explain to application authors how to construe
the identity of hosts on the network.  This is a barrel of worms.  We
already state that hosts can renumber.  Obviously, any static
association of an address with a host in this environment would be bound
to fail.

> ]   than one host. 

OK.

> ]   This is similar to the problem with forwarding

Not OK.  This implies that forwarding from one LL scope to another is
allowed, which it is not.  If it is an example it is not clear what it
means.

> ]   makes many operations difficult or infeasible.

This paragraph adds only dire admonition to the content above.
It detracts from the current text:

   Most existing software is not prepared for this
   ambiguity. In the future, application programming interfaces could
   be developed to prevent this problem. This issue is discussed in
   Section 3.

Best regards,

Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 09:03:49 -0400

> Do you intend to send more comments at a later time?

well, I'll probably reply to some of the responses to my comments.
(though not to everyone's responses)

but I consider the three sets of comments I've sent:
- the analysis comments
- the comments and suggested changes specifically about "always on" 
  operation
- the other suggested changes to the text
to be substantially complete.

> The SHOULD is OK.  The bit about disconnected networks is not OK. 

I don't think it's OK for this WG to extend the scope of RFC 1918.
This is not within the zeroconf WG's charter.  RFC 1918 was very 
carefully limited in scope for good reasons, and the use of RFC 1918
for other purposes has been demonstrated to be harmful.

> range not from the LL range.

and this document is incorrect in doing so.  RFC 1918 addresses should be
used consistently with RFC 1918.

it's certainly appropriate to mention RFC 1918, but not to specify 
conditions for use of RFC 1918 addresses that are more liberal than
those in RFC 1918.

> > ]  Similar considerations apply at layers above IP.

I think this was left over from earlier text; I don't see a problem in 
deleting that line.

> to *have* a LL address to know how to receive from a LL source or send

(c) is correct.   if an app sends an LL address in a referral to a 
host that is not able to use the LL address for any reason,  this can
cause the app to fail.  one reason the host might not be able to use
the LL address is that it doesn't support LL addressing - i.e. it
treats the LL address as if it were an ordinary IPv4 address, and
sends it to the default router. 

note that (c) doesn't say "...host receiving the address does not have
an LL address" it says "...does not support link-local addressing".

> (a) and (b) are covered in section 7 as are the next two paragraphs.

there is some redundancy between the two.  I don't mind if these
are consolidated as long as the result is complete and accurate.
 
> The current text, BTW, was crafted with your assistance, Keith.

understood - I think this text is clearer and better integrated
with the other text I suggested.

>    address on different links to be disambiguated by their different 

okay, I guess I thought the last sentence was redundant, but there's
nothing incorrect about it, so I don't object to leaving it in.

> were to fail or be improperly configured, the *same* threats would

no, it's a potentially different set of threats - because the set
of threats that had previously existed from a wired/configured interface
(which were perhaps dealt with by filters/firewalls) may be combined with 
a new set of threats from a wireless/unconfigured interface.  (or a 
wired/unconfigured interface that is bridged to a wireless network).
it's the same broad class of threats - in that they are attacks mounted
from a network - the point is that you need to do a different threat 
analysis on the new threats.

> to LL which adds or exposes new threats, except that 

I'd say that LL is being used on a link which is *differently* 
accessible than the link protected by the firewall/filter, and
thus LL is potentially subject to *different* threats.

If 'new' seems too sensitive, I'd consider the following sufficient:

]  Similarly, a host which was protected (to whatever degree)
]  from threats from other hosts via an external filter or firewall
]  may be exposed to a different set of threats as a consequence of
]  link-local addressing.

...perhaps with the caveat that these threats require separate
analysis and potentially different countermeasures.

> hardly worth pointing out.

I disagree strongly - the real security danger of LL is that it introduces 
new threats to a host or network without anyone at that host or network
doing anything except to upgrade to an OS that supports LL (or to get a 
new machine whose OS supports LL).  A warning in the RFC at least puts 
people on notice, and we require all RFCs to adequately document security 
considerations.  Why does zeroconf merit an exception to this rule?

documenting security considerations isn't about blame - it's about making
people aware of the consequences of using this technology.  actually
it should be more-or-less understood that these problems aren't 
zeroconf's "fault" - if they could feasibly be addressed by zeroconf then
our process expects zeroconf to address them.  as it is, about the only
thing that zeroconf can do to address these security problems and still
provide linklocal addressing is to provide a way to turn LL off - which 
is why I've insisted that this option be available.

>     may be exposed to previously prevented threats."

that's subtly misleading - the real point is that you have to deal differently
with threats coming from LL than you do with threats coming from a 
configured network that has means of filtering.  if you discover a new
threat from your configured network (not one which was "previously 
prevented") you probably have to deal with it on LL also, just in
a different way.

one consequence of LL might be that admins have to rely more on 
host-based filtering than firewall-based filtering.  which I'd probably
see as a Good Thing.

> preceding IETF last call!

yes, it's subsequently become apparent to me that LL does not necessarily
reduce threats - it changes them.  so the text I suggested earlier 
was misleading in this way.

> The wordsmithing of this security section has gone on for three years.

security is often difficult to get right, particularly when people are in
denial about the problems.  though it's not as if we didn't know that there
would be security issues with zeroconf - I seem to recall such issues
being raised at two separate zeroconf BOFs even before the WG was 
formed.

> simply *enables* them to do so, if this is required.  

no it doesn't "enable" them to do so, because it doesn't provide them 
with the mechanism to do so - and many application protocols simply 
lack such mechanisms.  that's part of why SHOULD is onerous.  the other
part is that it's painting with too broad a brush - as I point out,
different apps need to cope with this in different ways.

> > ]   IPv4 link-local addresses SHOULD NOT be forwarded via an application

again, the idea is that different apps need to deal with LL in different
ways- categorically forbidding apps to use LL in referrals to nonlocal
hosts may prevent them from working even when they take appropriate measures
in using those referrals.  hint: the host that an address referral
is initially sent to may not be the one that ends up trying to use
that address.

> can be pretty sure the recipient can make use of the locator.

again, the issue is not where the address is initially forwarded, it's which
hosts eventually end up trying to use that address, and also whether they 
apply appropriate checks or blindly trust it.

> modifications required to accomodate scoping rules. 

I believe the zeroconf WG should stop pretending it understands the needs
of all applications well enough to dictate their behavior.  In other words,
it should state the limitations on use of LL addresses (they're only valid
on the same link), rather than prescribe how apps should implement those 
limitations.

> of their peer is valid.  Otherwise what is the point of communication?

the point is that just because you have an LL-address-to-host binding
that was valid at one time from one location does not mean that it
is valid at another time and at a different location, so you need to
use some other means (like an application-specific ID) to verify that
the address you have is still valid.  perhaps it could be stated more
clearly.

> and attempt to resume communication.  

right - or it might use its own internal referral system to try to
get a more recent address.  

> useful change.  Appletalk works this way.  

application developers might or might not see the imposition of LL
as "useful".   LL can be anywhere from very useful to a major 
hinderance depending on the application.

> suggest that applications support renumbering and peers which renumber. 

never mind that it's often impractical for apps to do that, that there's
no support in TCP or most apps protocols to deal with address changes.
apps developers are supposed to wave a magic wand and pull a rabbit out
of the hat because the zeroconf WG told them to.

> association of an address with a host in this environment would be bound

well, I thought I was stating the obvious here.  LL addresses are not 
stably bound to hosts, and are subject to change without notice, so they're 
not host identities in any sense.  even DHCP assigned routable addresses
are bound to those hosts for the duration of the lease.

it seems that you don't want the limitations of LL addresses to be clearly
explained.  it's hard to see how this attitude serves the internet community.

> allowed, which it is not.  If it is an example it is not clear what it

No, it's not acceptable for this group to insist that apps forward addresses
only along the lines of network topology.  If an app has a referral service
that exists on a node that doesn't happen to be local, then the app needs
to be able to forward addresses to that node.  It's recognized that those
addresses are only valid on the same link, but insisting that the app
needs to implement a separate referral service on every link in order to
use LL addresses is overbroad.

>    be developed to prevent this problem. This issue is discussed in

The "current" text is incorrect because it states that API changes could
prevent the problem.  the text I suggested is entirely correct "in general 
the lack of a global address space makes many operations difficult or
infeasible". 

it's high time we stopped lying about the limitations of scoped addresses.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 26 Sep 2002 10:49:39 -0400

> analysis on the new threats.

The threats are going to be exactly the same. The sources will be different.
However, a conscientious network admin will have taken LL and new IETF
standards into account as they are released. LL is old enough that it
shouldn't be a surprise to anyone. As well, if a threat is *truly*
new...i.e. Has never been seen before, then, logic dictates that you cannot
analyze it until it has happened at least once, and been documented in
enough detail to be analyzed.

This is analogous to the way any countermeasures work. Threat happens ->
Threat is documented => Countermeasures are developed and tested =>
Countermeasure are deployed.

Exactly how can any standard change that procedure?

> analysis and potentially different countermeasures.

Most likely. But the information in the standard will tell anyone with the
correct training and experience exactly that anyway. In addition, if the
standard attempts to propose specific solutions to as - yet unknown threats,
(we'll assume predicting the future is possible in Einsteinian space-time
for the sake of argument), then anyone developing threats would have to be
quite stupid to use a threat method that is well-documented with
well-documented countermeasures. It *will* however make a handy guidebook to
what *not* to do, and encourage even more innovation in the area of
attacking systems. 

That's the biggest reason for not including howtos in a standard. In the
end, you gain nothing from it, while encouraging ISV's to ignore that part,
if not all of the standard. I assume that encouraging irrelevance is not
part of the WG's charter.

> prevented") you probably have to deal with it on LL also, just in

If I filter out the entire LL subnet as being invalid on all my hosts, then
I've effectively shut it off. Of course, that means destroying a significant
bit of functionality. That's always the balance in security. But once again,
LL is not going to create new attacks. It's not even creating a new window
for the attack. About the only thing that's remotely new is that *depending
on implementation*, that window is going to be there, open or not. So you
have to deal with that.

I also fail to see how the constant existence of LL will create new threats.
If it does, then I propose that all forms of LL be removed from all
networks, including IPv6 immediately.

> host-based filtering than firewall-based filtering.  which I'd probably

Any good admin is doing this anyway for critical hosts.

^^^^^^^^^^
> is initially sent to may not be the one that ends up trying to use

Which is why applications should not assume that an IP address is tied to a
host. DHCP, even bootp introduced this problem as well, and it's been being
handled for quite some time now. This is why there are far better ways of
dealing with connecting to a specific physical host than IP address.

> apply appropriate checks or blindly trust it.

Blindly trusting an address is pretty silly behavior when you realize that
bootp and DHCP have meant you can't trust IP addresss assignment for some
time now. 

> on the same link), rather than prescribe how apps should implement those

But you are advocating the WG create implementation standards for LL on/off
and security. 

> the address you have is still valid.  perhaps it could be stated more

How does this problem differ from DHCP and/or bootp, or any protocol that
does dynamic address assignment. This problem has been solved for years now.

> hinderance depending on the application.

I fail to see how it is a change from current practices at all. Dynamic
address assignment is a standard now, and means that you cannot assume the
validity of a given address outside of a specific connection. Just because
an address was assigned to host 'foo' an hour ago, doesn't mean that host
'foo' is going to have it now. If the host never disconnects from the link,
then it isn't going normally change it's address, although there are DHCP
setups where this will happen. So we already *now*, *today* are dealing
with:

1)  Inconsistent IP address to Host assignments between connections to the
        link.

2)  Inconsistent IP address to Host assignments for during a given
        connections on the link.

So LL is introducing absolutely no *new* problems here. Which means we can
really stop worrying that it is.

> of the hat because the zeroconf WG told them to.

Then how are DHCP/bootP/other dynamic assignment schemes functional. Apps
are dealing with this now, and have been for many years now.

> are bound to those hosts for the duration of the lease.

But the lease can change, the address can change. You can't assume that any
address will be assigned to any host five minutes from now. Any application
that does so is broken.

> explained.  it's hard to see how this attitude serves the internet community.

Because the limitations you speak of exist in DHCP and other dynamic
addressing standards. I fail to see how refusing to realize this serves this
WG.

> the lack of a global address space makes many operations difficult or

How is this suddenly new to LL?

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax