[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a drop/bypass action negotiation issue



Noam,

The first issue (as you defined it) implies also a case when
the port for service-traffic might be just randomly selected.
Consider an example where you have IPsec enabled FTP client.
If ftp-data are to be secured, your ftp-client _can_
_negotiate_ corresponded association with a remote peer.
But the case when ftp-data are to be passed in clear,
the only thing you can perform is set such SPD entry
_locally_ (and dynamically?) with no guaranties the
channel will be really established.
You cannot track potential problem because the way for
remote peer to tell you about it is not defined.

As about second issue, denoted in your response.
The problem is not only with policy distribution
and management, but also with the definition what
Security Policy means and how it works.
Unfortunately, the mention about security policy
is in the current arch draft, but is so less
developed that it might be better just remove some
of the draft statements.

>From the other hand, the Pass/Drop actions support,
the wildcards for IP address, protocol, port - all
this requires explanation of the IPsec _logic_ when
doing such things under real network environments.
Though, I do not say that this logic, even if
detailed, will completely clarify Security Policy
issues for IPsec.

Trying to compose some proposal for Security Policy
requirements, I meet with difficulties to understand
the logic of IPsec under particular operational
environments.
Restrictions for the IPsec logic means
(beside functionality) the same for the scope
of Security Policy.

By the way, do the potential customers of IPsec,
who are on this list, just throw examples below as
being rare cases?

The following cases are first addressed
to the logic and then to the policy issues.

1. How an application can be aware that the requested
   IPsec service will be definitely performed
   even it is allowed by an administrator, policy, etc.?
   (Like, upon system start the default policy was
   activated, so the standalone host did negotiate
   a fat secured channel through a firewall to internal
   network. Now an application on that host wants to
   negotiate particular connection to internal network
   under _dedicated_ crypto context.
   It might be done even with the same certificates,
   but prove me that drafts allow such service
   to be provided?)

2. How an implementation has to react, when a remote
   peer responses with SPI value already in effect for
   a past negotiated SA even the policy implies such
   behavior?
   (Like, a remote peer has negotiated a telnet connection
   through a gateway. Now it tries negotiate ftp connection.
   If the gateway policy says:'do the same SA context
   for all traffic with the same remote address',
   there is nothing extraordinary here.
   But a remote host did not know that telnet connection
   will be followed by ftp one, so it did negotiated only
   the first one to be the scope of first SA.
   May be the draft states that the same SPI must never
   be used for different SA requests?

3. How an IPsec implementation can restrict a remote user
   (read certificate) to access only from known IP addresses?
   (Like an ISP wants to allow secured access for it
   customers, but only from ISP dial-in facilities?
   Note: IP address here acts as a SA restraint rather than
   as a key ID selector.)

Other environments can be highlighted as well.

I agree that many IPsec functions and services can be
just cut off in IPsec-first, but how to make continuity
for IPsecond? Another word, how to do development
of new functions for IPsecond without redevelopment
of base IPsec drafts? I would be happy if everything
can be done with just new DOI, as it was probably
intended, but not sure this will work.

regards,
--Alexei

-----Original Message-----
From: Borovoy, Noam <nborovoy@oas_mail.brea.interlink.com>
To: 'Alexei V. Vopilov' <alx@elnet.msk.ru>; IPsec MailList <ipsec@tis.com>
Date: 19 декабря 1997 г. 23:42
Subject: RE: a drop/bypass action negotiation issue


:You're raising two very different issues:
:the first: securing some "control" communication while allowing the
:resulting service trafic to go in the clear, there are basically two
:possible situations:
:-the control trafic uses different protocols or ports from the service
:trafic - in this case the currently defined selectors should be enough.
:- the control trafic uses the same protocol and port as the service
:trafic, in this case the overhead to change the control application to
:negotiate a 'clear' connection for the service trafic would be probably
:greater than simply changing it to use a different protocol or port that
:would be defined by policy to be in the clear.
:
:On the second issue - policy management and distribution - there needs
:to be a lot of work done in IPsecond to enable future interoperability.
:I'll second you on policy negotiation and management being key to any
:wide deployment, there certainly should be more discussion on this
:topic.
:
:Regards,
:Noam Borovoy
:






Follow-Ups: