I've decidedly tried getting into the flow label debate, but will do so
for a few parts.
In general, I liked many of the Thomas's improvements; IMO, specification
of flow label itself (with or without RFC2119 keywords), and treatment
(like that nodes SHOULD label flows) should be more clearly separated.
Two comments..:
> > > 2. IPv6 Flow Label Specification
> > >
> > > The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> > > by a source to label packets of a flow. A non-zero Flow Label
> >
> > Note: I don't think the SHOULD/MUST usage in this document is always
> > helpful or even correct. It would make sense to go read the defintions
> > in RFC 2119 as cited.
>
> This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
> doing it.
> >
> > This document defines a flow as the three tuple. No "SHOULD" about
> > it. If a source wants to label a flow, it does so by setting the flow
> > label. A better wording would be something like:
> >
> > Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
> > the IP source address, and the IP destination address in the IPv6
> > header.
>
> No. We want to say that hosts SHOULD label flows. (Rationale: it's
> only by this becoming the norm that the flow label can become an effective
> tool. If only 1% of traffic is labelled, there is no benefit.)
I think Thomas's text is a very good introduction: if we want to say
"hosts SHOULD label flows", just add it in a new paragraph after that.
.. similar in some other cases ..
> > > Security Considerations
> > >
> > > The use of the Flow Label field enables flow classification also in
> > > the presence of encryption of IPv6 payloads. This allows the
> > > transport header values to remain confidential, which may lessen the
> > > possibilities for some forms of traffic analysis. However, the
> > > labeling of flows defined in this specification may reveal some
> > > structure of communications otherwise concealed by transport mode
> >
> > Seems like more could be said here. If use of the flow label allows
> > special treatment of traffic, aren't there possible theft of service
> > issues? Or DOS issues, if someone generates traffic trying to
> > overwhelm a particular flow? What about authorization? Can anyone set
> > up flows? Are there requirements or issues here that should be
> > mentioned in Section 4? This section seems a bit incomplete.
>
> Since flow labels are not protected by IPSEC-AH, they can be forged.
> We should probably state this. However, since the flow is actually
> identified by the {srce, dest, label} triplet, the theft of service
> or DOS problem actually requires address spoofing as well as label
> spoofing (and is prevented by ingress filtering). We should probably say
> this.
There are many ways to do theft of service, I guess.
Assume that node establishes (using some mechanism) a preferred treatment
for a flow with <src, dest, label> -- particularly meant for e.g. single
TCP connection. It can re-use this as much as it wants, getting better
service.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
