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

Re: IPSec SA DELETE in "dangling" implementation

Made a mistake while copying the message to the ipsec
list. sending it again.


--- Dan Harkins <dharkins@Network-Alchemy.COM> wrote:
>   You should check the archives of this list for a
> good description
> of the inline ISAKMP work. Basically it allowed for
> the SA negotiation
> to piggyback along with data to protect ala the SKIP
> protocol.
> 
>   I was imagining using one of the reserved SPI
> values (1 is for SKIP
> and 2-255 are reserved) for a local keepalive
> function. It's not thought
> out very well at all and was just food for thought.
> 
>   Dan.
> 
> On Sun, 05 Dec 1999 01:12:28 PST you wrote
> > 
> > Can u expand on what you mean by inline ISAKMP?
> > Do you mean ike control messages flowing as part
> of
> > ipsec data? This implies to process the control
> > message 
> > the ipsec SA has to be alive, which seem to defeat
> the
> > purpose of the notification messages. 
> > 
> > I was thinking along these lines..
> > 
> > A crude description follows.
> > 
> > The oneway authenticated message I described are
> not
> > dependent on any ipsec/ike SA. They are
> independently
> > authenticated messages.
> > The notification message can be of the form
> >         header
> >         notification payload
> >         id payload
> >         event specific information
> >         authentication information
> > 
> > The authentication information can be hash or a
> > signature computed over the header, notification,
> id
> > payload and
> > the event causing the notification (a message from
> the
> > peer might have caused the notification. In this
> case
> > the hash for the authentication information will
> > include the ip packet which caused the
> notification).
> > In case the notification message is generated and
> is
> > not a response
> > to a message from peer (as in the case of 'delete'
> > notification),
> > the hash can include spi, ipsec keys and other
> > information that
> > describe the event.
> > 
> > The id payload can be used by the peer to identify
> the
> > corresponding policy and authenticate the
> notification
> > payload. An
> > event specific information is also included. If
> the
> > notification message is generated as response to a
> > message from the peer the event specific
> information
> > can be the ip packet from the peer. If the
> > notification is generated spontaneously, the event
> > specific information can contain the spi, ipsec
> keys
> > or other information that describe the event. The
> > event specific information can be used by the
> > peer to verify that the notification message is
> not a
> > replay attack.
> > > payload
> > being
> > sent in the clear can be somewhat mitigated by
> > The notification message is sent in the clear. Are
> > there any drawbacks to this? concerns about ID

> doing a
> > one-way 
> > map of regular ID to identifier of type ID_KEY_ID
> and
> > sending 
> > the mapped identifier in the notification
> messages.
> > 
> > The advantage of oneway authenticated notification
> > message that is independent of IKE/IPSec SA is
> that
> > they can be sent any time without the need for an
> IKE
> > or IPSec SA. They could carry information about
> any
> > IPSec or IKE SA.
> > 
> > This way if a peer gets out of sync because the
> > corresponding
> > IKE or IPSec SA is absent, a notification can be
> sent
> > immediately
> > and the peer can take corrective action
> immediately.
> > 
> > Welcome your comments on this.
> > 
> >   Thanks,
> > -- sankar --
> > 
> > 
> > 
> > 
> > 
> > 
> > > On Fri, 03 Dec 1999 17:55:31 +0530 you wrote
> > >> Slava Kavsan wrote:
> > >> 
> > >> > Here is the dilemma: if "dangling"
> implementation
> > wants to send IPSec
> > >> SA
> > > > DELETE message, while the "parent" IKE SA is
> no
> > longer there (expired
> > > or
> > > > deleted), the alternatives are (and I do not
> like
> > either of them):
> > > 
> > > > a) do not send DELETE
> > > > b) re-negotiate IKE SA before sending DELETE
> > > 
> > > > Any suggestions?
> > > A third option is to design a oneway
> authenticated
> > message
> > > (proofed against replay attacks). Such oneway
> > authenticated message
> > > can be used for 'delete', 'invalid spi' and
> other
> > notifications.
> > > If such a design is possible then it is not
> > necessary to establish
> > > IKE SA to send a 'delete' notification.
> > > 
> > > The oneway message could be authenticated using
> a
> > signatures
> > > or hash generated using preshared secret, could
> > include the
> > > id payload to allow the peer to identify the
> > matching shared
> > > secret in the case of the pre-shared secret. The
> > oneway message
> > > could also use as part of the hash information
> from
> > the event
> > > causing the notification to be generated. This
> could
> > prevent
> > > replay attacks.
> > > 
> > > Any thoughts on this?
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Thousands of Stores.  Millions of Products.  All
> in one place.
> > Yahoo! Shopping: http://shopping.yahoo.com
> 

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com