Subject: A good point

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Sep 2001 15:03:52 -0500

Alex made a very valid point the other day:

> It would look like a 
> silly, technical weakness,  to have a field as read-only, 
> but with no mechanism for the final recipient to detect whether 
> it was changed or not. 

In other words, even if we declare that the flow label MUST NOT
be changed en route, since it is not authenticated by IPSEC
there is no way to tell if somebody does in fact change it.
So it is not a safe e2e field, even if we define it as an e2e field.

  Brian
--------------------------------------------------------------------
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: Thomas Narten <[email-masked]>
Date: Wed, 05 Sep 2001 07:46:51 -0400

> So it is not a safe e2e field, even if we define it as an e2e field.

In the cases discussed so far (i.e., QOS), I doubt that the final
recipient will care what the value of the Flow Label is. So being able
to verify its end-to-endness may not really be an issue.  I.e., if the
packet got there, the destination is presumably happy.
 
Routers, on the other hand, will presumably look at the Flow Label as
part of packet classification. Will it also need to somehow verify
that the Flow Label is legitimate? That would need seem to need
cryptography, which raises the question of how the routers along the
path learn the necessary keys.  One could imagine inventing a way for
routers to obtain the keys and do the verification, but that seems
like a high-cost operation. And what is the exact benefit? Would
routers need to do this? For every packet? I suspect they would not,
even if it were possible.

If we look at the Flow Label as a purely unused field and we later
decide that it needs to be end-to-end unique, it is unclear that IPsec
needs to cover it. Depends entirely on the semantics of the field. In
any case, if an intermediate router modfies it, and that causes the
recipient to do the wrong thing when the (modified) packet arrives,
isn't that analogous to a router modifying (say) the IP version field?
If routers just modify any field in the IP header without regards to
what impact that has, we're in big trouble already.

Thomas

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 5 Sep 2001 16:40:48 -0700

> what impact that has, we're in big trouble already.

Witness NAT :)

Actually we have this problem today because network operators
have been led to believe that diffserv is all about giving them
the power to remark the DSCP at their whim. Since they don't 
want to build the mechanism which would allow financial feedback
to curtail abuse from the source, they simply assume the 
received values are bogus and mark them without even looking at
anything except the port values.

Tony