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

RE: IKEv2 traffic selector subsetting.



At 2:55 AM -0500 12/14/01, Andrew Krywaniuk wrote:
>To add to this conversation, I would like to debunk this myth that the IPsec
>SADB selectors need to match the IPsec policy.
>
>The SPD, not the SADB, is supposed to enforce IPsec policy. As someone
>noted, it does no good to repeat the information in the SPD in the SA
>selectors, since that traffic will be filtered out by the SPD anyway. If you
>wish to avoid sending traffic that will be filtered out by the peer then
>that would be best accomplished by an IPSP protocol.
>
>The point of the phase 2 selectors is to enforce that (often ignored) 3rd
>aspect of network security: authorization. We want to bind the phase 2
>selectors to the phase 1 identity so that authenticated peers cannot
>impersonate each other. The use of the phase 2 selectors allows the
>per-packet SPD check to proceed without consulting the SADB (because the
>initial SADB check is sufficient for verifying that the phase 1 id is
>appropriate).
>
>This is an *OPTIMIZATION*. It is feasible to negotiate wildcard SAs (or
>transport mode SAs for an IP-in-IP tunnel) *iff* you do a phase 1 identity
>check on every packet (i.e. pass the SA context information up the stack).

I think this is a critical optimization, and in the next rev of 2401, 
I plan to use a processing model that caches selector info from a 
(de-correlated) SPD. Searching the SPD for each new outbound packet, 
or for inbound packets after processing, is not attractive (maybe not 
even feasible) at very high speeds.

>
>Port-constrained SAs make sense in the case of a multi-user UNIX machine
>where the phase 1 id associated with port FOO is not necessarily the same as
>the id on port BAR. Port-constrained selectors are NOT the best mechanism
>for implementing packet filtering. In the vast majority of VPN scenarios, a
>list of subnets would be appropriate for expressing phase 2 selectors.

I disagree. Port filtering is appropriate in IPsec for the same 
reasons it is appropriate in a firewall, i.e., a reasonable security 
policy may wish to constrain traffic from a specified source to a 
specific destination relative to a set of services offered by the 
destination. So, for example, I may wish to bypass traffic from any 
outside source directed to my SMTP server, but I want all such 
traffic to be SMTP traffic, to reduce the likelihood that the server 
can be attacked by external sources sending other types of traffic.

Steve


Follow-Ups: References: