|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: linux-ipsec: routing limitations
Date: Thu Feb 26 1998 - 04:24:05 EST
On Wed, 25 Feb 1998, Richard Guy Briggs wrote:
> I have been doing testing of tunnel mode and transport mode and think
> I have just hit a wall...
>
> The explicit routing explained in the INSTALL.txt works fine for two
> gateways on the same subnet under any kind of permutations of tunnel
> mode and transport mode since once the next_hop == destination, the packet
> is thrust out the physical interface. By chance, arp knows to which
> machine to send the packet since it does not need to send it via
> a gateway.
Hm. Probably correct.
> Some possible solutions include:
> 1) Use a flag in the skb to indicate if it has previously undergone
> ipsec processing. This will only work if tunnel mode in transport
> mode is not permitted (well, it could be checked for...but more difficult)
> for which I must check documentation (RFCs and drafts) for legality
> and more importantly, ignore ipsec device routes returned from the
> IP routing tables and look for a physical hardware route for the
> encapsulated packet. This may need changes to the Linux routing
> code.
This sounds like a huge hack to me which I would try to avoid personally.
> 2) Intercept the packet before it gets to the routing tables to check
> if it needs encapsulation. The processed packet needs to be checked
> again before being passed to the routing tables in case it will be
> transported in ipsec after it is tunnelled in ipsec. This last sentence
> I cannot be sure about until I check the relevant ietf-drafts and RFCs.
> This WILL need changes to the Linux routing code.
Does not sound too much better.
>
> Do I have this right? Am I understanding things thus far?
>
> There may be other possibilities which have not come immediately to
> mind. The strong inclination is to find out how it was done in *BSD.
I do not want to be seen like pushing the same idea too many times and too strongly, but my feeling after looking at the ENskip code for Linux is that that code might have the hooks you are looking for. The trick is that the security transforms (ie AH and ESP, be they in tunnel or transport mode) are integrated into the firewall processing rules, rather than having them as a device (which is the case with Sun's SKIP on W95).
Unfortunately I am extremely busy on a customer project until late next week, so I cannot spend too much time reading both implementations (ie. JI and Enskip) with your problems in mind, but I will try to do my best ASAP. I will also have a look at other implementations I can find around (ie. Ito Juns code and the old NRL code - is there anything else? I know about the NIST code, but that is a no-no to us living outside the US).
>
> I have all the source for OpenBSD 2.2 since I am
> mucking around with a sparc 2 here.
>
> I bought TCP/IP Illustrated Vol.1 and borrowed Vol.2, which I intend
> to also buy which may provide some ideas. Vol.1 looks at the concepts
> of half a dozen different vendors' implementations while Vol.2 looks
> at the code of the BSD NET/3 code. These books are excellent. But...
> you probably already knew that. :)
>
> - From that departure, The linux networking code needs to be hacked.
> The obvious place is somewhere around the hooks for firewalling,
> masquerading, multicasting, etc. before calling the routing table.
This sounds like a much better way to go than the previus ones.
>
> This means modifying (in the current setup, haven't checked with
> 2.1.8x kernels) ip_forward, ip_out, ip_in at minimum to catch all
> the directions.
>
> All this has serious implications on the road warrior situation and
> how soon we can get this solved. Can I please get some feedback to
> the validity of my assumptions.
I will try to send a more complete review by the end of next week.
>
> Slainte Mhath, rgb
Thanks and regards,
Petr
!Petr Novak Phone: +420 -2- 2424 5124 ! ! Fax: +420 -2- 2424 5125 ! !Internet servis, a.s. E-mail: Petr.Novak@internet.cz ! !Zirovnicka 6 NOTE: *In January 1998 our phone and*! !CZ-106 00 Praha 10 NOTE: *fax has changed. Please use **! !Czech Republic NOTE: *the numbers above.************! --------------------------------------------------------------------Received on Thu Feb 26 05:27:13 1998
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:27 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |