[RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Stephen Hemminger]

There are some addresses in the assigned vendor block that don't obey
the locally assigned convention. These should be avoided by random_ether_addr
assignment.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
 include/linux/etherdevice.h |   17 +----------------
 net/ethernet/eth.c          |   42 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 16 deletions(-)

--- a/include/linux/etherdevice.h	2011-05-13 12:37:08.199257621 -0700
+++ b/include/linux/etherdevice.h	2011-05-13 16:48:46.722745009 -0700
@@ -45,8 +45,7 @@ extern void eth_header_cache_update(stru
 extern int eth_mac_addr(struct net_device *dev, void *p);
 extern int eth_change_mtu(struct net_device *dev, int new_mtu);
 extern int eth_validate_addr(struct net_device *dev);
-
-
+extern void random_ether_addr(u8 *addr);
 
 extern struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
 					    unsigned int rxqs);
@@ -126,20 +125,6 @@ static inline int is_valid_ether_addr(co
 }
 
 /**
- * random_ether_addr - Generate software assigned random Ethernet address
- * @addr: Pointer to a six-byte array containing the Ethernet address
- *
- * Generate a random Ethernet address (MAC) that is not multicast
- * and has the local assigned bit set.
- */
-static inline void random_ether_addr(u8 *addr)
-{
-	get_random_bytes (addr, ETH_ALEN);
-	addr [0] &= 0xfe;	/* clear multicast bit */
-	addr [0] |= 0x02;	/* set local assignment bit (IEEE802) */
-}
-
-/**
  * dev_hw_addr_random - Create random MAC and set device flag
  * @dev: pointer to net_device structure
  * @hwaddr: Pointer to a six-byte array containing the Ethernet address
--- a/net/ethernet/eth.c	2011-05-13 12:37:08.219257985 -0700
+++ b/net/ethernet/eth.c	2011-05-13 17:03:39.412209908 -0700
@@ -392,3 +392,46 @@ ssize_t sysfs_format_mac(char *buf, cons
 	return (ssize_t)l;
 }
 EXPORT_SYMBOL(sysfs_format_mac);
+
+/* These vendors are known to violate the local MAC address assignment
+   convention. Avoid using them. */
+static const struct {
+	u8 oui[3];
+} inuse[] = {
+	{ .oui = { 0x02, 0x07, 0x01 } }, /* Interlan */
+	{ .oui = { 0x02, 0x60, 0x60 } }, /* 3Com */
+	{ .oui = { 0x02, 0x60, 0x8c } }, /* 3Com */
+	{ .oui = { 0x02, 0xa0, 0xc9 } }, /* Intel */
+	{ .oui = { 0x02, 0xaa, 0x3c } }, /* Olivetti */
+	{ .oui = { 0x02, 0xcf, 0x1f } }, /* CMC */
+	{ .oui = { 0x02, 0xe0, 0x3b } }, /* Prominet */
+	{ .oui = { 0x02, 0xe6, 0xd3 } }, /* BTI */
+	{ .oui = { 0x52, 0x54, 0x00 } }, /* Realtek */
+	{ .oui = { 0x52, 0x54, 0x4c } }, /* Novell 2000 */
+	{ .oui = { 0x52, 0x54, 0xab } }, /* Realtec */
+	{ .oui = { 0xe2, 0x0c, 0x0f } }, /* Kingston Technologies */
+};
+
+/**
+ * random_ether_addr - Generate software assigned random Ethernet address
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Generate a random Ethernet address (MAC) that is not multicast
+ * and has the local assigned bit set.
+ */
+
+void random_ether_addr(u8 *addr)
+{
+	int i;
+
+ retry:
+	get_random_bytes (addr, ETH_ALEN);
+
+	addr [0] &= 0xfe;	/* clear multicast bit */
+	addr [0] |= 0x02;	/* set local assignment bit (IEEE802) */
+
+	for (i = 0; i < ARRAY_SIZE(inuse); i++)
+		if (memcmp(inuse[i].oui, addr, 3) == 0)
+			goto retry;
+}
+EXPORT_SYMBOL(random_ether_addr);

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Rick Jones]

