[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a drop/bypass action negotiation issue
--- On Tue, 30 Dec 1997 10:47:48 +0300 "Alexei V. Vopilov" <alx@elnet.msk.ru> wrote:
> 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?)
People are sick of hearing this, but the fact is that the
original NRL code included a (simplistic) API for IPsec.
With such an API, it is trivial to inform the application
when some security has been requested but is not available.
That seems like an existence proof to me...
Details of such an API are beyond the scope of the IPsec
protocol specifications, though it would be useful (IMHO)
if IPsecond wrote an Informational RFC describing
extensions to POSIX.1g for IPsec.
> 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?
I don't see this as an issue. It is possible for different
devices to have conflicting policies. Depending on the
extent of the policy conflict, those devices might or might
not even communicate with each other.
> 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.)
Add a knob to one's KM daemon configuration that permits the
system admin to restrict the range of Source Identities that
are considered acceptable to one's own KM entity. See also
the preceding paragraph. Also, note that this knob is NOT a
protocol issue, but the knob's existence is instead a
quality-of-implementation issue.
> 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.
I don't think you have found any insurmountable problems in
the current DOI in the above note. In short, I'm not
persuaded there is a real problem here.
Ran
rja@inet.org
References: