Subject: Comments on draft-carpenter-6man-flow-update-02

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 12:14:52 +0200

Hello Authors of draft-carpenter-6man-flow-update-02 at
http://tools.ietf.org/html/draft-carpenter-6man-flow-update-02

I have some comments.

   "a.  "The Flow Label value set by the source MUST be delivered
        unchanged...
    b.  "IPv6 nodes MUST NOT assume any mathematical or other
        properties...
    c.  "Router performance SHOULD NOT be dependent on the distribution
        of the Flow Label values...

  The second two rules appear to forbid a usage in which... However,
  both before and after these rules were laid down, a considerable
  number of proposals for use of the flow label have been published...
  Examples... These authors propose use cases in which some combination
  of the following options apply: o  The flow label may be changed by
  intermediate systems..."

Er?  The logic sounds flawed.  You seem to be saying that earlier
Authors complained about "b" and "c".  But then you say they suggested a
solution where "a" is addressed too.  So actually they complained about
"a" too?  Not sure I understand what they wanted.

> The purpose of the proposed change is that the flow label should be
> available for domain-specific use, with locally defined semantics,
> without preventing uses that are compatible with RFC 3697.

Ok, but then make sure one considers coherently a Host being _in_ xor
_out_ of that domain.  Sometimes these usages can be mixed.  If we say a
Host _within_ the domain will _not_ set the Flow Label then we can't say
that the intermediary Routers within that domain will change it: because
it's hard to imagine a Router is not a Host at the same time.

> 1.  If and only if the flow label in an IPv6 packet has the default
> value of zero, then a router MAY set it to a value between between 1
>  and 0xFFFFF.  This option modifies the rule that the flow label must
>  be delivered unchanged, by allowing exactly one router to set it if
>  the source host did not set it.

I believe this may pose problems.  The case is when the sending Host1
does not set the Flow Label and the receiving Host2 knows somehow (e.g.
the app protocol is older than new Flow Labels) that H1 doesn't
implement Flow Labels and so expects "0" zero from it.  When H2 sees a
flow label set then it deduces something is wrong, because it knows H1
couldn't set it.

In RPL there's talk proposing "restoration" of the Flow Label at the
exit point, but I don't agree with that either.

> packets leaving the local domain may contain flow label values that
> are not pseudo-random

For some reason I have difficulty understanding "not pseudo-radom": does
it mean actually "random", interpreted as a double negation?  Does it
mean "not random but can't talk random because true random doesn't
exist"?  The implications of this clarification are wide I believe.

> The flow label is not protected in any way and can be forged by an
> on-path attacker.  On the other hand, a pseudo-random flow label
> cannot be readily guessed by an off-path attacker.

That "OTOH" makes think that because pseudo-random flow labels cannot be
guessed then the Flow Label is protected against on-path attackers.  I
don't think much protection is afforded by the use of visible be them
random numbers.  Were it public-private-keys then yes but here we don't
talk Flow Labels as security keys, at least because of the obvious
performance requirements.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 15 Apr 2010 08:43:18 -0700 (PDT)

I agree with Alex's comments.

I think that flow label field in IPv6 header is IPv6 design's soft underbelly. I can understand and appreciate Brian Carpenter's efforts on trying to resolve this issue.

My suggestion for Mext (and Netext) usage is to assign the first 16 bits of the flow label as FID.

Regards,

Behcet

----- Original Message ----
> From: Alexandru Petrescu <[email-masked]>
> To: 6MAN <[email-masked]>
> Sent: Thu, April 15, 2010 5:14:52 AM
> Subject: Comments on draft-carpenter-6man-flow-update-02
> 

I 
> have some comments.

  "a.  "The Flow Label value set by the 
> source MUST be delivered
      unchanged...
  b.  
> "IPv6 nodes MUST NOT assume any mathematical or other
      
> properties...
  c.  "Router performance SHOULD NOT be dependent on 
> the distribution

The 
> second two rules appear to forbid a usage in which... However,
both before 
> and after these rules were laid down, a considerable
number of proposals for 
> use of the flow label have been published...
Examples... These authors 
> propose use cases in which some combination
of the following options apply: 
> o  The flow label may be changed by
intermediate 
> systems..."

Er?  The logic sounds flawed.  You seem to be 
> saying that earlier
Authors complained about "b" and "c".  But then you 
> say they suggested a
solution where "a" is addressed too.  So actually 
> they complained about
"a" too?  Not sure I understand what they 
> wanted.

> without preventing uses that are compatible with RFC 

Ok, but then make sure one considers coherently a Host being _in_ 
> xor
_out_ of that domain.  Sometimes these usages can be mixed.  If 
> we say a
Host _within_ the domain will _not_ set the Flow Label then we can't 
> say
that the intermediary Routers within that domain will change it: 
> because
it's hard to imagine a Router is not a Host at the same 
> time.

>  the source host did not set it.

I 
> believe this may pose problems.  The case is when the sending Host1
does 
> not set the Flow Label and the receiving Host2 knows somehow (e.g.
the app 
> protocol is older than new Flow Labels) that H1 doesn't
implement Flow Labels 
> and so expects "0" zero from it.  When H2 sees a
flow label set then it 
> deduces something is wrong, because it knows H1
couldn't set it.

In 
> RPL there's talk proposing "restoration" of the Flow Label at the
exit point, 
> but I don't agree with that either.

> may contain flow label values that

For some 
> reason I have difficulty understanding "not pseudo-radom": does
it mean 
> actually "random", interpreted as a double negation?  Does it
mean "not 
> random but can't talk random because true random doesn't
exist"?  The 
> implications of this clarification are wide I believe.

> The flow 
> label is not protected in any way and can be forged by an
> on-path 
> attacker.  On the other hand, a pseudo-random flow label
> cannot be 

That "OTOH" makes think that 
> because pseudo-random flow labels cannot be
guessed then the Flow Label is 
> protected against on-path attackers.  I
don't think much protection is 
> afforded by the use of visible be them
random numbers.  Were it 
> public-private-keys then yes but here we don't
talk Flow Labels as security 
> keys, at least because of the obvious
performance 
> requirements.

Alex

--------------------------------------------------------------------
IETF 
> IPv6 working group mailing list
> href="mailto:[email-masked]">[email-masked]
Administrative Requests: > href="https://www.ietf.org/mailman/listinfo/ipv6" target=_blank 
> >https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2010 11:41:26 +1200

Thanks for the comments. Extracting:

On 2010-04-15 22:14, Alexandru Petrescu wrote:
...
> flow label set then it deduces something is wrong, because it knows H1

Indeed, I think we should make it clear that receiving hosts MUST NOT
rely on the flow label for any kind of upper layer behaviour. That is
a missing rule in RFC3697, I think.

> exit point, but I don't agree with that either.

That is *required* by the existing rules of RFC3697.

> exist"?  The implications of this clarification are wide I believe.

OK, good point. What is intended by "not pseudo-random" is that
it's either assigned systematically (e.g. 1, 2, 3...) or that the bits
are encoded with some special meanings. I don't like to write plain
"random" because most network nodes don't contain random number
devices.

> guessed then the Flow Label is protected against on-path attackers.  I

What? Not at all. On-path attackers can observe and/or forge any flow
label. But as draft-blake-ipv6-flow-label-nonce shows, they can have
value for making off-path attacks harder.

> performance requirements.

Indeed not.

   Brian