To IPsec or not to IPsec

I've now successfully done some IPsec configurations and tried it out.
But it seems to be purely policy based. That is, you decide where you
IPsec to be in effect or to not be in effect. But I'd like to also have
something different.

What I would like to set up is a host which others can communicate with
either using IPsec or not using IPsec, based on that peer host's own
choices. So the policy on my end would be "If they want to use IPsec,
then we will ... If they want to communicate in the clear, then we will".
And I'm not talking about NULL crypto; I'm talking about entirely not
using IPsec with any given host unless _they_ establish the security
association, in which case then the communication will be IPsec and will
stay on IPsec for all traffic between those hosts until some lengthy
period of no traffic. No third party should be able to inject a forged
packet that can turn the IPsec choice back off if it was chosen. But if
the peer host never chose IPsec (via a complete SA exchange, so it cannot
be forced on by a third party, either), then all communications shall not
use IPsec.

Is this even doable?

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-18-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

Am Sat, 18 Aug 2007 15:14:35 +0000 schrieb phil-news-nospam:

> What I would like to set up is a host which others can communicate with
> either using IPsec or not using IPsec, based on that peer host's own
> choices. So the policy on my end would be "If they want to use IPsec,
> then we will ... If they want to communicate in the clear, then we will".
> And I'm not talking about NULL crypto; I'm talking about entirely not
> using IPsec with any given host unless _they_ establish the security
> association, in which case then the communication will be IPsec and will
> stay on IPsec for all traffic between those hosts until some lengthy
> period of no traffic. No third party should be able to inject a forged
> packet that can turn the IPsec choice back off if it was chosen. But if
> the peer host never chose IPsec (via a complete SA exchange, so it cannot
> be forced on by a third party, either), then all communications shall not
> use IPsec.

You didn't understand how IPSec works, if the SA isn't established how do
you route your packets from RFC1918 through the internet to the other
gateway?
Anyway what you wrote makes in my opinion no technically sense.

cheers

Am Sat, 18 Aug 2007 18:34:33 +0200 schrieb Burkhard Ott:

> Am Sat, 18 Aug 2007 15:14:35 +0000 schrieb phil-news-nospam:
> You didn't understand how IPSec works, if the SA isn't established how do
> you route your packets from RFC1918 through the internet to the other
> gateway?

I mean RFC1918 adresses.

On Sat, 18 Aug 2007 18:34:33 +0200 Burkhard Ott <(E-Mail Removed)> wrote:

| Am Sat, 18 Aug 2007 15:14:35 +0000 schrieb phil-news-nospam:
|
|> What I would like to set up is a host which others can communicate with
|> either using IPsec or not using IPsec, based on that peer host's own
|> choices. So the policy on my end would be "If they want to use IPsec,
|> then we will ... If they want to communicate in the clear, then we will".
|> And I'm not talking about NULL crypto; I'm talking about entirely not
|> using IPsec with any given host unless _they_ establish the security
|> association, in which case then the communication will be IPsec and will
|> stay on IPsec for all traffic between those hosts until some lengthy
|> period of no traffic. No third party should be able to inject a forged
|> packet that can turn the IPsec choice back off if it was chosen. But if
|> the peer host never chose IPsec (via a complete SA exchange, so it cannot
|> be forced on by a third party, either), then all communications shall not
|> use IPsec.
|
| You didn't understand how IPSec works, if the SA isn't established how do
| you route your packets from RFC1918 through the internet to the other
| gateway?
| Anyway what you wrote makes in my opinion no technically sense.

Well, then you didn't understand what I wrote. RFC1918 addresses are not
involved, at least on my end. ESP doesn't encrypt the addresses, only the
payload, so it won't be a problem if the other end has NAT to use RFC1918
behind a firewall. AH would be a problem since it would fail authentication
if the address is changed. But I don't care about AH.

