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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 20 Dec 2001 16:12:24 +0100

> 
  >  In your previous mail you wrote:
  > 
  >    I had a preliminary idea and was going to write something
  >    about it. Basically the sender can generate the flow label
  >    based on a hash of the source and destination port numbers. 
  > 
  > => this kind of things was already proposed... The main
  > objection is this reveals too much of the higher layer
  > and can conflict with the purpose of ESP (when ESP is used),
  > i.e. this can become a security threat.
  > 

=> It would be good if yu could point out 
a link perhaps to help me understand the reasons. 
If breaking the key is a concern you can do
things to fix that (e.g. like adding x below).

  >    If we want to make it 
  >    more sophisticated then we can add another number 
  >    to the hash input (e.g P1 || P2 || x).
  >    Where x can be something specific to this flow.
  > 
  > => so why not just x (:-)...

=> Well because not all applications have that
luxury of knowing an 'x' beforehand. 
Also you would have to define for each application
what 'x' means. Or define some behaviour in the
IPv6 stack based on some shared secret, which again
is not always available.

Cheers,
Hesham

  > 
  > Regards
  > 
  > [email-masked]
  > 
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 20:32:16 +0100

=> there are tons of mails in the archive of this list about that.

=> I agree but...

   
=> I still don't understand what is the difference between
x and hash(P1 || P2 || x) where x can be something specific
to this flow.
   
Regards

PS: I can read between the lines that an end-to-end usage of
the flow label is proposed. IMHO this is only a waste of bits,
the flow label is in the header in order to be available to
intermediate nodes. For end-to-end options, a destination header
fits better.
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 12:15:13 -0800

> intermediate nodes. For end-to-end options, a destination header

There is value in a mechanism that the origin host can trust that a
remote router will see its intent. If you are strictly talking about
endpoint conversations, yes using an extension header is appropriate.
The point is that an application needs to communicate with routers along
the path and know that some random transit administration hasn't changed
the message.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 12:13:04 +0100

Francis Dupont wrote:
...
> intermediate nodes. For end-to-end options, a destination header

There's nothing between the lines: the argument is *very explicit*
that we want e2e flow labels if they are to be of any use for QOS
(intserv, diffserv, or any future QOS solution).

An extension header is useless. It's too clumsy and too far down the
packet for line-speed hardware matching.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 17:03:32 +0100

=> I believe we agree: I never wanted that some random transit
administration may change my messages, in fact I'd like that all
random transit administration may only look at what is needed for
advanced routing, i.e. the IPv6 (and hop-by-hop if any) header(s).
Especially they may not look at upper layer elements like ports
which are nothing to do with routing: my idea is that upper layer
elements should be protected as the content of (surface) mails.
I have an anology about transparent when the moon is not gibbous
middle boxes: if someone takes your surface mail and faxes it
without your agreement to your correspondent post office you don't
consider this as a service improvement and you'll loudly complain
(argh! In American English the right term is "sue").

Regards

PS: so I am still happy if the zero label one-way mutability is
restricted to a router in the domain of the sending or receiving node.
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 18:33:08 +0100

=> I believe we have to define more accurately what are e2e flow labels:
 (1) information for the peer node
 (2) information for intermediate routers that doesn't change en route.

=> so your interpretation is (2)

=> but for (1) you should agree a destination option is better.

Regards

PS: I agree with (2) if end-to-end stands for domains (with as constrainted
as you'd like definition of a domain).
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 14:26:31 +0100

> => so your interpretation is (2)

Yes. There is a theoretical possibility of the destination host looking
at the label for internal dispatching, but I think that last place that
is really likely is in the destination NIC.

> => but for (1) you should agree a destination option is better.

Yes, probably.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org