Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 21 Dec 2001 17:18:24 +0100

=> I agree with nealry everything you said except
for one point I'd like to clarify below. 

  > In general, Tony Hain's arguments are pretty persuasive to 
  > me ... but I
  > am not sure that I would go as far as to prohibit all changes to the
  > label - though the only ones I would allow are where the source has
  > explicitly said that changes are OK (which an initial label of 0, or
  > we could reserve FFFFF for the purpose, could be defined to 
  > do, and some
  > flow state setup mechanism could also do).

=> Fully agree with this and all of Tony's comments on 
this thread. 
One point I'd like to clarify here is my suggestion that 
some other part of the stack (other than the application). 
can set the flow label.

The reason I suggested that (and I do think it's different
from having it set by the router) is that I've been looking
at some mobility scenarios in which a multihomed IPv6 MN 
can direct it's inbound traffic to certain interfaces
based on some internal policies (QoS, cost, BW ...etc
on each interface) using MIPv6 signalling. 
So in this case, if you end up with an application that
doesn't support the flow label or simply doesn't
care, it might still be a good idea to set the flow 
by another function in the IPv6 stack to be able
to identify the flow when signalling to the CN
or HA. 
So to be very clear, I was suggesting that for
cases where the applications have not set the flow
label, AND the host requires an e2e immutable
value. 

  > 
  > Also, everyone please note, just in case it isn't already 
  > clear.  When
  > anyone says the field needs to be immutable (in this case 
  > anyway), it
  > isn't (really) because anyone cares what value is delivered to the
  > recipient node - it is that we want to know what value will 
  > be observed as
  > the packet passes through each routing domain along the 
  > path.   That's
  > important.  It just happens that this is equivalent to 
  > saying that the
  > field must not be modified (perhaps with some specific exceptions).

=> Agreed. But some of the cases I've looked into would
require the end node (as well as routers along the
path) to verify the validity of the flow label. 
This is an addition to what you say and doesn't 
contradict it. 

Without some sort of semi secured flow label, the 
mutability requirement seems like a gentlemen's
agreement :)
The problem is that this is not verifiable, which
is why I see a benefit in using some hash function
to generate it. 

Hesham
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Fri, 21 Dec 2001 23:48:41 +0700

Date:        Fri, 21 Dec 2001 17:18:24 +0100
    From:        "Hesham Soliman (ERA)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | So in this case, if you end up with an application that
  | doesn't support the flow label or simply doesn't
  | care, it might still be a good idea to set the flow 
  | by another function in the IPv6 stack to be able
  | to identify the flow when signalling to the CN
  | or HA.

Sure.

  | => Agreed. But some of the cases I've looked into would
  | require the end node (as well as routers along the
  | path) to verify the validity of the flow label.

That is going to be an interesting challenge.   Good luck.

  | Without some sort of semi secured flow label, the 
  | mutability requirement seems like a gentlemen's
  | agreement :)

Yes.   As Glenn Morrow said in a recent message, if it can be altered
and there's a business imperative, it will be altered.

However, what counts is "can be altered" - that happens only if things
don't break when it is altered.   If packets get rejected because it is
being authenticated, and the alteration is detected - that's breaking,
so anyone who tried to fiddle such a field would find themselves with
no customers.   But that's not the only way for things to break, and
any breakage has the same effect.

The reason that people got away with altering the IPv4 TOS field was
simply that no-one cared - it was used for nothing in practice.   Had
there been applications that actually used it, or routing schemes that
depended upon it, it wouldn't have been able to be altered without the
s**t hitting the fan.

We don't need cryptographic type protection to avoid that kind of
manipulation - we just need to actually care what the value is.

kre

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 21 Dec 2001 11:28:26 -0600

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
To: "Hesham Soliman (ERA)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, December 21, 2001 10:48 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt 

> manipulation - we just need to actually care what the value is.

Some people care what is in every bit, including the TOS (QoS) bits.

We can only fit ICMP, UDP and TCP in IPv4++
http://www.dot-biz.com/IPv4/Tutorial/
http://www.RepliGate.net

Also, the Unir Project and Virtual Personal Computer (VPC)
uses a concept called Wide-Pipes. It runs in TCP. Those
are 16-bit wide pipes where each byte has a stream number.
It was the cover story in Dr. Dobb's Journal, #88, February 1984
for those that reference prior art.

The Netfilter Project: Packet Mangling for Linux 2.4
http://netfilter.samba.org
http://www.IPv8.info
IPv16....One Better !!

Jim Fleming
http://www.ddj.com/articles/search/search.cgi?q=fleming
Oct93: The C+@ Programming Language