IPSEC Comments
Paul_Lambert-P15452@email.mot.com Tue, 11 April 1995 01:55 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14068; 10 Apr 95 21:55 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14064; 10 Apr 95 21:55 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa18355; 10 Apr 95 21:55 EDT
Received: by interlock.ans.net id AA35765 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Apr 1995 21:51:54 -0400
Message-Id: <199504110151.AA35765@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 10 Apr 1995 21:51:54 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 10 Apr 1995 21:51:54 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 10 Apr 1995 21:51:54 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul_Lambert-P15452@email.mot.com
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 21:51:54 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 21:51:54 -0400
Date: Mon, 10 Apr 1995 18:49:00 -0500
To: ipsec@ans.net
Cc: ipsec@ans.net
Subject: 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 --------------------------------------------
- IPSEC Comments Paul_Lambert-P15452