Re: proposed IPSEC changes/extensions
pau@watson.ibm.com Wed, 30 October 1996 15:22 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14704; 30 Oct 96 10:22 EST
Received: by relay.hq.tis.com; id KAA26883; Wed, 30 Oct 1996 10:27:04 -0500
From: pau@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma026872; Wed, 30 Oct 96 10:26:35 -0500
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA03461 for <ipsec@tis.com>; Wed, 30 Oct 1996 10:28:23 -0500 (EST)
Received: by relay.hq.tis.com; id KAA26868; Wed, 30 Oct 1996 10:26:34 -0500
Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma026866; Wed, 30 Oct 96 10:26:26 -0500
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id KAA15256; Wed, 30 Oct 1996 10:28:36 -0500
Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id KAA671400; Wed, 30 Oct 1996 10:28:24 -0500
Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22586; Wed, 30 Oct 1996 10:30:33 -0500
Date: Wed, 30 Oct 1996 10:30:33 -0500
Message-Id: <9610301530.AA22586@secpwr.watson.ibm.com>
To: kent@bbn.com
Subject: Re: proposed IPSEC changes/extensions
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Md5: APHYSVBYtQin7nH6Cfy2SA==
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Steve, thank you for the quick response. I put my comments after your text. Regards, Pau-Chen In message <v02130510ae9cfdd69597@[128.89.30.7]> Stephen Kent wrote : > > 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 > > My model is the policy will tell which (kind of) SA to use. So the 1st search is done through the policy to determine which (knid of) SA, if any, should be used. Then we go through the existing SA's to see if an SA meeting the policy requirements exists. If one exists, then we can just uses it. If not, one can be created. The policy will carry the notions of wildcard, address range, protocols, port ranges, etc.(God knows what.). (Of course, a simple mechanism is invented to define a "kind of" SA.) The intention here is to decouple the policy from the SA. I consider policy is very subjective and can, at least in theory, appears in many different forms; so it is not standarized (and IMHO, it should not be.). But SA should be simple, precise and standarized (at least in conceptual level), so SA can be negotiated by standard KMP. At present, the above concept has been implemented in IBM IPSEC code (including a key refreshment protocol (not ISAKMP)) and placed in IBM firewall. It seems to work pretty well. I do think, however, it is useful for an end of an SA to advise the other end how it wishes the SA to be used. This may be done by communicating protocol, port (ranges) in the KMP in addition to address (ranges). Pau-Chen
- proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Ran Atkinson
- Re: proposed IPSEC changes/extensions Hilarie Orman
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Bill Sommerfeld
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Rodney Thayer
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Steven Bellovin
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions John Gilmore