below...
Pekka Savola wrote:
>
> 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.
Well, we were strongly asked in Atlanta to shorten and simplify the
document. Now you are asking us to lengthen and complicate it again.
I'd like some guidance from the chairs about this.
>
> .. 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.
That's the authorization issue, which I agree should be mentioned
(see the immediately following paragraph in my previous message).
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
