Re: use of client IDs
"Scott G. Kelly" <skelly@redcreek.com> Fri, 19 June 1998 20:22 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16758 for ipsec-outgoing; Fri, 19 Jun 1998 16:22:57 -0400 (EDT)
Message-ID: <358ACC91.AAA96377@redcreek.com>
Date: Fri, 19 Jun 1998 13:39:45 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Pyda Srisuresh <suresh@livingston.com>, ipsec@tis.com
Subject: Re: use of client IDs
References: <199806191945.MAA07307@server.livingston.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Pyda Srisuresh wrote: > > > > If the selection criteria is set to be based on packet > > > (as opposed to policy), every new packet matching the same policy but > > > differing in one regard(say, IP address or TCP/UDP port) would require > > > a new SA. > > > > > > In the case where selection criteria is set to be based on policy, > > > the SA selection would match the selection of an SP. It is also > > > possible for an SA to match multiple policies. > > > > > > > Again, your terminology confuses me. When you say 'the selection > > criteria is set to be based on packet (as opposed to policy)', what do > > you mean? > > > > My terminology is based on the IP architecture draft, > <draft-ietf-ipsec-arch-sec-05.txt>, section 4.4.1, pg 17 below. > <trimmed...> Okay, now I think I understand what you are trying to say. Still, if you read a little further in the same draft, you'll find that your assertion that every packet differing in one or another regard would require a new SA is incorrect. In section 4.4.3, page 22, you'll find the text which explains why this is not so. I won't include it here, but it's in the paragraph which begins with For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to...
- use of client IDs Bryan Gleeson
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Scott G. Kelly
- RE: use of client IDs CJ Gibson
- Re: use of client IDs Scott G. Kelly
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Scott G. Kelly
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Pyda Srisuresh
- Re: use of client IDs Pyda Srisuresh
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Scott G. Kelly
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Daniel Harkins
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Bryan Gleeson
- Re: use of client IDs Pyda Srisuresh
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Pyda Srisuresh
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Daniel Harkins
- Re: use of client IDs Daniel Harkins
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Pyda Srisuresh
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Daniel Harkins
- RE: use of client IDs Bryan Gleeson
- RE: use of client IDs Bryan Gleeson
- RE: use of client IDs Chris Boscolo
- Re: use of client IDs Pyda Srisuresh
- Re: use of client IDs Pyda Srisuresh
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Pyda Srisuresh
- RE: use of client IDs Bryan Gleeson
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Pyda Srisuresh
- RE: use of client IDs Chris Boscolo
- RE: use of client IDs Bryan Gleeson
- Re: use of client IDs Pyda Srisuresh
- Re: use of client IDs Scott G. Kelly
- Re: use of client IDs Scott G. Kelly
- RE: use of client IDs Bryan Gleeson