[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
>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."


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 

Am I missing something in your suggestion?