Subject: RE: Turning off link-locals?

From: "Christian Huitema" <[email-masked]>
Date: Thu, 16 Jan 2003 11:05:34 -0800

>There is a "no" vote and a "yes" vote for enabling link-locals
>on a link where the "yes" wins over the "no".
>
>The "no" vote is the existence of a DHCP server which hands out addresses.
>The "yes" vote is some new protocol mechanism (could be a multicast
>query/response, or periodic multicasts).
 
There is really a need for two knobs: whether the host will configure a "v4 link local" address on an interface, and if does not configure such an address, whether it will accept to communicate with hosts using v4 LL on the link.
 
A lot of the programming issues arise from having multiple addresses of different scope for the same hosts -- there was an extensive debate on that point in the IPv6 WG. If a global address is available, using just that address has a number of good properties -- as in, it does not break existing applications. So, there is a strong incentive to not configure a LL address when a global address is available, either through static configuration or through DHCP. This would be knob #1.
 
Communicating or not with LL addressed hosts on a given link is a different issue. Even if a host has a configured global address, it could communicate with a LL addressed host; this is equivalent to having two different subnets on the same link, and there are obvious optimisations for LL aware hosts. This communication may be disallowed by a site manager for security reasons, but it may also be allowed in order to gain functionality. This would be knob #2.
 
-- Christian Huitema

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 16 Jan 2003 12:09:31 -0800

On Thursday, January 16, 2003, at 11:05 AM, Christian Huitema wrote:

> There is really a need for two knobs: whether the host will configure 
> a "v4 link local" address on an interface, and if does not configure 
> such an address, whether it will accept to communicate with hosts 
> using v4 LL on the link.
>
> A lot of the programming issues arise from having multiple addresses 
> of different scope for the same hosts -- there was an extensive debate 
> on that point in the IPv6 WG. If a global address is available, using 
> just that address has a number of good properties -- as in, it does 
> not break existing applications. So, there is a strong incentive to 
> not configure a LL address when a global address is available, either 
> through static configuration or through DHCP. This would be knob #1.

Does this need to be a knob? Can we just recommend that devices not 
acquire an IPv4LL if they get a global address? Is there ever a case 
where it's better to have an IPv4LL address in addition to the global 
address?

> Communicating or not with LL addressed hosts on a given link is a 
> different issue. Even if a host has a configured global address, it 
> could communicate with a LL addressed host; this is equivalent to 
> having two different subnets on the same link, and there are obvious 
> optimisations for LL aware hosts. This communication may be disallowed 
> by a site manager for security reasons, but it may also be allowed in 
> order to gain functionality. This would be knob #2.

Is this knob necessary? I don't believe anyone has presented a case 
where IPv4LL addresses introduce additional security risks.

-josh

---

From: Erik Guttman <[email-masked]>
Date: Fri, 17 Jan 2003 10:04:53 +0100 (CET)

Josh,

> where IPv4LL addresses introduce additional security risks.

There are some additional security risks which were raised in the IESG
comments.  

First:  If a multihomed host determines its LL configuration on one
interface by address information on another, it is possible that an
attacker on one link could force a host to perform address
reconfiguration on a different link.  This is a distributed attack which
was not possible without v4LL.  Section 3.2 suggests that a single
address could be used for all interfaces.  Forcing a conflict with the
host's address on any interface will cause reconfiguration on all of
them.  Section 3.3 suggests that different addresses be used for each
interface.  Even here, an attacker can force a conflict with an address
which is configured for the address configured on a different link and
cause address reconfiguration to occur there. 

Second:  There is concern that v4LL enables selective reconfiguration of
a host.  This will disrupt all communication with the host.  This is a
different attack than ARP spoofing which can redirect or disrupt
communication to a host, but does not change the state of the host or
break its transport level connections.

Third:  This is a concern of 'degree' not 'kind,' concerning wireless
interfaces.  Since it will be much easier for hosts to communicate with
others using v4LL, security flaws of all kinds will be trivially exposed
in cases where they were not as easily revealed in the past (on wired
networks.)

The IESG requested that the document be updated to include remarks on
each of these issues.

Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Jan 2003 11:24:56 -0500

"Christian Huitema" <[email-masked]> writes:

> optimisations for LL aware hosts. This communication may be
> disallowed by a site manager for security reasons, but it may also
> be allowed in order to gain functionality. This would be knob #2.

Note: the current draft (and what I've heard some people seem to argue
for recently) is that hosts with a global address CAN NOT and MUST NOT
speak with a node having a LL address. Some are arguing that the
service provided by LL addressing is to only use LL addresses to speak
with other nodes that also speak LL addressing, as specified in the LL
document. I have by own doubts about that model, but at least some
people have been arguing for it.

