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

Re: Revised drafts -- Arch, AH, ESP

> From owner-ipsec@portal.ex.tis.com Thu Jul  2 15:51:50 1998
> Message-Id: <199807022114.RAA18455@relay.hq.tis.com>
> Date:     Thu, 2 Jul 98 17:08:28 EDT
> From: Karen Seo <kseo@bbn.com>
> To: ipsec@tis.com
> cc: rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com,
>         kseo@bbn.com
> Subject:  Revised drafts -- Arch, AH, ESP
> Sender: owner-ipsec@ex.tis.com
> Precedence: bulk
> 
> Folks,
> 
> In follow-up to Thomas Narten's (IESG) feedback (see Ted Ts'o's email of
> 5/22/98) and subsequent email, we have submitted to the IETF secretariat
> revised versions of the following drafts:
>         o AH -- draft-ietf-ipsec-auth-header-06.txt
>         o ESP -- draft-ietf-ipsec-esp-v2-05.txt
>         o Architecture -- draft-ietf-ipsec-arch-sec-05.txt
> 
> A summary of the changes that were made is attached below.
> 
> Karen
<... snip>

Karen,

    I posted a list of queries a while back to this list. Some of these 
were responded to and others were not. I would appreciate if you could 
respond to the following and update the "Security Architecture" draft 
as necessary with the responses.

1. Sections 4.4.1 and 4.4.2 - Secure Policy data base and selectors

   The policy selectors such as source Address, Destination Address, 
   Transport Layer Protocol, Transport port no. etc. are allowed to 
   be either discrete numbers or a wildcard; Nothing in between.
   Yet, there is no mention of multiple SPD entries using the same SA. 
   (For example, how do I create a policy that uses a single SA to 
   encrypt TCP and UDP packets?)

   I believe, the following posting from Stephen Kent answers this.
   But, this needs to be documented, considering that the restriction 
   stated will likely be reviewed for removal in IPsecond.

   X-Sender: kent@po1.bbn.com
   Date: Mon, 29 Jun 1998 18:12:48 -0400
   To: avs@winner.lc.lucent.com
   Subject: Re: A question about SPD selectors
   Cc: ipsec@tis.com
   Sender: owner-ipsec@ex.tis.com
   Precedence: bulk
	
   Some time ago we agreed to simplify the selector types and removed some
   options, to make the SPD selectors align with the IKE payload ID types.
   That's why we limit the address choices, in part.  In IPSecond it may be
   possible to remove some of these restrictions, if corresponding changes to
   IKE are made.
	 
2. Section 4.4.2 - Name Selectors

   The User ID based name selector does not seem appropriate for an 
   IPsec SA selection. For example, a VPN router, trying to select
   an SA for forwarding the packet cannot know if the packet is
   originating from a certain user. It can only make a decision 
   based on the contents within IP and transport layer headrs. 
   In other wirds, the selection criteria has to boil down to
   fields you could match against in IP and transport headers.
   Does this make sense? Can you comment on this?

3. Section 4.6.2: Automated SA and Key management:

   IKE is specified as the default key management protocol, while 
   protocols such as kerberos and SKIP are mentioned (elsewhere in 
   the document) as other possible key managment protocols. What 
   does "default key management protocol" mean here? Is IKE a 
   manadatory key management protocol?

4. Section 5.0 - Last sentence of the first paragraph:
 
   The draft states 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.
   (May be, all you need to do is lower the case of "MUST" to "must").

Thanks.

cheers,
suresh
Follow-Ups: References: