RE: ISAKMP SA negotiation

["Baiju V. Patel" <baiju@xxxxxxxxxxxxxxxxxx>]

Playing the game of chicken is some what tricky for the 
responder. Moreover, it is a matter of policies on the
responder (over which the initiator has no control) as
to which proposal to accept. The fact that the initiator 
specified multiple proposal indicates that all of them 
are acceptable. 

If the responder plays "game of chicken" and the initiator
is "honest to god" simple implementation, responder may 
end up not having secure communication at all.

One can argue that the responder can initiate ISAKMP
and thus will not loose opportunity to communicate as
outlined by me above. However, this too is a matter of
policy on the original initiator. I can see that some initiators
may have a policy that they will always initiate security 
association (e.g., client in a client server paradigm or a firewall).

Nothing stops initiator from trying multiple policies to get
as "strict" acceptance of its policies (unless the responder is 
keeping track of denied SA negotiations and mistakes a 
initiator for someone launching denial of service attack).

So, one can implement mechanisms that be guard
against such "game of chicken" behavior up to an extent
(I don't think there a perfect solution here).

Baiju

On Monday, July 07, 1997 6:23 AM, Rodney Thayer [SMTP:rodney@sabletech.com] wrote:
> There is the implicit assumption that the two parties want to talk to each
> other...
> 
> p.s. if you don't like the proposals you can generate traps ;-)
> 
> At 02:53 PM 7/3/97 PDT, you wrote:
> >
> >Text item: Text Item
> >
> >
> >This does seem a bit strange.  The initiator could just send out its favorite
> >proposal and test for a response.  The responder could wait until it sees its
> >favorite proposal and perhaps accept a proposal it once rejected.  If the
> >initiator and the responder were being very competative and selfish, one
> could
> >image the parties holding out on accepting proposals until it gets what it
> >wants, playing a variant on the game of chicken.  How would one prevent this?
> >
> >-----Original Message-----
> >From:   owner-ipsec@portal.ex.tis.com 
> >Sent:   Tuesday, July 01, 1997 1:53 PM
> >To:     ipsec@tis.com
> >Subject:        Re: ISAKMP SA negotiation
> >
> >> That might be what you'd do but my implmementation chooses P2. In the
> >> example, B has his own policy priority settings; he wants P2 over P1.
> >> In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B
> >> would select P4. I never let someone else override my local policy. It
> >> was set like that for a reason.
> >
> >And what was that reason? :-)
> >
> >If A offered P1, you'd select P1.
> >If A offered P2, you'd select P2.
> >If A offered P3, you'd select P3.
> >But if A offered P1,P2,P3,P4 you'd select P4.
> >
> >
> >
> >
> 
>