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

IPSP WG solutions are too complex

(Reply to only one list, thanks.)

In my view what IPSP is trying to create is too complex. 
The SPS is a "swiss army knife" -type of solution, while there is
no need for that kind of a solution. There are certainly valid problems
to be solved, but the correct way would be specify only what is 
necessary, and not to try to solve everything at once.

For example, each network entity needs to have a base policy (ad hoc terminology)
so that the network entity knows what it can trust, who it's allowed to communicate
with, and so forth. This base policy is relatively static, it might
change for example when the network entity migrates to another network
location. It's perfectly OK for IETF to specify standards that define
how the base policy can be assigned for the network entity. 

However, several companies including F-Secure and Microsoft already have 
solutions for the problem of assigning a base policy for a network entity.
Such companies have little interest in changing the whole policy distribution
mechanism only to solve some of the other problems, which are not related
to the base policy (like security gateway discovery).

I would strongly suggest that the solutions created by IPSP be divided
into two categories:
1) The internal policy distribution of a company. Some companies may wish
   to employ IETF-specified policy distribution mechanisms, while other 
   companies wish to employ other, proprietary methods.
2) The problem of INTERCONNECTING network entities that belong to different
   organizations, and which have their policies defined by different authorities.
   Here we have (what I view) relevant problems for IPSP, including SGW discovery.

This division mirrors an existing philosophy already found in
routing protocols. Also, this division would enable parts of the network
to evolve in a more rapid speed than other parts. This would be similar
to an organization taking a new and improved routing protocol for its internal
network, while using an older and less capable routing protocol in interconnections
to the rest of the world.

Another reason to do this is that this would reduce the complexity of the
solutions created. As we've seen discussed quite extensively in IPSec WG,
the complexity of a solution creates bugs. The complexity of a security policy
system is just as bad as the complexity of IPSec/IKE.

Some specific issues follow..

A problem in category 2) is what happens when A wishes to contact to B using
IKE, and the connection setup fails. Here one problem is that A has really
little knowledge of WHY the setup failed, because IKE will not provide such
knowledge. I move that the correct way to solve this particular problem would
be to fix IKE (in IPSec WG) to provide sufficient information to A, so that
the IKE connection can be fixed (manually or automatically). The good way to 
solve this particular problem is not to employ SPS/SPP. If B doesn't wish to
give this information through a modified IKE, it hardly wishes to give it
through SPP either.

Another problem in category 2) is the SGW discovery problem. Let's take an example
situation: A laptop is roaming in the Internet, and it wishes to connect to its
own VPN, to a peer whose address is 10.x.y.z. Let's assume there are very many
SGWs, or some other reason, why we don't want to configure all of them statically
to the laptop. Here a policy protocol querying some server as to the correct
SGW to use is OK, and 'must' in fact be used since the peer's IP address is not routable. 
However, the protocol can be considerably simpler than (the whole of) SPP.

If the peer's IP address is routable, SGW discovery could be done by using ICMP security
failure messages. In my view this alternative should not be dismissed too lightly.
If the ICMP system is insecure ;), it should be fixed, and some WG should take on that task.

Also, a question regarding SPS: Assuming I have a laptop, and the laptop discovers
several SGWs that need to be traversed to reach point B, how would one specify
a policy that states that the laptop MAY NOT authenticate itself to any of the
SGWs that are dynamically discovered. (I'm worried in this case that No Such Agency
will try to put a SGW in the between, and discover who I am.) In any case, is there
any practical use for more than two SGWs? One between where I am now and Internet,
another between Internet and the destination? If there are no such cases, the first
SGW can be known by methods in category 1), the second by a simple SGW discovery
protocol in category 2).

Also, creating solutions incrementally in IPSP WG would make it much easier
to coordinate the solutions with those created in IPSRA, for example. Also,
incremental solutions would be much easier to take in real use. By incremental
I mean solutions that are "only what is necessary, and not everything at once".

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security