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

Auto filter rule generation for Phase 2 tunnels

>From what I understand, the typical implementation of Phase 2 tunnels involves
creating filter rules that describe the P2 tunnels.  While this is not
necessary, the use of the filter rules makes it easy to quickly associate a
packet with a tunnel using well-established techniques.  Here is my question.

Suppose a tunnel T1 is set up from subnet A inside one organization, through
Firewall A, through the Internet, through Firewall B of another organization,
to subnet B inside the second organization.  Say this tunnel is from host A1 on
subnet A to host B1 on subnet B.  A filter rule can be set up for this tunnel,
to admit packets from A1 to B1, via the tunnel T1.  Now, suppose a second
tunnel T2 is set up between these two subnets, admitting packets from *Subnet
A* to *Subnet B*.  Say T2 has different Security Parameters.  Now what does the
filter rule table look like?  If you did this right, in this simple case, you'd
like to keep Rule 1 before Rule 2.

But you can see where this goes.  The filter rules have at least two-tuples
(src IP addr, dest IP addr), or more generally, ([src IP addr, netmask], [dest
IP addr, netmask]).  There isn't an obvious total ordering, since src netmasks
have one ordering which may not match the destination netmask ordering.

Now we could have a policy that says the filter rules stay in the order in
which they were created, or we always sort only on the [destination IP addr,
netmask], or whatever.  However, if we don't have something that is common to
all implementations, then A could set up 2 tunnels with B, and when they want
to use the tunnels, it is possible that packets from tunnel 1 will match filter
rule 2, and get associated with tunnel 2.  Then the Security parameters would
not match, and packets can get discarded, which will probably lead to much
dissatisfaction all around.

Of course, we don't really need filter rules.  We can parse each packet on an
individual basis, and match all the parameters (including Security Parameters)
in the packet with a tunnel.  In effect, you use the filter rule, find a match,
get the Security Parameters of the associated tunnel, see if the Security
Parameters match, and call it a filter rule mismatch if they don't.  Then you
go on to the next rule.

This won't work with two tunnels that have the same Security Parameters,
though, unless you proceed to the next level of authentication, and see if the
authentication fails, call it a rule mismatch.  That's going to be very
expensive!  You could have two tunnels with the same Security Parameters if the
subnets they protect are not mergeable.  E.g., if one tunnel is host to host,
and the other is subnet to subnet, then they are mergeable.  If one tunnel is
from a subnet 4 bits wide to a subnet 8 bits wide, and the other from a subnet
5 bits wide to a subnet 7 bits wide, then by merging into one rule that is from
subnet 5 bits wide to subnet 8 bits wide, we allow more hosts to use the
tunnels than were originally allowed.

Vach Kompella
IBM Corp.
Network Security Product Development
kompella@us.ibm.com
Ph.: (919) 254-7281
Fax: (919) 254-4239
Follow-Ups: