Subject: Re: Flow label drafts updated

From: RJ Atkinson <[email-masked]>
Date: Tue, 3 May 2011 05:47:23 -0400

Hi,

My thanks to all of the editors for their joint work to sort out
these drafts and to progress them together.  It is substantial
work to undertake.  The drafts generally seem fine and are
eminently readable.

However, the "Security Considerations" for both 
draft-ietf-6man-flow-ecmp-02 and draft-ietf-6man-flow-3697bis 
seem not to mention the issue where the IPv6 Flow Label field
is a relatively high-bandwidth covert channel.  This means the
Security Considerations for those 2 I-Ds are incomplete.

I'm pleased that the covert channel issue is discussed on page 4 
of draft-ietf-6man-flow-update-05.  This covert channel issue is 
one reason why a number of deployed IPv6-capable firewalls (and 
other similar security appliances) clear the IPv6 Flow Label 
(e.g. in financial/trading environments where M&A information 
has very high monetary value).  

I request that this operational security concern, which is entirely 
legitimate albeit not applicable to all operational environments, 
at least be mentioned at the top of page 11 of draft-ietf-6man-flow-3697bis 
(i.e. where the fact that Flow Labels will continue to be zeroed 
in some deployments is noted).  At present, the words there seem 
to imply that the zeroing behaviour is illogical, silly, and/or wrong 
-- when in fact it is logical, sensible, and quite correct in certain 
deployments.  I would be MUCH happier if the wording were changed
to allow an "operational security" exception to the general 
principle of not modifying non-zero IPv6 Flow Labels during transit.
For example, the wording could say that network devices ought
not modify non-zero IPv6 Flow Labels *by default*, leaving it
open for users with particular security concerns to configure
a non-default configuration (i.e. zeroing the Flow Label).

I request that at least a brief mention of the covert channel
issue be made in the Security Considerations sections of both 
draft-ietf-6man-flow-ecmp and draft-ietf-6man-flow-3697bis.
If desired, such mentions could refer to the Gont draft or 
to the -3697bis draft for more detailed discussion of that
issue.

I am troubled by the apparent decision to ignore legitimate
operational security considerations (e.g. about covert channels) 
and also the apparent decision to write these documents 
in a manner intended to legislate reasonable security measures 
(if applicable only in selected deployments) out of existence.
This seems to be a case of the IETF levying deployment
constraints upon users/operators, which is something that the
IETF generally tries to avoid.

Yours,

Ran Atkinson

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 May 2011 09:58:24 +1200

Ran,

> operational security considerations (e.g. about covert channels) 

We should certainly mention the covert channels issue in the
security considerations of 3697bis.

> (if applicable only in selected deployments) out of existence.

I don't understand this comment. The flow label has always been
defined as immutable; the consensus in the WG is to keep that
property. So a firewall that overwrites it is unambiguously
breaking the standard.

Regards
   Brian

On 2011-05-03 21:47, RJ Atkinson wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 5 May 2011 08:55:57 -0400

> property. So a firewall that overwrites it is unambiguously

Brian,

The flow label has been modified by routers/security gateways 
for many years now.  It is not a new event.  I was first aware
of it circa 1997.  As near as I can tell, this has been done
for security reasons the whole time.  Those security reasons
are in fact reasonable, albeit not applicable to all environments.

