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

Re: Revised drafts -- Arch, AH, ESP




Thanks, Steve, for your responses. Additional comments below.

cheers,
suresh
> 
> 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.
> 

Got it. All I was asking was to state in the draft that there was a 
consideration to include a discrete list of individual entries, ranges
and blocks of entries, but has been dropped for the time being for ease
of implementation and to be in line with IKE and IP DOI  drafts.

If you dont add the clarification, you will continue to be asked the same 
types of questions on the subject over and over even after the draft is 
progressed into an RFC.

> >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).
> 
OK, I get it now. Thanks. 
Once again, I think, it would be useful to add the clarification to the
draft.

> >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.
> 

OK. That clears it up. I asked the question because even the basic ICSA 
certification 1.0 requires support for IKE. IPsec compliant, policy based,
manually configured SAs are not certifiable from ICSA. Yes, I do realize, 
ICSA is different from IETF. 

> >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.
> 

OK, I understand what you say. I was only objecting to the use of MUST
(as in RFC 2119).

> Steve
> 
> 
> 
cheers,
suresh


Follow-Ups: References: