[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on the latest Security architecture draft



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
Follow-Ups: