[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revised drafts -- Arch, AH, ESP
Pyda,
>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.
So the answer here is that, for now, you can support both TCP and UDP in
the same SA only by accepting ANY transport protocol in that SPD entry. To
do otherwise would require support for an enumerated list, a feature we
once had and then deleted due to concerns expressed by implementors, as
noted in my earlier message.
>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?
Section 4.4.2 requires security gateway support for the User ID name form
only for INBOUND SA processing. This is used to support mobile users with
dynamically assigned addresses. After SA creation, a temporary SPD entry
is created with the address of the mobile user (instead of the name), so
that subsequent traffic in both directions can be keyed off of the
IPaddress (and any other applicable selectors).
>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?
If one uses an automated key management protocol, the only one endorsed by
the IPsec WG is IKE. Thus it is the default. However, support for IKE is
not required for IPsec compliance.
>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").
Customary security policy is to reject any access that is not explicitly
authorized. The specified SPD processing is consistent with this policy. A
site can override this default by creating a final SPD entry that allows
for BYPASS of any packet, which then becomes the default action for a
packet that does not match any previous SPD entry.
Steve
Follow-Ups:
References: