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

RE: Question on IKERejectAction in IPsec information model



Cliff,

Sorry for late reply, comments in-line:

At 14:48 21/02/2001 +0000, Wang, Cliff wrote:
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?

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
the IKE packets?

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


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:jamie.jason@xxxxxxxxx]
Sent: Tuesday, February 20, 2001 8:19 PM
To: 'Eric Vyncke'; 'Wang, Cliff'; ipsec-policy@xxxxxxxx
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:evyncke@xxxxxxxxx]
> Sent: Tuesday, February 20, 2001 4:54 PM
> To: Jason, Jamie; 'Wang, Cliff'; ipsec-policy@xxxxxxxx
> 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:CWang@xxxxxxxxxxxxxx]
> >> Sent: Monday, February 19, 2001 11:11 AM
> >> To: ipsec-policy@xxxxxxxx
> >> 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: evyncke@xxxxxxxxx          Mobile: +32-475-312.458 (CHANGED)
> PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
>
>

Eric Vyncke Distinguished Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke@xxxxxxxxx Mobile: +32-475-312.458 (CHANGED) PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141