Subject: IPv6 w.g. Last Call on "IPv6 Flow Label Specification"

From: Bob Hinden & Margaret Wasserman <[email-masked]>
Date: Tue, 04 Mar 2003 10:40:23 -0800

This is a one week IPv6 working group last call for comments on advancing 
the following document as a Proposed Standard:

	Title		: IPv6 Flow Label Specification
	Author(s)	: J. Rajahalme, A. Conta, B. Carpenter, S. Deering
	Filename	: draft-ietf-ipv6-flow-label-05.txt
	Pages		: 8
	Date		: 2003-3-3

The chairs belive this draft represents the consensus of the working group 
and resolves issues raised during and subsequent to the working group last 
call.  However given the time that has elapsed we think a short working 
group last call is desirable to verify the consensus before forwarding the 
document to the IESG.

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  This last call period will end on 11 
March 2003.

Bob Hinden / Margaret Wasserman

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Mar 2003 22:57:00 +0200 (EET)

> group last call is desirable to verify the consensus before forwarding the 

[note: I had already written this message once but accidentally cancelled 
the message -- hope I don't forget anything]

In summary, I don't believe the doc is ready to be sent to the IESG.  
There are a few major issues to be worked out yet, the last of the the 
most important.

Comments below.

substantial:
------------

   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.

A possible fix would be to tone down "enable" (e.g. "make xxx possible") 
and add some minor tweaking.

   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.

   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?

   To enable co-existence of different methods in IPv6 nodes, the
   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.

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.

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.

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.

semi-editorial
--------------

   Nodes keeping dynamic flow state MUST NOT assume packets arriving 120
   seconds or more after the previous packet of a flow still belong to
   the same flow, unless a flow state establishment method in use
   defines a longer flow state lifetime or the flow state has been
   explicitly refreshed within the lifetime duration.

==> this is a way too sentence, 5 lines, and constructed in with a 
negative: "MUST NOT blahblah, unless foofoo".  You really have to read 
that a couple of times to understand what it's trying to say.  I'd 
strongly urge to reword and simplify.

editorial
---------

   If an IPv6 node is not providing flow-specific treatment, it MUST
   ignore the field when receiving or forwarding a packet.

==> reword: "providing .. treatment" seems to sound awkward in the case of 
"receiving a packet" (ie. in the case of end-node, not router).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2003 11:24:37 +0100

Pekka,

> There are a few major issues to be worked out yet, the last of the the

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.

> and add some minor tweaking.

I don't think we need to tweak. "Enable" is exactly right.

> 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. 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.

> 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.

> live with these, even though I think they're more fit to a non-standards

Then you don't want a change here?

> 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.
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. 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.
I think this was clear in the previous WG discussions.

> out only packets which include their own source address.

No. The checks can perfectly well be applied at ISP ingress.
I did want to include more aggressive text about ingress
filtering, but in fact it would be out of place. (By the way, do
you think nodes *should* be allowed to forge the source address?)

> 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.

Thanks for the review, and for the editos below.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Mar 2003 19:56:34 +0200 (EET)

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.

> 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.

> 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.  

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.

> If you want to standardize a socket API extension that's fine,

A MUST without a means is bad practise, IMO.

> 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.

> 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.

> 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.

> 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'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

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)
 
> (By the way, do

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.

> 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.

> I think your interpretation is quite wrong, but we can certainly ask a 

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. :-)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Mar 2003 13:32:55 +0200 (EET)

On Thu, 6 Mar 2003, Brian E Carpenter wrote:
> The flow label has been a forgeable field since IPSEC decided to leave
> it outside the crypto calculation. I'd be very happy if this decision
> could be reversed, since the field is immutable, but I don't think that 
> is realistic. IMHO the IESG would have no grounds for raising this now; 
> it derives automatically from ancient decsions.

The use of IPsec seems irrelevant for the *ISP* as they can't verify it 
-- no help there.

