[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
References: