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

"Hickman, Brooks" <brooks.hickman@spirentcom.com> Thu, 29 April 2004 19:13 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 PAA21051 for <bmwg-archive@lists.ietf.org>; Thu, 29 Apr 2004 15:13:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhG-0003ny-B0; Thu, 29 Apr 2004 14:55:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFfg-0006rj-L1 for bmwg@optimus.ietf.org; Thu, 29 Apr 2004 13:50:04 -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 NAA16518 for <bmwg@ietf.org>; Thu, 29 Apr 2004 13:50:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFfa-0006xC-VL for bmwg@ietf.org; Thu, 29 Apr 2004 13:49:59 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFeS-0006b8-00 for bmwg@ietf.org; Thu, 29 Apr 2004 13:48:48 -0400
Received: from smtp.spirentcom.com ([199.1.46.14] helo=exch-connector.netcomsystems.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFdk-0006Dn-00 for bmwg@ietf.org; Thu, 29 Apr 2004 13:48:04 -0400
Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2655.55) id <H54R7V9W>; Thu, 29 Apr 2004 10:47:37 -0700
Message-ID: <629E717C12A8694A88FAA6BEF9FFCD4405779FBD@brigadoon.spirentcom.com>
From: "Hickman, Brooks" <brooks.hickman@spirentcom.com>
To: "'bmwg@ietf.org'" <bmwg@ietf.org>
Date: Thu, 29 Apr 2004 10:47:35 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
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
Subject: [bmwg] draft-ietf-bmwg-ipsec-term-03.txt
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>

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.

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.

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
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."

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."

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.

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




 





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