In your previous mail you wrote:
> The SPI doesn't have the semantics.
>
> => I disagree, the SPI has the semantics we'd like to give to it.
When reasonable key management protocols are in use, IPSEC SPI's are
pseudo-random, chosen by the receiver, and securely communicated to
the sender via the key management protocol.
=> the only problem is "chosen by the receiver" because the first
packet will reveal the SPI to on-path attackers.
The use of random spi's is one of the defenses against off-path
denial-of-service attacks.. an off-path attacker forging source
addresses cannot easily guess a valid SPI, and so packets with invalid
SPI's can be quickly discarded without requiring any cryptographic
processing.
=> they can be only discarded if you know valid SPIs, ie. by the receiving
node (which can be overloaded just by a big number of packets) or if
a firewall has the needed knowledge (ie. there is a protocol which gives
new SPIs to it).
What semantics do you think you can impose on something like that?
=> just associate a QoS to a SPI and send the information (ie. how to
classify packets (addresses, ..., SPI) and the QoS) to the classifier
(which is by definition on-path).
Another solution is to ask the receiver to be less random (again the
info will be spread only on-path).
Regards
[EMAIL PROTECTED]
PS: I assumed in my previous mail than the trade-off was between flow
labels and SPIs. If we considered that flow labels *can't* replace
a part of famous 5-tuples then of course the same consideration
applies to SPIs.
PPS: Bill, as a IPsec person, would you like to have upper layer protocol
and port revealed in flow labels?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
