Subject: RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing Draft(06)

From: "Poretsky, Scott" <[email-masked]>
Date: Mon, 13 Nov 2006 14:29:28 -0500

Hi David,

At IETF 67 this week it was mentioned at the microphone of the BMWG
meeting that one of the test equipment vendors would not be implementing
to this draft.  I believe it was Veriwave.  Could you please comment
more on that?

Scott

-----Original Message-----
From: David Newman [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 10:36 AM
Cc: [email-masked]
Subject: Re: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
Draft(06)

Romascanu, Dan (Dan) wrote:
> In general I believe that the draft is ready for submission to the
IESG.
> I have a few non-critical comments that I believe should be taken into
> consideration in a future revision of the document, but prior to
> approval by the IESG. 
> 
> 1. Terminology and Acronyms - the document could benefit from a short
> terminology section. Also, there is broad usage of acronyms, without
> acronym explanation in a separate section or expansion at first
> occurrence
> 2. Section 2 refers to Ethernet MAC addresses. Actually BMWG documents
> that fall under the scope of this document could cover a broader range
> of IEEE 802 technologies out of which Ethernet is just one, for
example
> IEEE 802.11 wireless LAN. I suggest that the scope of this section and
> the text where relevant is changed so that it covers IEEE 802 rather
> than just Ethernet. 

We've had other suggestions for this ID to cover more than 802.3:

- --In response to input from Jerry Perser, we modified section 4.2 to
include an example covering 802.11 roaming.

Given that 802.3 and 802.11 share a common MAC address format (48 bits,
OUI in the same place), no 802.11-specific modification is needed for
the address pattern recommended here

- --In response to input from Scott Poretsky, we added section 4.3 on
MPLS
label contents

Thanks very much for the positive feedback.

dn

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

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

---

From: David Newman <[email-masked]>
Date: Mon, 13 Nov 2006 11:45:14 -0800

> to this draft.  I believe it was Veriwave.  Could you please comment

That's not my understanding, especially since I just completed this test
using VeriWave equipment that fully implemented this ID:

http://www.networkworld.com/2006/110606-wifi-test-index.html

The feedback I've heard from the VeriWave folks is that there are
situations where nonrandom MAC addresses are desirable, such as in
regression testing where the tester wants to have the same MAC addresses
used every single time a test config is generated. Thus, they may want
to have pseudorandom and nonrandom modes.

VeriWave folks can comment on their product features better than I, but
my experience with this company's equipment in multiple tests is that it
*is* fully capable of being hash-stuffing compliant.

dn

---

From: "Tom Alexander" <[email-masked]>
Date: Mon, 13 Nov 2006 12:16:33 -0800

Since this will (in the end) most likely eventually work its way to me, as 
being the Veriwave guy who said that it wasn't possible to do this, I'll 
take the liberty of cutting the Gordian knot. With apologies to David for 
diving in ...

Most of the enterprise class WLAN switch controllers we have tested 
implement a variety of proxies, intrusion detection logic, stateful 
firewalls and so forth. These features build state within the controllers 
that contains both the MAC and the IP addresses used by the wireless clients 
attempting to associate with the WLAN, plus various other bits of 
information. This state tends to be quite long-lived, compared to the 
duration of a test trial or the interval between trials; 5 minutes is not 
unusual. This persistent state plays havoc with the test when the MAC and IP 
address mappings change between trials, or even between test applications.

One enterprise switch controller, for example, maintains an ARP proxy as 
well as a stateful firewall that implements an IP spoofing function. 
Therefore, it not only preserves a mapping between IP and MAC addresses, but 
also responds to ARP requests from other devices on behalf of clients (in 
some cases even before the client has sent any IP packets), and rejects any 
client that is using a new MAC address with a previously observed IP 
address. It also takes quite a bit of time to accept a new IP address with a 
previously observed MAC address - unless the client is using DHCP - but 
that's another story.

When we use random combinations of MAC and IP addresses, therefore, there is 
no guarantee that these random combinations will be preserved across trials. 
What is worse, there is absolutely no way to guarantee that these random 
combinations will be preserved across test application invocations. 
Therefore, what we observe very frequently is that tests tend to work or 
fail in random ways. A test that runs properly on iteration #1 will fail 
flat (because the clients aren't allowed to transfer data) on iterations #2, 
#3, etc. Further, when person #1 runs a test it works great for him/her, 
then person #2 runs the same test and the clients don't even connect because 
the ARP proxy refuses to forward the ARP requests.

The only way that I know of guaranteeing that both IP and MAC addresses will 
bear a fixed mapping to each other and to the physical ports on which they 
are instantiated, regardless of how many times a given test is run, is to 
have some sort of deterministic mapping function that takes the physical 
port and/or client number and uses it to derive the IP and MAC addresses. 
This mapping function could be anything you choose, as long as it results in 
unique addresses for unique clients. It could even be pseudorandom, as long 
as you can guarantee that the mapping is the same no matter how many times 
you run the application.

Cheers,

- Tom

P.S. David - the equipment I was alluding to above wasn't part of your last 
test campaign ... though they do have a high market share.

----- Original Message ----- 
From: "Poretsky, Scott" <[email-masked]>
To: "David Newman" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 13, 2006 11:29 AM
Subject: RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing 
Draft(06)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFFUflMyPxGVjntI4IRApXBAKD4W1vrhyb4ByZeKy1OHkb2pl/zRQCghwhP
> M+zHhZm5To/DfYMnNJzwwzY=
> =KHra
> -----END PGP SIGNATURE-----
>

---

From: David Newman <[email-masked]>
Date: Mon, 13 Nov 2006 12:42:49 -0800

On 11/13/06 12:16 PM, Tom Alexander wrote:

> When we use random combinations of MAC and IP addresses, therefore,
> there is no guarantee that these random combinations will be preserved
> across trials. What is worse, there is absolutely no way to guarantee
> that these random combinations will be preserved across test application
> invocations. Therefore, what we observe very frequently is that tests
> tend to work or fail in random ways. A test that runs properly on
> iteration #1 will fail flat (because the clients aren't allowed to
> transfer data) on iterations #2, #3, etc. Further, when person #1 runs a
> test it works great for him/her, then person #2 runs the same test and
> the clients don't even connect because the ARP proxy refuses to forward
> the ARP requests.

My condolences for end-users of this scheme (which it seems to me would
fail for any clients who change or replace their radios, not that
network interfaces ever fail in production...).

At the same time, I agree with Tom and Tom's customers that there are
testing situations where nonrandom MAC addresses are desirable.

The issue raised in the draft is the opposite case, where devices either:

a) perform poorly with the static address/port distribution used by
default in many test instruments, even though performance is more than
adequate with the uniform address and/or port distribution found in
production networks; or

