Perry E. Metzger writes:
>
> Michael Thomas <[EMAIL PROTECTED]> writes:
> > Perry E. Metzger writes:
> > > Michael Thomas <[EMAIL PROTECTED]> writes:
> > > > Bzzt. You're overloading semantics. SPI's enumerate
> > > > the set of packets for which a given security policy
> > > > applies. That may have exactly zero to do with the
> > > > QoS policies you'd like to apply.
> > >
> > > In the scheme proposed, flow labels just enumerate a set of packets
> > > that a host has chosen to designate as a "flow" because, say, they're
> > > all using the same TCP socket -- which may also have exactly zero to
> > > do with the QoS policies you'd like to apply. How is it any different
> > > than the SPI situation?
> >
> > Again, security policy is not identical to
> > QoS policy. The only way to make them identical
> > is to have separate IPsec SA's for each QoS flow.
> > This would be a huge waste, both on the signaling
> > front as well as the SADB cost.
>
> Er, you already in practice have an SPI for every flow. See my other
> message on this subject.
Uh, no. In practice there's a single SPI for
all of the traffic. Also: in practice the
cross product of QoS and IPsec is pretty rare.
I expect that will change with the advent of
lots of IP phones going across VPN's, but
when that happens you want hard coupling of
QoS and Security even less: VPN concentrators
have finite memory/hardware for SA's. Since
there's no security benefit, you're just adding
cost to achieve feature parity. This would not
be the case with the flow label.
Mike
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
