[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Flow label drafts - updates, main open issue
From: Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date: 2011-02-25 21:42:00
Message-ID: 4D682228.7020304 () gmail ! com
[Download RAW message or body]
Hi,
There are three updated flow label drafts:
1. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-01.txt
This is the draft of the updated proposed standard for the flow label.
The open issues discussed for the previous draft have been closed
according to comments received - see the attached file for details.
The authors believe that there is one big issue remaining:
Should we delete most of the text concerning stateful methods
of handling the flow label? Basically that would mean deleting
Section 4 (and corresponding parts of the Security Considerations)
and making minor text adjustments elsewhere.
This would not mean that stateful methods are excluded for ever - it
would just recognise that we are only sure of the stateless approach
today.
2. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-03.txt
This draft is background rationale for the previous one, with minor
updates to keep it in synch.
3. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-01.txt
This is the ECMP/LAG draft updated according to WG Last Call comments.
Brian + co-authors
["flowIssues-res.txt" (text/plain)]
This note explains how the open issues noted for draft-ietf-6man-flow-3697bis-00
have been resolved in draft-ietf-6man-flow-3697bis-01.
--------------
ISSUE 1. A basic assumption in RFC 3697 is that flow labelling mechanisms will
be stateful and may need signaling. The changes discussed in the WG clearly
address a stateless approach that needs no signaling.
QUESTION: do we keep the text about flow establishment methods, or do we simply
remove it as being redundant? (This affects quite a lot of text in the draft,
and there will be several secondary issues to discuss if we keep this text.)
PROPOSED RESOLUTION: Clarify that there are two axes: stateless versus stateful
flow label assignment mechanisms, and non-signaled or signaled flow label usage methods.
Indicate that stateless, non-signaled is the default solution. Require any node that uses
stateful flow label assignment to set all Flow Labels properly, or at a minimum not to
send out Flow Label values that are zero. This requires a new MUST for such nodes:
However, any node that sets flow label values according to a stateful
scheme MUST ensure that packets conform to the present specification if
they are sent outside the network domain using the stateful scheme.
Additionally, this leads to some reordering of material to simplify the logic flow.
Also note that the stateful model is responsible for a considerable amount of
the text on possible theft of service attacks in the Security Considerations.
--------------
ISSUE 2. RFC 3697 states that flow label values must be unique (for a given address
pair and within a certain timescale). This requires the node that sets the label
to keep a list of labels currently in use. That is a significant complication
for a "stateless" implementation. If the main use of the flow label is for
load distribution, over a very large number of flows, strict uniqueness
isn't needed - a 'birthday paradox' level of label collisions is not a problem.
QUESTION: should this strict uniqueness requirement be relaxed to 'unique with high
probability'.
PROPOSED RESOLUTION: Allow the uniqueness requirement for stateful flow label
assignment mechanisms, relax it for stateless mechanisms.
--------------
ISSUE 3. 3697bis RECOMMENDS pseudo-random flow label values. The goal is be able to
use just the 3-tuple {dest addr, source addr, label} as input to load
distribution hashes. There have been a couple of objections to this:
- This property is not required for effective hashes for load distribution;
- Not all load distribution methods are statistical, so there may be some need for
deterministic flow label values.
On the other hand, the arguments for formally recommending pseudo-random labels are
that
- pseudo-randomness has security value (draft-gont-6man-flowlabel-security);
- pseudo-randomness does have value as input to hashes;
- a MAY would not have much impact on implementers, so nothing would change.
QUESTION: do we change the recommendation to set pseudo-random flow label values?
PROPOSED RESOLUTION: Keep the recommendation to set pseudo-random values, but
also see ISSUE 9 - a uniform distribution of values is the key point, in fact.
Various text adjustments to focus more on the uniform distribution.
--------------
ISSUE 4. The Introduction previously included:
Doing this [setting the flow label]
enables load spreading and receiver oriented resource allocation, for
example.
The phrase "receiver oriented resource allocation" has been deleted because
we don't know what it means.
QUESTION: Is this deletion OK?
PROPOSED RESOLUTION: Yes, delete it.
--------------
ISSUE 5. Section 2 says:
IPv6 nodes MUST NOT assume that the Flow Label value in a incoming
packet is identical to the value set by the source node.
QUESTION: This needs to be reconciled with the security usage mentioned in
draft-gont-. Would SHOULD NOT be acceptable?
PROPOSED RESOLUTION: Replace by:
Implementers should be aware that the flow label
is an unprotected field that could have been accidentally
or intentionally changed en route. Implementations MUST
take appropriate steps to protect themselves from being
vulnerable to denial of service and other types of attack that
could result.
Also added some related text in the Security Considerations.
--------------
ISSUE 6. As noted in Section 3:
QUESTION: Should we incorporate draft-gont- here, or leave it separate?
PROPOSED RESOLUTION: No comments received. We can leave it separate, and may
have to drop it if it shows no sign of getting on the standards track.
--------------
ISSUE 7. Section 5 says:
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. The use of the means to specify Flow
Label values is subject to appropriate privileges (see Section 6.1).
The source node SHOULD be able to select unused Flow Label values for
flows not requesting a specific value to be used.
As noted above, in stateless load distribution, occasional duplicate labels
surely don't matter. Also, experience suggests that applications and
transport protocols are unlikely to do any of this, and it isn't
a protocol design issue anyway.
QUESTION: Should we reduce this whole paragraph to a SHOULD or MAY, or even
remove it as out of scope in a protocol spec?
PROPOSED RESOLUTION: Drop it.
--------------
ISSUE 8. Section 6.1 says:
Only applications with an appropriate privilege in a sending host
will be entitled to set a non-zero Flow Label. Mechanisms for this
are operating system dependent. Related policy and authorization
mechanisms may also be required; for example, in a multi-user host,
only some users may be entitled to set the Flow Label. Such
authorization issues are outside the scope of this specification.
QUESTION: Should this be removed as speculative and out of scope in a
protocol spec?
PROPOSED RESOLUTION: Drop it.
--------------
ISSUE 9. The changes to section 2 include this paragraph. Please read all
of it, since the first sentence out of context causes confusion:
2. To enable stateless load distribution at any point in the
Internet, a network domain MUST NOT forward packets outside the
domain whose flow label values are other than zero or pseudo-
random. Neither domain border egress routers nor intermediate
routers/devices (using a flow-label, for example, as a part of an
input-key for a load-distribution hash) can determine by
inspection that a value is not pseudo-random. Therefore, if
nodes within a domain ignore the above recommendations to set
zero or pseudo-random flow label values, and such packets are
forwarded outside the domain, this would likely result in
undesirable operational implications (e.g., congestion,
reordering) for not only the inappropriately flow-labelled
packets, but also well-behaved flow-labelled packets, during
forwarding at various intermediate devices. Thus, a domain must
protect its peers by never exporting inappropriately labelled
packets. This document does not specify the method for enforcing
this rule. The suggested way to enforce it is that nodes within
a domain MUST NOT set the flow label to a non-zero and non-
pseudo-random number if the packet will leave the domain. If
this is not known to be the case, the border router will need to
change outgoing flow labels.
We've debated and tuned this over several versions of the predecessor
draft. But there are still objections, such as:
- MUST is too strong, if the downstream operator doesn't care about
the flow label;
- We don't fully specify what the border routers must do;
- We should more fully specify what that hosts must do.
The argument for MUST is that we shoudn't allow an operator
to send packets into the open Internet with badly formed flow labels.
From the Internet's viewpoint, we don't care whether the border router
discards packets, clears the label to zero, or classifies packets and
sets a new pseudo-random label. And if a host doesn't do what is already
recommended, we don't care what it does; the border router has to
hide it.
QUESTION: Should we, and can we, further improve this text?
COMMENT: There have been various contradictory opinions. The most telling point
was that even if a network spews non-conforming packets, the only real impact is
to deprive that network's traffic of the full benefit of load balancing.
So maybe we are worrying too much, especially about strict pseudo-randomness.
Another point is that the text was intended to apply to origin domains, not transit
domains, and that wasn't clear. Also note that the new MUST added due to Issue 1
does simplify this point; it is in fact a sufficient condition
so we don't need normative keywords here.
PROPOSED RESOLUTION: Yet another rewrite (* * marks changed text):
2. To enable stateless load distribution at any point in the
Internet, a network domain *should never export packets originating within the domain*
whose flow label values are other than zero or *uniformly distributed.*
*However,* neither domain border egress routers nor intermediate
routers/devices (using a flow-label, for example, as a part of an
input-key for a load-distribution hash) can determine by
inspection that a value is not *part of a uniform distribution*. Therefore, if
nodes within a domain ignore the above recommendations to set
zero or pseudo-random flow label values, and such packets are
forwarded outside the domain, this *might* result in
undesirable operational implications (e.g., congestion,
reordering) for not only the inappropriately flow-labelled
packets, but also well-behaved flow-labelled packets, during
forwarding at various intermediate devices. Thus, a domain must
protect its peers by never exporting inappropriately labelled
packets *originating within the domain*. *This is why nodes using
a stateful scheme must not set the flow label to a non-zero and
non-uniformly distributed value* if the packet will leave their domain.
*If it is known to a border router that flow labels originated within the
domain are not uniformly distributed, it will need to
set outgoing flow labels in the same manner as described
for forwarding nodes in Section 3.*
--------------
ISSUE 10. Section 2 also says:
Forwarding nodes such as routers and load balancers MUST NOT depend
only on Flow Label values being randomly distributed. In any usage
such as a hash key for load balancing, the Flow Label bits MUST be
combined with bits from other sources within the packet, so as to
produce a suitable distribution of hash values.
Why is it restricted to "within the packet"? Couldn't the load balancer
use something else too, especially for a stateful mechanism?
QUESTION: Should "within the packet" be deleted?
PROPOSED RESOLUTION: As Jarno said, the statement is not exclusive. We can clarify this
by writing:
...the Flow Label bits MUST be
combined at least with bits from other sources within the packet, ...
--------------
ISSUE 11. In section 3:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY set the flow label value. In that case, it is
RECOMMENDED that the forwarding node sets the flow label field for a
flow to a pseudo-random value.
QUESTION: Should we suggest how the forwarding node identifies packets belonging
to the same flow? (draft-ietf-6man-flow-ecmp talks about this.)
PROPOSED RESOLUTION: Make it clear that this will normally be done per 5-tuple.
Actually we should also make that clear as the normal case for labeling by source nodes too.
--
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic