[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
a drop/bypass action negotiation issue
The arch. draft introduces two additional
supported filtering actions, such as 'drop' and 'bypass'.
Unfortunately, there is no defined way to _negotiate_
these actions with a remote peer.
Does it seem appropriate to support such capability
in the next drafts?
Consider following examples.
1. An application wants to get access to some bandwidth
consuming service. It is reasonably to protect the request
for a service (e.g. to have secured control channel),
but it is desirable to not have performance impact upon
_using_ that service (for ex. a movie played over Internet).
Thus, a control-application should be aware that
the negotiation of a 'plain' connection is done before
starting corresponded service application.
Otherwise, the only way to resolve a problem with
somehow blocked channel is through the time-proven approach,
I mean the phone call ;-)
2. A client application (assuming the absence of corresponded
local SPD entry) needs to check whether particular service
is allowed for using at a remote server right now.
The 'negotiation' of a disabled SA can simply provide
required context of unavailability of some remote service.
The SA lifetime (if any) can be a hint for a client on
when to apply renegotiations with a remote peer.
This seems to be quite common situation when a light-weight
(and cheap) IPsec client does not need a
sophisticated policy management, but instead relies on
the policy dictated by the server side.
I think that support of the above examples will serve towards
synchronization of security polices on both ends of a
communication channel.
Overall IPsec approach (unlike other closed technologies)
gives users a _hope_ that it can be done, but does
not even highlight the policy negotiation/management
technique at the current development stage.
>From my experience the lack of standards
for flexible security policy management
will be the most barrier for wide deployment corresponded
network security products. In turn, the administrative
cost of the management of a network security system
gets much higher if there is no low-level support for
that built into underlined technology.
Does the mentioned problem make any sense
for IPsec folk to discuss even under 'IPsecond' label?
regards,
---
Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694
Software Architecture&Development Consultant.
---