Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt

From: Erik Guttman <[email-masked]>
Date: Wed, 27 Nov 2002 12:54:06 +0100 (MET)

Thomas,

As we iron out points, I will see to it that a new draft comes out.
Hopefully, we will polish the issues off quickly.  

 - - -

On Fri, 4 Oct 2002, Thomas Narten wrote:
> The IESG discussed this document recently, and has the following
> comments.
> 
> DISCUSS:
> ========
> Harald:
> 
> Three objections, based on a quick scan:
> 
> 1)
> 
> The document gives no (zero) examples of applications that can 
> successfully and safely be used with link-local addresses. I think a 
> list of applications would serve two purposes:
> 
> - document the motivation for this feature
> - serve as target for people arguing that this application has 
> serious failure modes when used with link-local addresses

Application examples:

  Tha classic peer to peer applications are
    'File sharing' - NFS and ONC RPC based protocols, SMB
    'Local printing' - LPD

  Let's add
    'Local web browsing' - FTP, HTTP
    'Local administration' - telnet

Caveats:

General -
  This does not describe how a link-local address is configured with the
  application.  This could be done using LLMNR, SLP, etc.  This implies
  that 'link-local locators' (names and addresses that have only link-
  local significance) can obtained service queries (SLP), or name
  lookups (LLMNR), etc.

  Since link local addresses may change over time (unlikely, but
  possible), it is best to obtain them dynamically (using SLP or LLMNR,
  etc.)

  Link-local local locators which are forwarded off-link are worthless.
  Therefore, some protocols, such as conferencing or those which build
  session based directories to forward locators would fail.

  An example of how a protocol which supports forwarding of locators can
  be made to work in a scoped address environment is in RFC 3111, SLP
  modifications for IPv6.  The only trick is to keep information which
  is received using a scoped address separate, and to only forward it
  to others in the same scope as it was received.

  The following comments apply equally to any use of these protocols
  in scoped or private address spaces.

  HTTP - 
    Redirects [RFC 2616, Section 10.3] and the Content-Location header 
    in general [RFC 2616, Section 14.14] will have to be link-local
    locators in order for a client configured with a link-local
    address to make use of it.
  
  HTML - 
    URIs refered to in anchors, etc. must be link-local locators in
    order for a a client configured with a link-local address to make 
    use of it.

> 2)
> 
> The following section:
> 
>  > 2.10 Higher-Layer Protocol Considerations
>  >
>  > Similar considerations apply at layers above IP.
>  >
>  > For example, designers of Web pages (including automatically
>  > generated web pages) SHOULD NOT contain links with embedded
>  > link-local addresses if those pages are viewable from hosts outside
>  > the local link where the addresses are valid.
>  >
>  > As link-local addresses may change at any time and have limited
>  > scope, storing link-layer addresses in the DNS is not well
>  > understood and it is NOT RECOMMENDED.
> 
> is not sufficiently draconian.
> 
> It should probably say something like:
> 
> The following set of protocols:
> 
> - FTP
> - DNS
> - NFS
> - IPSEC using IPv4 as an identifier
> - BGP
> - OSPF
> - RTP/RTCP
>  <<<the list is far longer, I think>>>
> 
> will fail if applications use a link-local address instead of a 
> globally unique address when sending the address of its interface in 
> a protocol packet.

In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK.

Why is this the case with FTP, DNS, NFS, RTP/RTCP?
If the sender and receiver are both on the same link these protocols
should work fine, I believe.  

Argument why link-local traffic will stay link-local:
  If they are not on the same link, theneither the router should prevent 
  the message from reaching the link-local destination or from leaving
  the link-local source.  In any case, link-local receivers will
  silently discard packets unless TTL=255 (modulo discussion in another
  thread).

> 3)
> 
> Security consideration, section 2.8:
> 
>  > The non-forwarding rule is important because it is expected that
>  > many link-local-only devices will be extremely simple devices of
>  > the kind that currently use X10 [X10], USB [USB] or FireWire [1394].
>  >
>  > The designers of these devices currently assume that they will
>  > communicate only with other local devices, and this allows them to
>  > produce cost-effective devices by implementing a degree of security
>  > appropriate for that expected environment. Any network gateway device
>  > that blindly forwards the contents of link-local IP packets off the
>  > local link (or onto the local link) exposes simple link-local-only
>  > devices to a much greater degree of risk than their designers may
>  > have planned for.
> 
> In the world of wireless LANs, this seems to be an extremely stupid 
> idea.  (not that it was a smart move before.....for kicks, try plugging 
> an X10 controller into your neighbour's outdoor electrical socket and 
> start playing....)
> I would suggest to add a NOTE:
> 
> NOTE: The existence of local links without physical security, such as 
> LANs with attached wireless base stations, means that expecting all 
> local links to be secure enough that normal precautions can be dispensed 
> with is an extremely dangerous practice, which will expose users to 
> considerable risks.

