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

Re: Phase 1 Re-keying Implementation Identification

I tend to agree with Tero. I've been following this discussion for
around a year now, and have always had a hard time understanding why
"dangling SAs" are such an issue. I have come to the conclusion that it
has something to do with the architectural viewpoint one takes with
respect to isakmp. Below is a diagram from RFC2408:

     +------------+        +--------+                +--------------+
     !     DOI    !        !        !                !  Application !
     ! Definition ! <----> ! ISAKMP !                !    Process   !
     +------------+    --> !        !                !--------------!
    +--------------+   !   +--------+                ! Appl Protocol!
    ! Key Exchange !   !     ^  ^                    +--------------+
    !  Definition  !<--      !  !                           ^
    +--------------+         !  !                           !
                             !  !                           !
            !----------------!  !                           !
            v                   !                           !
        +-------+               v                           v
        !  API  !        +---------------------------------------------+
        +-------+        !                Socket Layer                 !
            !            !---------------------------------------------!
            v            !        Transport Protocol (TCP / UDP)       !
     +----------+        !---------------------------------------------!
     ! Security ! <----> !                     IP                      !
     ! Protocol !        !---------------------------------------------!
     +----------+        !             Link Layer Protocol             !
                         +---------------------------------------------+


ISAKMP is clearly an application protocol which provides services to the
kernel, and the notion of binding ISAKMP constructs (sessions, SAs, or
what have you) to kernel constructs (SAs, in this case), really rubs me
the wrong way. The IKE SAs and the protocol SAs (despite the unfortunate
fact that they share a name) are distinctly different constructs in
distinctly different architectural layers. It seems incorrect to assert
that deletion of an application layer session should justify deletion of
a kernel-level session. 

I understand the keep-alive issue in the remote access scenario, but I
don't think this justifies cutting across the architectural layers here
in the name of a quick fix. IKE SAs really have no binding to the
protocol SAs they negotiate once they've been instantiated, and assuming
that it is okay to delete a protocol SA just because the IKE session
used to instantiate it goes away seems incorrect to me.

Scott
Follow-Ups: References: