Subject: Question on IKERejectAction in IPsec information model

From: "Wang, Cliff" <[email-masked]>
Date: Mon, 19 Feb 2001 19:11:22 -0000

In the information mode:

6.5. The Class IKERejectAction

   The class IKERejectAction is used to prevent attempting an IKE
   negotiation with the peer(s).  The class definition for
   IKERejectAction is as follows:

   NAME         IKERejectAction
   DESCRIPTION  Specifies that an IKE negotiation should not even be
                attempted.
   DERIVED FROM SAStaticAction
   ABSTRACT     FALSE
   PROPERTIES   DoLogging

What is the action on the packet, discard/drop/use static SA? It only
specifies no IKE negotiation.

---

From: "Jason, Jamie" <[email-masked]>
Date: Tue, 20 Feb 2001 17:18:49 -0800

That is what I was thinking as we already have a mechanism in place (via the
static actions bypass/discard) for noting that we don't wish to do any IKE
for certain types of packets.

Jamie

> -----Original Message-----
> From: Eric Vyncke [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2001 4:54 PM
> To: Jason, Jamie; 'Wang, Cliff'; [email-masked]
> Subject: RE: Question on IKERejectAction in IPsec information model 
> 
> 
> Jamie,
> 
> As far as I can remember, this action was mainly to reject an IKE
> session from specific peers. I.e. actually denying a remote peer
> to send IKE packet to us. The filter could be on IP addresses or
> IKE identity (in the case of aggressive mode).
> 
> Hence, if I am not mistaken, the description is wrong and should
> be fixed.
> 
> Cliff, 
> 
> this action should only be applied for inbound filters for
> UDP/500 or from some IKE identities.
> 
> -eric
> 
> At 09:12 20/02/01 -0800, Jason, Jamie wrote:
> >Cliff,
> >
> >let me look into this and see if the DMTF model/whitepaper 
> sheds any light
> >on it.  Upon re-reading the section, it seems to be vague 
> and at a minimum
> >should probably discuss the different scenarios when that 
> particular action
> >may be triggered (i.e., data packet sent/arrived with no SA, 
> IKE packet
> >arrives, etc.).
> >
> >Jamie
> >
> >> -----Original Message-----
> >> From: Wang, Cliff [mailto:[email-masked]]
> >> Sent: Monday, February 19, 2001 11:11 AM
> >> To: [email-masked]
> >> Subject: Question on IKERejectAction in IPsec information model 
> >> 
> >> 
> >> In the information mode:
> >> 
> Eric Vyncke                        
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: [email-masked]          Mobile: +32-475-312.458 (CHANGED)
> PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
> 
>

---

From: "Wang, Cliff" <[email-masked]>
Date: Thu, 22 Feb 2001 19:30:54 -0000

Yes, I see the intended purpose of this IKERejectAction.
But I am still doubtful about its usefulness.
When you find that an incoming ID mis-matches, I think that
a sane IKE implementation would drop the negotiation there.
Looking up the rule again for this default rule seems
unnecessary, or I am missing something?

-----Original Message-----
From: Lee Rafalow [mailto:[email-masked]]
Sent: Thursday, February 22, 2001 12:36 PM
To: [email-masked]
Subject: Re: Question on IKERejectAction in IPsec information model 

The intent of the IKERejectAction is to specify the drop rule for UDP port
500.  The implementation of this drop rule is more likely to be in the stack
than in the IKE service, but the functional decomposition is not addressed
in the model.  For the IKE Service, the IKERejectAction could be in a rule
that has condition=TRUE with the lowest priority to provide an explicit rule
for the default action as a responder.  So, for example, when you do get the
ID payload, it no longer matches the rule that was being used but now
matches this lower priority default rule.  Does this help or am I missing
something?

I'll fix the wording in the DMTF MOF to improve clarity and it'll get
reflected into the IETF draft.  Thanks, Lee

----- Original Message -----
From: "Wang, Cliff" <[email-masked]>
To: "'Jason, Jamie'" <[email-masked]>; "'Eric Vyncke'"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, February 21, 2001 9:48 AM
Subject: RE: Question on IKERejectAction in IPsec information model

> So any rule with IKERejectAction is to stop negotiation
> by dropping the packets? Or I have to pass a message
> to the IKE engine to drop the request and let the packet
> pass the filter?
>
> Would it be simpler just to have a drop rule to stop
> the IKE packets?
>
> If the filter is of type IKE identity, then there are
> a couple of issues:
> 1) The main mode identity won't come in until 5th
> message. At that time, you have done D-H exchange.
> If the purpose of this filter is to prevent
> denial-of-service, the adversary has just defeated that.
> 2) The filter code itself has no IKE protocol
> intelligence. That means the IKE engine has to
> lookup up the filter again after receiving
> the ID payload. This requirement is not RFC 2409
> specified.
>
> I would suggest that to stop peer IKE negotiation,
> just set up a simple drop rule with that peer
> on UDP port 500.
>
> From: Jason, Jamie [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2001 8:19 PM
> To: 'Eric Vyncke'; 'Wang, Cliff'; [email-masked]

---

From: Eric Vyncke <[email-masked]>
Date: Mon, 26 Feb 2001 09:56:25 +0100

Cliff,

Sorry for late reply, comments in-line:

>to the IKE engine to drop the request and let the packet

The goal is to prevent IKE to start a negotiation as responder,
the way you implement it is probably local matter.

>Would it be simpler just to have a drop rule to stop

No, because we would also like to reject connections from some IKE
by using their identity (obviously only applies to aggressive mode).

I hope that this does make sense ;-)

-eric

Eric Vyncke