Subject: RE: [bmwg] possible additional term for draft-ietf-bmwg-ipsec-ter m-05.txt

From: Michele Bustos <[email-masked]>
Date: Wed, 22 Jun 2005 14:07:47 -0700

Hi There David,

production settings?

Production Settings are clearly out of scope for BMWG:

To better distinguish the BMWG from other measurement initiatives in 
the IETF, the scope of the BMWG is limited to technology 
characterization using simulated stimuli in a laboratory environment. 
Said differently, the BMWG does not attempt to produce benchmarks for 
live, operational networks. Moreover, the benchmarks produced by this 
WG 
shall strive to be vendor independent or otherwise have universal 
applicability to a given technology class.

###############
and here you even agreed with that mod:

"Fully agree with the spirit of this change, and almost all the wording.

The only edit I'd recommend would be to delete the words "or their
elements" from the second sentence. In fact, the bmwg is intimately
concerned with producing benchmarks for network elements like routers,
switches, and other widgets -- just not in a production setting.

dn"

http://www.ietf.org/mail-archive/web/bmwg/current/msg00411.html

============================================= 
Michele Bustos 
Ixia 

26601 W. Agoura Road 
Calabasas, CA 91302 
Tel: (818) 871-1800 (US), ext. 1 
+1 (818) 871-1800 (international) 
<http://www.ixiacom.com> 
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
David Newman
Sent: Wednesday, June 22, 2005 1:32 PM
To: [email-masked]
Subject: Re: [bmwg] possible additional term for
draft-ietf-bmwg-ipsec-term-05.txt

On Wed, 22 Jun 2005, Paul Hoffman wrote:

<many valid complaints about XAUTH deleted>

>> While this is mostly a methodology issue, there is no discussion of XAUTH

>> in the terminology draft. Certs are covered in the IKE discussion.
>
> I think that XAUTH cannot be discussed because it is not a standard. There

> are are lots of unbaked remote-access solutions that didn't move forwards
for 
> IPsec (and I say that as the co-chair of a working group that had one near

> completion before we gave up due to lack of interest).

Fair point, and frankly not one I'd considered. In its defense, XAUTH 
(unlike CAs) is not "poorly deployed." Its use is fairly widespread both 
among service providers and enterprises.

My concern, and this is really for the methodology doc, is that we end up 
with a tunnel capacity test using pre-shared keys only, thus allowing 
meaningless claims of support for umpity-poo tunnels when in production 
settings users get just a fraction of umpity-poo because XAUTH and/or 
certs come into play.

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: Wed, 22 Jun 2005 14:25:32 -0700 (PDT)

> Production Settings are clearly out of scope for BMWG:

The fact that we do our stuff in test labs and not on live networks does 
not absolve us of the responsibility of developing metrics that are 
meaningful, not only for device makers but also for end-users.

In the case of IPSec tunnel testing, there is clearly interest for 
implementers in testing the pre-shared key case alone. However, since 
customers may (and usually do) use auth methods other than pre-shared key, 
we should develop additional tests that will be meaningful predictors of 
device performance.

Nowhere in the charter does it say the bmwg's work should be divorced from 
the real world. I was interested to learn recently from Scott Bradner and 
Jim McQuaid that the traffic mesh patterns in 2544 are set up the way they 
are because Will Leland had provided them data from production networks 
showing overloads on egress ports.

dn

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jun 2005 15:26:17 -0700

At 2:25 PM -0700 6/22/05, David Newman wrote:
>implementers in testing the pre-shared key case alone. However, 
>since customers may (and usually do) use auth methods other than 
>pre-shared key, we should develop additional tests that will be 
>meaningful predictors of device performance.

If we can do that, great. If we can't, I think it's OK to write up 
the deficiency and punt.

In the case of XAUTH, you can't nail it down so you can't say how to 
measure it. For certs, you can let the IPsec community nail it down 
for you, like they are doing in the PKI4IPSEC Working Group.

...that has been running for over a year and has almost no interest 
and they can't really agree where you can and can't put CERT and 
CERTREQ payloads (that will affect benchmarking) and they can't 
really agree on what to do with cert chains (that will affect 
benchmarking) and they can't agree on RSA key sizes (that will affect 
benchmarking) and and and.

Sorry to be so cynical, but trying to say anything measurable about 
certificate use in IPsec is just plain silly. That's why VPNC has 
never done any certificate interop testing, and ICSA's stab at it has 
a humorously short list of vendors, many of whom will tell you that 
they would have preferred a sharp stick in the eye.

--Paul Hoffman, Director
--VPN Consortium

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 22 Jun 2005 17:01:05 -0700

The intent (although I haven't yet sync'ed up with other co-authors who 
will correct me if I'm wrong :)) was that the methodology doc wouldn't 
specify the actual authentication mechanism but would have language in 
place to make the choice available to use mechanisms other than 
pre-shared keys so that some real-world scenarios can be tested 
apples-to-apples should that come up.  The important part will be to 
ensure that all reporting information is consistent so everyone knows 
what was tested and can realistically compare results.

Remember that with EAP there are a zillion mechanisms to be 
used......and although IKEv2 is not in scope for this version, should 
some later version address IKEv2, that will have a similar issue (and 
XAUTH functionality was designed into the IKEv2 spec itself).

- merike

On Jun 22, 2005, at 3:26 PM, Paul Hoffman wrote:

>> customers may (and usually do) use auth methods other than pre-shared 
>> key, we should develop additional tests that will be meaningful 
>> predictors of device performance.
>
> If we can do that, great. If we can't, I think it's OK to write up the 
> deficiency and punt.
>
> CERTREQ payloads (that will affect benchmarking) and they can't really 
> agree on what to do with cert chains (that will affect benchmarking) 
> and they can't agree on RSA key sizes (that will affect benchmarking) 
> and and and.
>