Subject: RE: [bmwg] Terminology for Benchmarking IPSec Devices Work Propos al

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 22 Jan 2003 13:54:51 -0800

> While this proposal is a first draft, I would like to see a 
> revised proposal
> with the following considerations:
> -I think it is impractical to rewrite the proposal, however your valid
> comments can be incorporated into the actual draft(s).  See below:

While it may be impractical, it was a suggestion that may help this work
become a BMWG draft versus an individual draft.  You will be doing a lot of
revising.  Weather you chose to do it in the beginning or toward the end is
your decision.  This comment was to point you to the easier path.
 
> 1. IPv6!  There has been a lot of implementation of IPv6.  At 
> Yokohama, we
> had a presentation on IPv6 experiences from users.  We should 
> not exclude
> IPv6 from any new work.
> -We feel that metrics/methodology do not change with Ipv6.  
> -We do NOT preclude IPv6. For a first draft terminology 
> document, this is
> irrelevant.

To quote second paragraph of your proposal "At this time, any testing that
pertains to IPv6 is out of scope, ..."  You need to explain the difference
between "IPv6 is out of scope" and "We do NOT preclude IPv6".  I find the
two statement contradict.  The Authors should come to a general consensus on
IPv6 support before proposing a draft.

As for "irrelevant", you have a growing IPv6 community you are excluding.
At what version of the draft are you planning to include them?

> 2. What different metrics, methodologies are being 
> introduced?  Why not just
> use RFC1242, RFC2289, or RFC2432?  The table of Contents looks like a
> laundry list of everything done before with the word IPSEC 
> prefixed.  The
> only thing I found missing was Differentiate Services.
> -Methodology is beyond the scope of a terminology document. 
> -We are working on a methodology draft, in accordance with 
> BMWG tradition,
> as a separate proposal. 
> -The proposed draft is, obviously, based on prior IPSec work. 
> We are NOT
> trying to redefine the IPSec protocol terms. However, the 
> draft defines the
> terms specific to "benchmarking IPSec devices". 

Metrics?  Or is this just RFC1242 over IPSEC (or a secure Network
Interconnection Device)?

If you look at BMWG tradition, you will see that they do not list all the
protocols they are testing over.  For example RFC2432 (and the draft
methodology) just measures encapsulation throughput.  They do not list each
type of encapsulation.  How is testing NULL encryption (section 5.21.1)
throughput (section 6.3.1) any different than DES-CBC, 3DES-CBC, or AES-CBC?

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

---

From: Tim Van Herck <[email-masked]>
Date: Wed, 22 Jan 2003 16:14:38 -0800

Jerry,

COMMENTS INLINE ...

 >>revised proposal with the following considerations:

 > While it may be impractical, it was a suggestion that may help this
 > work become a BMWG draft versus an individual draft.  You will be
 > doing a lot of revising.  Weather you chose to do it in the beginning 
 > or toward the end is your decision.  This comment was to point you to
 > the easier path.

The intention is to develop this I-D under the BMWG umbrella rather then
submitting it as an individual draft and as such we're seeking for as
much feedback as possible at the very start of writing the document so
we have at the very minimum absorbed all content related comments into 
the draft.

In short, point taken ... bring on the comments !

 >>Yokohama, we had a presentation on IPv6 experiences from users. We
 >>should not exclude IPv6 from any new work.
 >>-We do NOT preclude IPv6. For a first draft terminology document, 
this >>is irrelevant.

 > To quote second paragraph of your proposal "At this time, any testing 
 > that pertains to IPv6 is out of scope, ..."  You need to explain the
 > difference between "IPv6 is out of scope" and "We do NOT preclude
 > IPv6".  I find the two statement contradict.  The Authors should come
 > to a general consensus on IPv6 support before proposing a draft.

Note that this paragraph was sent out before you brought up the topic !
Initially we wanted to focus on IPv4 IPSEC devices since we didn't see
an immediate need for IPv6 IPSEC benchmarking. After looking at it a
second time and knowing that future drafts should take IPv4&6 into
account, we decided to incorporate IPv6 BUT functionally there will be
no difference between IPv4 and IPv6 IPSEC operation. So in essence IPv6
IPSEC benchmarking will be an extrapolation of IPv4 benchmarking. So the 
direction we will take now is to describe IPv4 IPSEC benchmarking and 
point out all diffs wrt IPv6 and clarify where required.

 > As for "irrelevant", you have a growing IPv6 community you are
 > excluding. At what version of the draft are you planning to include
 > them?

