Pekka, Please see in line:
Pekka Savola wrote:
>
> We may be treading into a very difficult situation (in some ways similar
> to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd
> really appreciate if folks would have a look at the particular issue (at
> the end of the mail) and think whether it is a problem or not.
>
> On Wed, 5 Mar 2003, Brian E Carpenter wrote:
> > > The 3-tuple of the Flow Label and the Source and Destination Address
> > > fields enables efficient IPv6 flow classification, where only IPv6
> > > main header fields in fixed positions are used.
> > >
> > > ==> this might require some extra analysis somewhere (not in that
> > > particular place, I think). In particular, this seems to say that once
> > > this is published people can happily move to using the three-tuple
> > > classification. The reality is probably quite different, and one must
> > > also consider the big portion of nodes which do not mark the flows.
> >
> > The goal of this document is not to describe use cases. It is
> > to set the minimum conditions hosts and routers must meet. I do
> > not believe we should add use cases to this document.
>
> I believe the original text does not give a realistic picture of the
> situation.
>
> For the purpose of minimum conditions, the text could be removed
> altogether, of course -- that would be fine by me. I could also live with
> (by a thread :-) the current version, but I really believe it should be
> changed slightly.
>
I would suggest we take your statement that "you could live with the
current version".
I do not think that what is to be said, can be said significantly
better, than the way it is said in the draft, in plain, simple, accurate
English.
> > > To enable applications and transport protocols to define what packets
> > > constitute a flow, the source node MUST provide means for the
> > > applications and transport protocols to specify the Flow Label values
> > > to be used with their flows.
> > >
> > > ==> this requirement seems unacceptable at the moment. This clearly
> > > requires (at least) de-facto API so applications could set Flow Label
> > > values -- and as such does not exist. If it did (and I believe there's
> > > work in progress), there would *have to be* a normative reference to it).
> > > So, clearly a MUST seems to a big no-no.
> >
> > But this is a statement about what hosts must do to make the flow label
> > useful.
>
> No, that's not correct, or either of us is misunderstanding the paragraph
> above (if so, a wording change is needed).
>
> The nodes (kernel, in particular) are able to mark flows by itself,
> without any interaction from the applications -- so having apps have a
> MUST possibility to influence the flow labeling is undoubtedly useful, but
> certainly not something requiring MUST, considering the current situation.
>
In simplified translation, the text says that the IP layer is not the
only layer selecting
flow label values. This is the way it MUST be: in a node, which is
sourcing labeled packets,
the flow label value is in the same category with other fields of the
IPv6 header: clients
of the IP layer (layers above) MUST be able to set the value, if they
need to.
> Note: I'd argue for MUST myuself if we had had a standard (or even
> de-facto standard!) mechanism specified (and hopefully implemented) for 1
> year before this being sent to the IESG.
>
The (this) requirement is not conditional to the existence of an API, or
an API function call
mechanism. Rather the API, or the API function call, or the API function
call parameter,
is a consequence of this requirement, which is the way it should be.
> > If you want to standardize a socket API extension that's fine,
> > the Open Group exists for that. However, I believe a MUST is needed.
>
> A MUST without a means is bad practise, IMO.
>
This sets the rule, from the protocol stack angle, for the flow label
related API, API function call, or API function call parameter(s). The
rule will bring the "means".
> > > A source node MUST ensure that it does not reuse Flow Label values it
> > > is currently using or has recently used when creating new flows. Flow
> > > Label values previously used with a specific pair of source and
> > > destination addresses MUST NOT be assigned to new flows with the same
> > > address pair within 120 seconds of the termination of the previous
> > > flow.
> > >
> > > ==> so, if I make create a raw socket, manually fiddle in the flow label
> > > value which was previously used, and send the packet, the operating system
> > > kernel should hijack it and prevent it from going out? Get real. Perhaps
> > > s/reuse/unintentionally reuse/, or some other rewording?
> >
> > Yes, the stack is supposed to do that. It's not hard. In an earlier version
> > we included an algorithm, but the WG wanted it removed, so we removed it.
>
> Yes, the stack can do it easily -- no doubt about that -- but it's
> *wrong*; this is connected to the security issue, below.
>
There were people that requested this particular behavior.
So, were you saying earlier that if the text in the draft
***MUST ensure that it does not reuse Flow Label values....***
were:
***MUST ensure that it does not unintentionally reuse Flow Label
values....***
it would be OK with you ?
> > > methods MUST meet the following basic requirements:
> > >
> > > ==> this and the following points seem a little oddly placed in this memo:
> > > they seem out-of-place, as the rest of the memo seems to concentrate on
> > > entirely different issues. Personally I view specifying how source nodes
> > > should label flows one thing, and the rest entirely another. But I can
> > > live with these, even though I think they're more fit to a non-standards
> > > track document.
> >
> > Then you don't want a change here?
>
> I can live without it -- waiting to hear others' opinions -- but I think
> the source node behaviour is entirely different issue from the network
> treatment.
>
Here is another opinion. The two are the essential aspects of the flow
label mechanism:
setting the flow label in nodes sourcing packets(1), and processing flow
labels in
nodes receiving labeled packets (2) [packet forwarding nodes].
> > > 5.1 Theft and Denial of Service
> > >
> > > ==> this section mainly deals with issues relating to forging all of the
> > > source,destination,label three-tuple (exception is the last paragraph,
> > > which deals with a trusted-node-but-untrusted-user/application case),
> > > which protects mainly against a DoS attack (resource depletion).
> > >
> > > This seems to overlook the most important part: the typical model today is
> > > that operators perform differentiation of flows *themselves*: this
> > > document proposes to shift that, *over an administrative boundary*, to the
> > > source nodes, which suddenly become trusted to do the right thing.
> >
> > No, it adds the *labelling* of flows to the source, as a new capability.
>
> The labeling with current "service model" leads to differentiation. I'll
> try to reword it again below. If the "service model" would be such that
> the source node is *not* expected to label flows correctly, I'd certainly
> agree.
>
>From the point of view of the "operators model", servicing packets based
on
packet classification, labeling flows is essentially not different than
setting
other packet header fields, which are used for packet classification, so
I do not
understand why you see a difference. There is no intention in the draft
to
shift the current model to a different one, to any "administrative body"
on the
source nodes.
> > It says *nothing* about how differentiation is done. That is indeed
> > a separate and quite complex discussion, that will keep the QOS
> > community busy for years.
>
> I believe a bit similar arguments were on the table when mobileip working
> group proposed MIPv6 to the IESG, and it got pushed down, as "doesn't
> work, be more specific". That was some 2-3 years ago, and only now MIPv6
> is nearing completion.
>
I wish I knew what you were referring to, to be able to respond. I will
stop here, since
the rest of your message seems to elaborate further on a reference that
is not at all
clear.
Regards,
Alex
Not read after this point!------------------------------
> I'd rather handle these kind of issues before IESG, if possible.
>
> The problems are different, but there seem to be some dangerous common
> elements.
>
> > The idea is to keep that discussion out
> > of the IPv6 WG, by defining the boundary conditions here, so that
> > the flow label becomes a viable tool for differentiation downstream.
>
> My fear is that false assumptions lead to wrong conclusions and broken
> tools, and wasted effort (both from IPv6 wg and especially from the
> follow-up wgs).
>
> > I think this was clear in the previous WG discussions.
>
> Unfortunately, the flood was so huge at a point that I couldn't keep up
> (because I didn't really even care, except whether WG would go on a course
> which seems really problematic, like now)
>
> > > This would be equivalent to replacing network ingress filtering (to drop
> > > packets with forged source addresses) to a requirement for nodes to allow
> > > out only packets which include their own source address.
> >
> >
> > (By the way, do
> > you think nodes *should* be allowed to forge the source address?)
>
> I'll answer this first.
>
> The nodes certainly should be allowed (in the kernel level) to forge the
> source addresses: any model which forces this is broken.
>
> The reason for breakage is that such a model assumes that the nodes behave
> "properly". For most cases, that is correct. But because there is still
> a huge number of systems behaving differently, you cannot depend on it,
> and assuming it is being done would be wrong.
>
> The right (my humble POV, of course :-) answers to your question are:
>
> - no, the user privileged process on a node should not be able to set the
> source address (no problem today)
> - no, the *network* where the node is attached to should not allow the
> user to forge the source address (note: different administrative entity)
>
> > No. The checks can perfectly well be applied at ISP ingress.
>
> Yes, but as the first comment seems to show, in practise this checking
> would be de-facto removed for performance etc. reasons.
>
> > I did want to include more aggressive text about ingress
> > filtering, but in fact it would be out of place.
>
> I'm not sure which kind of text you're referring to, but IMO ingress
> filtering misses the biggest point.
>
> > > Needless to say this seems to indicate a major oversight of the
> > > security/operational reality. I'd be very surprised if this was not
> > > pushed back in the IESG unless this caveat is very explicitly documented.
> >
> > I think your interpretation is quite wrong, but we can certainly ask a
> > security expert or two.
>
> Ok.
>
> To try to clarify what I meant, let me try to explain it again.
>
> Any model that requires that source nodes prevent the root/administrator
> from willingly doing something, and more or less *depending on that* is
> broken.
>
> Let me try to give an example. When Windows XP was being published, some
> very popular magazines were writing about their belief that adding "raw
> sockets" functionality would be catastrophic for the Internet, degrade
> security as people could "now" send any kind of packets they'd want etc.
> The reality was entirely different. Such can be done *anyway*, using
> other implementations, using different mechanisms to achieve the same
> goal, etc.
>
> This is a similar issue. Given an *untrusted* node, specifying mechanisms
> which try to make the *untrusted* node do something you'd like to trust
> (to a rather full extent) seems *completely* bogus..
>
> Certainly, one should specify checks that user-mode applications MUST NOT
> be able to re-use flow labels within a lifetime, but that's entirely
> different from the approach in the draft.
>
> Certainly, this is a very problematic issue (which was thought to be
> solved later, in some other w.g.). I'm not requiring it be solved here.
> But I'm requiring that we don't pass the problem on without stating *very*
> explicitly the issues why it might/might not work properly -- so that any
> followup efforts that might start to build QoS mechanisms on this would
> not start with an entirely different set of assumptions (easily leading to
> wrong conclusions and broken tools).
>
> I'm not sure if I managed to make the point any clearer, I hope so.
>
> I'd also really appreciate comment on this viewpoint (for or against :-)
> from everybody.
>
> Especially those with (ISP) operator [the "customer of the IETF" in this
> instance] or security background would be encouraged to speak up. :-)
>
> --
> 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]
> --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