The problem is of trying to make untrusted end-nodes trusted to label the 
flows properly.  Changing IPsec will not help (except if you assume 
communication is to e.g. ISP's own servers, middleboxes etc.).
 
> I agree that we should get a security person to look at your comments, but 
> unless anyone else supports your concern, it's my impression that you are 
> worrying about something we cannot change anyway. 

There are two most major issues here:

 1) something we should change
 2) something we must document if we cannot change

I'm requiring at least 2).

> The security considerations
> simply document facts of life.

Unfortunately, the security considerations as of now *does not* document 
these facts of life.  This is the biggest concern.

Of course, I strongly also want to change the model slightly (e.g. the
MUST requirement for nodes not to send out used flow lables), to make it
the restrictions of the model clearer.  This does not yet fix the core
problem, how the ISP can make anything of these labels -- trust them --
but at least now the starting assumptions are closer to correct.

The extreme case would be taking a full halt here for all of the flow 
label draft, working out the details, and only then publishing it.  I 
don't think this is correct approach for now.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Mar 2003 11:33:33 +0100

I agree that we should get a security person to look at your comments, but 
unless anyone else supports your concern, it's my impression that you are 
worrying about something we cannot change anyway. The security considerations
simply document facts of life.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Mar 2003 13:32:08 +0100

Pekka,

Please send text for what you think we should add to the security 
considerations.

Personally, I see no reason why the ISP's trust model changes here. Most IP
header fields potentially used for QOS classification are forgeable. This
isn't a flow label problem, or an IPv6 problem, or even an IP problem.
It's a characteristic of connectionless datagrams.

All your other points really are not new issues, and we have been
working on the draft for more than a year to make it fit around
the various perspectives expressed in the WG. 

   Brian

---

From: Alex Conta <[email-masked]>
Date: Wed, 12 Mar 2003 15:45:18 -0500

Pekka,

Please see in line:

> (by a thread :-) the current version, but I really believe it should be

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.

> 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. 

> 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. 

> 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".

> *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 ?

> the source node behaviour is entirely different issue from the network

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].

>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.

> work, be more specific".  That was some 2-3 years ago, and only now MIPv6

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!------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Mar 2003 09:19:27 +0200 (EET)

Ok.
 
> 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.

...
 
> 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.

No, I have to disagree with this approach.  In this case, making a
normative reference to an API document (which would delay the publication
of flow label specification until the API is published) would be OK, but
I'm not sure that's what folks would want.

For *applications* and application writers (which are also the customers
of flow label spec here) requiring that implementations provide any
programming interface at all, one specific to the implementation is the
worst choice possible.  So, if one would like to write portable
applications, you'd have to use each implementation-specific programming
interface for every implementation.

That seems counter-productive and unacceptable, IMO -- but I'd like to
hear what application writers would say about that.  I agree with the need
of a way to have applications to be able to influence the flow label, but 
a MUST would possibly lead to one of the below:

1) all implementations implementing different programming interfaces; a
non-starter for applications

2) implementations not implementing all of the flow label spec, ie. just
blatantly ignoring the MUST (compare with the temporary/public address
knob in the default address selection, in RFC3484 sect 5r7 -- this was a
bad last-minute compromise which nobody have implemented AFAIK)

3) implementations waiting for an API before implementing the flow label 
spec

> rule will bring the "means".

I guess we disagree on the usability of the API for application writers if
the API is not uniform enough.  Personally, I view an
implementation-specific API for something generic like this useless (as a
programmer).
 
> There were people that requested this particular behavior. 

I wonder if they realized the implications.  I'm sure that e.g. people
focusing on the network part of the flow label would really appreciate
having a flow labels guaranteed to be distinct, so their use in QoS and
whatever would be a lot simplified, but that ignores the big picture at
the expense of looking at only part of the solution space.
 
> it would be OK with you ?

I find that acceptable.  Extra text in security considerations would still
be required, though (as noted later in my message).

> label mechanism: setting the flow label in nodes sourcing packets(1),
> and processing flow labels in nodes receiving labeled packets (2)
> [packet forwarding nodes].

