hipl-maintainer team mailing list archive

[Witold Baryluk <713552@xxxxxxxxxxxxxxxxxx>]

Hmm, adding -N option make it much better indeed. But description is
confusing:   "-N do not flush ipsec rules on exit".  on exit? it
currently do not flush ipsec rules on startup (and probably also on exit
right?).

So it will help, but...


Will automatically create SPDs will be somehow removed after some time? Suppose I have this -N option. Suppose I have 20 HIP connections, and then I restart hipd. Now what will hipd do? Remove this 20*4 SPD/SD which will disconnect my connections, or just leave them forever?. (becuase for example remote host never sends anything to update this entries anymore). Then after some time a again restart hipd, and now have next 20*4 SPD/SD, totally 160. And this is not something unexpected, in mobile environments we will have often many different dynamic SPDs, right?


Going to test -N option more :)

-- 
You received this bug notification because you are a member of HIPL
maintainer team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/713552

Title:
  Should not mess with existing IPsec keys and policies

Status in Host Identity Protocol for Linux:
  New

Bug description:
  HI.

  I have been testing hipl on Debian squeeze, on 2.6.32 kernel.

  
  I started hipd on one box and momentally some hosts on my LAN stoped responding even to ping.
  I started tcpdump on this machines, and seen that icmp packets are recived there,
  but not encrypted! This is strange becuase I have ipsec enabled beetwen this machines
  in transport mode.

  hipd disabled (probably flushed all ipsec rules) this encryption
  somehow.

  I i have rules like in /etc/ipsec-tools.conf

  spdadd 10.0.2.5 10.0.2.7 any -P out ipsec esp/transport//require ah/transport//require;
  spdadd 10.0.2.7 10.0.2.5 any -P in ipsec esp/transport//require ah/transport//require;

  hipl removed them (by flush), and then of course traffic started
  to be droped on the other side (correctly, becuase other side also want traffic to be encrypted).

  
  This is what setkey shows before hipl was started:

  # setkey -DP | grep -A 7 149.156.1.1
  149.156.1.1[any] 10.0.2.5[any] any
  	fwd prio def ipsec
  	esp/transport//require
  	ah/transport//require
  	created: Feb  5 09:42:19 2011  lastused:                     
  	lifetime: 0(s) validtime: 0(s)
  	spid=6809474 seq=39 pid=16409
  	refcnt=1
  149.156.1.1[any] 10.0.2.5[any] any
  	in prio def ipsec
  	esp/transport//require
  	ah/transport//require
  	created: Feb  5 09:42:19 2011  lastused: Feb  5 09:42:48 2011
  	lifetime: 0(s) validtime: 0(s)
  	spid=6809464 seq=40 pid=16409
  	refcnt=10
  10.0.2.5[any] 149.156.1.1[any] any
  	out prio def ipsec
  	esp/transport//require
  	ah/transport//require
  	created: Feb  5 09:42:19 2011  lastused: Feb  5 09:42:48 2011
  	lifetime: 0(s) validtime: 0(s)
  	spid=6809457 seq=0 pid=16409
  	refcnt=8
  # setkey -D | egrep '(ah mode|hmac|aes|^1)'
  10.0.2.5 149.156.1.1 
  	esp mode=transport spi=53341147(0x032debdb) reqid=0(0x00000000)
  	E: aes-cbc  fa937e03  .....
  	A: hmac-sha1   b3459515 .....
  10.0.2.5 149.156.1.1
  	ah mode=transport spi=28939182(0x01b993ae) reqid=0(0x00000000)
  	A: hmac-sha1  8866d881     .....
  149.156.1.1 10.0.2.5 
  	esp mode=transport spi=33621199(0x020104cf) reqid=0(0x00000000)
  	E: aes-cbc  b3036571  ....
  	A: hmac-sha1  e53c5990    .....
  149.156.1.1 10.0.2.5 
  	ah mode=transport spi=207398168(0x0c5ca518) reqid=0(0x00000000)
  	A: hmac-sha1  023d63c4    ....
  #

  Then i start hipl.  ( i actually have also setkey -x started for
  monitoring).

  rerunning above commands give me

  # setkey -DP | grep -A 7 149.156.1.1
  (empty)
  # setkey -D | egrep '(ah mode|hmac|aes|^1)'
  10.0.2.5 149.156.1.1
  	ah mode=transport spi=28939182(0x01b993ae) reqid=0(0x00000000)
  	A: hmac-sha1  8866d881 ....
  149.156.1.1 10.0.2.5 
  	ah mode=transport spi=207398168(0x0c5ca518) reqid=0(0x00000000)
  	A: hmac-sha1  023d63c4 ...
  #

  esp modes disapeared.

  Lack of esp keys is not yet tragical (but bad for performance) as normally keys will be renegotiated again.
  (BTW. I keys are negotietied using racoon IKE daemon on both machines, with preshared secrets.)

  But policies disappered too, this is much more catastrophic.

  After a while or after performing some HIP traffic, actually setkey -D starts showing
  also esp keys (probably remote side requested IKE rekeying), but they are not used due to the
  removed policy on sending/reciving on local host.
  (I actually concurently see old and new keys for ah/esp, but this is probably a way how rekeying works,
  to acomodate recieving latly araving packets with old keys).
  I'm not sure about this, becuase both keys (old and new), have state=mature, and essentially
  do not have any different flag beyond keys, pointers, and creation date.

  I was trying to work this problem, by reexecuting my policies short time after a hipl started.
  Unfortunetly this makes possible to intercept not-encrypted traffic in this 5 seconds.

  It actualy also make HIP traffic to stop working (it works if I do not reexcute
  ipsec policies with my own, and if I change /etc/resolv.conf to use non-ipsec DNS server
  obviously, as ipsec dns server will not responde due to the just-removed-ipsec-policies locally)

  (i assume that problem with vulnerable time window can be solved correctly by adding additional
  dropping of unecrypted traffic to the 149.156.1.1 on the iptables level
  using esp and ah module somehow, i.e. iptables -A POSTROUTING -d  149.156.1.1 ! -p esp -j DROP,
  and eventually passing a IKE traffic, i.e. iptables -A POSTROUTING -d 149.156.1.1 -p udp --dport 500 -j ACCEPT,
  and similary for iptables6 if needed )
  (this trick is needed, becuase -m policy --dir out --pol ipsec ! --proto esp   -j DROP,
  will not work of course, due to the policy database cleaned)

  
  But it will still not solve problem of cooperation of hipl policies and user suplied policiec.

  I removed command 'spdflush;' from my /etc/ipsec.tools, and it makes hipl happy,
  as it will not remove hipl spd's.
  And I can then perform concurently HIP traffic and normal IP/IPV6 traffic with ipsec
  to boxes i configured.


  Please make hipd respect already present policy rules.

  Preferably hipd should be concerned only about rules it added itself.

  Only real problem would be a cleaning garbage after unclean termination of hipl.
  (on clean shutdown hipd should remove policiec hipl added, to prevent
  memory leaks)

  In such situation hipd have multiple possiblities:
    - store all local/remote IP pairs in log file, which will be scaned on next startup and removed from spd's.
    - do not use spdflush to remove all spd's, but iterate over all of them and for example only remove this which operates in eps-udp with port 10500 in mode=3.
    - iterate over them but do not touch entries which match to the entries in /etc/ipsec-tools.conf (pretty hard actually, needs parser and actually not all spd entries comes from ipsec-tools.conf file alone)
    - patch ipsec stack to support "temporary policies" which will be garbage collected in kernel after some inactivity time. (they still can be manually removed or flushed) (nice, simple, and also robust, but pretty hard to implement)
    - patch ipsec stack to support labeling policies by flags, to distinguish what tool (setkey or hipd) added them. (this will simplify iteration, and will make log file unneeded. (simplest, and most robust, and easy to implement). [there is something like label and tag in spd, but this is for something very different].

  Marking as security vulnerability, due to dropping user policy, and
  starting to send unecnrypted traffic which already was encrypted.

  Thanks.