Comments on the latest Security architecture draft
suresh@livingston.com (Pyda Srisuresh) Sun, 31 May 1998 15:42 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08098 for ipsec-outgoing; Sun, 31 May 1998 11:42:50 -0400 (EDT)
From: suresh@livingston.com
Message-Id: <199805311557.IAA15764@kc.livingston.com>
Subject: Comments on the latest Security architecture draft
To: kent@bbn.com, rja@corp.home.net
Date: Sun, 31 May 1998 08:57:30 -0700
Cc: ipsec@tis.com, suresh@livingston.com
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve and Ran, Below are my comments on <draft-ietf-ipsec-arch-sec-05.txt>. I would appreciate your responses. Thanks. 1. Section 3.2 - Last paragraph Is there a recommendation for key-encryption keys? 2. Secion 4.1. Defintion of an SA A Security Association(SA) is a triple of (Dest_Addr, SPI, security_protocol). Yet, the SPI number is fixed by the initiator and selected by the responder (refer ISAKMP and IKE documents). There is a problem with the above two statements to work together. Suppose there are 2 secure gateways (called SGW1 and SGW2) talking to the same target dest. Address (hereafter called target), using the same SPI number and same security protocol (say ESP). Surely, the target node should maintain 2 SAs with different sets of attributes (such as keys, SA lifetime etc..), one for traffic from SGW1 and another for traffic from SGW2. Yet, the triple of both these SAs on target is identical. When a packet arrives at the target node (from SGW1 or SGW2), how does the target know to distinguish which of the two SAs the packet belongs to? Comment: (a) The target needs to use Source address to find the right SA, in which case the SA would be 4-tuple. (A correction required to this draft) or, (b) The SPI number should be allowed to be fixed by the target, instead of SGW1 or SGW2. (This would require a correction to IKE/ISAKMP drafts) 3. Section 4.4.1. The Secure policy data base Outbound: You state that an SPD entry could spin off one or more SAs, depending on whether the source of the selector value is SPD entry or the packet itself. But, you do not mention the possibility of multiple SPD entries refering the same SA. ex: Say, the SA selector value is set to SPD entry (as opposed to pkt). And, say, you had the following 2 policies to set up an SA on a VPN node. 1. All TCP packets originating from Address X to Address Y 2. All UDP packets originating from an address range inlcuding X to Address Y I dont see why a single SA could not be used to securely tranfer packets matching either one of the above policies. Inbound: Likewise, I dont believe, you could make the assumption that a matching SA will have a single SPD entry that could be verified against for selector values. For the same reason I stated above, one ought to assume there could be a series of policies applicable to the same SA. 4. Section 4.4.2 - Selectors The "name" selector (in particular, the User ID) seems appropriate for an ISAKMP SA negotiation and not relevant to an IPsec SA negotiation. If so, I think, it would be a good idea to state this explicitly in the document. Also, where would you find a Data sensitivityy label on a V4 packet? Are you talking about the TOS field being used for this purpose? 5. Section 4.6.2: Automated SA and Key management: You say, IKE is a default key management protocol and mentin others such as kerberos and SKIP as a may be (elsewhere in the document). Is IKE a MUST or manadatory key management protocol? 6. Section 5.0 - Last sentence of the first paragraph: You state that a packet MUST be discarded, if no policy in SPD matches the packet, inbound or outbound. Why is this a MUST? This should be left to local administrator to determine the local default policy. For example, the local site could choose to send pakcets in clear, by default, if there is no matching policy in SPD. Thats all for now. have a nice day. cheers, suresh
- Comments on the latest Security architecture draft Pyda Srisuresh
- Re: Comments on the latest Security architecture … Matt Thomas
- Re: Comments on the latest Security architecture … Pyda Srisuresh
- Re: Comments on the latest Security architecture … C. Harald Koch
- Re: Comments on the latest Security architecture … Pyda Srisuresh
- Re: Comments on the latest Security architecture … tytso
- Re: Comments on the latest Security architecture … Pyda Srisuresh