[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auto filter rule generation for Phase 2 tunnels
Vach, look at the comments inserted into original message.
-----Original Message-----
From: Vach Kompella <kompella@us.ibm.com>
To: danmcd@Eng.Sun.Com <danmcd@Eng.Sun.Com>; rpereira@TimeStep.com
<rpereira@TimeStep.com>; naganand@BayNetworks.COM
<naganand@BayNetworks.COM>; rob.glenn@nist.gov <rob.glenn@nist.gov>;
ipsec@tis.com <ipsec@tis.com>
Date: 18 ноября 1997 г. 20:27
Subject: Auto filter rule generation for Phase 2 tunnels
[deleted stuff ...]
: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.
^^^^^^^^^^^^^^^
After a tunnel has been set up, the incoming packets (to the end-point of
tunnel)
get associated with that tunnel based on SPI + tunnel address values found
in
ESP/AH headers. After stripping out ESP/AH headers you have all information
to
check the packet parameters against the policy applied for particular SA.
For a packet possibly entering a tunnel there is no SPI value available
from
the packet itself, since it is not yet converted into IPsec format.
But, once you have taken the right decision to map the first packet of a
network connection to particular SA, consequent traffic can be filtered
much easier. Just apply hash function over packet headers' fields and get
the index into SAs database.
:
: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.
^^^^^^^^^^^^^^
Consider ports-range as part of a high-level rule to make your
life even more difficult ;-)
:
: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.
^^^^^^^^^^^^
To solve _this_ problem you should tune you implementaion to employ
variable netmasks when discriminating security policy against
source/destination IP addresses from the network packet.
It means you should look even on a stand-alone address as on subnet
0 bits wide. Your target is to find the least enclosing registered
subnet for IP address being checked. Thus you will find the _object_
an IP address belongs to.
I can provide with number of algorithms to do that.
In turn, any brand IP routing software also does this job.
: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.
^^^^^^^^^^^^^
For IPsec formatted ( read incoming) packet, if you have found that SPI
matches to the one from a 'rule', but security parameters do not - drop the
packet.
For a plain IP (read outgoing) packet you have nothing of security
parameters in the
packet itself to perform _your_ checking!
:
: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
^^^^^^^^^^^
Do you mean 'the same SPIs' here? - if yes, it gonna be the same tunnel!
: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.
^^^^^^^^^^^
As Michael Richardson wrote there should be a way to distinguish traffic
of 4 bits <-> 7 bits wide subnets from both registered tunnels!
Well, this is interesting problem. Probably the following would work:
1. Since a tunnel is negotiated _before_ the using both parties become
aware of subnets on it ends.
In your case, the following subnets are registered to start play:
4,5 on the one end and 8,7 on the other.
2. Assume, two tunnels (SAs) has been registered, namely 4-8 and 5-7
3. Now, if a packet is going from 4 to 7 it must be discarded at the
tunnel start until corresponded SA (4-7) will be explicitly negotiated.
The explanation follows.
4. By using discriminating search an implementation at the tunnel start
might find the rule 4-8 as seemingly matching to correct parameters for
a packet from 4 to 7.
However, since the remote player 7 is known as a separate entity and
it's subnet has not been registered to play with 4 the packet must be
discarded.
The rule 5-7 will fail for 4-7 tunnel because 4 does not even fit in 5.
Summarizing above list an implmentation should work with network objects
rather than with addresses and the thesis would be:
"The players must be known before a game starts!"
The proposed scheme will work while all assigned subnets are known to
policy checking engine.
Suppose, again in your case, the 5-7 tunnel is just deleted along with
information about subnets 5 and 7. Then traffic 5-7 will be covered by
the remaining rule for 4-8 tunnel that might be not good for you...
sometime, right?
:
:Vach Kompella
:IBM Corp.
:Network Security Product Development
:kompella@us.ibm.com
:Ph.: (919) 254-7281
:Fax: (919) 254-4239
Hope this help.
---
Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694
Software Architecture&Development Consultant.
---