OK.

> Steve:
> How do current hosts behave with respect to this: 
> 
> 	All ARP packets (*replies* as well as requests) that contain a 
>       link-local 'sender IP address' MUST be sent using link-level 
>  	broadcast instead of link-level unicast. This aids timely 
> 	detection of duplicate addresses. An example illustrating how this 
> 	helps is given in Section 4.   
> 
> (I understand the necessity, but is it done? I suspect not. This 
> suggests that there be a warning that link-local addresses SHOULD NOT 
> be manually configured.)  

This is already in the text.

1.4. 169.254/16 Not To Be Used for Other Purposes

   Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
   manually or by a DHCP server. Manual or DHCP configuration may cause
   a host to use an address in the 169.254/16 prefix without following
   the special rules regarding duplicate detection and automatic
   configuration that pertain to addresses in this prefix.
 
> I have vague recollections of an RFC that permits hosts to ignore 
> spontaneous ARP replies, i.e., those not in response to a query, in an 
> effort to block connection hijacking. I think that some hosts actually 
> do this. That would interfere with the claim-and-defend mechanism, and 
> with renumbering, I believe.

I assume that this RFC is an elective standard.

Hosts which support claim-and-defend will require new code.  If
the upgraded stacks contain old code which conflicts with this
new code, the implementor must decide which standards to implement.
 
> What use is link-local security in a world of wireless bridges?

I think that this point is addressed in the NOTE proposed in section 2.

> The Security Considerations section should note that address-based IKE 
> certificates [RFC2409, I think] MUST NOT be issued for link-local 
> addresses.

OK.
 
> How does Windows XP behave?

Windows XP uses the machine name in certificates issued for use with
IPsec. 

> Alex:
>  Seems to me that a "routing considerations" section is required.
>    Some things that should be described:

My opinions follow.
 
>      - should a route be installed in the routing table based
>          on the link-local address on an interface?

This depends on the host implementation, right?
 
>      - should/can the 169.254/16 prefix be announced by dynamic
>          routing protocols?

Section 2.7

   An IPv4 packet whose source and/or destination address is in the
   169.254/16 prefix MUST NOT be sent to any router for forwarding, and
   any network device receiving such a packet MUST NOT forward it,
   regardless of the TTL in the IP header.

No.  Datagrams whose source or destination address is in this
prefix MUST NOT be forwarded.

>      - if received from a routing protocol, should the prefix
>          be installed in the RT?

No, see above.

>      - what the behavior should be if the prefix somehow
>          made it to the RT (static route, old routing proto)?

The host MUST NOT send packets to routers for forwarding.  This is
unambiguous.

> Erik:
>
> The abstract and first paragraph in the introduction can easily be
> read as these addresses being a full-fledged replacement of DHCP
> assigned addresses.  Having the text explicitly say that such
> addresses can not be used for communication outside a single link
> would make sense. 

OK.
 
> In the applicability section it would make sense to add explicit 
> warnings about issues for applications. One issue is the addresses 
> are of limited scope which might cause problems for multi-party 
> applications that pass IP addresses between parties.
> The other issue is that these addresses might have much shorter and 
> unpredictable lifetime, which would have an impact on applications 
> using them on the link. (This is true especially given the 
> suggestions in section 2.5 to pick a new address when a conflict is 
> detected after the address has been used for a while.)

Are Sections 7. 1 and 7.2 insufficient?

> The text in section 2.5 says that in some cases the host MUST cease 
> using the address. Since it is easy for an on-link attacker to spoof 
> the ARP packets it can cause the host to break all its connections by 
> switching to a new address. The document should at least warn against 
> this in section 2.5, and presumably also discuss it in the security 
> considerations section.

We can add this to Section 5:

   The ARP protocol [RFC 826] is insecure. A malicious host may send
   fraudulent ARP packets on the network, interfering with the correct
   operation of other hosts. For example, it is easy for a host to
   answer all ARP requests with replies giving its own hardware address,
   thereby claiming ownership of every address on the network.

   add ->

   It would also be possible for an on-link attacker to spoof ARP
   packets which would cause a host to break all its connections by
   switching to a new address.

Please note that there are similar attacks which exist against hosts
which use global addresses.  An on-link attacker could spoof ARP
packets which would cause a packets destined for a host to be
redirected to the attacker, who could discard them, etc.

