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

Re: SPI orthogonality

Theodore Y. Ts'o wrote:
> 
> I think the main problem is one of terminology.  
> To quote the SPI text:
>
% The SPI is an arbitrary 32-bit value that uniquely identifies the
% Security Association for this datagram, relative to the destination IP
% address contained in the IP header (with which this security header is
% associated) and relative to the security protocol employed.
> 
> This statement, while technically correct (the last clause is 
> critical), is perhaps confusing to some in the case where a 
> datagram has both AH and ESP applied to it.  Suppose host A 
> exchanges keying material with host B, and then uses said 
> keying material to protect datagrams using both AH and ESP 
> ---- how many security associations are there between
> host A and host B?  Are there one, or are there two?
> 
> If you answer that there is only one security association, then the
> first part of the above definition can be confusing --- because there
> are two SPI's, one for AH and one for ESP.

My answer is (and the historical intent has been):

	Let an IP session exist between nodes A and B.
	Let that session use both AH and ESP for protection.

	Then one has two separate IPsec Security Associations;
	one for AH and a different one for ESP.  The
	combination of (SPI, Destination Address, {AH XOR ESP})
	uniquely identifies an IPsec Security Association.

	Note that this does NOT preclude the operational
	practice of creating the AH and ESP SAs at the
	same time using a single KM process.  It also does
	not mean that a particular implementation cannot choose
	to _internally_ handle those SAs as a pair.  However,
	it also does not require that an implementation handle
	them as a pair or create them at the same time using
	a single KM process.


> I believe this is the crux of Bill's compliant.

	Bill's terminology for "SA" and "SPI" as used in recent
	messages to this list appears to be unique to him.  His
	terminology is not identical to the historical intent 
	of the IPsec document author or with the formal definition
	of an IPsec Security Association in the existing RFCs
	(whose clarity is admittedly suboptimal due to historical
	factors).  

	I beg to differ with Bill's assertion that he defined 
	the semantics for the "SPI".  For good or ill, the 
	semantics were defined in the RFCs (1825-1827) --
	Bill was neither author nor editor for those RFCs.

	Bill did suggest the term "SPI" -- to help with the
	sociological issue that some folks familiar with 
	SP3/ISO-NLSP occasionally associated semantics unique 
	to those protocols to ESP/AH.  I have not seen any
	recent notes whose author appeared to be associating
	SP3/ISO-NLSP semantics with the IPsec protocols, 
	though I think the term SPI should be retained for
	consistency.
	
	I believe that the current text on SAs and SPIs
	from Steve Kent is largely very reasonable (and
	generally an improvement on the original RFCs).  
	I think it might be helpful for Steve's text to be 
	slightly revised (1) to note the reasons why it matters
	that an implementation support separate SPI spaces for AH
	and ESP {a separate note from me this morning outlined the
	technical issues on that topic, but my words would benefit
	from editorial help from Steve Kent & Co}.  Ted's suggestion
	(2) that the spec define the term "Security Association" in
	slightly more crisp language also seems sensible to me 
	{Perhaps an informative sentence or two outlining the
	example situation that Ted outlines above would suffice}.

Regards,

Ran
rja@inet.org
References: