Subject: RE: Question on IKERejectAction in IPsec information model

From: "Wang, Cliff" <[email-masked]>
Date: Wed, 21 Feb 2001 14:48:40 -0000

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.

-----Original Message-----
From: Jason, Jamie [mailto:[email-masked]]
Sent: Tuesday, February 20, 2001 8:19 PM
To: 'Eric Vyncke'; 'Wang, Cliff'; [email-masked]
Subject: RE: Question on IKERejectAction in IPsec information model 

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:
> >> 
> >> 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.
> >> 
> 
> 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: "Lee Rafalow" <[email-masked]>
Date: Thu, 22 Feb 2001 12:36:28 -0500

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