>  And here is a "bonus" I didn't mention on the call:
>        The time values specified above are intended for use on 
> 	 technologies such as Ethernet, where switches that implement 
> 	 Spanning Tree [802.1d] often silently discard all packets for 
> 	 several seconds. The time values specified above result in a 
> 	 delay of 8-10 seconds before a chosen IP address may be used. 
> 	 For a desktop machine on Ethernet,
> 
>  FWIW when 802.1d is enabled on the port I plug in my laptop at the 
>  office, the delay before the switch starts forwarding packets is 45 
>  seconds. (I think the 802.1d spec indicates a default time of around 
>  30 seconds.) So 10 seconds don't seem to do much good.

2.3 Shorter Timeouts on Appropriate Network Technologies

   The time values specified above are intended for use on technologies
   such as Ethernet, where switches that implement Spanning Tree
   [802.1d] often silently discard all packets for several seconds. The
   time values specified above result in a delay of 8-10 seconds before
   a chosen IP address may be used. 

   add -->

   In some cases, the delay can be considerably longer due to other 
   networking infrastructure.

The purpose of this section is to give some guidance to implementors
to set appropriate values for their timers, not to definitively answer
what those settings should be.

>        If the destination address is the 255.255.255.255 broadcast 
> 	 address or a multicast address, then the host may use either 
> 	 its link-local source address or a routable address, as 
> 	 appropriate.
> 
>  OK for a link-local multicast destination. But for other multicast 
>  destinations I assume it SHOULD use any routable address instead of 
>  the link-local.

OK.
 
>  section 3.2:
>        Some operating systems have networking APIs that allow 
> 	 applications to specify network interfaces by name, index value, 
> 	 or other local identifier, and to identify interfaces this way 
> 	 both for incoming and outgoing packets/connections. For operating 
> 	 systems that have this capability (and have application software 
> 	 that makes use of it) it is sufficient to configure all interfaces 
> 	 with a single common IPv4 link-local address, and defend that 	
> 	 address on all interfaces.
> 
>  Add warning that uses the same address on all interfaces makes the host
>  more suceptible to attacks and other reasons for duplicate addresses 
>  being detected late, resulting in a shorter lifetime for the link-local 
>  addresses. Using a separate address per interface limits the "damage" 
>  in such a case to a single link.

OK.  This can be added to Section 5.
 
>  section 3.3
>        In addition, this kind of host should probe for, and defend, all 
> 	 of its link-local addresses on all of its active interfaces that 
> 	 are using link-local addresses.
> 
>        When bringing up a new interface, the host SHOULD first probe 
> 	 for all of its existing link-local addresses on that new interface. 
> 	 If any of the addresses are found to be already in use by some 
> 	 other host on that new link, then the interfaces in question MUST 
> 	 be reconfigured to select new unique link-local addresses. 

>        The 
> 	 host should then select a link-local address for the new interface,
> 	 and probe on all of its active interfaces to verify that this new 
> 	 address is unique on all the links that the host has connections to.

>  The above breaks if multiple interfaces on the host are connected
>  to the same link. It also isn't clear to me why this is needed; 
>  presumably the interfaces can be managed indepdently as long as the host 
>  ensures that it doesn't assign the same link-local address to more than 
>  one interface.

This paragraph assumes the right thing to do is configure all interfaces
with the same link-local address.

Either 
(a) The paragraph must be augmented with the following:
    Host must consider the case where more than one interface is 
    connected to the same link.  Say the list of link-layer addresses
    for a given host is L.  The claim-defend algorithm MUST consider
    the case when arp sender link-layer address is in L.  In this case, 
    the IP sender address field in the arp message *does not* constitute
    a conflict necessitating the host to select another address for any
    interface in the list L.

(b) Each interface should be assigned a different v4LL address and
    can then operate independently.

(b) is simpler, and as you state above, it is less instable due to 
    address reconfiguration events and has fewer security consequences.
    Further, (a) relies upon all link-layer addresses being unique,
    which is not necessarily true and not required for (b).

Proposal:  (b)

> Thomas:
> 
>    If the destination address is in the 169.254/16 prefix (including the
>    169.254.255.255 broadcast address), the host SHOULD use its link-
>    local source address, if it has one. If the host does not have a
>    link-local source address, then it MAY choose to ARP for the
>    destination address and then send its packet, with a routable source
>    IP address and a link-local destination IP address, directly to its
>    destination on the same physical link. The host MUST NOT send the
>    packet to any router for forwarding.
> 
> The above wording suggests that if host has no LL address, but it does
> have a global address, it is not required to use that global address
> to talk to a device that only has a LL address. This seems
> broken. I.e, it will result in communication failure that is hard to
> diagnose. Two nodes, both with legitimate addresses that should work,
> for some strange reason won't talk to each other. Seems to me like the
> MAY should really be a MUST. You can't NOT use the global address, if
> it's the only address you have. Or, if there are legitimate reasons
> why an implementation might not want to use its global address in this
> case (knowing that communication will fail as a result) please include
> some background explaining why this might be a reasonable approach.
> 

