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

RE: IKEv2 traffic selector subsetting.



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

Well, I think you misunderstood which aspect of the processing was an
optimization. In the paragraph you responded to, I said that the use of the
selectors for IP-id binding was an optimization. Yes, cacheing the SPD is
another optimization, but it doesn't rely on negotiating the phase 2
selectors for its effectiveness.


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

I don't disagree that port filtering is appropriate; I just disagree with
your model. I think it's an SA to a specific destination with a
port-constrained policy. One implementation of this model could be an SA
with a back-reference to a decorrelated SPD entry. Another is a
topology-aware IPsec layer with a completely separate firewalling module.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent
> Sent: Monday, December 17, 2001 4:38 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: 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: