[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Results of the IPSEC document reading party
Ben,
(I flipped your post, 2nd issue 1st, 1st issue 2nd)
> Rescinding the
> original concession, I look at the SADB that Dan proposes. Regardless
> of the interpretation, if we want to claim that only one SA matches a
> telnet packet from host a to host b (whether it be first, or most
> restrictive), what we are essentially saying is that we are working with
> the following set of SA's (order rearanged to simply notation):
>
> Ht = { all telnet packets from host a to host b }
> Hp = { all packets from host a to host b } - Ht
> Np = { all packets from net A to net B } - Ht - Hp
>
> which is nice and non-ambiguous, but it assumes that we have some way to
> do these sorts of set operations on the implicit sets defined by a given
> set of selectors.
Yes, that's my point exactly. We should decide on "some way to do these sorts"
otherwise we will not have interoperability.
> Moreover, it also assumes that we could deal with the
> situation where we first negotiate:
>
> Np = { all packets from net A to net B }
>
> and then want to negotiate a more restrictive rule for all packets from
> host a to host b. This looks to me to require an implicit renegotiation
> of the selector set for Np.
Why can't we deal with that situation? I know of vendors whose implementations
can deal with this situation just fine.
I think we have to deal with this situation. In my opinion it is a Good Thing
to have shared and unshared SAs exist simultaneously in the SADB and to enforce
the policy that created them. I can envision real world situations where
people want certain protection for all resources on a subnet _except_ for
a particular one (or two...) which will have different protection. If we don't
decide on "some way to do these sorts" then you'll use any old SA that you
happen to have (because it is valid in your opinion since we did negotiate
it) and I'm going to throw it on the ground because it doesn't match my
local policy.
Now back to your first example:
> I'm mostly concerned about the following situation:
>
> net A and net B are connected via two security gateways (call
> them Ga and Gb). These gateways agree on the following SADB
> entries:
>
> all packets from net A to host b
> all packets from host a to net B
>
> Now, Ga receives a packet from host a to host b. He cannot
> decide which SA selector is more restrictive because neither
> are. (I think this is how we got started on the original
> conversation, no?)
>
> So, we'd have to figure out a way to make one of these "better" than the
> other. One approach was to say that the first is the one that we'd
> always choose (in the case that they are otherwise of equal
> preference). However, I would claim that both of the SA's are
> perfectly valid for this type of traffic, and either should be perfectly
> acceptable.
That policy is ambiguous so the resulting SADB will be similarly ambiguous.
Can we prevent an administrator from implementing ambiguous policy? Should
we? I don't think so.
If such policy was configured and 2 sets of SAs ended up being negotiated
then there is no "better" one. In that case I guess you'd have to accept
a packet from host b to host a using either of your 2 inbound SAs. You (the
administrator) made that bed, now lie in it. We should follow the example
set my other developers of munitions: "point away from foot when firing".
But it seems to me that for unambiguous policy we can have a standard,
unambiguous, way to do those sorts-- to decide which is "better".
If my unambiguous policy says: "all traffic from net A to net B is
protected by FOO except traffic from host a to host b which is protected
by BAR" then why can't we decide that receipt of a packet from host b
for host a that is not protected by BAR MUST be dropped?
Is this not a Good Thing?
We could define the sorting to be "most restrictive" and then say that
"Specific selector entries are always more restrictive than wildcard entries."
This would be nice and unambiguous except in this situation:
address service
--------- -------
wildcard telnet
specific host wildcard
which we could unambiguously agree to say that specific services are always
more restrictive than specific addresses. And in the situations where you
have ambiguous policy then your sort is done ambiguously and you live with
the results, or lack thereof.
Perhaps this isn't the best way to define the sorting. I'm not claiming it
is, only that it's something for the WG to consider and I really really
really believe that the WG should consider a standard, unambiguous way to
define sorting. Just saying, "take the first one" doesn't work.
Dan.
P.S. Dynamically changing policy-- where the administrator on one side adds
more restrictive policy to his gateway or host and packets start to be
silently dropped-- should be an IPSecond issue.
Follow-Ups:
References: