linux-ipsec: Pluto tripping over own feet

After Pluto has negotiated an SA, it must direct the kernel to implement the SA. Currently, these SAs are supposed to process all traffic between Pluto's client and Pluto's peer's client. If the client includes Pluto's host, then Pluto will lose its clear path to and from the peer!

One important special case of this is any host-mode setup.

Currently, pluto refuses to perform the required routing commands to implement the SA if the peer's IP address is within the peer's client subnet. The reason is that Pluto does not wish to lose touch with its peer. The situation is symmetric if the peer is Pluto (I can't speak for other IKE implemntations).

This does not seem to be acceptable. What should we do?

My first thought is that Pluto should be able to tell the kernel not to use the SA for UDP port 500 messages (the official IKE port). But that doesn't seem to fit in with routing commands. Packets need to be dealt with based on more than their destination IP number. It seems much more like packet filtering.

Is there an easy and clean way to handle this problem? Does it fit KLIPS? Is it something that can be done more easily in the 2.1.x LINUX kernels?

Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253

PS: Currently, when Pluto is acting as a Quick Mode initiator, it installs the SA before sending the I2 packet -- a quirk of the implementation. This guarantees that the responder won't understand the packet if the SA applies to it. On the other hand, adjusting this detail doesn't fix the problem: if the I2 packet is lost, it would have to be resent and by that time the SA would have been established. The path continues to be needed anyway for Notification messages. Received on Wed Jun 24 21:35:54 1998

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek