Re: [bmwg] draft-ietf-bmwg-ipsec-term-03.txt

Tim Van Herck <herckt@cisco.com> Fri, 07 May 2004 21:39 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22406 for <bmwg-archive@lists.ietf.org>; Fri, 7 May 2004 17:39:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCw1-0000F5-3k; Fri, 07 May 2004 17:31:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCsG-0007Sf-Ig for bmwg@optimus.ietf.org; Fri, 07 May 2004 17:27:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21902 for <bmwg@ietf.org>; Fri, 7 May 2004 17:27:12 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMCsD-0004CL-Sd for bmwg@ietf.org; Fri, 07 May 2004 17:27:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCrQ-0003mE-00 for bmwg@ietf.org; Fri, 07 May 2004 17:26:25 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BMCql-0003IM-00 for bmwg@ietf.org; Fri, 07 May 2004 17:25:43 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 13:28:43 +0000
Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47LPAC1013183; Fri, 7 May 2004 14:25:10 -0700 (PDT)
Received: from cisco.com (macedon-alpha-10-34-41-193.cisco.com [10.34.41.193]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ASD16628; Fri, 7 May 2004 14:23:24 -0700 (PDT)
Message-ID: <409BFEB4.7090306@cisco.com>
Date: Fri, 07 May 2004 14:25:08 -0700
From: Tim Van Herck <herckt@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hickman, Brooks" <brooks.hickman@spirentcom.com>
CC: "'bmwg@ietf.org'" <bmwg@ietf.org>
Subject: Re: [bmwg] draft-ietf-bmwg-ipsec-term-03.txt
References: <629E717C12A8694A88FAA6BEF9FFCD4405779FBD@brigadoon.spirentcom.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

	Brooks,

> I have been reading over the IPSec Terminology document and have a few
> comments/suggestions. I am by no means an expert on IPSec, so if I am
> mistaken on any on the items below, please let me know.

Thanks for taking the time to read through it !

> 7.7.1 IKE Tunnel
> Definition:
> One simplex Phase 1 IKE SA
> The definition states "One simplex Phase 1 IKE SA". I thought that Phase 1
> tunnels are always bi-directional. The term "simplex" in the definition
> implies one direction. Would suggest removing the word simplex from the
> definition.

You have a point ! What we meant to say is that the IKE SA is set up 
from one node to another in a simplex fashion but that it allows 
bidirectional communication.

We'll change it to 'One Phase 1 IKE SA which allows bidirectional 
control plane communications between two IPSEC devices.'

> 7.7.3 Tunnel
> Issues: 
> If only a single Phase 2 SA or more then two Phase 2 SA's have been
> negotiated through a single IKE Tunnel, then this specific ratio must be
> mentioned and the term 'Tunnel' MUST NOT be used in this context. 
> 
> If I am not mistaken, I believe the verbiage is to cover the case where
> anything other than one IPSec Tunnel is configured for each direction. If

That is correct.

> so, what if I have two Phase 2 SA's configured in the same direction. I
> could use the term "Tunnel" in this case. Also, should the first occurrence
> of "must" in the sentence be upper case or lower case? Suggest something
> along the lines of:
> If other than a single Phase 2 SA, for each direction, have been negotiated
> through a single IKE Tunnel, then this specific ratio MUST be mentioned and
> the term 'Tunnel' MUST NOT be used in this context."

Yes, we have to be slightly more specific that this is about SA's 
negotiated for EACH direction. And your verbiage is much more to the 
point. We'll replace it.

> 7.7.3 Active Tunnel
> Definition:
> A tunnel that has completed Phase 1 and Phase 2 SA negotiations and is
> transmitting data. 
> Suggest:
> "A tunnel that has completed Phase 1 and Phase 2 SA negotiations and is
> forwarding data."

Agreed, we'll incorporate that suggestion !

> 10.3.2 IPSec Tunnel Encryption Frame Loss Rate
> 10.3.3 IPSec Tunnel Decryption Frame Loss Rate
> Both the definition and unit of measurement in sections 10.3.2 and 10.3.3
> are terms of a percentage, not a rate. The unit of measurement is not "n
> packets/second". While I realize that this is basically carrying over the
> term defined in RFC1242(Section 3.6), I think that the rate should be
> dropped from the term in both cases.

Again, I agree, We'll drop the 'rate' and set the measurement units in % 
dropped of offered frames.

> In addition, were there any plans to add tunnel(Phase I and Phase 2)
> establishment time to the terminology document.

If you're asking tunnel setup rates (which is the inverse of a tunnel 
setup/establishment time) then it is already available in the 
terminology document. If the question is, if we intend to complete the 
blanks in those definitions, then the answer is yes !

	Thanks,
	Tim-


_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg