Subject: IPv6 -> MAC multicast address mapping

From: "Nir Arad" <[email-masked]>
Date: Sun, 27 Jul 2003 14:52:54 +0200

Hi,

Should a node (a router) check the validity of the mapping of IPv6 multicast destination address into the Ethernet MAC multicast address?

I didn't find this requirement anywhere, and perhaps there shouldn't be one, but I wanted to provoke some thought on this issue.
Could there be a security issue? Perhaps other issues?

Regards,

-- Nir Arad

---

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 28 Jul 2003 16:20:51 +0530

Hi Nir,

My thoughts... Add the validation check! It does not seem to be expensive.
One scenario where is this check might be useful is to prevent
identification of the OS running on the router; the assumption is that not
checking the mapping is/will be atypical behavior. :-)

CP

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nir Arad
Sent: Sunday, July 27, 2003 6:23 PM
To: IPng mailing list
Subject: IPv6 -> MAC multicast address mapping

Hi,
 
Should a node (a router) check the validity of the mapping of IPv6 multicast
destination address into the Ethernet MAC multicast address?
 
I didn't find this requirement anywhere, and perhaps there shouldn't be one,
but I wanted to provoke some thought on this issue.
Could there be a security issue? Perhaps other issues?
 
Regards,
 
-- Nir Arad

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Nir Arad" <[email-masked]>
Date: Tue, 29 Jul 2003 11:57:20 +0200

Thanks for the reply, Chirayu.

Indeed, this does not seem expensive (even for a hardware implementation...), but if it is agreed that this validation
should take place, perhaps it should be documented in the "Node Requirements", or in RFC 2464 and the likes which
mandate those mappings.

Regards,

-- Nir Arad

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 29 Jul 2003 14:25:55 +0200

Hello,

On Sun, Jul 27, 2003 at 02:52:54PM +0200, Nir Arad wrote:

> Should a node (a router) check the validity of the mapping of IPv6
> multicast destination address into the Ethernet MAC multicast address?

In a weak sense, they do this automatically, by 

a) implementing a MAC multicast filter representing the subscribed IP
   multicast group list, thus only receiving correct packets

b) checking for what IP group the received packets are, and discarding the 
   wrong ones in one way or other.

Now, this is only a very weak check, because:

a1) most hardware multicast filters are leaking

ab2) a node can subscribe to multiple groups, probably mapped to different
MAC multicast addresses. Thus nodes subscribed to addresses A and B don't
normally know if a message for group A was received at MAC(B). If I 
understand correctly, this is your concern.

I can't think of a way this is a security problem - can you point this out
please? With the exception that a DOS might be mounted by sending packets
to the wrong MAC address that are later discarded... But you'll have to
stop them at the source, not at the receivers, to prevent the DOS.

Regards,
	-is

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 29 Jul 2003 18:00:48 +0200

> Could there be a security issue?

Exactly my question. To be exact:

Assume the receiving node R had subscribed to IPv6 multicast groups A and B.
Assume that the corresponding MAC groups are a = mac(A) and b = mac(B).

Also, let C be an IPv6 multicast group with a = mac(C), and D be an IPv6
multicast group with mac(D) != a and mac(D) != b. 

To make things more interesting, most multicast filters accept a pretty 
large equivalence class of multicast MACs - so let E be an IPv6 multicast
group with (e = mac(A)) != a and e != b, but where R receives at layer 2
e if it is configured to receive a.

I observe:

- Your proposal obviously can't protect R against receiving packets 
addressed to C, and has to filter against them on layer 3 (actually,
naturally it will do this as it will have no consumer for them).

- For similar reasons, it will already block/ignore, at layer 3, all E
packets.

So the only case that your proposal makes a difference is when a rogue
sender S sends a packet for B to the MAC address a, which is accepted on
layer 2 because R also wants to receive A, and which is later accepted
on L3 because R wants to accept B in the first place.

* Is there any security threat here? Of course, you can construct a DOS,
but you would need to block this at the sender, not after the first hop.

* Also, if S sends out packets with the wrong MAC address, most receivers
will NOT receive them. Harm is done to the sender, not the receiver. A 
diagnostic tool should be around to detect this, so that S's software
can be fixed - but should be add additional code to check for this
everywhere, hurting all nodes for all L2-received packets, while wrongly
L2'd packets are dropped anyway later? I think not.

Regards,
	-is