Subject: ACTION STARTED: revision of draft-ietf-zeroconf-ipv4-linklocal-05.txt

From: Erik Guttman <[email-masked]>
Date: Thu, 23 May 2002 03:35:37 -0700 (PDT)

Everyone,

REMINDER:  This document has gone through WG and IETF last 
call.  We are currently evaluating the last outstanding 
issues which arose during IETF last call.

Keith has brought up a number of issues I have proposed 
resolution of.  We need to evaluate the working group 
consensus on these matters and take action.

* This is a formal call for comments.  At the end of two   *
* weeks the chairs will evaluate consensus on the basis of *
* discussion, revise the WG document and submit the final  *
* result to the IESG for advancement to proposed standard. *

--------------------------------------------------------------

[1] Proposed Action: Add a section "Application Programming 
    Considerations"
 
      Use of IPv4 link-layer autoconfigured addresses presents
      additional challenges to writers of applications and may
      result in existing application software failing.     

    - New subsection:  Address changes, failure and recovery

      IPv4 link-local addresses used by an application may 
      change over time.  Current application software 
      encountering an address change will likely completely 
      fail. For example, client TCP connections will fail, 
      servers whose addresses change will have to be 
      rediscovered, blocked reads and writes will exit with
      an error condition, and so on.

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

    - New subsection:  Limited forwarding of locators

      IPv4 link-layer addresses MUST NOT be forwarded via an
      application protocol (for example in a URL), to a destination
      which is not link-local, on the same link.  This is discussed
      further in Section 2.9 and 3.  

      Existing distributed application software which forwards 
      address information may fail.  For example, FTP [RFC 959] 
      passive mode transmits the IP address of the client.  Assume a
      client starts up and obtains its *passive* IP configuration at 
      a time when the host has only an link-local address.  Later, the
      client gets a global IP address configuration (for one of its
      interfaces).  It uses this global IP address to contact an FTP
      server off of the local link for which it had (or still has) a 
      link-local address configured.  If the ftp client transmits its
      passive IP configuration to the FTP server, the FTP server will
      be unable to reach the FTP client.  The passive FTP operation
      will fail.

    - New subsection:  Address ambiguity

      Application software run on a multihomed IP host which 
      supports IPv4 link-layer address configuration on more
      than one interface may fail.  This is because application
      software assumes that an IP address is unambiguous, that it
      can refer to only one host.  IPv4 link-layer addresses are
      unique only on a single link.  A host attached to multiple 
      links can easily encounter a situation where the same address 
      is present on more than one interface, or first on one 
      interface, later on another; in any case associated with more 
      than one host.  Existing software is not prepared for this
      ambiguity.  In the future, application programming interfaces 
      could be developed to prevent this problem.  This issue is 
      discussed in Section 3.

[2] Proposed Action: Revise "Security Considerations"

    - The address allocation algorithm using ARP exposes an
      attack.  It is of the same kind as the common ARP DOS
      or redirecting attack, but it is of greater severity
      as it generates more traffic as a result.

    - Change text from:

   The use of link-local addresses may somewhat reduce the breadth of
   attack to which a device may be subject, from the entire Internet to
   only attackers who have access to the local link, but that should not
   be seen as a reason to ignore security issues. Developments such as
   wireless networking mean that an attacker does not necessarily need
   to be inside the building to have access to the local link. Even a
   device using only link-local addresses should still implement
   end-to-end cryptographic security at a level appropriate to that
   device and its intended operating environment.

      To:

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

   While there may be particular kinds of devices, or particular
   environments, for which the security provided by the network is 
   adequate to protect the resources that are accessible by the 
   device, it would be misleading to make a general statement to 
   the effect that the requirement to provide security is reduced 
   for devices using linklocal addresses as a sole means of access.

   In all cases, whether or not linklocal addresses are used, it 
   is necessary for implementors of devices supporting the Internet 
   Protocol to analyze the known and credible threats to which a 
   specific host or device might be subjected, and to the extent 
   that it is feasible, to provide security mechanisms which 
   ameliorate or reduce the risks associated with such threats.

 [3] Proposed Action: Revise Section 1.1, "Conventions and 
    Terminology Used in this Document"

    Change definition of "same link" from

   Two hosts are considered to be on the same link if, when 
   one host sends packets to the other, using unicast, 
   multicast, or broadcast, the entire link-layer packet
   payload arrives unmodified.

    to:

   A set of hosts is considered to be "on the same link", if:

   - when any host A from that set sends a packet to any other 
     host B in that set, using unicast, multicast, or broadcast, 
     the entire link-layer packet payload arrives unmodified, 
     and

   - a broadcast sent over that link by any host from that set 
     of hosts can be received by every other host in that set

[4] Proposed Action: Revise Section 2.9 "Higher-Layer Protocol 
    Considerations"

    Remove text:

   For example, DNS Resource Records containing link-local addresses
   SHOULD NOT be sent to hosts outside the link to which those
   link-local addresses apply. Since DNS treats Resource Record Sets
   [RFC 2181] as indivisible units (e.g. for generating DNS reply
   packets, signatures, etc.), RRSets SHOULD only contain A records
   where all the addresses have the same scope. Link-local and routable
   addresses SHOULD NOT be mixed in a single set.

    Modify text:

   Designers of Web pages (including automatically generated web pages)
   SHOULD NOT contain links with embedded link-local addresses if those
   pages are viewable from hosts outside the local link where the
   addresses are valid.

    To:

   For example, designers of Web pages ... (as above).

    Add:

   As link-local addresses may change at any time and have limited
   scope, storing link-layer addresses in the DNS is not well 
   understood and it is NOT RECOMMENDED.
 
 [5] Proposed Action: Reject

   Suggestion: Require support of a mechanism to disable use of 
   IPv4 link-layer address configuration (on configued links).

   Comment:  The rationale for this requirement are issues 
     which are considered above.  The WG must decide whether the 
     issues are sufficiently addressed that it is reasonable to 
     reject Kieth's suggestion.

--------------------------------------------------------------

I want to thank Keith for the persistent and thoughtful 
attention he has paid to the quality of this document.
We are making every reasonable attempt to address his 
concerns.  

If the above is an incomplete list of issues, I will 
augment it.

To remind working group members: The IETF working group 
process does allow for objections of individuals to be 
overridden as a roughness in the arrived at consensus.
It should be your goal to help us arrive at the right 
answer.  Do not be concerned to necessarily arrive at
a unanimous one.

I appreciate your comments.

Erik Guttman 
ZEROCONF cochair