Note that (2) also semantically includes the destination nodes, not just 
in-between routers, if you're not careful with the terminology.

As I read it, you wrote that as a disagreement, but IMO that sounds very 
much like a partial agreement to me: that flow labeling consists of two 
different functions.

These functions have entirely different requirements and considerations, 
but naturally, both are required to implement flow labeling.

I was just arguing that "2" and "1+1" still makes "2", but "1+1" could be
simpler for those that are only interested in the first or second "1",
etc.

> 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.

The spec very clearly states that flow labeling enables classification 
based on (src, dst, flow label).  That is clearly different than (src, 
dst, protocol, srcport, dstport).

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Mar 2003 22:11:10 +0200 (EET)

Hello,

Following up from the last call and the issues I raised, I'll try to 
propose something to start with to make the security considerations more 
in line with certain imporant issues.

Note: I'm assuming that the sentence:

   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.

will be changed, at least to "unintentionally reuse".

Now, to the security considerations.

   The goal of the Flow Label is to allow different levels of service to
   be provided for traffic streams on a common network infrastructure. A
   variety of techniques may be used to achieve this, but the end result
   will be that some packets receive different (e.g., better or worse)
   service than others. The mapping of network traffic to the flow-
   specific treatment is triggered by the IP addresses and Flow Label
   value of the IPv6 header, and hence an adversary may be able to
   obtain better service by modifying the IPv6 header or by injecting
   packets with false addresses and labels. Taken to its limits, such
                                ^^^

==> false addresses _or_ labels.

   theft-of-service becomes a denial-of-service attack when the modified
   or injected traffic depletes the resources available to forward it
   and other traffic streams.

==> after this, add a new paragraph:

   Note that there is no guarantee that flow labels used in a node are
   not used in any manner the node wants to, even reusing flow labels.
   This is a feature: as nodes are typically untrusted, it cannot be 
   assumed that they would in fact implement or adhere to any restrictions 
   if such would be set -- and therefore any assumptions made by the 
   network on nodes' behaviour should be very limited except in 
   cases where the nodes are explicitly trusted.

==> and after the "Since flows.." paragraph, add paragraphs:

   There are two issues with different properties:
   spoofing of only Flow Label, and spoofing of the whole 3-tuple, 
   including Source and Destination Address.

   The former can be done inside a node which is using the correct source 
   address.  Being able to spoof Flow Label typically requires being in 
   position to also forge an address -- but in many cases, spoofing the 
   address may not be the interesting, especially if the spoofer's goal
   is theft of service, not denial of service.

   The latter can be done by a host which is not subject to ingress 
   filtering [INGR] or an intermediate router.  Due to its properties, 
   such is typically useful only for denial of service.

==> TODO: consider whether changes are needed (on ingress filtering) in 
the second-last paragraph.

Perhaps this should get one started.

---

From: Alex Conta <[email-masked]>
Date: Thu, 13 Mar 2003 16:17:29 -0500

Pekka,

Please see in line:

Pekka Savola wrote:
> [....]

I think this was never intended: it is not a normative reference to an
API 
document. It is simply a requirement for implementations. 

> interface for every implementation.

The mechanism, whatever it is, a standard or proprietary API, or one
function 
call of an API, or one or more parameters of an existent function call,
or 
anything else, are all completely independent of this flow label
specification. 
Please remember: publishing IPv6 specs as proposed 
standard (RFC), was never dependent on publishing or referencing an API.
 
> non-starter for applications

I think this is orthogonal to the flow label specification.

> bad last-minute compromise which nobody have implemented AFAIK)

It is a fact of life to have non-fully compliant implementations. 
That is orthogonal to the progress of a specification to proposed
standard.