What I want is for my end, a server, to use IPsec or not use IPsec based
on whether the remote host has chosen to do so or not. I see two ways that
can happen. One is to simply handle either the clear or encrypted packets
as they come, applying IPsec for the encrypted ones. But that's risky.
The other way would require a dynamic policy that would get established if
the SA is established. The way things work for static policies is that if
the policy says "use IPsec" then that triggers the SA initiation if it is
not yet established, and the clear packet is dropped or queued for later
encryption. For what I want to do, at least my end would have to handle
this more smartly. That is, if a request to establish an SA arrives, it
would go ahead and do so, and either when that is done, dynamically set up
a policy on the fly to force all traffic with that remote IP to be handled
via IPsec. When the SA times out completely, the policy would be dropped.
The remote end could just use a static policy if they choose. But if the
remote end were doing things dynamically, something would have to trigger
the SA to be established. Manually running setkey could set the policy to
force that. But for both ends to say "I'll talk in the clear unless the
other end _can_ talk encrypted" might need a new protocol or extension to
offer the _option_ to go with an IPsec SA that could be discarded if the
other end doesn't have it.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-18-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

Am Sat, 18 Aug 2007 22:09:13 +0000 schrieb phil-news-nospam:

> On Sat, 18 Aug 2007 18:34:33 +0200 Burkhard Ott <(E-Mail Removed)> wrote:
>
> | Am Sat, 18 Aug 2007 15:14:35 +0000 schrieb phil-news-nospam:
> |
> |> What I would like to set up is a host which others can communicate with
> |> either using IPsec or not using IPsec, based on that peer host's own
> |> choices. So the policy on my end would be "If they want to use IPsec,
> |> then we will ... If they want to communicate in the clear, then we will".
> |> And I'm not talking about NULL crypto; I'm talking about entirely not
> |> using IPsec with any given host unless _they_ establish the security
> |> association, in which case then the communication will be IPsec and will
> |> stay on IPsec for all traffic between those hosts until some lengthy
> |> period of no traffic. No third party should be able to inject a forged
> |> packet that can turn the IPsec choice back off if it was chosen. But if
> |> the peer host never chose IPsec (via a complete SA exchange, so it cannot
> |> be forced on by a third party, either), then all communications shall not
> |> use IPsec.
> |
> | You didn't understand how IPSec works, if the SA isn't established how do
> | you route your packets from RFC1918 through the internet to the other
> | gateway?
> | Anyway what you wrote makes in my opinion no technically sense.
>
> Well, then you didn't understand what I wrote. RFC1918 addresses are not
> involved, at least on my end. ESP doesn't encrypt the addresses, only the
> payload, so it won't be a problem if the other end has NAT to use RFC1918
> behind a firewall. AH would be a problem since it would fail authentication
> if the address is changed. But I don't care about AH.
>
> What I want is for my end, a server, to use IPsec or not use IPsec based
> on whether the remote host has chosen to do so or not. I see two ways that
> can happen. One is to simply handle either the clear or encrypted packets
> as they come, applying IPsec for the encrypted ones. But that's risky.
> The other way would require a dynamic policy that would get established if
> the SA is established. The way things work for static policies is that if
> the policy says "use IPsec" then that triggers the SA initiation if it is
> not yet established, and the clear packet is dropped or queued for later
> encryption. For what I want to do, at least my end would have to handle
> this more smartly. That is, if a request to establish an SA arrives, it
> would go ahead and do so, and either when that is done, dynamically set up
> a policy on the fly to force all traffic with that remote IP to be handled
> via IPsec. When the SA times out completely, the policy would be dropped.
> The remote end could just use a static policy if they choose. But if the
> remote end were doing things dynamically, something would have to trigger
> the SA to be established. Manually running setkey could set the policy to
> force that. But for both ends to say "I'll talk in the clear unless the
> other end _can_ talk encrypted" might need a new protocol or extension to
> offer the _option_ to go with an IPsec SA that could be discarded if the
> other end doesn't have it.
>

Hi Phil,

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'.

cheers

On Sun, 19 Aug 2007 08:16:02 +0200 Burkhard Ott <(E-Mail Removed)> 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?

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-19-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

