> After some thinking, I also feel that providing
> kind of flexibility
> is good. It is really going to solve the problem
> of creating security tunnel between two sites,
> having multiple
> subnets, when combined with services.
>
> To support, this kind of flexibility, current TS
> is not good
> enough. Based on example given, 3000 Traffic
> Selectors need to
> be sent ( Did I get my math correct? ) which
> results to 40K of
> data in IKE message.
A more relevant question might be why we need to have
this complicated selector negotiation at all. We could
save ourselves a lot of hassle by just letting each
party enforce their own policy at the firewall level.
This is an issue that was brought up on this list a
long time ago, and it's a shame that it didn't get
included in the IPsec/IKE redesign process.
As I remember it, the justification for this design
was that the SADB and the firewall might be located on
different physical devices. But come on... Raise your
hand if you are deploying an IPsec implementation that
is not integrated with a firewall. So the question is
why are we optimizing for the edge case, while
complicating the configuration of the average case.
-a
=====
Andrew Krywaniuk, Fortinet Technologies
Please *do not* reply to this address. (I will not read it)
Reply to askrywan..hotmail..com or my home address.
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca