[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AHbis WG LC: need for source address based selectors
At 1:55 AM +0300 6/18/03, Tero Kivinen wrote:
>Stephen Kent writes:
>> >I don't know how to handle this so late in the process. I would
>> >like to see the text to be sufficiently revised to allow source
>> >address based SA selection, so that we could use it directly in SEND.
>> >However, I have no idea how the IPSEC WG would feel about that.
>...
>> considerable debate and analysis, to accommodate SSM. Your proposed
>> change represents yet another bit of complexity for an IPsec
>> implementation and I question whether the WG ought to agree to such a
>> change at this late date.
>
>If I undestand correctly Pekka is asking that the document does not
>say you MUST NOT allow source address based SA selection (I do not
>thing it currently says so). I assume that if it does not say anything
>that this is forbidden or even better says that implementation MAY
>support SA selection based on the SPI and source address, he will be
>happy.
>
>Even if the document says "MAY" to this thing, it does not require
>anybody to change anything nor does it make any implementations
>non-conforming. We are simply allowing implementations to also have
>this kind of features too.
>
>I.e adding something like this to the text:
>
>"The SPIs from the reserved range may used different demultiplexing
>algorithms and use source and/or destination address and/or protocols
>and/or some other information for the actual demultiplexing. A
>document describing new reserved SPI number MUST also specify the
>demultiplexing algorithm used for that specific SPI."
Tero,
The primary motivation in the IETF for developing standards is to
promote interoperability. What you seem to suggest is a that we not
preclude someone from saying that they comply with IPsec, even though
they would be following a demuxing policy that is not used in any
extant implementations and thus would not be interoperable with any
of these implementations. This does not promote interoperability;
all it does is allow someone to claim conformance with a standard.
That does not seem constructive and, as I noted, it only add to
complexity.
Am I missing something in your suggestion?
Steve