[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A question on SA establishment in RFC 2408
Tim, IBM's code does check the responder's repoly against the
initiator's list of proposals. I wrote the code that way and I
have no arguments there.
I like the numbers to be retained precisely for the reason you mentioned,
faster lookup for comparison; I remember that was the reason why
retaining these numbers was introduced into the draft initially.
IMHO, if the numbers are not retained, then RFC 2408 should state clearly
what values should be used in their places to avoid ambiguity
on the initiator's side.
Pau-Chen
> From tjenkins@TimeStep.com Fri Jun 4 09:48:11 1999
> Message-Id: <319A1C5F94C8D11192DE00805FBBADDFAEB9E3@exchange>
> From: Tim Jenkins <tjenkins@TimeStep.com>
> To: Mike Williams <mikewill@ibm.net>, pau@watson.ibm.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: A question on SA establishment in RFC 2408
> Date: Fri, 4 Jun 1999 09:51:25 -0400
> Mime-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2232.9)
> Content-Type: text/plain;
charset="iso-8859-1"
> Content-Length: 2928
> Status: RO
>
> Even if the responder kept the original proposal # and transform #, wouldn't
> it be prudent to check that they match the contents of those that the
> initiator sent?
>
> If so, what's the point of keeping the numbers the same? (Other than a
> faster lookup for comparison?) You still have to check the contents of the
> returned proposal against your policy again anyway...
>
> Or is this too paranoid?
>
> ---
> Tim Jenkins TimeStep Corporation
> tjenkins@timestep.com http://www.timestep.com
> (613) 599-3610 x4304 Fax: (613) 599-3617
>
>
>
> > -----Original Message-----
> > From: Mike Williams [mailto:mikewill@ibm.net]
> > Sent: June 4, 1999 9:42 AM
> > To: pau@watson.ibm.com
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: A question on SA establishment in RFC 2408
> >
> >
> > We ran into this at the bakeoff last week.....
> >
> > This would provide value if it was required that the
> > responder retain the
> > Proposal # and Transform #. Since it is only suggested as a
> > SHOULD and since
> > we have found several implementations that have not followed this
> > recommendation, it provide little if no value.
> >
> > Take for example the situation where the initiator proposes 3
> > proposals, each
> > having 4 transforms and the responder chooses transform #3 in
> > proposal #2.
> > Most implementations followed the recommendation and would
> > send back an SA
> > payload with a single proposal payload with a proposal #2
> > containing a single
> > transform payload with a transform #3. Others did not follow this
> > recommendation and would return the contents of proposal #2
> > and transform #3,
> > however numbering them proposal #1 and transform #1. Given
> > this different
> > behavior, the initiator has very little choice other than to
> > go back through
> > all proposed proposals and transforms with the reply looking
> > for a match.
> >
> > Mike Williams
> >
> > IBM AS4/00 TCP/IP Development
> >
> >
> >
> > pau@watson.ibm.com wrote:
> >
> > > My apology if this question has been raised before.
> > >
> > > Section 4.2 of RFC2408 (the ISAKMP RFC) describes SA
> > establishment,
> > > in its last paragraph before section 4.2.1, it states :
> > >
> > > ".......The responder
> > > SHOULD retain the Proposal # field in the Proposal
> > payload and the
> > > Transform # field in each Transform payload of the
> > selected Proposal.
> > > ..."
> > >
> > > My question is about the word "SHOULD". This word means
> > the responder
> > > does not have to retain the proposal and transform
> > numbers. If it does
> > > not retain the numbers, then what numbers should be used in the
> > > "proposal number" and "transform number" fields in the
> > proposal and
> > > transform payloads sent from the responder to the initiator ?
> > >
> > > A related and more fundamental question is that how the initiator
> > > could determine if the responder retains the numbers or not ?
> > >
> > > Thanks in advance.
> > >
> > > Pau-Chen
> >
>