[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a drop/bypass action negotiation issue
Hi, Inder.
-------From Inder:
:I disagree with policy negotiation, this can become
:a considerable security hole which a network
:administrator configuring policy cannot comprehend. Does this
:negotiation mean, secure when you can, not-so-secure when you
:can't? (borrowing very common phrase..).
:Can you give me an example where such negotiation would help
:security?
:
:Thanks,
:Inder
Easily. Just consider the way an administrator will manage your
personal laptop when you are working with office from home.
He/She has to provide you with the list of (let's call it)
SPD entries, which will much the Corporate Security Policy.
There is no problem with that, except the list has to
be somehow delivered on your machine and updated there.
The problem is how the list will coexist with _your_
intention to visit a favorite WEB or protect _your_
system from a friend you are playing 'in hackers' with?
What should be the order in which the Corporate SPD
entries are inserted into your local SPD file?
How long they should be there?
Now consider the following way.
Since you have to traverse a Corporate firewall whenever
accessing your mail/ftp/nfs server, an administrator can
just provide you with one Certificate (the firewall's one).
You _always_ do a SA negotiation either with a gateway or
directly with a server. You may get one of the:
secure, bypass, or sorry replies.
For you at home does it make any sense what the policy
the remote peer is dictating, if you do need _get access_
to information rather than _protect_ the laptop resources?
In turn, even working from inside a Corporate LAN,
why you don't consider ISAKMP as the proven carrier
to distribute Security Policy on the network
terminals?
Sure you might want to have this kind of negotiations
disabled, but, probably, not as the statement in the
IPsec standard.
Did I answered your question?
Sorry for the reply-delay,
---Alexei