It's irrelevant in the sense that there is no functional difference !
Yes, you are right that there is a growing IPv6 community out there but
as far as I know any deployments of IPSEC with IPv6 are still in an
academic stage and there is still a lot of design efforts going on in 
that area.

 >>introduced?  Why not just use RFC1242, RFC2289, or RFC2432? The table
 >>of Contents looks like a laundry list of everything done before with
 >>the word IPSEC prefixed.  The only thing I found missing was
 >>Differentiate Services.
 >>-We are working on a methodology draft, in accordance with BMWG
 >>tradition, as a separate proposal.
 >>We are NOT trying to redefine the IPSec protocol terms. However, the
 >>draft defines the terms specific to "benchmarking IPSec devices".

 > Metrics?  Or is this just RFC1242 over IPSEC (or a secure Network

As you know IPSEC is a vast collection of RFC's. What the terminology 
draft will do is define all elements out of those RFC's on a very high 
level so testengineers will know what metrics, parameters are important 
wrt IPSEC benchmarking. This will be the basis for a methodology draft 
that will describe in detail on how to execute various tests.

To answer your question, yes, half the document will look like a remake 
of RFC1242 applied to IPSEC secured link, the other half will be a brief 
description of IPSEC terminology. Again, consider this as an 
informational document paving the road for a methodology doc.

 > If you look at BMWG tradition, you will see that they do not list all 
 > the protocols they are testing over.  For example RFC2432 (and the
 > draft methodology) just measures encapsulation throughput.  They do
 > not list each type of encapsulation.  How is testing NULL encryption
 > (section 5.21.1) throughput (section 6.3.1) any different than
 > DES-CBC, 3DES-CBC, or AES-CBC?

No different, you're right there ! And yes, maybe describing the cyphers 
is a little too detailed for the scope of the document.

	Regards,
	Tim-

---

From: Tim Van Herck <[email-masked]>
Date: Wed, 22 Jan 2003 16:14:38 -0800

Jerry,

COMMENTS INLINE ...

this >>is irrelevant.

	Regards,
	Tim-

---

From: "David Newman" <[email-masked]>
Date: Wed, 22 Jan 2003 16:47:48 -0800

> is a little too detailed for the scope of the document.

This raises another issue. There needs to be a bright yellow line separating
performance benchmarks of IPSec devices (clearly in scope for bmwg) from
assessments of cryptographic strength or implementation correctness (far out
of scope).

dn

---

From: "David Newman" <[email-masked]>
Date: Wed, 22 Jan 2003 16:47:48 -0800

dn

---

From: Tim Van Herck <[email-masked]>
Date: Wed, 22 Jan 2003 16:57:31 -0800

David,

> assessments of cryptographic strength or implementation correctness (far out

ABSOLUTELY ! We're not touching cypher strength testing, only 'packet 
forwarding' related performance metrics are on the menu.

	Tim-

---

From: Tim Van Herck <[email-masked]>
Date: Wed, 22 Jan 2003 16:57:31 -0800

David,

	Tim-

---

From: Rick Jones <[email-masked]>
Date: Wed, 22 Jan 2003 17:24:47 -0800

> forwarding' related performance metrics are on the menu.

Probably beyond scope of the Terminology rfc and more for Methodology,
but it would be goodness to have some strongly worded caveats about
"never" making competitive comparisons when the cypher being used isn't
the same. One thing if it is different cyphers in the same
box/product/solution/pickyour term, but another if it is crossing vendor
boundaries.

Or perhaps I'm thinking too much with my SPEC-like hat on... :)

rick jones
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Rick Jones <[email-masked]>
Date: Wed, 22 Jan 2003 17:24:47 -0800

rick jones

---

From: Tim Van Herck <[email-masked]>
Date: Wed, 22 Jan 2003 18:43:18 -0800

Rick,

> Or perhaps I'm thinking too much with my SPEC-like hat on... :)

Not at all !! This makes sense and is a mandatory item to report 
together with your obtained performance results.

If you look at our preliminary TOC you will see that we have defined 
something called a 'security context'. This will encompass parameters of 
the path that the tunnel is established over as well as an extensive set 
of IKE/IPSEC related parameters that will describe the tunnel behavior 
and it's impact on the secured traffic flow.

Hope that eases your concern and makes you sleep better tonight ;-)

	Tim-

---

From: Tim Van Herck <[email-masked]>
Date: Wed, 22 Jan 2003 18:43:18 -0800

Rick,

	Tim-