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

Results of the IPSEC document reading party

Theodore Y. Ts'o writes (quoting Dan Harkins' minutes):

>   2. Arch doc seems to mandate that the "first" SA bundle be used to 
>      protect targeted packets and not the most restrictive. E.g. if there
>      are SAs in the SADB currently for:
> 
> 		all packets from net A to net B
> 		all telnet packets from host a to host b
> 		all packets from host a to host b
> 
>      (in that order) and a telnet packet from host a to host b comes along
>      the most restrictive SA (the one with the most exact matches vs. wild-
>      card matches), the one specifically for telnet packets from a to b
>      should be used and not "the first". 
> 
>      I'm not sure I agree with this contention but the issue did arise.
>      As an aside, we (cisco) _always_ use the most restrictive SA as that
>      seems the best way to build and properly use shared SAs.

Sorry to jump into this particular conversation a bit belatedly, but I
was waiting on a response from Bob to an issue I had wanted resolved
before bringing this to the group.  But, he's evidently too busy to
respond, so here we go:

I'm a bit more concerned about the larger issue here, which is the idea
that one SA selector set might be "better" than another, even when they
both provide matches on a given packet.  For the moment I'll concede the
above point to Dan (for the case he mentions) while I stir up a little
trouble elsewhere.

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.

More to the point, I'd argue that if we support this selector scheme,
then we should never have conflicting selectors.  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.  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.


I would suggest that if we were to stick with the concept of selectors,
then we use them literally.  If a given packet matches the selectors of
more than one SA, then it can be en/de-capsulated by any of them.  I am
very uncomfortable with the implication that a second ISAKMP negotiation
can change the meaning of an earlier negotiation.

If you elect to prefer one SA over another for encapsulation, that is
your business.  But you cannot require that I do the same.  If that is
your intent, then I would require that you negotiate a deletion of the
less restrictive rules, and renegotiate them as non-overlapping sets.


ben

PS- Before anyone takes this message as my tacit approval of the
selector concept in general, I want to note that I am merely pointing
out what I see to be one weakness.  The rest will follow as a response
to the notes on the discussion I had with Stephen Kent, Cheryl Madson
and a number of others near the end of the document reading.  If this is
not posted (was anyone taking notes at that time?), then my comments
will come unsolicited... :)
Follow-Ups: References: