Re: To IPsec or not to IPsec
- From: phil-news-nospam@xxxxxxxx
- Date: 20 Aug 2007 12:04:15 GMT
On Mon, 20 Aug 2007 06:31:18 +0000 (UTC) Burkhard Ott <postmaster@xxxxxxxxx> wrote:
| Am Mon, 20 Aug 2007 01:21:45 +0000 schrieb phil-news-nospam:
|
|> On Sun, 19 Aug 2007 08:16:02 +0200 Burkhard Ott <b.ott@xxxxxxxxx> wrote:
|>
|> | it still doesn't make sense to me but how about routing?
|> | If IPsec is established then you get a route entry, change the metric, you
|> | can do it via ospf either that you can send/receive the packets
|> | 'loadbalanced'.
|>
|> How is that? Does the program ("racoon" in "ipsec-tools") that establishes
|> the security associations do this?
|>
|
| Usually after the SA is established you'll get a new route entry, let's
| say with metric 30 you could now add a additional route with metric 40.
| After the tunnel is gone your route with metric 30 should be automatically
| removed by racoon, but you still have the route with metric 40 and that is
| the way your packets will go.
| Via ospf you could inject these routes easily to you other routers, if one
| line down (or too much traffic) the best path will be used, depends on
| your config.
Could you explain why such a route would need to be injected to other routers?
That does not make sense for end-to-end encryption. Once encrypted within the
host, maybe the router is needed internally to cause the packet to go through
the encryption steps. But once it is encrypted and headed out to the internet,
why would it need to go through any different router?
And just what kind of route change would this be if my server is still served
by the same router run by my ISP?
If you were running an ISP that hosted web servers, would you allow your users
to inject OSPF routes into your infrastructure?
What I do see actually happening is not routes. It is an internal policy that
specifies what peers should engage certain types of IPsec encryption. If the
policy is in effect, traffic does not go to that host in the clear, and any
attempt to send traffic to that peer when an SA is not established causes one
to be initiated (which should work if the peer is also set up for it). This
basically means I need to decide IN ADVANCE which peers will and which peers
will not engage IPsec. What I WANT TO DO is not make that decision in advance,
but rather, make that decision on my end based on whether the peer has chosen
to use IPsec or not. If they choose to use IPsec (which could be determined
simply by establishing a successful SA) then all traffic to their IP should
then be encrypted (and all traffic from then decrypted). Otherwise, none of
the traffic should.
Have you ever used the ipsec-tools package?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-20-0654@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- Follow-Ups:
- Re: To IPsec or not to IPsec
- From: Burkhard Ott
- Re: To IPsec or not to IPsec
- References:
- To IPsec or not to IPsec
- From: phil-news-nospam
- Re: To IPsec or not to IPsec
- From: Burkhard Ott
- Re: To IPsec or not to IPsec
- From: phil-news-nospam
- Re: To IPsec or not to IPsec
- From: Burkhard Ott
- Re: To IPsec or not to IPsec
- From: phil-news-nospam
- Re: To IPsec or not to IPsec
- From: Burkhard Ott
- To IPsec or not to IPsec
- Prev by Date: Re: ssh tunnel to non-standard ssh port
- Next by Date: Re: The OpenSSL API
- Previous by thread: Re: To IPsec or not to IPsec
- Next by thread: Re: To IPsec or not to IPsec
- Index(es):
Relevant Pages
|