> COMMENT
> -------
> Scott: notes:
>                 references not split
>                 this can get fixed when Harald's discuss is delt with 
> 

OK.

Erik

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Nov 2002 07:20:21 -0500

On Wednesday, Nov 27, 2002, at 06:54 America/Montreal, Erik Guttman 
> In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK.

With respect to AH/ESP, the original claim (from IESG ?) is utter 
nonsense.
A correct statement would be something like this:

	If one has a Security Association between a pair of hosts (A, B)
	on a common link, AH/ESP will work only if the IP addresses
	used in the packet are consistent with the IP addresses that
	are part of the Security Association in use.  This means that
	if the Security Association uses link-local addresses, then
	the packets MUST use those same link-local addresses.  This
	also means that if the Security Association uses global IP
	addresses, then the packets MUST use those same global IP
	addresses.

I also do not believe that some of the protocols claimed as 
broken-by-link-local
by the IESG (e.g. NFS) do NOT necessarily break just because link-local 
addresses
are used.  In fact, I might have an NFS server at home (that works fine
using link-local IP addresses) as an existence proof counter-example.

If the IESG want to say that an NFS server cannot be contacted from 
off-link
by using the NFS server's link-local address, then yes that is true and 
a bit
of a tautology.  But an NFS server that is on-link most assuredly can be
contacted from on-link using link-local addressing.

The IESG appear to be behaving religiously about this and seem to have 
lost
the needed technical precision in their claims.  Not good.

Ran

---

From: Erik Guttman <[email-masked]>
Date: Wed, 27 Nov 2002 14:26:51 +0100

Thomas,

Here is a little bit more.

> Why is this the case with FTP, DNS, NFS, RTP/RTCP?

I meant to include DNS in the not-ok category.

>to talk to a device that only has a LL address. 

The paragraph says

a) if a destination is link-local *and* a host has a link-local
    address configured, it SHOULD use the link-local address.

    (Was this unclear to you in the first sentence of the paragraph?)

b) otherwise - the host MAY resolve the link-local destination address
    to a mac address and send the packet directly from the host's
    address to the destination address.

c) otherwise - the host will not be able to send the packet at all.
    This is because the packet MUST NOT be sent to a router for
    forwarding.

The reason for b and c in the paragraph is to call out that if a
host wishes to send to a link-local destination, it cannot do this
by simply sending the packet to a router for forwarding (c).  The
host will need to send the packet directly (b), which is maybe
different than the way its IP forwarding algorithm operates today.

 >This seems

If your problem is that the text above leaves open the possibility
of a host's policy falling through the cracks of a's SHOULD and b's
MAY into 'c'?  If so, I agree with your concern.

Proposal:

    becomes ->

    If the destination address is in the 169.254/16 prefix (including the
    169.254.255.255 broadcast address), the host SHOULD use its link-
    local source address, if it has one. If the host does not have a
    link-local source address, then it MUST resolve the destination
    address using ARP and then send its packet, with a routable source
    IP address and a link-local destination IP address, directly to its
    destination on the same physical link.  This is the only way a host
    with a global address would not be able to send to a link-local
    destination, as the host MUST NOT send the packet to any router
    for forwarding.

Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Nov 2002 11:28:36 +0100 (CET)

> Are Sections 7. 1 and 7.2 insufficient?

Three issues with those:
 - They don't explicitly mention that the stability of the addresses is
   affected by late collisions i.e. when the address has been in use for a
while
 - They are written as "all applications SHOULD be fixed to be usable in
   this environment" - it is more realistic for people deploying this
technology
   to turn this around and instead issue a warning that link-locals should not
   be used unless all applications used in the network are known to not depend
   on X, Y, Z.
 - Warnings about limitations of the applicability makes sense up front in the
   document - not towards the end.

>    switching to a new address.

OK, but you need to point out that this is a new threat added
by link-local - and not just bundle if with the current "arp is insecure"
threats.

> redirected to the attacker, who could discard them, etc.

That is a different threat - MiTM can be done with current ARP vs. the new
"IP address invalidation" attack with is possible with this draft.
RFC 826 isn't subject to a threat were an on-link attacker can get
a host to change its address thereby, as a result of receiving a single ARP
packet, will break all its existing communication.
This distinction should be made clear.

> what those settings should be.

Thanks for the attempt, but I think this addition is insufficient.

Deleting text might be a better approach.

>     a conflict necessitating the host to select another address for any

Wouldn't this result in the two (or more) interfaces attached to the same
link on the node to have the same v4LL address? While it might be possible
to get such a configuration to work, I suspect it requires additional things.

>     which is not necessarily true and not required for (b).

Which of the two b's? :-)

  Erik