> implementation-specific API for something generic like this useless (as a

Even if we do not go any further on this, I think we reached an area
which is way 
outside the scope of the flow label specification. I may agree with you
close to 100% 
on what you say right above, but only as part of a completely different
topic, which 
is not this flow label specification, it is not this last call. 

> the expense of looking at only part of the solution space.

I think they did. Even though it is succinct, the specification defines,
or 
mentions a number of mechanisms pertinent to a very diverse set of
views, 
and uses. Personally, I favor some over the others, but after thinking, 
and understanding, I agreed that all can work. This was essential 
for being part of the current consensus, which took a long time, and a
lot 
of work, from the WG, the authors, the WG chairs, and the area
directors.

> be required, though (as noted later in my message).

Let's hold on to this (including the word "unintentionally") for a
moment.

>[...]
> [...]

Indeed, there is partial agreement. And there would be full agreement,
if you 
looked at that as two functions, or rather two components of one
mechanism.

> simpler for those that are only interested in the first or second "1",

Indeed, so we agree, as I expected above.

> dst, protocol, srcport, dstport).

You're pointing now to a difference in the placement of the fields in
the 
headers, which I think is orthogonal to the difference you were pointing
at before, 
to which I responded that there is no difference.

Earlier, I think you were trying to say that without flow label, there
is a 
certain model, which changes with the use of the flow label.
Essentially, I 
responded that it is not the case, the model does not change: the model
of 
trusting/doubting a flow label is not different from the model of 
trusting/doubting a pair of ports and a protocol number: they're all set
by 
the source node of the packets, and are part of some classifiers set
with some 
direct/indirect knowledge/agreement from network infrastructure
operators.

Regards,
Alex Conta

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Mar 2003 23:43:17 +0200 (EET)

> standard (RFC), was never dependent on publishing or referencing an API.

Then again, not all that may IPv6 specs state that implementation MUST
provide applications with a way to set "foo".

> That is orthogonal to the progress of a specification to proposed

Depends on what you want.  I'd prefer working, useful specifications which 
do not have requirements which are not met.
 
> or mentions a number of mechanisms pertinent to a very diverse set of
> views, and uses. Personally, I favor some over the others, but after
> thinking, and understanding, I agreed that all can work. This was
> essential for being part of the current consensus, which took a long
> time, and a lot of work, from the WG, the authors, the WG chairs, and
> the area directors.

Consensus is not useful unless the result is useful.
 
> the headers, which I think is orthogonal to the difference you were
> pointing at before, to which I responded that there is no difference.

No, I'm not interested in the placement -- I'm concerned about the data 
available to the network operator, and the assumptions the spec will give 
him on its applicability.
 
> is a certain model, which changes with the use of the flow label.

That's correct.

> Essentially, I responded that it is not the case, the model does not
> change: the model of trusting/doubting a flow label is not different
> from the model of trusting/doubting a pair of ports and a protocol
> number: they're all set by the source node of the packets, and are part
> of some classifiers set with some direct/indirect knowledge/agreement
> from network infrastructure operators.

If you believe adding the flow label in the mix does not change the model,
I'd maybe call it naivete.  The question is how much (and how) it's
changed.

But perhaps it would be better to have a look at some of the security
considerations text I proposed on the list a few hours ago, and if you
disagree, try to describe how you see the the model between the network
and source nodes so we could understand the views better.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Mar 2003 15:51:49 +0200 (EET)

On Fri, 14 Mar 2003, Brian E Carpenter wrote:
> But what more is needed about ingress filtering? That seems
> to me to be a generic issue, with very little specificity
> to flow label attacks.

What I meant is that there is some overlap with the text and some 
wordsmithing might be useful.  No new text is needed, AFAICS.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2003 14:41:20 +0100

Apart from reserving the right to touch up the English, I
have no trouble with Pekka's proposed additions.

Thanks
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2003 16:14:45 +0100

Oh, OK. Wordsmithing I can manage!

I doubt if we can do any more on this before the IETF. I only have 15 hours
before I must be on a train to the airport, and 14.9 of them are reserved.

   Brian

---

From: Alex Conta <[email-masked]>
Date: Fri, 14 Mar 2003 10:51:42 -0500

Pekka,

Echoing Brian's message, I am comfortable with the authors working on 
fitting in the draft, after some wordsmithing, the text that you have 
proposed for the Security Section.

Regards,
Alex