Re: IPSec - IPTables issues

Re: IPSec - IPTables issues

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

Hello Pablo,
(netfilter guys, please read 
http://www.uwsg.iu.edu/hypermail/linux/net/0405.0/0002.html before)

Pablo Neira [Mon, May 03, 2004 at 01:48:15PM +0200]:
> Hi Nico,
> 
> since this stuff is netfilter-related and netfilter/iptables geeks are 
> mostly in netfilter's maillist, I think you could redirect this request 
> there, someone could help you out.

Thank you for the hint. I first thought this is a netfilter problem, but
currently I don't think so.

The problem is IMHO the design of the Linux IPSec implementation.

I'll compare what freeswan did with what Linux 2.6 does now:

Freeswan has virtual devices (ipsec*), through which the unencrypted
packets come into the system. So you can add these firewall lines:

- allow AH, ESP, UDP/500, deny rest on eth0
- allow IPs/networks, etc. on ipsec0

With Linux 2.6 I don't have virtual devices. This means that my IPSec
packets enter the physical device twice:

1. esp encrypted packet enters
2. Linux decrypts it
3. Linux sends the unencrypted packets through the same device again

The problem with that is, that

- allow AH, ESP, UDP/500, deny rest on eth0

will deny the _content_ of my encrypted packages (step three is broken).

Wouldn't this work fine, if we have the virtual device like freeswan had
or is netfilter broken with this?

I mean I cannot practicly setup an IPSec only access point with the current
netfilter and ipsec in Linux 2.6, or am I deadly wrong?

Greetings,

Nico


-- 
Keep it simple & stupid, use what's available.
pgp: 8D0E E27A          | Nico Schottelius
http://nerd-hosting.net | http://linux.schottelius.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: IPSec - IPTables issues

[Aidas Kasparas]

Nico,

	If you have SPD rule (sorry for racoon/setkey speak)
0.0.0.0/0 Your.IP/32 any -P in esp/.../require (or unique)
then any packet coming to your box which is not esp encapsulated will be 
thrown away by ipsec code in kernel (if I remember correctly, it will 
not even reach FORWARD chain). Therefore you could safely skip check for 
esp, ah, udp/500 in iptables rules.

	P.S. you may need to add SPD rule allowing udp/500 before enforcing esp 
traffic. I never required to ipsec all the traffic and therefore I'm not 
sure on this detail.

Nico Schottelius wrote:
> Hello Pablo,
> (netfilter guys, please read 
> http://www.uwsg.iu.edu/hypermail/linux/net/0405.0/0002.html before)
> 
> Pablo Neira [Mon, May 03, 2004 at 01:48:15PM +0200]:
> 
>>Hi Nico,
>>
>>since this stuff is netfilter-related and netfilter/iptables geeks are 
>>mostly in netfilter's maillist, I think you could redirect this request 
>>there, someone could help you out.
> 
> 
> Thank you for the hint. I first thought this is a netfilter problem, but
> currently I don't think so.
> 
> The problem is IMHO the design of the Linux IPSec implementation.
> 
> I'll compare what freeswan did with what Linux 2.6 does now:
> 
> Freeswan has virtual devices (ipsec*), through which the unencrypted
> packets come into the system. So you can add these firewall lines:
> 
> - allow AH, ESP, UDP/500, deny rest on eth0
> - allow IPs/networks, etc. on ipsec0
> 
> With Linux 2.6 I don't have virtual devices. This means that my IPSec
> packets enter the physical device twice:
> 
> 1. esp encrypted packet enters
> 2. Linux decrypts it
> 3. Linux sends the unencrypted packets through the same device again
> 
> The problem with that is, that
> 
> - allow AH, ESP, UDP/500, deny rest on eth0
> 
> will deny the _content_ of my encrypted packages (step three is broken).
> 
> Wouldn't this work fine, if we have the virtual device like freeswan had
> or is netfilter broken with this?
> 
> I mean I cannot practicly setup an IPSec only access point with the current
> netfilter and ipsec in Linux 2.6, or am I deadly wrong?
> 
> Greetings,
> 
> Nico
> 
> 

-- 
Aidas Kasparas
IT administrator
GM Consult Group, UAB

Re: IPSec - IPTables issues

[Patrick McHardy]

Nico Schottelius wrote:

> Wouldn't this work fine, if we have the virtual device like freeswan had
> or is netfilter broken with this?
> 
> I mean I cannot practicly setup an IPSec only access point with the current
> netfilter and ipsec in Linux 2.6, or am I deadly wrong?

Check out the ipsec-* patches and the policy match in netfilter pom-ng.

Regards
Patrick

Re: IPSec - IPTables issues

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

On Tue, May 04, 2004 at 11:15:58PM +0200, Nico Schottelius wrote:
> Hello Pablo,
> (netfilter guys, please read 
> http://www.uwsg.iu.edu/hypermail/linux/net/0405.0/0002.html before)
> 
> Pablo Neira [Mon, May 03, 2004 at 01:48:15PM +0200]:
> > Hi Nico,
> > 
> > since this stuff is netfilter-related and netfilter/iptables geeks are 
> > mostly in netfilter's maillist, I think you could redirect this request 
> > there, someone could help you out.
> 
> Thank you for the hint. I first thought this is a netfilter problem, but
> currently I don't think so.
> 
> The problem is IMHO the design of the Linux IPSec implementation.
> 
> I'll compare what freeswan did with what Linux 2.6 does now:
> 
> Freeswan has virtual devices (ipsec*), through which the unencrypted
> packets come into the system. So you can add these firewall lines:
> 
> - allow AH, ESP, UDP/500, deny rest on eth0
> - allow IPs/networks, etc. on ipsec0
> 
> With Linux 2.6 I don't have virtual devices. This means that my IPSec
> packets enter the physical device twice:
> 
> 1. esp encrypted packet enters
> 2. Linux decrypts it
> 3. Linux sends the unencrypted packets through the same device again
> 
> The problem with that is, that
> 
> - allow AH, ESP, UDP/500, deny rest on eth0
> 
> will deny the _content_ of my encrypted packages (step three is broken).
> 
> Wouldn't this work fine, if we have the virtual device like freeswan had
> or is netfilter broken with this?
> 
> I mean I cannot practicly setup an IPSec only access point with the current
> netfilter and ipsec in Linux 2.6, or am I deadly wrong?

right and wrong, trying to do it the old say doesn't work, simple
solution, tack on your own updown script which updates iptables.

there are some other new patches for netfilter that lets you match
packets to policy's which means you would not need to do the above, but
I haven't looked at this so can't comment


> 
> Greetings,
> 
> Nico
> 
> 
> -- 
> Keep it simple & stupid, use what's available.
> pgp: 8D0E E27A          | Nico Schottelius
> http://nerd-hosting.net | http://linux.schottelius.org



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IPSec - IPTables issues

[Aleksandar Milivojevic]

Nico Schottelius wrote:
> I'll compare what freeswan did with what Linux 2.6 does now:
> 
> Freeswan has virtual devices (ipsec*), through which the unencrypted
> packets come into the system. So you can add these firewall lines:
> 
> - allow AH, ESP, UDP/500, deny rest on eth0
> - allow IPs/networks, etc. on ipsec0
> 
> With Linux 2.6 I don't have virtual devices. This means that my IPSec
> packets enter the physical device twice:
> 
> 1. esp encrypted packet enters
> 2. Linux decrypts it
> 3. Linux sends the unencrypted packets through the same device again
> 
> The problem with that is, that
> 
> - allow AH, ESP, UDP/500, deny rest on eth0
> 
> will deny the _content_ of my encrypted packages (step three is broken).

Haven't worked much with IPSec (at least not over firewall).  Are you 
sure that IPSec packets will go through Netfilter twice (once encrypted, 
and than once again unencrypted)?

Anyhow, if I assume that what you wrote is correct (and it is how Linux 
kernel handles packets), I still don't see need for virtual devices.

If above is what really happens, the proper way to do what you want to 
do is (IMHO):

   - allow hosts/networks on eth0 (in Netfilter part of kernel)
   - setup IPSec policies so that traffic from allowed hosts/networks is 
required to be encrypted (in IPSec part of kernel)

This way, you will get an equivalent configuration (you accept traffic 
only from defined set of hosts/networks, and require that traffic to be 
encrypted).  If you want to limit traffic to say only HTTP, than you 
would allow it if it is: from host/network and (AH or ESP or UDP/500 or 
HTTP).

So you get:

1. Linux requires packets from defined hosts/networks to be encrypted. 
If packets is not encrypted, Linux rejects it because of IPSec policy
2. Packet goes through Netfilter encrypted (accepted since it is AH, 
ESP, or UDP/500 and from allowed src IP)
3. Linux decrypts it
4. Packet goes through Netfilter again (accepted because it is HTTP and 
allowed src IP)

I'm not familiar with kernel internals, so I don't know if steps 1 and 2 
are actually inverted (doesn't change anything).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: IPSec - IPTables issues

[Aleksandar Milivojevic]

Aleksandar Milivojevic wrote:
> Nico Schottelius wrote:
>> - allow AH, ESP, UDP/500, deny rest on eth0
>> - allow IPs/networks, etc. on ipsec0
> 
>   - allow hosts/networks on eth0 (in Netfilter part of kernel)
>   - setup IPSec policies so that traffic from allowed hosts/networks is 
> required to be encrypted (in IPSec part of kernel)

One thing that just came to my mind.  The unencrypted packet is 
obviously related to the encrypted packet.  I don't know if IPSec part 
of kernel is aware of Netfilter part of kernel, and I have no idea how 
Netfilter (or kernel) is internally tracking packtes, but a thing to try 
(might work, or might fail misserably) in exactly this order:

- allow hosts/networks if state is RELATED
- allow AH, ESP, UDP/500 if state is NEW or ESTABLISHED

Once again, I have no idea if your assumption that encrypted packtes are 
traversing Netfilter tables twice is correct, so above might just be me 
blabing about something I have no idea how it works.  Consider this to 
well intended brainstorming (just some ideas from back of my head, that 
might not have any support in reality).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: IPSec - IPTables issues

[Antony Stone]

On Wednesday 05 May 2004 3:47 pm, Aleksandar Milivojevic wrote:

> Nico Schottelius wrote:
> > I'll compare what freeswan did with what Linux 2.6 does now:
> >
> > Freeswan has virtual devices (ipsec*), through which the unencrypted
> > packets come into the system. So you can add these firewall lines:
> >
> > - allow AH, ESP, UDP/500, deny rest on eth0
> > - allow IPs/networks, etc. on ipsec0
>
> Haven't worked much with IPSec (at least not over firewall).  Are you
> sure that IPSec packets will go through Netfilter twice (once encrypted,
> and than once again unencrypted)?

They do.   This makes it easy to filter the packet types you want to allow 
through the tunnel, rather than having a VPN which passes just everything.

> Anyhow, if I assume that what you wrote is correct (and it is how Linux
> kernel handles packets), I still don't see need for virtual devices.

That's the way FreeS/WAN does it.

Regards,

Antony.

-- 
"There has always been an underlying argument that we should open up our 
source code more broadly. The fact is that we are learning from open source 
and we are opening our code more broadly through Shared Source.

Is there value to providing source code? The answer is unequivocally yes."

 - Jason Matusow, head of Microsoft's Shared Source Program, in response to 
recent leaks of Windows source code on the Internet.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: IPSec - IPTables issues

[John A. Sullivan III]

On Wed, 2004-05-05 at 11:22, Antony Stone wrote:
> On Wednesday 05 May 2004 3:47 pm, Aleksandar Milivojevic wrote:
> 
> > Nico Schottelius wrote:
> > > I'll compare what freeswan did with what Linux 2.6 does now:
> > >
> > > Freeswan has virtual devices (ipsec*), through which the unencrypted
> > > packets come into the system. So you can add these firewall lines:
> > >
> > > - allow AH, ESP, UDP/500, deny rest on eth0
> > > - allow IPs/networks, etc. on ipsec0
> >
> > Haven't worked much with IPSec (at least not over firewall).  Are you
> > sure that IPSec packets will go through Netfilter twice (once encrypted,
> > and than once again unencrypted)?
> 
> They do.   This makes it easy to filter the packet types you want to allow 
> through the tunnel, rather than having a VPN which passes just everything.
Please pardon my ignorance; I haven't yet played with 2.6 and the native
IPSec.  So how does one distinguish packets which have arrived from an
IPSec tunnel and are now re-traversing netfilter from those which have
arrived unencrypted and are traversing netfilter for the first time? We
would typically have a different set of access controls for data coming
from a quasi-trusted tunnel versus data coming in from the Internet and
historically differentiated by examining the interface (e.g., ipsec0
versus eth0).
> 
> > Anyhow, if I assume that what you wrote is correct (and it is how Linux
> > kernel handles packets), I still don't see need for virtual devices.
> 
> That's the way FreeS/WAN does it.
> 
> Regards,
> 
> Antony.
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re: IPSec - IPTables issues

[Aleksandar Milivojevic]

Antony Stone wrote:
> That's the way FreeS/WAN does it.

Yes, I know that's the way FreeS/WAN implements it.  But it doesn't mean 
  it is the only way it can be implemented.  Actually, I like better 
Linux 2.6 implementation that doesn't use virtual devices.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: IPSec - IPTables issues

[Antony Stone]

On Wednesday 05 May 2004 5:12 pm, Aleksandar Milivojevic wrote:

> Antony Stone wrote:
> > That's the way FreeS/WAN does it.
>
> Yes, I know that's the way FreeS/WAN implements it.  But it doesn't mean
>  it is the only way it can be implemented.

Well that is certainly true, but if you are using FreeS/WAN then this is the 
system you have to work with.

> Actually, I like better Linux 2.6 implementation that doesn't use virtual
> devices.

Yes, it seems like a better design; now if only we could work out how to 
filter the unencrypted traffic before it all just disappears down the tunnel, 
it might turn out to be a good idea.

Regards,

Antony.

-- 
Anyone that's normal doesn't really achieve much.

 - Mark Blair, Australian rocket engineer

                                                     Please reply to the list;
                                                           please don't CC me.

Re: IPSec - IPTables issues

[Antony Stone]

On Wednesday 05 May 2004 5:08 pm, John A. Sullivan III wrote:

> On Wed, 2004-05-05 at 11:22, Antony Stone wrote:
> > On Wednesday 05 May 2004 3:47 pm, Aleksandar Milivojevic wrote:
> > > Nico Schottelius wrote:
> > > >
> > > > Freeswan has virtual devices (ipsec*), through which the unencrypted
> > > > packets come into the system. So you can add these firewall lines:
> > > >
> > > > - allow AH, ESP, UDP/500, deny rest on eth0
> > > > - allow IPs/networks, etc. on ipsec0
> > >
> > > Haven't worked much with IPSec (at least not over firewall).  Are you
> > > sure that IPSec packets will go through Netfilter twice (once
> > > encrypted, and than once again unencrypted)?
> >
> > They do.   This makes it easy to filter the packet types you want to
> > allow through the tunnel, rather than having a VPN which passes just
> > everything.
>
> Please pardon my ignorance; I haven't yet played with 2.6 and the native
> IPSec.  So how does one distinguish packets which have arrived from an
> IPSec tunnel and are now re-traversing netfilter from those which have
> arrived unencrypted and are traversing netfilter for the first time?

That is a very good question, and one to which I am not aware of a good 
answer.   In my (extremely limited) experience of looking at IPsec in the 2.6 
kernels this is a major disadvantage of the design, and means it is not 
possible to secure a VPN (by which I mean selecting which traffic is allowed 
down it and which is not, as it was possible to do with FreeS/WAN by writing 
netfilter rules specifying ipsecN as the output interface).

> We would typically have a different set of access controls for data coming
> from a quasi-trusted tunnel versus data coming in from the Internet and
> historically differentiated by examining the interface (e.g., ipsec0
> versus eth0).

I agree.   If anyone knows a sensible way of achieving this with the new 2.6 
IPsec implementation, please share the knowledge :)

Regards,

Antony.

-- 
If you can't find an Open Source solution for it, then it isn't a real 
problem.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: IPSec - IPTables issues

[Aleksandar Milivojevic]

Antony Stone wrote:
> On Wednesday 05 May 2004 5:12 pm, Aleksandar Milivojevic wrote:
>>Actually, I like better Linux 2.6 implementation that doesn't use virtual
>>devices.
> 
> Yes, it seems like a better design; now if only we could work out how to 
> filter the unencrypted traffic before it all just disappears down the tunnel, 
> it might turn out to be a good idea.

You let IPSec kernel module take care that anything unencrypted comming 
from the wire or into the wire is dropped.  This should be easily 
acomplished by setting IPSec policy for the connection to required.  So 
you do not need Netfilter to filter out unencrypted traffic from the 
wire.  IPSec is going to do that for you.

Than in Netfilter, you accept packets if they are:

1. IPSec packets (AH, ESP, UDP/500)
2. unencrypted packets for the services (HTTP, FTP, telnet, etc) you are 
allowing

This way, Netfilter will take care of packets before they are encrypted, 
and after they are decrypted.  Therefore protecting the local services 
and allowing you to filter "before it all just dissapears down the 
tunnel".  IPSec will take care that there is no unecrypted traffic going 
onto the wire (or accepted from the wire).

So you don't need virtual interface to differentiate first and second 
pass through Netfilter's chains.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: IPSec - IPTables issues

[Patrick Turley]

Aleksandar Milivojevic wrote:
> Nico Schottelius wrote:
> 
>> I'll compare what freeswan did with what Linux 2.6 does now:
>>
[... many interesting facts...]

I'm reading this thread with great interest and I'm curious about the 
new implementation. Specificaly, does anyone know if the firewall marks 
on packets are preserved after they are encrypted?

Re: IPSec - IPTables issues

[Wolfgang Walter]

Am Dienstag, 4. Mai 2004 23:15 schrieb Nico Schottelius:
> Hello Pablo,
> (netfilter guys, please read
> http://www.uwsg.iu.edu/hypermail/linux/net/0405.0/0002.html before)
>
> Pablo Neira [Mon, May 03, 2004 at 01:48:15PM +0200]:
> > Hi Nico,
> >
> > since this stuff is netfilter-related and netfilter/iptables geeks are
> > mostly in netfilter's maillist, I think you could redirect this request
> > there, someone could help you out.
>
> Thank you for the hint. I first thought this is a netfilter problem, but
> currently I don't think so.
>
> The problem is IMHO the design of the Linux IPSec implementation.
>
> I'll compare what freeswan did with what Linux 2.6 does now:
>
> Freeswan has virtual devices (ipsec*), through which the unencrypted
> packets come into the system. So you can add these firewall lines:
>
> - allow AH, ESP, UDP/500, deny rest on eth0
> - allow IPs/networks, etc. on ipsec0
>
> With Linux 2.6 I don't have virtual devices. This means that my IPSec
> packets enter the physical device twice:
>
> 1. esp encrypted packet enters
> 2. Linux decrypts it
> 3. Linux sends the unencrypted packets through the same device again
>
> The problem with that is, that
>
> - allow AH, ESP, UDP/500, deny rest on eth0
>
> will deny the _content_ of my encrypted packages (step three is broken).
>
> Wouldn't this work fine, if we have the virtual device like freeswan had
> or is netfilter broken with this?
>
> I mean I cannot practicly setup an IPSec only access point with the current
> netfilter and ipsec in Linux 2.6, or am I deadly wrong?
>
> Greetings,
>
> Nico

We solved the problem by marking ipsec traffic in the mangle table 
(PREROUTING). This mark is preserved when the packet gets decrypted. So 
basically:

* if a paket is AH, ESP mark it with 1 in mangle table, PREROUTING chain

* if you see non-ip-sec pakets: if it is marked with 1 it is a decrypted ipsec 
packet, otherwise it came in unencrypted.

Greetings,

-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Re: IPSec - IPTables issues

[Aleksandar Milivojevic]

Antony Stone wrote:
> On Wednesday 05 May 2004 5:08 pm, John A. Sullivan III wrote:
>>Please pardon my ignorance; I haven't yet played with 2.6 and the native
>>IPSec.  So how does one distinguish packets which have arrived from an
>>IPSec tunnel and are now re-traversing netfilter from those which have
>>arrived unencrypted and are traversing netfilter for the first time?
> 
> That is a very good question, and one to which I am not aware of a good 
> answer.   In my (extremely limited) experience of looking at IPsec in the 2.6 
> kernels this is a major disadvantage of the design, and means it is not 
> possible to secure a VPN (by which I mean selecting which traffic is allowed 
> down it and which is not, as it was possible to do with FreeS/WAN by writing 
> netfilter rules specifying ipsecN as the output interface).

In general case, both of you are right.

However, in practice, you will always require all traffic from selected 
IP addresses to be encrypted.  After all, the original question was how 
to achieve that kind enforcement.  The solution is to enforce it by 
IPSec policy, so you do not need to worry about it when writing your 
firewall rules.  If you see unencrypted packet traversing Netfilter 
chains, than it is traversing it for the second time.  If packet arrived 
in clear text from the wire, it would be dropped by IPSec module (and it 
is irrelevant if packet is first handad to Netfilter or IPSec, in either 
case it will be dropped long before it reaches userspace or any other 
part of kernel).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: IPSec - IPTables issues

[John A. Sullivan III]

On Thu, 2004-05-06 at 11:59, Aleksandar Milivojevic wrote:
> Antony Stone wrote:
> > On Wednesday 05 May 2004 5:08 pm, John A. Sullivan III wrote:
> >>Please pardon my ignorance; I haven't yet played with 2.6 and the native
> >>IPSec.  So how does one distinguish packets which have arrived from an
> >>IPSec tunnel and are now re-traversing netfilter from those which have
> >>arrived unencrypted and are traversing netfilter for the first time?
> > 
> > That is a very good question, and one to which I am not aware of a good 
> > answer.   In my (extremely limited) experience of looking at IPsec in the 2.6 
> > kernels this is a major disadvantage of the design, and means it is not 
> > possible to secure a VPN (by which I mean selecting which traffic is allowed 
> > down it and which is not, as it was possible to do with FreeS/WAN by writing 
> > netfilter rules specifying ipsecN as the output interface).
> 
> In general case, both of you are right.
> 
> However, in practice, you will always require all traffic from selected 
> IP addresses to be encrypted.  After all, the original question was how 
> to achieve that kind enforcement.  The solution is to enforce it by 
> IPSec policy, so you do not need to worry about it when writing your 
> firewall rules.  If you see unencrypted packet traversing Netfilter 
> chains, than it is traversing it for the second time.  If packet arrived 
> in clear text from the wire, it would be dropped by IPSec module (and it 
> is irrelevant if packet is first handad to Netfilter or IPSec, in either 
> case it will be dropped long before it reaches userspace or any other 
> part of kernel).

Thank you very much for your responses.  This issue will become very,
very important to us in the ISCS project (http://iscs.sourceforge.net)
as we incorporate support for the native Linux IPSec stack.

I assume you mean that this decision is made on a per connection basis
otherwise how would we use the same box to handle VPN connections from
the internal network and Internet access to a DMZ.  In other words,
(again I am completely ignorant of the syntax), we would say all traffic
coming from the 10.1.5.0/24 network must be encrypted or dropped while
traffic not from the 10.1.5.0/24 network can be unencrypted and passed
to iptables.  We would then have rules such as 
iptables -A FORWARD -s 10.1.5.0/24 -d SpecialSecureInternalServer -p tcp
--dport ftp -j ACCEPT
iptables -A FORWARD -d PublicServer -p tcp --dport http -j ACCEPT

I assume we are protected from spoofing because if a public user spoofs
10.1.5.8, it will be dropped because it is not encrypted.

Have I followed you correctly thus far?

This still presents the ISCS project with problems.  ISCS is designed to
handle very complex security.  How would this native IPSec solution be
handled in the following two problem cases.

First, both to minimize the size of the rules set and to allow RAS users
to route through the entire VPN cloud from a single VPN gateway, we both
separate the evaluation of source and destination and make all security
decisions on the gateway protecting the Accessor (our term for a user,
i.e., the source) and not the one protecting the Resource (i.e., the
destination).

In other words, we do not write monolithic rules like:
iptables -A FORWARD -s TheAccessor -d TheResource -j ToSomeAction

Instead, every gateway in the cloud knows about every resource.  When an
Accessor attempts to access a Resource, the Accessor sends the packet to
its protecting gateway where it encounters a rule which evaluates only
the source, e.g., 
iptables -A ACCESS_GROUPS -s TheAccessor -j
ToAccessorGroupMembershipChain

It jumps to the GroupChain (how we implement policies which grant access
based upon hierarchical group membership with inheritance) where it
encounters rules that jump the packet to the Resource Group chains (the
other half of how we implement policies which grant access based upon a
hierarchichal grouping of both Accessors and Resources with inheritance)
where it encounters only ACCEPT (or DROP in the case of DENY policies)
rules, e.g., 

iptables -A AccessGroupChain -j ResourceGroupChain

iptables -A ResourceGroupChain -d x.x.x.x -p y --dport z -j ACCEPT

Thus, the access control decision about what is allowed in the tunnel is
made at the ingress point.  To avoid all gateways having to make the
exact same decision again and to avoid requiring all gateways to know
about all possible Accessors including RAS connected ones, the remote
(Resource) gateway trusts the decision of the local (Accessor) gateway
by allowing all traffic coming out of the tunnel.  How would I identify
this traffic without knowing the source IP (communicating the source IP
for every RAS connection would be a nightmare)?

Second, we would eventually like to encrypt data based upon the needs of
the data rather than the network path.  In other words, there may be a
VPN connection between gatewayA and gatewayB but, the encryption
strength varies based upon the data we are passing between them.  If we
are passing very sensitive data, we might use AES, if we are passing
only moderately sensitive data, we might use DES and if we are passing
public data, we will pass it in the clear.  This not only saves CPU
cycles but provides a powerful and legal way to allow access to less
sensitive data in areas with encryption use restrictions without
compromising security for the entire site.  This again makes it
important to identify the data as emerging from the tunnel whether it is
encrypted or not.  How would we do this?

I understand this is a long e-mail so feel free to ignore it.  These are
issues I will need to resolve once we get the first release of ISCS out
the door.  Thanks - John
-- 
Open Source Development Corporation
Financially Sustainable open source development
http://www.opensourcedevelopmentcorp.com