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

RE: IKEv2 traffic selector subsetting.

On Sun, 23 Dec 2001, Andrew Krywaniuk wrote:
> > [the IPsec specs] basically include a specification for an
> > Internet-standard minimum firewall mechanism.
> 
> Which brings us right back to the original point of the thread. Traditional
> firewalls enforce a policy without advertising it.

Indeed so.  And based on our experience with FreeS/WAN, this is *easily*
the biggest single source of confusion for people trying to get IPsec
working:  their IKE or ESP packets don't get through, they don't know why,
and there's no easy way to troubleshoot it, because it's a firewall
configuration problem.

We should be trying to reduce the number of places where such unannounced
non-negotiable policy can block packets, not adding yet another.

> IPsec SPD firewalls add
> this extra 'selector negotiation' feature. However, the IPsec selectors are
> not adequate to express the entire spectrum of what a fully featured
> firewall can use.

Indeed they don't, but they provide a highly useful subset.

> I prefer the model in which each side merely enforces its
> own policy.

How is that policy arrived at?  By manual configuration?  That's fine for
a VPN environment, where all tunnels are essentially preconfigured, but
not all IPsec applications are VPNs.  And even when manual configuration
is practical, it's grossly error-prone. 

> If you desire the capability to detect and avoid black holes (a feature not
> found in traditional firewalls), then it would be preferable for both peers
> to issue ukases describing what types of traffic they are willing to accept.

I'm having trouble envisioning how this would work, especially in a
non-VPN environment where the policies are quite generic and what's
permissible on a specific tunnel has to be inferred.  It sounds
complicated, and I don't see the benefit.  It seems far simpler for one
side to say what it wants and have the other side say "yes" or "no". 

> This avoids the aforementioned problem where the responder chooses selectors
> that don't match the triggering packet...

If the responder says "yes" to the initiator's request, then it should set
up selectors which match the initiator's request!  Anything else is a bug.
If the responder cannot comply *fully* with the request, its answer should
be "no".

> ...and it makes it easy to add or
> delete policies without renegotiating the SA.

And thus easy to break the tunnel without notifying the other end, which
is exactly what some of us want to avoid.

                                                          Henry Spencer
                                                       henry@spsystems.net
Follow-Ups: References: