[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.
---