[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-palet-v6ops-ipv6security-00.txt
Hi Brian,
Thanks a lot for your inputs.
My comments below, in-line.
Regards,
Jordi
----- Original Message -----
From: "Brian E Carpenter" <brc@zurich.ibm.com>
To: "IPv6 Operations" <v6ops@ops.ietf.org>
Sent: Friday, March 26, 2004 9:18 AM
Subject: Re: I-D ACTION:draft-palet-v6ops-ipv6security-00.txt
A few comments (not including nits; this is in the spirit of
an early review):
I will make the next version with XML, so a lot of this issues will be ok by default ;-)
> 1.
> Introduction
>
> The todayÆs Internet paradigms for security need a revision with the
> deployment of IPv6, offering end-to-end security capabilities.
>
> Current security policies based on a centric approach with unique
> border devices donÆt longer apply. Often they are based in a firewall
> or security gateway and statically configured rules.
And they don't work either, due to the "crunchy outside, soft inside"
phenomenon (i.e. half of the enemies are inside the firewall). Additionally,
note that the firewall model is deeply incompatible with the model
of virtual organizations that is fundamental to Grid computing - virtual
organizations cross all traditional security boundaries.
[Jordi] Very good input. I will include those aspects in the next release.
> Keeping todayÆs static security model is a wrong approach, which
> disables the end-to-end features and advantages of IPv6.
"disables" is too strong - "interferes with" is more accurate.
[Jordi] Ok.
> Enforcing the nomadic users and devices to connect to Internet by
> means of the security device, is almost equivalent to disable the
> IPsec stack on each node, thus invalidating one of the key IPv6
> advantages.
I don't think this is really true, with current solutions for IPSEC to
traverse NAT, and future solutions from Midcom for firewall traversal.
[Jordi] I will reword it. The main idea is that not all the host, or even NATs or firewalls support this or yes ? This is the same trouble we have with the IPv6 transition ...
> On the other hand, is also true and perfectly understandable that
> there is a need to enforce security in the networks, in such way that
> the network administrator has always the control over it.
It's the security administrator who wants control; she is often different
from the network administrator.
[Jordi] I will use "security administrator (or even the network administrator)", as some times is the same (medium and small networks).
Missing argument here: the current enterprise network security model
prevents innovation.
[Jordi] again very good input.
> 2.
> Distributed security model
Please credit Steve Bellovin and his colleagues, who first proposed a
"distributed firewall" model a few years ago.
http://www.research.att.com/~smb/papers/distfw.pdf
http://www.research.att.com/~smb/papers/ccs-df.ps
[Jordi] Will do so. We are already working in some more drafts on this topic, so there will be concrete references to this work and some others with similar views.
> The distributed security model implies the use of node or personal
> firewalls.
>
Not only that. It also implies the use of end-to-end applications level
security (for example the Web Services security standards).
[Jordi] Will include this.
> These node or personal firewalls must respect the security policy of
> the network where they are attached.
It's more subtle than that. If the "home" security policy of a roaming system
is *different* from the local policy where the system is connected, there may
be actual conflict between the policies. To take a trivial case, local
policy might prohibit ICMP messages, but the home policy might require ICMP
probes for some checking purpose. So the solution must allow for resolution
of conflict between security policies.
[Jordi] My point of view is that if the security administrator of the visited network don't allow ICMP we need to respect it, otherwise they will not accept this distributed security model. If they allow using a tunnel, then it might be an option to respect the "wishes" of both policies.
> This is possible in most of the situations because, even if IPsec and
> encryption are enforced for most of the communications, nodes often
> have powerful CPUs with unused cycles that will easily accommodate
> the extra required workload.
Sorry but that's nonsense. Particularly in the case of small roaming devices,
they *don't* have spare capacity. You can argue that capacity for security
should be provided by design, but you can't simply assume there will be such
capacity.
[Jordi] Will reconsider this, may be the text is confusing. The point was not considering roaming devices, but nodes in the infrastructure of the network that could be configured by the security policy/manager to share resources for non IPsec capable sensors or roaming devices (just examples). This could be the case if the firewall doesn't exist (SOHO networks, SMEs), or the firewall capability is exceed by whatever reason. Anyway, when I check my laptop CPU and LAN card usage, usually they are at a very low level of utilization. I guess this is becoming more and more frequent.
> On the other hand, the central firewalls will be able to dedicate CPU
> cycles to new functions, or be able to protect bigger networks.
Should intrusion detection be centralized or distributed?
Also note that the central firewalls will need to support Midcom-style
firewall traversal in future.
[Jordi] I believe they should be also distributed, if we can create a trusted model. Yes, we are already checking the Midcom work.
> 4.
> The visiting node
>
...
>
> Different visited networks have different security requirements.
> Consequently is required that those nomadic nodes dynamically
> accommodate their own security policy to the one defined in the
> visited network.
As noted above, this is subject to the need for conflict resolution
when the policies are incompatible.
[Jordi] Right, but I'm still not convinced, in the sense that the priority must be always the "more strict" policy, otherwise, you can be banned to access that network or even Internet from that network ?
> 6.
> The security policy server and protocol
...
>
> When a node is attached to a visited network and receives the visited
> network security policy, basically there are two possible situations:
>
> a) The network security policy is less or same restrictive than the
> node configuration. In this case, the node will not change its
> security policy configuration.
>
> b) The network security policy is more restrictive than the node
> configuration. In this case, the node will adapt its security
> configuration to at least match the one indicated by the security
> policy.
>
> Until the node performs and acknowledge the required security policy
> configuration update, it will not be allowed to transfer/receive data
> to/from other nodes either in the network or other connected
> networks.
Again the same point. If my employer's corporate security policy has
requirement A and I visit a network whose policy has requirement Z,
it is *not* true in general that A is either more or less restrictive
than Z. It may be that they are simply incompatible. My employer would
require that A wins and the host network would require that Z wins.
So who wins?
[Jordi] That's the point. The more strict one ?
...
> A possible approach is to align this with the existing COPS [iii] and
> COPS-PR [iv] standards.
It's very unclear that COPS will be widely implemented.
[Jordi] COPS was considered as a good option, but we are already considering other options. Obviously the goal is not developing something new if there is anything that can be used "as is" or extended for this mission.
> 7.
> Single versus multiple point of attack
...
> The failure of the central firewall could completely disconnect the
> network from Internet or other networks. In the case of a central
> policy server fail, the nodes can be configured by the security
> policy in such way that continue working, keeping the same security
> restrictions imposed by the policy server.
Instead of "same" I think you mean "most recent."
[Jordi] Right.
On the other hand, during such a failure, there is a risk of incorrectly
or partially configured hosts being wide open.
[Jordi] One option could be a "default" network security policy for this situations, but just a quick thought. Will work on this.
How about a compromised host that pretends to conform to the central
policy but is actually a hacker haven?
[Jordi] Yes, this could happen, even when the central firewall is still working. We are already working on some options here.
> 8.
> Non-security-capable nodes and security workload distribution
>
> Increase in security often means increase in processing power.
>
> Some nodes could not have the required CPU cycles to afford the
> complete required security policy.
>
> The firewalls or even other security-capable nodes with free
> resources, could act as trusted security gateways for the non-
> security-capable nodes.
>
> This seems only possible if minimum security verification can be done
> by those nodes, i.e. digital signature verification.
Why? They don't today. All you need is that if a host fails to say
"yes, I installed your central security policy", then you treat it
as a non-security-capable host.
[Jordi] Right. It was a too quick thought. We need to reconsider this. I will like this feature, but I'm not really convinced is feasible, or even useful. We need to think in a concrete scenario to see if it makes sense.
> 10.
> Virus and spam
>
> As part of the services offered by the distributed security model, it
> should be considered means to alleviate the effects of virus and
> spam.
It seems to me that this is far to complex and expensive to distribute.
Spam/virus filters require contnuous updating of very sophisticated and
large signature files. Since all email flows through mail servers anyway,
I can't see any argument for distributing this complexity. In any case,
it's not an IPv6 issue.
[Jordi] May be you're right for spam, but virus can also come from a device attached to the node (disk drive, CD-ROM, USB stick, ....). We need to evaluate this. What about instant messaging, IRC, file sharing ... I think we need to work on the feasibility of doing this and balance pros/cons.
Brian
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.