[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed IPSEC changes/extensions
Pau-Chen,
I thought some more about the question of where the info shoukld
live that defines the set of IP datagrams that map into a single SA. My
initial response to your message was that I may have put this data in the
wrong place, by listing it in the per-SA MIB. However, the right answer
may be that it lives in two places: the MIB entry I described and a
separate database that defines policy. My thinking is that when we receive
an outbound packet we have to do a table lookup to determine if any
existing SA is appropriate for carrying this packet, or if a new SA must be
established. The first check is made against a database of existing SAs,
while the second refers to a separate database that expresses the static
policy of what sort of SAs should be created. Thus it would seem
reasonable to make the first check against a databse that showed what set
of selectors were already in use for outbound traffic. In that context,
your suggestion about explicitly listing the set of IP addresses (ports,
etc.) bound to a single SA makes sense and may be better than the wildcard
address approach I described (depending on the search details). If an
explicit address list were used, then a new packet that could be carried on
an existing bulk SA would not be immediately recognizzed, but when it was
referred to the SA policy the wildcard match would indicate that the packet
could be muxed with other traffic. Then one would have to make a different
check to see if such an SA already exists and add this outboud address to
the explicit list bound to that SA. These processing details are below the
level one would want in the spec, but having this sort of model to discuss
may help resolve the questions you raised.
Steve
Message-ID: <32776224.1FCA@ascend.com>
Date: Wed, 30 Oct 1996 09:11:48 -0500
From: Karl Fox <karl@ascend.com>
Reply-To: karl@ascend.com
Organization: Ascend Communications
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: Michael Sabin <msabin@netcom.com>
CC: ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions
References: <199610300056.TAA17309@relay.hq.tis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Michael Sabin wrote:
> Compression is greatly helped by including a field that controls two
> functions: (1) whether or not the contents of the packet are compressed;
> and (2) whether or not the compression state was reset prior to this packet.
It seems to me that such a field could easily be prepended to the
(possibly) compressed data before encryption takes place, being merely a
part of the compression transform and therefore not requiring any ESP
header space.
Besides, wouldn't this be more secure?
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841