[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q about SA bundles
There is a great leap of faith in this statement: "H2 receives the
packet and successfully applies SA1 and SA2 to this." If both sides
have identical configs your scheme could work but that seems somewhat
limited to me. What about permiscuous policy or opportunistic encryptors?
They might not know that SA1 _AND_ SA2 have to be applied because they
were not told so. Also, H2 doesn't know that H1 will end up making that
2nd offer. 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.
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. It will be impossible to configure such policy in your
implementation so you'll never have to worry about offering it and you
can just hope the the other box won't offer it to you. But if you do think
they're useful then such a policy statement is valid. So we have a valid
policy which can be properly expressed by KM in a straightforward,
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.
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.
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....
Dan.
On Thu, 21 Jan 1999 14:55:57 +0200 you wrote
>
> > From: Mohan Parthasarathy <Mohan.Parthasarathy@eng.Sun.COM>
> > Last time this was discussed, somebody replied
> > "While you are negotiating AH IPSEC SA, and the other end's policy
> > requirement is ESP + AH, how does the other end know you will
> > negotiate ESP after negotiating AH i.e should the other side
> > accept the negotiation assuming you will negotiate ESP in
> > a short while or reject assuming that you are not negotiating
> > ESP " ?
>
> A short answer:
>
> While negotiating AH IPSEC SA, the responder site doesn't need
> to know or care whether it is associated with a AH+ESP bundle
> or not.
>
> Longer answer:
>
> H1 H2
> ------------------------ ------------------
> (0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1
> \ ^ ^
> \ | |
> \ | |
> (1) ACQUIRE SA: H1->H2 | <-- Key Mgmnt --> |
> \ |
> ------------------------------> (2) GETSPI: dst=H2
> | UPDATE SA: dst=H2
> | /
> /
> (3) ADD SA: dst=H2 <--------------------
>
>
> The initiator (H1) only has the PFKEY ACQUIRE information to go with,
> and it simply includes a list of algorithms from which to choose (the
> other information is address and identity)
>
> Thus assume, a policy saying
>
> dst=H2 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5)
>
> then, the ACQUIRE for AH contains combinations
> 1) md5
> 2) sha1
> 3) foo
> all of these supported by the initiator side. This list is passed to
> the responder (H2).
>
> The responder host only supports md5 and sha1 (known to the key
> management from the reply of the PFKEY REGISTER message).
>
> My claim and goal is: The responder side of the negotiation
> does not need to care about the policy.
>
> It only selects the SPI and chooses the algorithm from the proposed
> list (md5, sha1, foo), and as it only knows the first two, it can pick
> either one, say sha1. It creates the end point SA and reports back to
> the initiator the SA attributes, so that it can create the starting
> point of the SA.
>
> The ESP is handled exactly the same way, independently. and ending
> with, for example, (3des,md5) for ESP. With SAs set
>
> SA1 (AH: sha1) --------------------> SA1 (AH: sha1)
> SA2 (ESP: 3des,md5) ----------------> SA2 (ESP: 3des,md5)
>
> H1 is finally able to send a packet to the H2. H2 receives the packet
> and successfully applies SA1 and SA2 to this. And, only *after* this
> it needs to be checked whether the policy is matched. For example
>
> src=H1 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5)
>
> Looking for a matching SA for AH(md5, sha1, foo) and packet, it should
> return SA1, and for ESP(3des, idea, blowfish, md5) it should return
> SA2. If this happens, the policy condition is filled and packet
> passes, and otherwise not.
>
> [I admit that the above matching part is somewhat untraversed
> territory for me, as my policy defition doesn't (yet) have
> alternatives for the algorithm, policy just says use one or
> don't communicate. With multiple choices of algorithms, the
> search may(?) result with one SA per algorithm, and my guess
> is that if the applied SA is included in such result, the
> policy passes.]
>
> My key premise here is still: policies on both ends must be same.
>
> Note also, that I have included 'foo' in the policy of H2, even though
> it does not support it. The idea is that, if the support for 'foo' is
> added to the kernel IPSEC, then it becomes automatically available for
> the negotiations. This allows gradual deployment of new algorithms.
>
> ********************************
>
> SOME OTHER COMMENTS:
>
> - assuming policy with bundle ESP+AH, there is nothing in PFKEY
> ACQUIRE (unless I missed something), that would tell the key
> management that these two ACQUIREs are actually from the same
> bundle. [And I think this is a good thing ]
>
> - with all this, I am only trying cut down the implementation work
> into manageable pieces, most important being the ability to
> describe the pieces of IPSEC in exact manner. These descriptions
> can be used to decide which implementation is correct, when
> problems surface.
>
> - there are many fuzzy areas, for example, how do ACQUIRE information
> and the resulting SA information relate to each other, specifically
> things like SRC_ADDRESS, PROXY_ADDRESS, IDENTITY etc. How much
> freedom the keymanagement really has? For example, my current
> implementation
>
> if ACQUIRE has exlicit SRC_ADDRESS, and the resulting ADD SA
> does not include the same source address extension, then my
> SA locating does not find the SA. And vice versa, if ACQUIRE
> does not have the SRC address, it should not be present in
> the SA either (IADDR_ANY). [The presence of SRC and other
> things in ACQUIRE is mostly controlled by the policy
> definition, which is very delicately involved in the SA
> locating, as can be deduced from my descriptions... ]
>
> --
> 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/ms
>a/
Follow-Ups:
References: