[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Move TS to optional (RE: Don't remove TS from IKEv2)
Mike, what you suggest is a valid alternative to TS. However, if you want to
understand what the purpose of TS is, it might be helpful to think of them
as an SPD optimization. For every packet that comes in (in addition to
enforcing your regular firewalling rules), you must ensure that it
originates from a valid IP, on an SA that was negotiated using the correct
IKE identity, and that the SA uses the required cryptographic transforms.
This is all part of the SPD check.
Doing this check for every incoming packet could be very expensive, so it
would be nice to have a cache of the selector->SA binding, and that's what
the TS does. When you receive a packet on the SA, you simply compare the TSs
and this guarantees both that the transforms are acceptable and that the
TS->id binding is correct for this flow. Of course, in order to use this
optimization, you must be able to guarantee that the TS->SA binding is the
best match for any IP/port in the TS. In the general case, this means that
your SPD lookup matrix must be invertable. This is why Steve Kent keeps
pushing the "decorrelated SPD" model that will be incorporated into RFC
2401bis.
Note that the use of TS I just described does not necessarily mean that you
have to send the TS on the wire. You could simply attach them to the SA data
structure on your end, and this would allow you to express more complicated
rules. The reason for sending them on the wire is that IKE acts (among other
things) as a policy agreement protocol. By sending the rules you will
enforce to the peer (or a subset thereof), you make it easier for the user
to diagnose configuration errors. (And since you theoretically already have
the TS from the SPD caching mechanism, it isn't difficult to send them on
the wire.)
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mike Ditto
> Sent: Friday, March 29, 2002 7:19 PM
> To: dharkins@tibernian.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2)
>
>
> On the specific idea of making TS optional, isn't it effectively
> optional already? Can't an implementation that has no use for them
> always propose wildcard selectors, and always accept (and ignore) any
> selectors proposed to it?
>
>
> Dan Harkins <dharkins@tibernian.com> wrote:
> > If the selectors that defined your particular SPD entry
> allowed this
> > received packet already then no "broadening" would be necessary.
>
> That depends on what you mean by SPD. Do you mean the
> traffic selectors
> affiliated with each SA, as communicated by IKE/SOI/whatever?
> Or do you
> mean the configured policy that I must enforce? They are quite
> different things. Traffic selectors as currently proposed are simple
> sets of addresses, protocols, port numbers and the like. My
> policy is,
> in essence, a function that takes a packet as input and produces a
> boolean output. I can't take some selectors and see if they match my
> policy, and if I somehow encode my policy function (say, as a
> Java class
> file or a bit vector with a value for every conceivable IP packet) and
> send it to you when we're negotiating a tunnel, it will be just as
> useless to you as your traffic selectors are to me.
>
> I could, with a lot of otherwise unnecessary work, generate a set of
> selectors that loosely approximates my policy, and use them
> to negotiate
> a tunnel with you. If your end does reduce the set at all, I have no
> way of knowing whether that subset will actually allow the services I
> want to use over that tunnel. In general, the "approximation
> selectors"
> will include some things that aren't really included by the policy, or
> exclude some things that are, or some of both. So there will
> always be
> a discrepancy between the actual policy and the traffic
> selectors. This
> could probably be lived with if the discrepancy was small, like a few
> corner cases. But for some commonly used services, the discrepancy is
> so large that the selectors have no value (because they are wildcards)
> or prevent interoperability (because they are too constraining).
>
>
> > A new
> > packet that required "broadening a tunnel's traffic
> selectors" would BY
> > DEFINITION be dropped on the other side so there is no
> point in sending
> > it under protection of that SA in the first place.
>
> That is only true if each end somehow knows exactly how the
> other end's
> policy actually differs from the negotiated traffic selectors. I can
> see how this could work if both ends are the same
> implementation, or if
> both are trivial implementations that don't have any policy other than
> addresses and port numbers. But I don't see how it can work in real
> life.
>
>
> > If we choose to just do away with the TS payloads (as you
> suggest) then
> > we have no standard way of agreeing on anything. What would
> happen is that
> > two boxes would be correctly configured to protect FOO
> (some protocol) but
> > because the definition of how to implement protection of
> FOO is left to the
> > imagination of those implementing IPsec the two boxes might
> not interoperate.
>
> We can still agree about any particular packet, which is the
> only thing
> we have agree on. I don't see why they wouldn't interoperate, unless
> their respective definitions of the service are actually incompatible,
> which is equally possible regardless of how IKE works or even whether
> IPsec is in use at all.
>
>
> -=] Mike [=-
>