On Fri, 2011-05-13 at 17:17 -0700, Stephen Hemminger wrote:
> There are some addresses in the assigned vendor block that don't obey
> the locally assigned convention. These should be avoided by random_ether_addr
> assignment.

How "recent" are these violations?  Is there really a non-trivial chance
of colliding?  Much more than two or more stations in the same broadcast
domain randomly picking the same random MAC anyway?

At one level, avoiding using those OUIs seems to be a tacit approval of
the violations.

rick jones

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Stephen Hemminger]

On Fri, 13 May 2011 17:28:25 -0700
Rick Jones <rick.jones2@hp.com> wrote:

> On Fri, 2011-05-13 at 17:17 -0700, Stephen Hemminger wrote:
> > There are some addresses in the assigned vendor block that don't obey
> > the locally assigned convention. These should be avoided by random_ether_addr
> > assignment.
> 
> How "recent" are these violations?  Is there really a non-trivial chance
> of colliding?  Much more than two or more stations in the same broadcast
> domain randomly picking the same random MAC anyway?
> 
> At one level, avoiding using those OUIs seems to be a tacit approval of
> the violations.

These were assigned long ago in the early days of Ethernet.
It makes sense to me to avoid them as just good policy.


-- 

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Rick Jones]

On Fri, 2011-05-13 at 17:32 -0700, Stephen Hemminger wrote:
> On Fri, 13 May 2011 17:28:25 -0700
> Rick Jones <rick.jones2@hp.com> wrote:
> 
> > On Fri, 2011-05-13 at 17:17 -0700, Stephen Hemminger wrote:
> > > There are some addresses in the assigned vendor block that don't obey
> > > the locally assigned convention. These should be avoided by random_ether_addr
> > > assignment.
> > 
> > How "recent" are these violations?  Is there really a non-trivial chance
> > of colliding?  Much more than two or more stations in the same broadcast
> > domain randomly picking the same random MAC anyway?
> > 
> > At one level, avoiding using those OUIs seems to be a tacit approval of
> > the violations.
> 
> These were assigned long ago in the early days of Ethernet.
> It makes sense to me to avoid them as just good policy.


Well, then by a quick glance at
http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
there are more to add... (some overlap with your list, I've not checked
the entire thing, how the name conflicts should be resolved I've no
idea)

raj@tardy:~$ grep ^02- oui.txt 
02-07-01   (hex)		RACAL-DATACOM
02-1C-7C   (hex)		PERQ SYSTEMS CORPORATION
02-60-86   (hex)		LOGIC REPLACEMENT TECH. LTD.
02-60-8C   (hex)		3COM CORPORATION
02-70-01   (hex)		RACAL-DATACOM
02-70-B0   (hex)		M/A-COM INC. COMPANIES
02-70-B3   (hex)		DATA RECALL LTD
02-9D-8E   (hex)		CARDIAC RECORDERS INC.
02-AA-3C   (hex)		OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01   (hex)		OCTOTHORPE CORP.
02-C0-8C   (hex)		3COM CORPORATION
02-CF-1C   (hex)		COMMUNICATION MACHINERY CORP.
02-E6-D3   (hex)		NIXDORF COMPUTER CORPORATION

The ieee's list doesn't have any 52's though.

rick

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Rick Jones]

> Well, then by a quick glance at
> http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
> there are more to add... (some overlap with your list, I've not checked
> the entire thing, how the name conflicts should be resolved I've no
> idea)
> 
> raj@tardy:~$ grep ^02- oui.txt 
> 02-07-01   (hex)		RACAL-DATACOM
> 02-1C-7C   (hex)		PERQ SYSTEMS CORPORATION
> 02-60-86   (hex)		LOGIC REPLACEMENT TECH. LTD.
> 02-60-8C   (hex)		3COM CORPORATION
> 02-70-01   (hex)		RACAL-DATACOM
> 02-70-B0   (hex)		M/A-COM INC. COMPANIES
> 02-70-B3   (hex)		DATA RECALL LTD
> 02-9D-8E   (hex)		CARDIAC RECORDERS INC.
> 02-AA-3C   (hex)		OLIVETTI TELECOMM SPA (OLTECO)
> 02-BB-01   (hex)		OCTOTHORPE CORP.
> 02-C0-8C   (hex)		3COM CORPORATION
> 02-CF-1C   (hex)		COMMUNICATION MACHINERY CORP.
> 02-E6-D3   (hex)		NIXDORF COMPUTER CORPORATION
> 
> The ieee's list doesn't have any 52's though.

