Re: (IPng) out-of-band key management is like virtual ...

"Housley, Russ" <housley@spyrus.com> Tue, 07 March 1995 23:08 UTC

Received: from interlock.ans.net by nis.ans.net with SMTP id AA21462 (5.65c/IDA-1.4.4 for <archive-ipsec@nis.ans.net>); Tue, 7 Mar 1995 18:08:59 -0500
Received: by interlock.ans.net id AA10760 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 18:06:11 -0500
Message-Id: <199503072306.AA10760@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 18:06:11 -0500
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 18:06:11 -0500
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 18:06:11 -0500
Date: Tue, 07 Mar 1995 14:46:01 -0000
From: "Housley, Russ" <housley@spyrus.com>
Encoding: 963 Text
To: perry@imsi.com
Cc: ipsec@ans.net
Subject: Re: (IPng) out-of-band key management is like virtual ...

Perry:

>> Multicast Security Associations (SAs) cannot be managed in the same way as 
>> peer-to-peer SAs.  Given this, the SAID should have some structure to 
>> easily separate the multicast SAs from the peer-to-peer ones.
>
>That is hardly obvious, and conflicts with the mechanisms described in 
>the drafts.
>
>As clearly described in the drafts, SAIDs are assigned at the pleasure 
>of the entity controlling the destination address. The us of "entity 
>controlling" rather than "destination host" was deliberate -- it was 
>there because of multicast.

I agree that the SAID must me assigned by the entity controlling the 
destination address.  In fact, this is exactly my point.  Key management 
will do something different to establish a security association for two 
IPSP peers than to establish a multicast security association.

The IPSP processing may well be identical once those security associations 
are in place.

Russ