[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A question on SA establishment in RFC 2408



> From owner-ipsec@lists.tislabs.com Thu Jun  3 11:56:09 1999
> Message-Id: <3.0.5.32.19990603181256.00a81bb0@smtp.datafellows.com>
> X-Sender: joern@smtp.datafellows.com
> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
> Date: Thu, 03 Jun 1999 18:12:56 +0300
> To: ipsec@lists.tislabs.com
> From: Joern Sierwald <joern.sierwald@datafellows.com>
> Subject: Re: A question on SA establishment in RFC 2408
> In-Reply-To: <9906031415.AA22386@secpwr.watson.ibm.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: 8bit
> X-Mime-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA07099
> Sender: owner-ipsec@lists.tislabs.com
> Precedence: bulk
> Content-Length: 1300
> Status: RO
> 
> At 10:15 3.6.1999 -0400, you 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 ?
> >
> You are free to use whatever you like. 
> You may return the original numbers, or 0 or 1 or 42.
> 
> >   A related and more fundamental question is that how the initiator
> >   could determine if the responder retains the numbers or not ?
> It can't. The initiator has to match the returned proposal against
> the proposals that it sent. Please notice that the responder might
> return something the initiator did not propose. Or it might return 
> all proposals the initiator sent.

 Then that statement in section 4.2 of RFC2408 would be practically useless.
 Since then the initiator would not be able to use these numbers
 sent by the responder in any effective way.
 
 Also, if I read RFC2409 correctly, the responder is supposed to choose
 only one proposal, which may contain multiple proposal payloads with
 the same propsoal number, and choose only one transform within each
 proposal payload. The responder should not return all proposals sent
 by the initiator. Did I miss anything ?
 
 Just my $0.02 opinion.
 
 
 Pau-Chen 
> 
> >
> >
> > Thanks in advance.
> >
> >
> > Pau-Chen
> >
> >
> Jörn
> 
>