b) are tuned for benchmarks so they perform well only with the static
addresses and/or ports used by many test instruments

Until hash-stuffing, there was no specified way to generate pseudorandom
addresses, or factor for bit- and byte-stuffing. Those are the goals of
the ID, not the extinction of static addressing patterns.

I do not believe we're talking about mutually exclusive goals. The verbs
in hash-stuffing are RECOMMENDs and not MUSTs; there is nothing in the
ID that says testers can't use both methods for different kinds of tests.

dn

---

From: "Jerry Perser" <[email-masked]>
Date: Tue, 14 Nov 2006 10:14:33 -0800

Scott,

I'm surprised you forgot my name (/e weeps inside).  I was the one at the
microphone.  I was trying to make my time at the microphone short so we
wouldn't run over.  So let me expand more here.

In February 2006, Veriwave implemented random MAC addresses per
draft-ietf-bmwg-hash-stuffing-05.txt.  We released a product that ran BMWG
test suite.  Sometime after that, I posted my implementation notes and Mr.
Newman was kind enough to include them in draft-06.

>From February to this day, random MAC addresses have not been a problem on
my test bed.  My test bed consists of two different Access Points connected
together by a L2 switch.  I don't have an AP controller to test with.  On
the other hand, Veriwave Customer Support Department were finding problem
with certain AP controllers.  Tom Alexander did a good description of the
problem so I would go into it.

During Mr. Newman's public test
(http://www.networkworld.com/2006/110606-wifi-test-index.html), we used
pseudorandom MAC addresses with a fixed random seed (David, the seed I used
in on line 22 in GUI.py). The 500 MAC addresses used appeared completely
random to the SUT/DUT and to anyone looking at the packet dumps.  This is
still complies with draft-ietf-bmwg-hash-stuffing-06.txt, and helps the
repeatability of the tests.  But during the test, Veriwave's management
decided to remove the random MAC address function from the released product.
Veriwave's WaveApps 2.2 contains random MAC addresses, version 2.3 does not.

I want to restate this: I, as an individual, believe
draft-ietf-bmwg-hash-stuffing-06.txt is finished with last call and should
be forwarded to the AD.  My current benefactor/employer, Veriwave, has
temporary decided to disable my implementation of
draft-ietf-bmwg-hash-stuffing-06.txt.

At the Microphone, I poked Veriwave's CTO and asked him if he could look
into this.  This problem looks like it's related to wireless LAN switches
and wireless LAN meshes (the last presentation at the BMWG meeting).

Jerry Perser

> From: Poretsky, Scott [mailto:[email-masked]]
> To: David Newman
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.14.3/531 - Release Date: 11/12/2006

---

From: "Tom Alexander" <[email-masked]>
Date: Tue, 14 Nov 2006 12:08:42 -0800

And to complete the process of discussing VeriWave product development on
the BMWG reflector, I'm sure that as soon as we figure out a way of
unambiguously linking MAC and IP addresses such that they remain linked
across application invocations, we'll be back to using
draft-ietf-bmwg-hash-stuffing-xx.txt.

Cheers,

- Tom

P.S. In defence of VeriWave management (well, maybe), I doubt that any of
them know that draft-ietf-bmwg-hash-stuffing-06.txt even exists. ;-) I got
the random addresses put on hold after a particularly nasty debacle at a key
customer site. When we figure out the WLAN-specific solution to this issue,
rest assured that it will be published in
draft-perser-wlan-switch-benchmarking-01.txt.

-----Original Message-----
From: Jerry Perser [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 10:15 AM
To: [email-masked]
Subject: RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
Draft(06)

Scott,

Jerry Perser