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

Re: Q about SA bundles


> From: Daniel Harkins <dharkins@cisco.com>

> There is a great leap of faith in this statement: "H2 receives the
> packet and successfully applies SA1 and SA2 to this."

There is probably different interpretation of "successfully apply"
between me and you. For me it just means that the IPSEC transforms
defined by SA1 and SA2 are successful on the received packet
(authenctications, replay checks, decryptions etc. all succeed). I
don't see any need for "faith" here, either the packet selects the
correct SA by (dst, protocol, SPI) or not.

> If both sides have identical configs your scheme could work but that
> seems somewhat limited to me. What about permiscuous policy or
> opportunistic encryptors?

First, the IPSEC RFC's do not specify such features. However, I do
think things could be desirable and have considered possibilities of
implementing. But, before it can be done, the base of the IPSEC must
be firmly in place, and this is what I am trying to achieve.

> H2 could end up receiving packets protected by SA1 that he'll just
> end up dropping because they weren't also protected with SA2. In
> fact, I'd wager that you'd probably fully process the packet before
> deciding to drop it. That would almost be the moral equivalent of a
> DOS attack and it would be a bitch to debug to boot.

Anyone can sniff the line and mount an attempt for a DOS attack by
generating correct looking packets using sniffed SPI's and sequence
numbers as a guide. Receiving end would have to process these packets
exactly as much as "real packets" (like compute the digest value). My
way of dealing with bundles doesn't make a difference.
 
> If you don't think compound policy statements like "AH AND ESP" or
> "ESP AND PCP" are particularly useful then you can just ignore the
> whole SA bundle issue.

I'm still trying to follow RFC-2401 and it doesn't appear to allow for

	selector -> apply bundle1 or bundle2

My IPSEC version uses bundles exactly as defined in RFC-2401. What I
am trying to achieve is

 1) The key management does not need to know about bundling at all.

 2) The key management does not need to know about policy (other than
    what it gets via PFKEY interface)

I believe we can achieve all that IPSEC is set to achieve even with
above statements in force. Wouldn't it be nice to have a simple key
management definition that just "managed keys", without any fuzzy
issues that seems to surface, when you mix it with policy.

*IF* there is a need of negotiating policy issues, let that be a
different and independent standard (it could be even an extension to
ISAKMP). This negotiation could transform the "meta policy"
	selector -> apply bundle1 or bundle2
into either
	selector -> apply bundle1
or
	selector -> apply bundle2
to be used in the SPD as specified in RFC-2401.


	Note: PCP is one example where a concept of optional bundle
	item would be useful, e.g have a policy as

	selector -> PCP(null,lzv,gz)?,ESP(..),AH(..)

	and the "SA" for PCP would be negotiated independently, and if
	result is NULL algorithm, no PCP headers would be
	generated. (Perhaps a kludge, but would avoid a need for a
	separate policy negotation for simple cases). The "optional"
	part is needed on receiver end to accept packets, even when
	they don't have the PCP "SA" applied. The sending side would
	need the PCP "SA" place holder to indicate omission of PCP by
	having 'null' as algorithm.


> interoperable way that precludes the problems described above but
> because a PF_KEY ACQUIRE message is unable to express conjunctions
> you're hoping that the problem can just go away if everyone agrees
> to constrain their implementations in a similar manner.

In this sense you are right, I'm trying to reach a solution, where the
"problem" goes away. But, without constraining the
implementations. I'm just trying get the key and policy management
separated.

> The responder _does_ need to know whether the offer is part of a
> bundle.  That was the whole reason that confusing parsing and
> payload numbering text was added to RFC2408.

Thus making it more complex. My view is that they should have backed
off and looked at the situtaion from the viewpoint I'm advocating, and
made the result simpler :-)

> It seems that PF_KEY has put you in a box that you're
> (intentionally?)  not looking out of. Imagine an ACQUIRE-like
> message (with the corresponding ADD/UPDATE-like message) that could
> express compound, conjunctive offers....

Yes, intentionally. I prefer to use simple concepts to build very
complex systems (hey, I like LISP approach!!).

If the current ISAMKP is to be used, what you suggest (complex ACQUIRE
with conjuctive offers) does become necessary. The current ISKAMP and
PFKEY v2 do not work together. And, of course, my point is: ISAMKP
should adjust, not the PFKEY v2.

-- 
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
Follow-Ups: References: