Brian was correct, in what he said, and what he meant to say. He
compared apples with apples, and therefore referred to non-RFC 2207
Intserv (non-SPI based classifiers).
Mike has a problem with the ESP transport header privacy implications of
the Diffserv Flow label approach. But, RFC 2207, defines IPv4, and IPv6
Filter Specs containing the Generalized Port Identifier - GPI - and does
not define anything for the IPv6 flow label. It rather refers to the
IPv6 flow label only to say that "it can be useful, but it is left for a
future definition".
We - Brian, I, and others - said this before, in a different context,
and will say it again: the privacy implications of the Diffserv flow
label are not different than those of the Intserv flow label approach --
please see Footnote 1.
Furthermore, it seems that the data plane RFC 2207 based classifier
cannot differentiate same protocol ID traffic between two end-nodes --
please see Footnote 2. That is relevant
only to the point made by Mike earlier that RFC 2207 solves all Intserv
transport ESP related problems.
Regards,
Alex
Footnote 1.
------------
The Intserv filter specification based on a flow label, is an
alternative to the filter specification based on source port. So, the
flow label can be seen as a replacement or alternative of the source
port, in the filter specification. Or, the Intserv flow label has a
relationship, for the duration of a flow state, with the port
information. That relationship is not different than the relastionship
between a Diffserv flow label value, and the source port. Therefore, a
Intserv use of flow label, versus a Diffserv use of flow label,
vis-a-vis compromising privacy of transport mode ESP, is similar.
Footnote 2.
-----------
According to RFC 2207, a Intserv RFC 2207 based RSVP session is
identified by the 3-tuple:
DstAddr, Protocol ID, vDstPort (Session Spec)
while a sender (Sender Template) is defined by the 2-tuple
SrcAddr, GPI=SPI (Filter Spec)(Sender Template)
Furthermore a RCF 2207 based classifier is using a 4-tuple:
DstAddr, Protocol ID, SrcAddr, GPI (page 7)
where the Protocol ID, and GPI=SPI are fetched from the AH, or ESP
headers.
The control plane - admission control - (in FF Style) seems to be using
the Session spec, and Filter SPec, in making resource reservations. But
the the data plane (traffic) classifier does not hold the 'vdstprt', and
therefore it cannot make a differentiation between distinct flows with
the same protocol ID between two end-nodes (same SPI, SRC, DST
addresses).
End Footnotes
------------
[EMAIL PROTECTED] wrote:
>
> Mike,
>
> I believe you misunderstood what I meant. To rephrase: The currently defined
> RFC 2460 App.A semantics allows the IPv6 flow label field to be used for
> intserv MF-classification, instead of any of the transport headers. In this
> case the multi-field (MF) classifier would look only at the IP addresses and
> the flow label. Intserv does not need to care about any of the headers above
> the IP header, if the flow label is used and signaled end-to-end. With the
> current flow label definition there are no additional privacy implications
> raised by the use of the flow label in intserv signaling and classification.
>
> Brian has repeatedly mentioned that intserv would have a problem with ESP.
> With reference to RFC 2207 this is clearly not true (uses SPI instead of the
> ports). Additionally, using the IPv6 Flow Label to label the flows for
> intserv allows the intserv signaling implementation to be independent of the
> IPsec policy in place (e.g. signaling would be the same regardless the IPsec
> policy, don't need to refresh the intserv state when re-keying, etc.).
>
> Jarno
>
> Michael Thomas wrote:
> >
> > [EMAIL PROTECTED] writes:
> > > Just some comments for clarifying some stuff that keeps coming up
> > > repeatedly:
> > >
> > > Brian E Carpenter wrote:
> > > >
> > > > This is a very unfair comment. Diffserv is just fine in the
> > > > case of unencrypted traffic. It has a problem (and so does
> > > > intserv I suspect) with tunnel or transport mode ESP.
> > > >
> > >
> > > IPv4 intserv shares the same difficulty of doing
> > MF-classification with ESP.
> > > However, in IPv6 the flow label can be used in
> > MF-classification for intserv
> > > semantics, even when ESP is used.
> >
> > This is incorrect. RFC 2207 defines a way to classify
> > ESP traffic for intserv *and* it doesn't compromise
> > privacy. What's being floated here for diffserv requires
> > that I compromise privacy in order to work, which I
> > think is bogus.
> >
> > Mike
> >
S/MIME Cryptographic Signature
