In your previous mail you wrote:
> => can you explain why it is not enough to use the SPI in place of
> higher layer selectors?
The SPI doesn't have the semantics.
=> I disagree, the SPI has the semantics we'd like to give to it.
A QOS classifier needs to *know*
the port and protocol numbers; that's how it takes its decisions.
=> I can't see a deep difference between a QoS classifier and
a SPD entry.
For example you might put traffic with protocol number 30 in a
different class from traffic with protocol number 41.
=> and you might use a different SPI... I can't see why it is
possible to associate to some kind of flow a 24 bit pseudo-random
number (the flow label) and not a 32 bit pseudo-random number
(the SPI).
Alex's idea of using "server port number" is in fact
interesting, since it would allow you to classify traffic
on its original well-known port #, without having to rely
on dynamically assigned port #s for classification.
=> I don't like the idea to have an official cover-channel
with the flow label: security people won't buy this.
They'd like to hide things then they can express their policy
(ie. what they accept to reveal) into the SPD then the choice
of SPIs...
But the flow label isn't long enough for everything we need.
=> the SPI is 32 bit long (:-)!
Regards
[EMAIL PROTECTED]
PS: I am in no camp. I believe Jim/Itojun/... are right but the
flow label is not protected by AH then a router may rewrite it.
As it is not a stack it should be rewritten only closed to the source
(ie. if you want to rewrite it anywhere you should encapsulate packets
before, the decapsulation will restore the original flow label).
In the future I can see two cases:
- the flow label is set by the source (first camp)
- the flow label is set by an edge router (with the DiffServ definition
of what is an edge router) because the source box (or its user) is
too dumb to deal with QoS/..., according to the edge router manager.
I think we'll get a mixed situation.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
