To IPsec or not to IPsec

Discussion in 'Linux Networking' started by Guest, Aug 18, 2007.

  1. Guest

    Guest Guest

    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?
     
    Guest, Aug 18, 2007
    #1
    1. Advertisements

  2. Guest

    Burkhard Ott Guest

    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?
    Anyway what you wrote makes in my opinion no technically sense.

    cheers
     
    Burkhard Ott, Aug 18, 2007
    #2
    1. Advertisements

  3. Guest

    Burkhard Ott Guest

    Am Sat, 18 Aug 2007 18:34:33 +0200 schrieb Burkhard Ott:
    I mean RFC1918 adresses.
     
    Burkhard Ott, Aug 18, 2007
    #3
  4. Guest

    Guest Guest

    | 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.
     
    Guest, Aug 18, 2007
    #4
  5. Guest

    Burkhard Ott Guest

    Am Sat, 18 Aug 2007 22:09:13 +0000 schrieb phil-news-nospam:
    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
     
    Burkhard Ott, Aug 19, 2007
    #5
  6. Guest

    Guest Guest

    | 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?
     
    Guest, Aug 20, 2007
    #6
  7. Guest

    Burkhard Ott Guest

    Am Mon, 20 Aug 2007 01:21:45 +0000 schrieb phil-news-nospam:
    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.
     
    Burkhard Ott, Aug 20, 2007
    #7
  8. Guest

    Guest Guest

    | Am Mon, 20 Aug 2007 01:21:45 +0000 schrieb phil-news-nospam:
    |
    |>
    |> | 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?
     
    Guest, Aug 20, 2007
    #8
  9. Guest

    Burkhard Ott Guest

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

    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.
    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.
    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.
    And then what happend with the packets, they use the default gw or a
    static route.
    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.
    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
     
    Burkhard Ott, Aug 20, 2007
    #9
  10. Guest

    Guest Guest

    | 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.
     
    Guest, Aug 22, 2007
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.