Subject: Re: RFC 3697bis Open issue 9

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Feb 2011 20:00:03 -0500

FWIW....

I agree with Joel. I'd like Flow Labels to remain immutable *except*
in the case where it is zero. I know we can't enforce that, but that
is the principle we should continue to support, and devices that
violate this principle should be flogged by the Protocol Police. :-)

I think we really do want the Flow Label to retain end-to-end
meaning. That is, it's contents are created as close to the
originating source as possible, since the source probably has the most
information available to set it sensibly.

That means a first hop router or a router at the originating site's
boundary should be able to change it from 0 to something sensible. I
view this is a sort of optimization that allows the Flow Label to get
set to a useful value even in cases where the host can't be upgraded 
to do that. I do not want to encourage routers elsewhere in the
network to be modifying the Flow Label.

We should not just say that because we can't enforce that Flow Labels
in received packets satisfy certain properties, we should give up and
let it be modified in any way anyone sees fit.

My view is that we are just relaxing the Flow Label semantics a little
bit. We aren't completely changing them. I think we can do this, while
still preserving the original intent (at least in most aspects). No
need to change the semantics of the Flow Label any more than the
minimal necessary to make it useful for load balancing.

IMO, the old text in the document should just be tossed. It makes no
sense to me and I don't understand what it is trying to say. :-(

If someone can explain to me what the intention of that text is, or
what thinking motivated it, that might be useful. :-)

E.g.

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

So, If I'm an AS out in the middle of the network, and I'm forwarding
packets I don't originate, I'm *required* to reset the Flow Label
value because I have no idea if they satisfy the above properties? Say
it ain't so!

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

Correct. But this isn't necessarily fatal either.

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

Reordering? I don't understand why this is so.

Congestion? Maybe, but it is going to far to  say "likely".

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

Right. And Bad Guys are really respectful of doing the right thing
that the spec says in order NOT to be Bad Guys...

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

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Feb 2011 20:31:27 -0500

I'm not an RSVP expert, but I wonder if the wording at issue comes
from the notion that (in some cases) the receiver is the one that
actually initates flow setup (in the reverse direction) and wants to
tell the routers what Flow Labels the source is using. The source is
labeling the packets, but is not actually involved in doing the Flow
Setup (and indeed, may not even know it is in use).

I think it is OK to drop the words.

Thomas

Jarno Rajahalme <[email-masked]> writes:

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

> Full context:

> "The minimum level of IPv6 flow support consists of labeling the	
>    flows.  IPv6 source nodes supporting the flow labeling MUST be able
>    to label known flows (e.g., TCP connections, application streams),
>    even if the node itself would not require any flow-specific
>    treatment.  Doing this enables load spreading and receiver oriented
>    resource reservations, for example."

> The phrase "receiver oriented resource allocation" was intended to refer to a case where a receiver of a flow allocated resources for the flow (e.g. on a radio interface). This could be useful where the source considers the traffic best-effort, but where the destination wants/needs better than best-effort treatment (without involving the source in any way).

> It is OK for deletion.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Feb 2011 20:36:51 -0500

Jarno Rajahalme <[email-masked]> writes:

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

IMO, "MUST NOT" is the wrong word.

What we want to say here is that it is possible for intruders, Bad
Guys, and broken implementations to produce packets in which the Flow
Label is not identical to its original value. Implementations MUST
(SHOULD?) take necessary steps to protect themselves from being
vulnerable to DOS and other types of attack that could result.

Or something like that.

I.e., give the implementor some practice advice, rather than making
this a protocol requirement.

And if we have some examples of the kinds of bad things that an
implementation should look out for, list a few of them.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Feb 2011 15:52:40 +1300

> value because I have no idea if they satisfy the above properties? Say

That certainly wasn't the intention. The intention was to say that
a domain that is mucking with the flow label internally must not export
packets with mucked-about flow labels.

The problem here is (and I think we basically agree) that we don't want
people to do strange things with the flow label, but we know that we can't
detect if they do. I'd like to have normative language that allows
the protocol police to prosecute if somebody exports strange flow labels.

Now, getting back to another of your points, if somebody does (for
example) export every packet with the flow label set to abcde, the
worst this can do in the load-sharing model is make the hash function
work less well. So maybe the current text worries about this too
much?

> Correct. But this isn't necessarily fatal either.

Agreed.

> Reordering? I don't understand why this is so.

If they break the rule that all packets of a given flow carry the
same label, reordering can happen in an ECMP or LAG scenario.

But of course the traffic that suffers is the traffic with
wrongly set labels, so maybe we don't care.

> Congestion? Maybe, but it is going to far to  say "likely".

Oops, I thought that had been changed to "might".

> that the spec says in order NOT to be Bad Guys...

Well, this is where the protocol police would come in. But actually
it seems that this is going to hurt the Bad Guys' own traffic more
than anyone else.

>>>>         change outgoing flow labels.

I'm inclined to change my mind about this and simply make it a SHOULD
with the observation that traffic that breaks the rule will not get
treated correctly further downstream.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Feb 2011 15:56:17 +1300

> I think it is OK to drop the words.

Yes. A flow label can in theory be signalled in an RSVP TSpec,
but that is outside the scope of 3697bis, as long as we do the
appropriate text clean-up about stateless v stateful v signalled
methods.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Feb 2011 16:03:38 +1300

> implementation should look out for, list a few of them.

OK, something like

   Although the flow label is defined as immutable once it has
   been set to a non-zero value, implementers should be aware
   that it 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.

      Brian

---

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Feb 2011 09:02:12 -0500

>    vulnerable to denial of service and other types of attack that

This sounds about right.

To put this in perspective, routers can't assume the source or
destination address in a packet has not been modified since leaving
the originator. But that doesn't cause us all to Freak Out! :-)

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Feb 2011 08:34:53 +1300

> the originator. But that doesn't cause us all to Freak Out! :-)

Correct. There's a subtle difference though - if the flow label
alone has been changed, the packet has in fact been delivered
to the correct place and any reply packet will be sent to the
correct place. So the attacks and side-effects are a bit different
than if one (or both) addresses were changed.

   Brian