Pretending those legitimate security considerations don't exist 
is actively harmful, which is why the operational practice is 
not new.  IPv6 specifications should reflect reality, 
not a theoretical world that we know does not exist
(and never has, or at least hasn't existed for ~15 years now).

I proposed edits that are reasonable.  This WG has not
considered those edits.  It is not obvious to me that 
there is any consensus, either way, on the current 
wording or on the proposed wording.  There should be 
further WG discussion if you really believe the proposed
edit is technically unsoundl, otherwise the edit ought 
to be made (or a wordsmithed version of it).

Yours,

Ran

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 5 May 2011 13:48:42 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, May 03, 2011 5:58 PM
Subject: Re: Flow label drafts updated

> and also the apparent decision to write these documents in a manner 
> intended to legislate reasonable security measures (if applicable only 
> in selected deployments) out of existence.

I don't understand this comment. The flow label has always been defined as immutable; the consensus in the WG is to keep that
property. So a firewall that overwrites it is unambiguously breaking the standard.

[WEG] now it's my turn to be confused by your comment, Brian. I missed this detail of interpretation when reviewing the draft for
LC, and I apologize, but I think it's pretty important...
>From the 3697bis draft:
"There is no way to verify whether a flow label has been modified en
   route or whether it belongs to a uniform distribution.  Therefore, no
   Internet-wide mechanism can depend mathematically on immutable and
   uniformly distributed flow labels; they have a "best effort" quality."
 But it goes on to say:
" This specification defines the flow label as immutable once it has
   been set to a non-zero value.  However, implementers are advised that
   forwarding nodes, especially those acting as domain border devices,
   might nevertheless be configured to change the flow label value in
   packets.  This is undetectable."
My interpretation of the above is that it functionally renders the flow label mutable. If one cannot assume that the flow label will
arrive at its destination with the original value intact, nor detect when it has been changed, it is by definition mutable and it's
nonsensical to have this discussed in such an ambiguous way in the draft, because no implementer in their right mind is going to try
to use this for an application that needs the label to be immutable in all cases. This draft should be correcting the fundamentally
flawed assumption that an unprotected field can be immutable. I don't see how Ran's comments would be a different case and
(apparently) a different interpretation of the above.

I don't recall consensus forming around this idea of immutable, but with asterisks instead of simply acknowledging that regardless
of what the standard said before, the label has always been mutable since it's unprotected. However, I've had a couple of gaps where
$day_job has taken precedence over IETF lists, so I might have missed a part of that discussion. Apologies if I'm rehashing. Perhaps
the chairs would like to offer an interpretation?

Wes George

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 May 2011 20:52:54 -0300

+1

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 May 2011 09:26:46 -0400

> My interpretation of the above is that it functionally renders the
> flow label mutable.

I think we are getting too hung up on definitions.

Is the UDP port number mutable? Is the TCP sequence number immutable?

There are ways of modifying them that are undetecable. Does that make
them mutable?

The intention is that the Flow Label not get modified. Doing so can
impact its usefulness. This is true of most fields in packets. If
random actors start tweaking various fields in a packet, that tends to
not be helpful (or worse).

I do think the document needs to say something about covert channels
and border routers zeroing out the field (and not just stick its head
in the sand and try to have it both ways, which the wording Wes quoted
effectively does).

But that doesn't mean we are declaring that the field is "mutable",
implying that anyone can start doing with it what they want.

Thomas

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 6 May 2011 19:50:31 +0000

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Friday, May 06, 2011 9:27 AM
Subject: Re: Flow label drafts updated

Is the UDP port number mutable? Is the TCP sequence number immutable?
[WEG] I think both are immutable because there's a checksum to detect changes. That doesn't make it impossible to change it in the
middle, as you mention, but it makes it much less likely that it will be.  

There are ways of modifying them that are undetecable. Does that make them mutable?
[WEG] Would you write similar language into the TCP and UDP spec like this that claims immutable but that implementers should assume
that it'll be changed along the way? By my interpretation, it comes down to level of risk for modification. IMO the checksum is a
significant difference and means that there is a reasonable assumption that things won't be changed along the way. At the very least
it'll detect changes due to data corruption, which you can't say for the IPv6 header.

The intention is that the Flow Label not get modified. Doing so can impact its usefulness. This is true of most fields in packets.
If random actors start tweaking various fields in a packet, that tends to not be helpful (or worse).
[WEG] Absolutely agree, but I don't think that calling it immutable is the only way to say it, especially if you bracket it with a
qualifier that says it's likely to get changed anyway.

I do think the document needs to say something about covert channels and border routers zeroing out the field (and not just stick
its head in the sand and try to have it both ways, which the wording Wes quoted effectively does).
But that doesn't mean we are declaring that the field is "mutable", implying that anyone can start doing with it what they want.
[WEG] fair enough, but I think this is sort of like the line between MUST NOT and SHOULD NOT.
What you're saying here is you SHOULD NOT change the value, while acknowledging that it's likely to happen in certain applications.
To me, Immutable implies MUST NOT be changed, and while people may still ignore MUSTs it's less likely.
To me, "anyone can start doing what they want" implies a MAY be changed

Wes George

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 May 2011 13:12:48 +1200

Ran,

I'm obliged to repeat myself: there has been endless feedback in the
WG that the flow label remains defined as immutable, so any middlebox
that changes it is violating the standard.

Of course the chairs can tell me this is now an open issue, but we
have been over it many times.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 May 2011 13:23:16 +1200

below...

> What you're saying here is you SHOULD NOT change the value, while acknowledging that it's likely to happen in certain applications.

It's the first I've heard of it. You MUST NOT change addresses and port numbers
in a packet; not that RFC 791 and 793 bother to mention it, because it was
unimaginable in 1981 that anyone except an attacker would do such a thing.

I'm hard over on a MUST NOT. What we've been arguing with Thomas is really about
how to express the warning that the flow label might get undetectably changed by
an on-path device, even though that is against the standard. A node downstream
from the change can't tell that it was changed, whether maliciously or by a
misguided firewall.

   Brian

> ------------------------------------------------------------------------
>

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 7 May 2011 07:33:14 -0400

On 06  May 2011, at 21:23 , Brian E Carpenter wrote:
> from the change can't tell that it was changed, whether maliciously or
> by a misguided firewall.

Brian,

  As Wes and others (including me) have been pointing out is that the
IPv6 specs have been ambiguous about the Flow Label field for a very long 
time (i.e. including before this current set of I-Ds).  The specs have 
tried simultaneously both to discourage modification of the Flow Label 
field (which I believe everyone agrees is strongly desirable in normal 
circumstances) and simultaneously recognising that the field might be 
changed (i.e. in some other circumstances).

  This issue is very far from new.  As the AH designer/author, I can say
that the reason AH doesn't include the Flow Label field in its integrity
checks is that network operators (a term I use to mean *anyone* who operates
any network, whether service provider, content provider, home network, 
enterprise network, educational network, or other network) way back 
in the early 1990s were clear that in some circumstances the Flow Label 
field would be changed during transit.  The IPv6 WG was comfortable
with that at the time.  

  Further, other IETF standards-track specifications (e.g. RFC-2402, 
Section 3.3.3.1.2.1; RFC-4302, Section 3.3.3.1.2.1) clearly note the 
IPv6 Flow Label as "mutable".  RFC-1886 Section 6 and RFC-2460 Section 6 
both require that hosts/routers *that do not support the Flow Label* 
not modify it, but does NOT require that hosts/routers that do support 
the Flow Label not modify its value.  RFC-4302 specifically notes that 
RFC-2460 does permit modification of the IPv6 Flow Label.  The Security 
Gateways I've been talking about clearly DO support the Flow Label, 
so are NOT covered by that prohibition.  It is only with RFC-3697
that an attempt is made to prohibit modification of the Flow Label
in transit -- but of course there are a number of IPv6 devices
deployed that pre-date that specificatio.  Further, RFC-3697
does NOT claim to update RFC-2460 (and RFC-2460 does allow 
modification).  

  So there is an inherent ambiguity in the set of IETF standards-track 
specifications on this topic.  It is also quite clear the IPv6 WG 
does NOT have some sort of long-standing agreement that this practice 
should be prohibited; instead the long-standing situation is that change 
should be strongly discouraged (i.e. SHOULD NOT), but is both expected 
and tolerated in the (few) situations where it is necessary from an
operational security perspective.

  Your assertion that a firewall modifying the Flow Label field is 
"misguided" is not technically sound.  In some deployment situations, 
rewriting the Flow Label field (e.g. from some received value which
might contain covert information to some different value which the
security gateway determines does not contain covert information) 
is the only technically sound behaviour.  Those situations are not 
numerous, fortunately.

  I find it curious that you aren't addressing the technical issues
that various folks are raising here, instead solely talking about
legalistic claims.  If you have a concrete technical issue, 
please put it forward and lets discuss it.  It is also wrong to try
to separate this concern from Thomas Narten's concern as they are
quite closely related and inter-twined.

Yours,

Ran Atkinson

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 May 2011 11:06:23 +1200

Wes,

Let me focus on one phrase of yours:

> because no implementer in their right mind is going to try
> to use this for an application that needs the label to be immutable in all cases.

Correct, and that has always been the case, even for any hypothetical
implementers of RFC 3697. The difference is that we're trying to say it
more clearly in 3697bis, and obviously haven't quite succeeded yet.

Nodes MUST NOT change the flow label. But since you can't detect whether
it's been changed, mechanisms using the flow label for some purpose must
be robust against unanticipated changes.

What that means in the stateless load-balancing model is that the impact
of a changed value needs to be limited to sub-optimal load balancing.

What it means in other, hypothetical, models for using the flow label
I cannot say. It's for the designer of such a model to figure out.

Maybe it's just the use of the word "immutable" that is causing the
problem here, because it implies something that physically isn't true.

Regards
   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 8 May 2011 18:21:35 -0500

> be robust against unanticipated changes.

If I may try to express what I perceive the problem to be, we have been told that (for example, and there may be others) certain security gateways DO change the value of that FL. And presumably, for good security-minded reasons. So to say FL MUST NOT be changed is, I gather, factually not possible anymore.

I agree that "since you can't detect whether it's been changed, mechanisms using the flow label for some purpose must be robust against unanticipated changes," however I think the hard nut is this MUST NOT be changed requirement.

So for example, the load balancing use of FL must not cause the session to break if FL has been changed.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 May 2011 11:47:57 +1200

> changed (i.e. in some other circumstances).

IMHO, RFC 3697 is quite clear that the flow label must not be modified,
but quite unhelpful in discussing how to deal with the fact that it
isn't checksummed.

What RFC 2460 says about the flow label is pretty useless on all counts,
which is why we wrote RFC 3697 in the first place.

> field would be changed during transit.  The IPv6 WG was comfortable

I take your word for it, but when the WG did RFC 3697 in 2003/2004, there was
strong consensus for the immutability rule.

> IPv6 Flow Label as "mutable".  

There was a thread about this on the IPv6 WG list in September 2004,
under the subject "AH and flow label". The conclusion was to continue
to leave the flow label out of the ICV calculation in the AH update
that became RFC 4302, although it was by then clearly specified as
immutable by RFC 3697.

It seemed that the goal was to be backwards compatible with RFC 2402.
The terminology "immutable" and "mutable" was the only way in that RFC
to tag header fields as included or excluded in the ICV calculation.
So an immutable field (under RFC 3697) is  labelled mutable in RFC 4302.
Duh!

RFC-1886 Section 6 and RFC-2460 Section 6
> RFC-2460 does permit modification of the IPv6 Flow Label.  

I missed that. It's a bug, since the correct normative reference at that
time was RFC 3967.

The Security
> does NOT claim to update RFC-2460 (and RFC-2460 does allow 

3697 clearly should have been tagged as formally updating 2460.
3697bis will definitely fix this.

But it's really playing with words to assert that a firewall which
chooses to overwrite the field is "supporting" it in the sense
intended by the phrase "Hosts or routers that do not support the
functions of the Flow Label field...".

> should be prohibited; 

IPv6 and its successor 6MAN have been very clear on this since 2003/4
when RFC 3697 was developed.

instead the long-standing situation is that change
> operational security perspective.

So far, the guidance from the WG has been for a MUST NOT. Obviously,
if the consensus changes, so will the draft.

> is the only technically sound behaviour.  Those situations are not 

"Misguided" was an emotional choice of word, for which I apologise.

I agree that there should be a discussion of covert channels
in the Secutity Considerations of 3697bis. That is a clear omission.

> legalistic claims.  

What I'm talking about is what I think we heard from the WG over the
past many months.

If you have a concrete technical issue,
> please put it forward and lets discuss it.

The technical issue is that load balancing based on flow label values
won't work properly if middleboxes (or attackers) change the values
arbitrarily.

  It is also wrong to try
> quite closely related and inter-twined.

Thomas has argued that if the label MUST NOT be changed, we should
remove any suggestion of cases in which it's OK to change it. Followed
to its logical conclusion, that means it's not OK for a firewall to
change it.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 08 May 2011 20:02:23 -0400

I rather hate the following idea, and I am not sure that security 
gateways would be willing to follow it.

In order for flow label usage to actually help the ECMP hardware, we 
have to expect it to work.
What if security gateways were expected to put reasonable, flow 
distributing, flow -labels on their packets?
Put differently, what if security gateways were behaving as if the 
received flow label were 0, and they were responsible for adding flow 
labels as the spec allows?

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 May 2011 13:55:07 +1200

Joel,

My loop detector just buzzed. This is more or less where we were
a couple of drafts ago, but people said "don't say that". Now,
I never delete old xml2rfc files, so I can bring back that text.
However, I'd like the WG chairs to decide...

Bert is correct below - if a load balancer doesn't balance the load,
it won't break sessions, but it will degrade performance.

    Brian

On 2011-05-09 12:02, Joel M. Halpern wrote:
>> If I may try to express what I perceive the problem to be, we have
>> been told that (for example, and there may be others) certain security
>> gateways DO change the value of that FL. And presumably, for good
>> security-minded reasons. So to say FL MUST NOT be changed is, I
>> gather, factually not possible anymore.
>>
>> I agree that "since you can't detect whether it's been changed,
>> mechanisms using the flow label for some purpose must be robust
>> against unanticipated changes," however I think the hard nut is this
>> MUST NOT be changed requirement.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 08 May 2011 21:58:43 -0400

As I said, I don't like what I (re-)suggested.
But if we want routers to actually use this, then we need it to be 
sufficiently reliable.  If too much stuff won't get balanced, operators 
will not accept the solution.

Yours,
Joel

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 9 May 2011 09:02:28 -0400

> problem here, because it implies something that physically isn't true.

I think that is a very very important part, possibly the 
central element, of this discussion.  This is a large part
of why Wes's concerns, Fernando's concerns, and my concerns 
are in fact deeply intertwined with Thomas Narten's concerns.

IMHO, trying to prohibit change in the Flow Label is about 
as sensible as the USA's attempt last century to prohibit all
consumption of alcohol.  (For folks outside the USA, that attempt 
failed miserably and within N years "prohibition" was repealed.)

A much more reasonable approach would be to say (edit to taste):

	"The Flow Label SHOULD NOT be changed in transit." 

probably coupled with (also, edit to taste):

	"If the Flow Label is changed in transit (e.g. due to 
	operational security considerations), then the Flow Label
	should be changed to a value that complies with the 
	mathematical requirements for use in load balancing."

A security gateway is by definition trusted.  So it could take
a non-zero value that potential contains hidden information and
replace it with some different non-zero value that the gateway
knows does not contain hidden information.  So long as both 
values comply with the mathematical requirements for load-balancing,
there is no adverse impact on the operational goals of the current
drafts.  It would be reasonable to prohibit taking a non-zero value
and making it zero, IMHO.  Although deployed systems are not likely
to change their behaviour, over time such systems might get upgraded
to rewrite in a way that both meets security requirements and also
meets the load-balancing objectives.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 9 May 2011 09:10:23 -0400

> functions of the Flow Label field...".

It is not playing with words.  Those security gateways normally
are also routers, using the formal IPv6 definition of a router, 
often participate in routing protocols (e.g. eBGP in the case
of multi-homed uplinks from an end-site; OSPF or RIP within an
end -site) as routers, and often use the Flow Label value as input 
to their forwarding decisions.

> won't work properly if middleboxes (or attackers) change the values

As near as I can tell, everyone here agrees on the objective of
enabling the Flow Label to be useful for load-balancing.

As my note of a few moments ago suggested, there is a way to address
both the operational security concerns and the load-balancing objectives.
Rather than repeat myself, I'll just refer back to that note.

> to its logical conclusion, that means it's not OK for a firewall to

The crux of his concern seems to be that the current text tries 
to have things both ways, which ambiguity is long-standing, 
as I noted in my weekend email.  

I hope, perhaps overly optimistically, that the formula I proposed
in my note of a few moments ago will find middle ground that most
folks find acceptable.

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 May 2011 11:00:30 +1200

Hi Ran,

> 	"The Flow Label SHOULD NOT be changed in transit." 

The authors really need to hear that from more than one person, or to
hear from the WG Chairs that it's a consensus, because it goes against
several months of discussion.

> 	mathematical requirements for use in load balancing."

Well, others have said 'don't say that', in response to earlier versions
with loosely equivalent text, so again the authors need to be told what
the consensus is.

As Ray Hunter said on another thread, reality suggests that the IETF
should recognise the existence of firewalls... so why not be explicit?

I suggest squaring this circle by retaining the MUST NOT (which IMHO
is the present consensus) but making it clear in the security
considerations that there will be exceptions. The problem here is that
the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is
what we really need. SHOULD NOT is not perceived as strong enough.

> and making it zero, IMHO.

Agreed.

   Brian

> Although deployed systems are not likely

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 May 2011 11:04:06 +1200

Hi again Ran,

> to their forwarding decisions.

Really? There are routers today that look at the flow label?

> Rather than repeat myself, I'll just refer back to that note.

Ack

> in my note of a few moments ago will find middle ground that most

As I just commented, we seem to be squaring the circle and the authors
need to be told what the WG consensus is...

   Brian

---

From: John Leslie <[email-masked]>
Date: Mon, 9 May 2011 19:27:07 -0400

> several months of discussion.

   I agree with Ran that SHOULD NOT is more appropriate for this case
where the horse has long since left the barn. Middleboxes _are_ going
to clear it (or worse).

   OTOH, I don't actually _object_ to MUST NOT -- in the narrow sense
that any node that disobeys the MUST NOT isn't speaking the protocol
as defined.

   I do believe we should, regardless, excise all use of the word
"immutable" for the Flow Label. That word isn't helping.

> what we really need. SHOULD NOT is not perceived as strong enough.

   I could live with that; but I really do suggest wordsmithing the
3 uses of "immutable".

   Additionally, I'd like to see some treatment of what may go wrong
if middleboxes change the Flow Label. If I understand, it will partly
break load-balancing. Middlebox designers probably don't understand
this issue. (Even if they did, they'd likely say, "some users are
entirely willing to accept that tradeoff.")

--
John Leslie <[email-masked]>

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 10 May 2011 12:09:38 +0000

+1 - this articulates my concerns and what I'd like to see done to resolve.

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Leslie
Sent: Monday, May 09, 2011 7:27 PM
To: Brian E Carpenter
Cc: [email-masked]; RJ Atkinson
Subject: Re: Flow label drafts updated

> several months of discussion.

   I agree with Ran that SHOULD NOT is more appropriate for this case where the horse has long since left the barn. Middleboxes
_are_ going to clear it (or worse).

   OTOH, I don't actually _object_ to MUST NOT -- in the narrow sense that any node that disobeys the MUST NOT isn't speaking the
protocol as defined.

   I do believe we should, regardless, excise all use of the word "immutable" for the Flow Label. That word isn't helping.

   Additionally, I'd like to see some treatment of what may go wrong if middleboxes change the Flow Label. If I understand, it will
partly break load-balancing. Middlebox designers probably don't understand this issue. (Even if they did, they'd likely say, "some
users are entirely willing to accept that tradeoff.")