swIPe vulnerabilities

[jfjr@mbunix.mitre.org (Freedman)]

In regards to S. Bellovin's swIPe comments:

  We have modified our swIPe implementation slightly by adding host
filtering. Once swIPe is turned on - the ifconfigs and ioctls have
been issued - any packets from a designated swIPed partner that are
not swIPed are rejected. This is a few lines of code, mainly in ip_input.


 We also have a protoype key manager using Diffie-Hellman key exchange.
This is done "out-of-band" over raw IPIP sockets. We have not yet included
any third party certification.

 We believe that tieing swIPe processing to routing tables makes swIPe
as vulnerable as the routing tables. Consider, HostA and HostB are swIPe end
points. Packets from A intended for B are routed through the sw*
interface and thus swIPed. HostC is a bad guy and, by playing
interesting games with routing protocols, is able to cause changes in
A's routing tables such that packets from A intended for B *bypass*
the sw* interface and go out in the clear. B will reject such
packets(assuming the host filtering described above is implemented)
since they are from A, a swIPed host, and are not swIPed.  The attack
will fail on a full duplex TCP/IP channel wouldn't work. However,for
UDP style, one way, communication this attack works fine.

 There should be some guarantee that packets intended for a swIPe host
will undergo swIPe processing. As things stand now, with swIPe
processing tightly bound to routing tables this is not the case.
 
                              J. Freedman,
                              J. T. Wittbold
                              M. Michnikov

---

• Prev by Date: Re: swIPe comments
• Next by Date: SKIP (a key-management proposal)
• Prev by thread: Re: swIPe
• Next by thread: SKIP (a key-management proposal)
• Index(es):
  • Main
  • Thread