Link local address ambiguity

[becarpenter]

(I have only just become aware of this work, please excuse me if this has been discussed in the past.)

Section 2.1. IP Address Space defines IPv6 link-local addresses as local, which seems logical enough at first sight. However, there is no discussion of how to handle link-local addresses when the device in question has more than one interface (i.e. more than one Layer 2 link). In this case, link-local addresses are no longer guaranteed unique: fe80::abcd could exist on two different interfaces and therefore refer to two different devices. IPv6 addresses have syntax to cover this, but URIs currently do not.

I seriously question whether it is safe to categorise link-local addresses as local; if a client communicates a link-local address to a server, it might be ambiguous at the server end and any attempt to use it might fail. It is only safe when used on the same link that it came from.

Should link-local addresses be treated as loopback? Or should there be a link category between loopback and local?

(Logically, the same argument would apply to IPv4 link-local addresses - see Section 3.2 of RFC3927. Unfortunately IPv4 addresses don't have any syntax defined to resolve the ambiguity.)

[becarpenter]

I think I'd better illustrate the issue with a diagram. IPv6 nodes assign their own link-local addresses and nothing prevents a setup like the diagram shows: in particular, B has given itself the same address on two different links, and A1 and A2 have given themselves the same address. Nutty, perhaps, but allowed, and it will work fine as long as all parties tag the addresses with the corresponding link identity. But you can see how things can go horribly wrong if the address of A1 is accidentally referred to node D; it will likely communicate with A2 by mistake. That's why it's essential to tag these addresses with the link identity (known as the zone ID in IPv6 parlance). Link-local addresses must never be used or communicated on the wrong link.

[letitz]

Hi there, and thanks for the feedback!

I agree that the current classification is imperfect, and acknowledge that there are valid grounds to question even attempting such a classification based on IP address alone. For example, even absent link-local address ambiguity, RFC1918 IPv4 addresses can route to different hosts over time. There was indeed some prior discussion of this in #28.

Now, the aim of this specification is to prevent untrusted websites from attacking devices on the local network, generally using CSRF. Do you see a scenario in which the duplication of fe80::bbbb across B's interfaces, along with the classification of that address as local, allows an attack?

[becarpenter]

I'm not sure I can design an attack as such, but if node C receives an HTML document from B including (say) https://[fe80::aaaa]/some_resource we cannot determine whether it refers to A1 or A2. So it's A1 and A2 having the same address that causes the problem. The address is ambiguous within local and an attacker could presumably find a way to exploit that. Let's say for example that A2 is legit, but A1 is a CSRF honeypot. (B having the same address twice just adds to the confusion.)

This is rather contrived because the attacker would already need to have captured A1, but address ambiguity is always a bad thing.

Certainly in IETF-land, we think of link-local being a narrower scope than site-local, even though we formally scrapped site-local since we couldn't make it work properly [RFC3879].

[letitz]

I see. It seems to me that B sending fe80::aaaa to C is the original sin here: it does not mean (to C) what B thinks it means.

Without changes to URLs, I don't see how we can resolve this ambiguity, even if we classified link-local addresses as a smaller scope than local. Since C accesses B on a link-local address, B's IP address space would always be the same as A1/A2's.

Maybe the right thing to do here is to explore extending URL syntax for link-local IPv6 addresses, such that they can be tagged with the right link?

In any case, I don't think this specification can do much to address the issue, but we can definitely note this as a potential pitfall in the spec.

[becarpenter]

Maybe the right thing to do here is to explore extending URL syntax for link-local IPv6 addresses, such that they can be tagged with the right link?

The challenge there is that there is such a syntax but
a) it is not currently valid in URLs: draft-ietf-6man-rfc6874bis is still an unapproved draft;
b) the IETF address syntax doesn't assign names to links, but to interfaces on individual hosts.

I agree that noting the issue in the current spec would be a good next step.