It does have some A's though:
~$ grep ^.[26AE]- oui.txt 
[the aforementioned 02's]
AA-00-00   (hex)		DIGITAL EQUIPMENT CORPORATION
AA-00-01   (hex)		DIGITAL EQUIPMENT CORPORATION
AA-00-02   (hex)		DIGITAL EQUIPMENT CORPORATION
AA-00-03   (hex)		DIGITAL EQUIPMENT CORPORATION
AA-00-04   (hex)		DIGITAL EQUIPMENT CORPORATION

which if I've not botched my bits has the locally administered bit set.

rick

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Bill Fink]

On Fri, 13 May 2011, Rick Jones wrote:

> > Well, then by a quick glance at
> > http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
> > there are more to add... (some overlap with your list, I've not checked
> > the entire thing, how the name conflicts should be resolved I've no
> > idea)
> > 
> > raj@tardy:~$ grep ^02- oui.txt 
> > 02-07-01   (hex)		RACAL-DATACOM
> > 02-1C-7C   (hex)		PERQ SYSTEMS CORPORATION
> > 02-60-86   (hex)		LOGIC REPLACEMENT TECH. LTD.
> > 02-60-8C   (hex)		3COM CORPORATION
> > 02-70-01   (hex)		RACAL-DATACOM
> > 02-70-B0   (hex)		M/A-COM INC. COMPANIES
> > 02-70-B3   (hex)		DATA RECALL LTD
> > 02-9D-8E   (hex)		CARDIAC RECORDERS INC.
> > 02-AA-3C   (hex)		OLIVETTI TELECOMM SPA (OLTECO)
> > 02-BB-01   (hex)		OCTOTHORPE CORP.
> > 02-C0-8C   (hex)		3COM CORPORATION
> > 02-CF-1C   (hex)		COMMUNICATION MACHINERY CORP.
> > 02-E6-D3   (hex)		NIXDORF COMPUTER CORPORATION
> > 
> > The ieee's list doesn't have any 52's though.
> 
> It does have some A's though:
> ~$ grep ^.[26AE]- oui.txt 
> [the aforementioned 02's]
> AA-00-00   (hex)		DIGITAL EQUIPMENT CORPORATION
> AA-00-01   (hex)		DIGITAL EQUIPMENT CORPORATION
> AA-00-02   (hex)		DIGITAL EQUIPMENT CORPORATION
> AA-00-03   (hex)		DIGITAL EQUIPMENT CORPORATION
> AA-00-04   (hex)		DIGITAL EQUIPMENT CORPORATION
> 
> which if I've not botched my bits has the locally administered bit set.

The AA addresses are used by DECNET and related protocols.

					-Bill

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Eric Dumazet]

Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> There are some addresses in the assigned vendor block that don't obey
> the locally assigned convention. These should be avoided by random_ether_addr
> assignment.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


We call random_ether_addr() for some virtual devices, maybe we can add a
__random_ether_addr() helper for them and not avoid these OUI ?

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Joe Perches]

On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > There are some addresses in the assigned vendor block that don't obey
> > the locally assigned convention. These should be avoided by random_ether_addr
> > assignment.
> We call random_ether_addr() for some virtual devices, maybe we can add a
> __random_ether_addr() helper for them and not avoid these OUI ?

Unless it's speed critical, it's probably not worthwhile.

I think that using get_random_bytes, because it can drain
the entropy pool, may not be a great thing to do.

There's little value in crypto secure OUI's for random
ethernet addresses.

I think using get_random_int or random32 is probably good
enough.

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Eric Dumazet]

Le dimanche 15 mai 2011 à 13:20 -0700, Joe Perches a écrit :
> On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> > Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > > There are some addresses in the assigned vendor block that don't obey
> > > the locally assigned convention. These should be avoided by random_ether_addr
> > > assignment.
> > We call random_ether_addr() for some virtual devices, maybe we can add a
> > __random_ether_addr() helper for them and not avoid these OUI ?
> 
> Unless it's speed critical, it's probably not worthwhile.
> 

