[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC Comments
Attached are my comments on the 5 IPSEC documents
draft-ietf-ipsec-arch-00.txt
draft-ietf-ipsec-esp-00.txt
draft-ietf-ipsec-esp-des-cbc-03.txt
draft-ietf-ipsec-auth-00.txt
draft-ietf-ipsec-ah-md5-02.txt
Regards,
Paul A. Lambert
--------------------------------
Comments on the March 1995 IPSEC Last Call
The following are comments on the March 1995 last call documents in the IPSEC
working group:
draft-ietf-ipsec-arch-00.txt
draft-ietf-ipsec-esp-00.txt
draft-ietf-ipsec-esp-des-cbc-03.txt
draft-ietf-ipsec-auth-00.txt
draft-ietf-ipsec-ah-md5-02.txt
Notes on Comment Types:
Major Technical - indicates that the documented flaw MUST be fixed
prior to advancing the specification.
Minor Technical - indicates that the documented flaw SHOULD be fixed
prior to advancing the specification.
Major Editorial - indicates that the editorial recommendations MUST be
made prior to advancing the specification
Minor Editorial - editorial suggestions that SHOULD be incorporated.
--------------------------------------------
Comment Type: Major Editorial
Location: all
Comments: The draft specification have redefined the Security Association
Identifier (SAID) field to be a "Security Parameter Index" field. There is
considerable existing architectural work in others standards activities
defining the SAID and its usage. The documents would benefit from an alignment
with this work.
Recommendation: Change all occurrences of SPI to SAID. Use SAID definition
from IEEE 802.10.
--------------------------------------------
Comment Type: Major Technical
Location: draft-ietf-ipsec-esp-00.txt section 3.1
Comments: The reserved ranges of the SPI/SAID field are defined as:
> The set of SPI values in the range 0x00000001 though 0x000000FF
> are reserved to the Internet Assigned Numbers Authority (IANA) for
> future use.
Reserved values have been proposed for several purposes including some for
multicast mechanisms. A larger range should be provided for
reserved/experimental usage.
Recommendation: Only the SPI/SAID values between 0x00000100 and 0x07FFFFFF
should be allowed for pair-wise SAID assignment. All others (should be
reserved for now. Replace text with:
The Security Association Identifier (SAID) field is a 32 bit value identifying
the security association for the datagram. The SAID value of 0x00000000 is
used to indicate that no SAID is available for the source and destination.
SAID Value SAID Usage
----------------------------------------------------
0x00000000 Used to indicate no SAID
assigned to destination.
0x00000001 to 0x000000FF Reserved for future use.
0x00000100 to 0x07FFFFFF Selected by implementations
to identify a unique Security Association.
0x08000000 to 0xFFFFFFFF Reserved for future use.
The reserved SAID values are assigned by the Internet Assigned Numbers
Authority (IANA). A reserved SAID value will not normally be assigned by IANA
unless the use of that particular assigned SPI value is openly specified in an
RFC.
--------------------------------------------
Comment Type: Major Technical
Location: draft-ietf-ipsec-esp-00.txt section 3.1
Comments: The use of the zero SAID is not adequately defined. More detail on
it's usage should be provided, or the mechanism should be removed. When the
SAID is zero, what does the rest of the packet look like? What is the
processing that accompanies this packet. When is a zero SAID sent (versus a
ICMP message).
Recommendation: Define the zero SAID to be experimental for use as a no SA
indicator. Add usage text or remove mechanisms after interoperability testing.
--------------------------------------------
Comment Type: Major Technical
Location:
draft-ietf-ipsec-arch-00.txt
draft-ietf-ipsec-esp-00.txt
Comments: The ESP/IPSP specification do not adequately document the way the
protocol must examine all traffic passing through the network layer. This
"packet filtering" functionality is essential to a "strict" security policy
that limits non-protected communications.
Recommendation: Include a description of the filtering functionality in
ESP/IPSP and/or the architecture document. A possible figure for this
description is:
+------+ +-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... | |Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+
| | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| TCP | | UDP | ... | ... | | TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
+--------------------------+----+ - - - - | - - - - | - - - - | +
| IP Security Protocol | [f] [f] [f] |
+-------------------------------+ - - - - | - - - - | - - - - | +
| | | |
+---------------------------------------------------------------------+
| Internet Protocol |
+---------------------------------------------------------------------+
|
+-----------------------------------------------------------------+
| Local Network Protocol |
+-----------------------------------------------------------------+
--------------------------------------------
Comment Type: Major Editorial
Location:
draft-ietf-ipsec-esp-00.txt
draft-ietf-ipsec-esp-des-cbc-03.txt
Comments: The splitting of the mandated transforms from the "esp"
specification makes the documents more difficult to read. The base protocol
specification should include the mandated transform(s) and serve as the
template for future optional transform specifications.
Recommendation: Merge transforms documented in "draft-ietf-ipsec-esp-des-cbc-
03.txt" into appendix of "draft-ietf-ipsec-esp-00.txt".
--------------------------------------------
Comment Type: Major Technical
Location:
draft-ietf-ipsec-esp-00.txt
draft-ietf-ipsec-esp-des-cbc-03.txt
Comments: The current mandated ipsec-esp security transform only provides
confidentiality services. This transform is subject to possible threats based
on the replay, reflection, or modification of packets. The "mandatory
transform" should include integrity services.
Recommendation: In the merged ESP/IPSP specification include a mandatory
transformation that provides both confidentiality and integrity services.
As a suggestion, this transformation should be based on DES-CBC with either a
ones complement (Fletcher) checksum or use of MD5.
--------------------------------------------
Comment Type: Major Editorial
Location:
draft-ietf-ipsec-esp-00.txt
draft-ietf-ipsec-esp-des-cbc-03.txt
Comments: The working group has had the goal of providing a simple
encapsulation mechanisms that supports various algorithms and security
services. The goals had been to document baselines for security transforms to
support confidentiality, integrity, and confidentiality with integrity.
Recommendation: In the merged ESP/IPSP specification three transformations
should be described: DES-CBC, Keyed-MD5 (or other integrity only), and DES-
CBCwith Integrity. At a minimum, the DES-CBCwith Integrity should be mandated
as a MUST implement (given the current IETF direction for security in IPv6).
--------------------------------------------
Comment Type: Major Editorial
Location:
draft-ietf-ipsec-arch-00.txt section 6
Comments: Unnecessary editorial
Recommendation: Remove last three paragraphs. Replace with:
Protection from traffic analysis is outside the scope of this specification.
--------------------------------------------
Comment Type: Minor Editorial
Location: draft-ietf-ipsec-arch-00.txt (section 1.1 par. 1)
Comments: Should reference ISO 7498/2
Recommendation: add ISO 7498/2 to references
--------------------------------------------