Am Mon, 20 Aug 2007 01:21:45 +0000 schrieb phil-news-nospam:

> On Sun, 19 Aug 2007 08:16:02 +0200 Burkhard Ott <(E-Mail Removed)> 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.

On Mon, 20 Aug 2007 06:31:18 +0000 (UTC) Burkhard Ott <(E-Mail Removed)> 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 <(E-Mail Removed)> 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-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

Am Mon, 20 Aug 2007 12:04:15 +0000 schrieb phil-news-nospam:


> 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?

That is what I told you in my first response to you posting but anyway...
If I understood correctely you try to establish a tunnel on you gateway
and if the tunnel is gone you want that the traffic goes still out via
NAT, thats the thing you could do.

> And just what kind of route change would this be if my server is still served
> by the same router run by my ISP?

I didn't know that your network is so simple, usually you have more than
one entrypoint to the backbone and in this case you will need also the
posibility to route dynamically.

> If you were running an ISP that hosted web servers, would you allow your users
> to inject OSPF routes into your infrastructure?

I work on an ISP and yes bigger customers have access to the routers and
can change their routes, in every bigger environment have you the same
constellation.
Have you ever heared from a route filter, probably not.

> 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

And then what happend with the packets, they use the default gw or a
static route.

> 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.

Now where is then the problem, if the packets pass the policy and are
encrypted then they will be sent via default gw if there is no other
route, if they not pass the policy they do the same but unencrypted.

> Have you ever used the ipsec-tools package?

I don't know if we have the same version and OS, probably not but I built
successfull tunnelsetups with openswan,freeswan,strongswan,racoon,kame and
some properitary solutions like netscreen or sonicwall.
Usually I only would help you.
cheers

On Mon, 20 Aug 2007 13:18:31 +0000 (UTC) Burkhard Ott <(E-Mail Removed)> wrote:
| Am Mon, 20 Aug 2007 12:04:15 +0000 schrieb phil-news-nospam:
|
|
|> 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?
|
| That is what I told you in my first response to you posting but anyway...
| If I understood correctely you try to establish a tunnel on you gateway
| and if the tunnel is gone you want that the traffic goes still out via
| NAT, thats the thing you could do.

There is no NAT.


|> And just what kind of route change would this be if my server is still served
|> by the same router run by my ISP?
|
| I didn't know that your network is so simple, usually you have more than
| one entrypoint to the backbone and in this case you will need also the
| posibility to route dynamically.

That may be the case. But that can be done by the ISP even if I have only one
gateway setting on my machine. Maybe I'll have more than one. Maybe I'll add
OSPF routing. But that's orthogonal to what I'm trying to do with IPsec.


|> If you were running an ISP that hosted web servers, would you allow your users
|> to inject OSPF routes into your infrastructure?
|
| I work on an ISP and yes bigger customers have access to the routers and
| can change their routes, in every bigger environment have you the same
| constellation.

Define "bigger"? Would someone running 1 colocated host be eligible?
Or 4 hots?


| Have you ever heared from a route filter, probably not.

I know what router filters are. I don't understand the context of what you
are asking.


|> 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
|
| And then what happend with the packets, they use the default gw or a
| static route.

Whatever is appropriate for the destination IP address.


|> 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.
|
| Now where is then the problem, if the packets pass the policy and are
| encrypted then they will be sent via default gw if there is no other
| route, if they not pass the policy they do the same but unencrypted.

But how to make the policy handle it. It will have to be dynamic. The
gateway is irrelevant because it will be the same gateway for that IP
address whether the packets are encrypted or not.


|> Have you ever used the ipsec-tools package?
|
| I don't know if we have the same version and OS, probably not but I built
| successfull tunnelsetups with openswan,freeswan,strongswan,racoon,kame and
| some properitary solutions like netscreen or sonicwall.

This isn't for a separate tunnel. This will be IPsec transport mode,
though tunnel mode might be a viability if doable within the same machine.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-22-(E-Mail Removed) |
|------------------------------------/-------------------------------------|