Speed was not my concern, but getting idea of why avoiding pre-assigned
OUI was a concern for them, if they dont hit a real Ethernet domain.

> I think that using get_random_bytes, because it can drain
> the entropy pool, may not be a great thing to do.
> 

This has litle to do with Stephen patch. You could discuss this with
Matt Mackall.

By the way, since 2.6.29 every exec() gets 16 bytes from
get_random_bytes() for PRNG seeding.

Typical machine starts far more programs than network interfaces ;)


Anyway, it seems to have no impact at all, even gathering 128*6 bytes
here : 

# cat /proc/sys/kernel/random/entropy_avail
142
# modprobe dummy numdummies=128 
# cat /proc/sys/kernel/random/entropy_avail
156

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Rick Jones]

On Sat, 2011-05-14 at 02:28 -0400, Bill Fink wrote:
> On Fri, 13 May 2011, Rick Jones wrote:
> 
> > > Well, then by a quick glance at
> > > http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
> > > there are more to add... (some overlap with your list, I've not checked
> > > the entire thing, how the name conflicts should be resolved I've no
> > > idea)
> > > 
> > > raj@tardy:~$ grep ^02- oui.txt 
> > > 02-07-01   (hex)		RACAL-DATACOM
> > > 02-1C-7C   (hex)		PERQ SYSTEMS CORPORATION
> > > 02-60-86   (hex)		LOGIC REPLACEMENT TECH. LTD.
> > > 02-60-8C   (hex)		3COM CORPORATION
> > > 02-70-01   (hex)		RACAL-DATACOM
> > > 02-70-B0   (hex)		M/A-COM INC. COMPANIES
> > > 02-70-B3   (hex)		DATA RECALL LTD
> > > 02-9D-8E   (hex)		CARDIAC RECORDERS INC.
> > > 02-AA-3C   (hex)		OLIVETTI TELECOMM SPA (OLTECO)
> > > 02-BB-01   (hex)		OCTOTHORPE CORP.
> > > 02-C0-8C   (hex)		3COM CORPORATION
> > > 02-CF-1C   (hex)		COMMUNICATION MACHINERY CORP.
> > > 02-E6-D3   (hex)		NIXDORF COMPUTER CORPORATION
> > > 
> > > The ieee's list doesn't have any 52's though.
> > 
> > It does have some A's though:
> > ~$ grep ^.[26AE]- oui.txt 
> > [the aforementioned 02's]
> > AA-00-00   (hex)		DIGITAL EQUIPMENT CORPORATION
> > AA-00-01   (hex)		DIGITAL EQUIPMENT CORPORATION
> > AA-00-02   (hex)		DIGITAL EQUIPMENT CORPORATION
> > AA-00-03   (hex)		DIGITAL EQUIPMENT CORPORATION
> > AA-00-04   (hex)		DIGITAL EQUIPMENT CORPORATION
> > 
> > which if I've not botched my bits has the locally administered bit set.
> 
> The AA addresses are used by DECNET and related protocols.

Um, ok, I was figuring something along those lines - but regardless, in
the context of Stephen's RFC, they are pre-assigned OUIs with the
locally administered bit set and presumably as such ones that should not
be assigned by the random ethernet address generator.  Assuming that
checking for such things is indeed necessary in the first place.

rick jones

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Stephen Hemminger]

On Sun, 15 May 2011 23:10:26 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le dimanche 15 mai 2011 à 13:20 -0700, Joe Perches a écrit :
> > On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> > > Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > > > There are some addresses in the assigned vendor block that don't obey
> > > > the locally assigned convention. These should be avoided by random_ether_addr
> > > > assignment.
> > > We call random_ether_addr() for some virtual devices, maybe we can add a
> > > __random_ether_addr() helper for them and not avoid these OUI ?
> > 
> > Unless it's speed critical, it's probably not worthwhile.
> > 
> 
> Speed was not my concern, but getting idea of why avoiding pre-assigned
> OUI was a concern for them, if they dont hit a real Ethernet domain.