Also, there is the issue of a host with a global address (who doesn't
understand LL addresing at all) sending packets for a LL destination
to a router. According to the current wording in the LL document (I
believe), the router will drop the packet. Thus, communication fails.

This can be fairly easily fixed. The rule could/should be that a
router doesn't forward LL packets off of the link from which it was
received. It would be fine for it to send the packet back out on the
same link on which it was recieved though.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Fri, 17 Jan 2003 11:35:35 -0500

> believe), the router will drop the packet. Thus, communication fails.

The router may drop the packet.  Of course, if it is not link-local
aware:

      1. It could route the packet if it has a route for some reason
      2. It could have cached ARP information it learned from the
         destination and forward it back out the same interface

> same link on which it was recieved though.

That rule is fine if the router is LL aware.

What about also sending an ICMP redirect to the sender?

Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 11:34:51 -0500

> same link on which it was recieved though.

there is an interesting idea.  if communications between managed hosts and LL hosts were required to go through a router, and managed hosts were expected to ignore LL traffic not coming from a router, then the router could provide filtering as necessary to implement local policy. 

--
Keith Moore                              http://www.cs.utk.edu/~moore/
27 February 1933                                     11 September 2001

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Jan 2003 11:38:07 -0500

> there is an interesting idea.  if communications between managed
> hosts and LL hosts were required to go through a router, and managed
> hosts were expected to ignore LL traffic not coming from a router,
> then the router could provide filtering as necessary to implement
> local policy.

Not my thinking at all.

I've always been concerned with the idea that LL-enabled devices
should not be allowed (by definition) to communicate with devices that
don't implement LL. That seems like a strange service to me. I can
understand individual applications making such a choice (on a
per-service basis), but I'm less sure it makes sense for that to be
the semantics of LL addressing when used by any device/application.

But if a goal is to allow traffic between nodes _connected to the same
link_, but one using a global addr and one using a LL addr, something
like what I proposed may well be needed in order to make the
communication work in practice.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Jan 2003 11:43:30 -0500

>          destination and forward it back out the same interface

Right, in other words, for non LL-aware routers, they will probably
forward LL packets back as they should (if they have assigned the
prefix to the interface). Or is this a big if??

> That rule is fine if the router is LL aware.

Yes. Note that the draft currently says a node MUST NOT forward a LL
packet further.

> What about also sending an ICMP redirect to the sender?

That would be fine too, except wouldn't the host likely ignore it?  In
IPv4, the host will presumably not realize the destination is on link,
which is the issue that caused it to forward the packet to a router in
the first place...

Thomas

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 11:49:52 -0500

> the semantics of LL addressing when used by any device/application.

I have multiple concerns.  

One is that devices supporting LL should inherently be allowed to
connect to any service on any host that it needs to talk to (i.e. that
such hosts can be expected to be on the same link).   The concern here
is with promoting this as an assumption that device vendors can use to
simplify their designs, when it's not a reasonable assumption.

Another is that devices supporting LL get to circumvent whatever
policy is in place for that link merely because they can acquire an
LL address.  For better or worse many sites currently use DHCP as a
means to control access to hosts - if your MAC address isn't known to
the DHCP server then you can't talk to other hosts on the same net.  

(And especially with wireless networks it's important that
autoconfiguration not facilitate attacks that would normally be thwarted
by filters).

> communication work in practice.

I certainly agree that LL should not be used to communicate off-link
(not even with a NAT, though some think that NAT+v4LL is a great
substitute for DHCP).

---

From: Brian Haberman <[email-masked]>
Date: Fri, 17 Jan 2003 13:32:50 -0500

> prefix to the interface). Or is this a big if??

You are correct in that they need to have routing info for that
prefix.  So, yes, it would be a big if.  Though, if operational
guidance was provided somewhere, a network operator could add
the LL prefix to the interface in order to support a mix of
hosts (LL-aware and LL-unaware).

I will point out that some routing platforms will not forward
a packet back out the interface it was received.

> which is the issue that caused it to forward the packet to a router in

I am not sure how many, if any, host implementations would accept
the redirect...

Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jan 2003 13:32:25 -0600

> hosts (LL-aware and LL-unaware).

This assumes that the router only has one interface connected to a 
network with LL-aware clients.   If it has two or more, it won't know 
how to do the forwarding, because any of the LL-aware ports would be a 
valid place to which to forward the packet.   It might Just Work anyway 
because of the ARP cache, but I wouldn't want to have to depend on it.