[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two issues: AH death, and SA identification
I'd like to second this. I really see not much
point in having two SA negotiation capabilities
(KINK/IKE) so long as the line is cleanly drawn
such that son-of-IKE doesn't keep breaking KINK
and visa versa. As it stands right now, we are
going to copy-by-value all of the SA negotition
from IKE into KINK and delete stuff that's not
appropriate for KINK. A propos the previous mail
about port range selectors, it would be nice to be
able to have KINK inherit that ability as well.
Maybe what we could do is do a split in Son-of-ike
for just the SA management and have both KINK and
IKE reference that, or be able to reference that
RFC in the future. For the time being, KINK should
still do the copy by value, but structure it so
that we can drop in another SA-negotiation
subsystem in the future. The same could be done
for IKE, I suppose.
Mike, who knows this goes against
the general desire for consolidation...
Derek Atkins writes:
> Perhaps we need yet another "line" separating SA management and key
> management? (As it is, KINK will probably incorporate much of IKE
> phase-II quick-mode for the SA negotiation).
>
> -derek
>
> Stephen Kent <kent@bbn.com> writes:
>
> > Negotiation of SA parameters is an SA management function, though not
> > necessarily a key management function. We have disconnects today
> > between IKE capabilities and IPsec architecture. I want to close
> > those gaps in the next rev, and not by reducing IPsec functionality.
> >
> > Perhaps what I should say is that I want to specify more concretely
> > what an SA management protocol must provide for IPsec, whether that
> > protocol is IKE or not.
> >
> > Steve
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
References: