Subject: [bmwg] Implemeation notes from draft-ietf-bmwg-hash-stuffing-05.txt

From: "Jerry Perser" <[email-masked]>
Date: Tue, 14 Mar 2006 17:05:54 -0800

I am not going to be able to make the next IETF meeting in March, so I
thought I share my experiences with implementing
draft-ietf-bmwg-hash-stuffing-05.  These are thing that I experienced and
should in no way be construed as displeasure of the drafts last call status.
In fact, version 04 was good enough to implement on.

1. Used (RR & 0xFC) instead of (RR & 0xFE) for the MAC addresses first
Octet.  I do not know the impact of mixing GLOBALLY ADMINISTERED ADDRESS and
LOCALLY ADMINISTERED ADDRESS in the same test.  No completely sure if it's
still used.  The IEEE 802.3 standard gives no information on the use or
issues.  I decide to play it safe and only allow GLOBALLY ADMINISTERED
ADDRESS.

2. The PP:PP 1-indexed interface number referred to the first interface that
frames are transmitted from.  I am dealing with clients that move from one
interface to another (test of wireless LAN roaming).  In a list of possible
interfaces, the MAC address refers to the first interface that sees frames.
This complies with the draft.  I just wanted to be clear in my
implementation.

3. Pseudorandom number runs the risk of repeating during a test.  The odds
are 16 million to 1 (roughly), but with my luck it will happen in February
in New England during a test, and I will have to go there.  I have
implemented some crude code to filter out repeats.  Looking for something
better that keeping a table of used addresses.

4. Pseudorandomness is playing havoc with some security devices.  I am
currently investigating a problem when using a static IP and a pseudorandom
MAC.  It seems that this looks like an attack to the SUT/DUT and won't play
with me.  If anyone has some suggestions, I'm all ears.

Jerry Perser
VeriWave
Main :  818-338-4000
Direct: 818-338-4112
Fax:    818-338-4005

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: David Newman <[email-masked]>
Date: Tue, 14 Mar 2006 23:02:22 -0800

Hi Jerry,

Very glad to hear this is useful, and thanks much for the feedback. I've 
embedded comments/questions inline.

> issues.  I decide to play it safe and only allow GLOBALLY ADMINISTERED

One of the ID authors is a whole lot better than the other at bitwise 
math. When this topic came up, it took the more knowledgeable author 
about 9 nanoseconds to observe that ANDing an odd hex digit with 0xFE 
makes the number even. Hence there's no need to AND with 0xFC or 0xF6 or 
any of the other one's complements of the various multicast MAC 
high-order bytes. They're all odd, made even by ANDing them with 0xFE.

> This complies with the draft.  I just wanted to be clear in my

Not sure I follow here. The draft deals with addressing of the 
transmitting interfaces of the test instrument, not the receivers.

For actual clients doing roaming, the client's source MAC wouldn't 
change as the client roamed from one access point to another. Test 
instruments should emulate that behavior too.

We may be saying the same thing here. If you're doing the same thing as 
an actual client -- with one source MAC throughout the test -- then 
we're on the same page.

> better that keeping a table of used addresses.

The only chance for repetition, however remote, is among source 
addresses from the same interface of the generator (because of the 
unique port IDs).

For test cases where 0 repetition is needed, filtering out dupes sounds 
like a sensible way to implement the ID.

OTOH, the primary goal is to lessen the effects of hash collisions, and 
not necessarily to eliminate duplication.

Currently, defaults in some test instruments produce 100.00 percent 
duplication, with a high likelihood of hash collisions. Randomizing 
addresses (as might be found in production settings) greatly reduces the 
probability of hash collisions, but it doesn't eliminate that chance 
altogether. I don't know that 0 percent hash collisions is any more 
meaningful than 100 percent hash collisions.

> 4. Pseudorandomness is playing havoc with some security devices. 

Pseudorandom patterns wreak havoc with some switches and routers as 
well. They've been getting off easy with the static addresses we've fed 
them in lab testing all these years. It's the old tuning-for-benchmarks 
problem...

dn

  I am