Re: SPD issues

[Tero Kivinen <kivinen@ssh.fi>]

Markku Savela writes:
> For me, it is the next hop destination. Note, however that if SG is
> also a router, there will be two cases for incoming packet with
> routing header:
> a) ip dst = routers own address => process routing header, IPSEC will
> apply to next hop. (which may be the router itself again). 
> b) ip dst != routers own address, routing header is NOT processed,
> next hop is searched based on the ip dst address. Again, IPSEC apply
> to next hop.
> This is as it should be. Do not mess with it!

That interpretation is fine as long as there is nothing that looks
like firewall there. In the IPsec there are drop rules so it have a
minimal firewall inside of the IPsec implementation. Using the routing
header allows users to bypass the restrictions created by the
adminstrator.

I.e Adminstrator defines policy of the SGW in the remote office:

	Host - SGW - Internet - SGW ----+--- internal net
				        |
					+--- smtp server
					|
					+--- www-proxy
					|
					+--- news server

	1) Any traffic to www-proxy is allowed (bypass)
	2) Any traffic to smtp server is protected by IPsec
	3) Drop all other traffic.

Now if users want to use some other services, like news server they
can send the packet to the www-proxy with routing header forwarding
the traffic to the news server, and that will go through even when we
have the rule 3, that says that traffic should be dropped.

They can also use the www-proxy to send traffic to the smtp-server,
which will now go through the internet in clear instead of using IPsec
protection as specified in rule 2. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/