Indeed, there is a need for at least one packet of a high QoS level
before one could steal the value of the flow label and use it for a
non-authorized flow
(it is mostly, if not always, known which ports are high QoS level and
which not).
However, once the pseudo-random number is cached, or stored, the RISK is
not different.
A long flow state time to live obviously helps the wrongdoer.
Pekka Savola wrote:
>
> On Wed, 15 Aug 2001, Alex Conta wrote:
> > >Jun-ichiro itojun Hagino wrote:
> > >
> > > >The traffic class field is not enough. If you have to re-classify traffic at
> > > >an administrative boundary, then by definition at that point the traffic class
> > > >field is inadequate; you need more information. The advantage that IPv6 has
> > > >is that even when the header is partly hidden by IPSEC, the flow label is
> > > >available to carry additional semantics. The actual proposal is to use the
> > > >PHB identifier which has end to end semantics.
> > >
> > > I heard the presentation differently. in IETF51 presentation Alex
> > > Conta made the following proposals, at least:
> > > - putting PHB value
> > > not trustworthy.
> >
> > The PHB is as trustworthy as anything else, including the pseudo-random
> > value. If a user can set values as pleases, it can do that with the
> > pseudo-random number as well.
>
> The user does not know which pseudo-random value to choose (2^19 or the
> like is lots..) to select to "steal specific kind of traffic", at least
> before you have indeed sent legally that kind of traffic and observed
> higher priority given to the that flow. If this were based on port numbers
> etc., the user could more easily guess/experiment with the behaviour, and
> set it as you please.
>
> --
> Pekka Savola "Tell me of difficulties surmounted,
> Netcore Oy not those you stumble over and fall"
> Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
S/MIME Cryptographic Signature
