Re: Last Call: IPSec DOI Proposed Standard

"Derrell D. Piper" <ddp@Network-Alchemy.COM> Thu, 23 April 1998 17:35 UTC

Return-Path: ddp@Network-Alchemy.COM
Received: from pleco.cisco.com (pleco.cisco.com [171.69.30.22]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28382 for <ippcp-archive-file@ftp-eng.cisco.com>; Thu, 23 Apr 1998 10:35:35 -0700 (PDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by pleco.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id KAA07198 for <extdom.ippcp@aliashost.cisco.com>; Thu, 23 Apr 1998 10:35:27 -0700 (PDT)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id KAA03470 for <ippcp@external.cisco.com>; Thu, 23 Apr 1998 10:35:24 -0700 (PDT)
Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id KAA13738 for <ippcp@external.cisco.com>; Thu, 23 Apr 1998 10:35:22 -0700 (PDT)
Received: from gallium.network-alchemy.com(199.46.17.139) by proxy2.cisco.com via smap (V2.0) id xma013729; Thu, 23 Apr 98 17:35:21 GMT
X-SMAP-Received-From: outside
Received: from gallium.network-alchemy.com (localhost.network-alchemy.com [127.0.0.1]) by gallium.network-alchemy.com (8.8.7/8.8.8) with ESMTP id KAA05830; Thu, 23 Apr 1998 10:31:30 -0700 (PDT) (envelope-from ddp@network-alchemy.com)
Message-Id: <199804231731.KAA05830@gallium.network-alchemy.com>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
cc: Avram Shacham <shacham@cisco.com>, "'iesg@ns.ietf.org'" <iesg@ietf.org>, ipsec@tis.com, ippcp@external.cisco.com
Subject: Re: Last Call: IPSec DOI Proposed Standard
In-reply-to: Your message of "Wed, 22 Apr 1998 22:37:16 EDT." <199804230237.WAA16620@dcl.MIT.EDU>
Date: Thu, 23 Apr 1998 10:31:29 -0700
From: "Derrell D. Piper" <ddp@Network-Alchemy.COM>

All,

The ISAKMP protocol defines the size of its Transform ID field as one octet.
The IPSEC DOI defines the legal values for this field when using IPSEC with
ISAKMP (as IPPCP does).  If IPPCP wants to use only six bits of the octet for
the compression transform identifier, that's fine, but it's still eight bits
on the wire in ISAKMP.  It can also be just six bits in the IPPCP protocol.

The current IPSEC DOI says that the values not defined in the IPSEC DOI are
reserved to IANA and that requests to IANA must be accompanied by a standards
track RFC, like IPPCP, that details the use of the requested allocation.

The only potential problem I see is that the IPSEC DOI does state that "the
values 249-255 are reserved for use private use amongst cooperating systems."
I will correct this in the next draft.

Derrell