My concern was that after some discussion with IEEE committee that many
virtual environments are using locally assigned addresses that get bridged
onto real networks.

That started me thinking that the current code should be more careful
to avoid potential conflicts. My opinion is that this not worth worrying
about because the likelihood of conflict with any one of these old
addresses is as about as the unlikely as two hosts choosing the same
value. But I wanted to raise the issue for explicit discussion and frame
it with what would be required to handle it.

-- 

Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr

[Stephen Hemminger]

On Mon, 16 May 2011 08:46:44 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:

> On Sun, 15 May 2011 23:10:26 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
> > Le dimanche 15 mai 2011 à 13:20 -0700, Joe Perches a écrit :
> > > On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> > > > Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > > > > There are some addresses in the assigned vendor block that don't obey
> > > > > the locally assigned convention. These should be avoided by random_ether_addr
> > > > > assignment.
> > > > We call random_ether_addr() for some virtual devices, maybe we can add a
> > > > __random_ether_addr() helper for them and not avoid these OUI ?
> > > 
> > > Unless it's speed critical, it's probably not worthwhile.
> > > 
> > 
> > Speed was not my concern, but getting idea of why avoiding pre-assigned
> > OUI was a concern for them, if they dont hit a real Ethernet domain.
> 
> My concern was that after some discussion with IEEE committee that many
> virtual environments are using locally assigned addresses that get bridged
> onto real networks.
> 
> That started me thinking that the current code should be more careful
> to avoid potential conflicts. My opinion is that this not worth worrying
> about because the likelihood of conflict with any one of these old
> addresses is as about as the unlikely as two hosts choosing the same
> value. But I wanted to raise the issue for explicit discussion and frame
> it with what would be required to handle it.

I thought of one problem that the current code has related to udev.
If a virtual device chooses one of the pre-assigned OUI values then
udev will put in the persistent network device file.
This will cause the device to change name.

If you look at /lib/udev/rules.d/75-persistent-net-generator-rules
it has special case code for this.


# ignore KVM virtual interfaces
ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
# ignore VMWare virtual interfaces
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"

# These vendors are known to violate the local MAC address assignment scheme
# Interlan, DEC (UNIBUS or QBUS), Apollo, Cisco, Racal-Datacom
ENV{MATCHADDR}=="02:07:01:*", GOTO="globally_administered_whitelist"
# 3Com
ENV{MATCHADDR}=="02:60:60:*", GOTO="globally_administered_whitelist"
# 3Com IBM PC; Imagen; Valid; Cisco; Apple
ENV{MATCHADDR}=="02:60:8c:*", GOTO="globally_administered_whitelist"
# Intel
ENV{MATCHADDR}=="02:a0:c9:*", GOTO="globally_administered_whitelist"
# Olivetti
ENV{MATCHADDR}=="02:aa:3c:*", GOTO="globally_administered_whitelist"
# CMC Masscomp; Silicon Graphics; Prime EXL
ENV{MATCHADDR}=="02:cf:1f:*", GOTO="globally_administered_whitelist"
# Prominet Corporation Gigabit Ethernet Switch
ENV{MATCHADDR}=="02:e0:3b:*", GOTO="globally_administered_whitelist"
# BTI (Bus-Tech, Inc.) IBM Mainframes
ENV{MATCHADDR}=="02:e6:d3:*", GOTO="globally_administered_whitelist"
# Realtek
ENV{MATCHADDR}=="52:54:00:*", GOTO="globally_administered_whitelist"
# Novell 2000
ENV{MATCHADDR}=="52:54:4c:*", GOTO="globally_administered_whitelist"
# Realtec
ENV{MATCHADDR}=="52:54:ab:*", GOTO="globally_administered_whitelist"
# Kingston Technologies
ENV{MATCHADDR}=="e2:0c:0f:*", GOTO="globally_administered_whitelist"

# match interface dev_id
ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"

# do not use "locally administered" MAC address
ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

# do not use empty address
ENV{MATCHADDR}=="00:00:00:00:00:00", ENV{MATCHADDR}=""

LABEL="globally_administered_whitelist"