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
>
>