Re: No SPD

[Charles Lynn <[e-mail]>]

> with respect to the draft-ietf-ipsec-arch-sec-04.txt
> 
> "The following table summarizes the relationship between the "Next Header"
> value in the packet and SPD and the *derived Port Selector value for the
> SPD and SAD.*"
> 
> Above paragraph says that derive the port selectors value for both SPD and
> SAD. Why one should derive the port selectors value for SPD. I think the
> port selectors value for the SPD is determined by the administrator not by
> the "Next Header" value in the packet and SPD. I think we have derive the
> port selectors value only for the SAD.

Think of the case of a security gateway at the head of a tunnel, i.e.,
outgoing processing.  If the packet arriving from inside is already
protected by ESP end-to-end, then the security gateway will be able to
determine neither the transport protocol (since ipsec protocol is no
longer a selector) nor the source and destination ports.  How is that
packet processed against the SPD to find the matching SPD entry?

When we had "opaque", one could place the policy entry containing opaque
protocol and ports either before or after policy entries with the same
source and destination addresses and explicit protocol and ports; but
opaque has been removed so that freedom is no longer possible.

If one makes the explicit wildcard SPD entry choice, as you are
suggesting, then the result is that the entry is essentially "after".
Trying to place it before the explicit entry would effectively hide the
explicit entry since anything that would match the explicit entry would
also match the wildcard entry preceding it.

If one makes the "derive (protocol and) port selector value" choice, as
the document is written, then one has a single SPD entry that is a
combination of the two.  However, one has the possibility that the SPD
entry that will be matched is not the "expected" one, but some previous,
possibly explicit, SPD entry that has the same source and destination
addresses, but different (protocol and) port selectors.

We need to make a decision, and live with it's pluses and minuses.

The situation for fragmentation is really ugly.  Life was relatively
simple when fragments (arriving at a security gateway) for outbound
processing were simply dropped (with associated PMTU processing).
Trying to permit fragments to enter a tunnel has a range of
implementation choices, many of which can lead to interoperability
problems and possible failure of the expected security mechanisms (and
possible resulting litigation).

One issue is making sure that the second to last fragments receive the
same protection as the first fragment.  For example, I would not want to
be the Security Officer who tells the CEO that the trade secret which is
the basis for the company's existence was lost because the first
fragment utilized the confidentiality service but the other fragments
only received integrity protection.

I suspect that making sure all fragments receive the same protection
will lead one to create dynamic SPD entries, logically inserted before
the "configured" SPD entries, based on <source and destination
addresses, protocol, IP Identifier>; or an alternative of doing the
queueing (the first fragment might not be the first to arrive at the
security gateway) and bookkeeping associated with IP Reassembly to
direct the latter fragments to the same SPD as the first.

Then, if there is an ESP header, one looses transport protocol as well
as ports resulting in a less specific policy.  Then, if there are
redundant security gateways, not all fragments may be routed to the same
security gateway.  Does one really want to try coordinating things
between security gateways?  In general, it seems like a lot of code, for
a (hopefully :-) few packets, that may be very hard to get right, and to
interoperate (with the input SPD implementation at the tunnel endpoint).

Charlie