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

Re: Racing QM Initiator's

To: Valery Smyslov <svan@trustworks.com>
Subject: Re: Racing QM Initiator's
From: "Scott G. Kelly" <skelly@redcreek.com>
Date: Fri, 15 Oct 1999 09:34:31 -0700
CC: Dan Harkins <dharkins@network-alchemy.com>, Sankar Ramamoorthi <Sankar@vpnet.com>, Jan Vilhuber <vilhuber@cisco.com>, Ben McCann <bmccann@indusriver.com>, ipsec@lists.tislabs.com
Organization: RedCreek Communications
References: <199910150644.KAA03616@relay1.trustworks.com>
Sender: owner-ipsec@lists.tislabs.com

Hi Valery,

Valery Smyslov wrote:
> >
> > Assuming policy is correctly configured (and implemented), this packet
> > should never reach the IKE implementation, should it?
> 
> Why not? IKE is built atop TCP/IP stack, for the stack it is
> perfectly valid packet, IPsec policy usually allows any IKE packet
> (UDP/500) to pass through (otherwise you won't be able to communicate
> with nomadic peers). So, what prevents this packet from reaching IKE
> implementation?

RFC 2401 explicitly notes that IKE traffic is subject to policy. Maybe
your policy usually allows any IKE packet to pass through, but if your
implementation is compliant with RFC 2401, then this is a policy matter,
and not hard-coded. It seems to me that this is a non-issue, since these
packets may easily be prevented from passing up the stack in a compliant
implementation.

Scott

References:

Re: Racing QM Initiator's

From: "Valery Smyslov" <svan@trustworks.com>

Prev by Date: RE: request
Next by Date: RE: comments on the latest GSSAPI draft changes
Prev by thread: Re: Racing QM Initiator's
Next by thread: RE: Racing QM Initiator's
Index(es):
- Main
- Thread