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

From: [email-masked]
Date: Thu, 20 Dec 2001 14:13:26 +0200

Francis,

You wrote:
>  In your previous mail you wrote:
> 
>    The current draft states that a non-zero label could be 
> changed by an
>    intermediate node to a non-zero value. However, during the 
> discussion on the
>    topic in SLC it was concluded (IMO) that this is 
> undesirable, and it would
>    be more useful (and sound) to keep the value always 
> immutable (end-to-end).
>    
> => I disagree: if the end node is too dumb to set itself the label
> (i.e. just uses in any case the zero value) and the first router
> for instance sets the label when needed then the zero value should
> not be immutable. I don't use dumb hosts (:-) but it seems 
> this kind of
> things already commonly happens for RSVP in the real world so 
> we should
> keep the door open... So I fully share Robert Elz's opinion.

It was your input on this list that prompted us to put that option in the
draft. However, in the meeting we discussed the topic, and my perception was
that the room did not want to have this (the possibility for a router to
change the value from zero to non-zero). I know that you disagree with this.

What Robert explained in his previous message was that IF the end-to-end
value can be changed (as written in the draft), then AH couldn't be changed
to protect the value AND deal with the change.

However, if the change from zero value to non-zero value is banned, then the
end-to-end value would always be immutable, and AH could be changed to
protect the end-to-end value. But, as I pointed out in the message you
partially quoted, this would be a problem, if the AH implementations at the
source and the destination would not agree on what fields to protect.

Anyway, my point was that since AH has quite limited use in the real world,
it might not be worth the trouble, even if possible. I never suggested the
routers in the middle to mess with AH.

The analogy to the situation with RSVP is not 100% applicable. We could make
all the IPv6 sources to mark the packets with flow labels, even if they had
no interest in participating in any kind of resource reservations. If we
could raise the bar for the "dumb hosts" to do this, the other end of the
connection could still utilize flow label based classifiers.

The "dumb host" and "smart router" scenario has other problems as well. For
example: 

- what if your default router goes down, and you start using another? How
would you make sure that the flow label would be marked the same way by the
new router?

- Or assume that the host distributes different flows to different default
routers. How will you guarantee that the routers will not pick the same flow
label values (which would be a problem if the flows go to the same
destination)?

- Or what if the host is "dumb" only with some flows, but will assign flow
label values for some other flows. How will you synchronize the flow label
setup in the host and the router?

> 
>    AH: It could be possible to change AH, but it might not be 
> worth it.
> 
> => Robert Elz has just explained why we must not change AH...

That was based on the assumption that the zero flow label can be changed by
a router to a non-zero value. See above.

> And it seems you don't understand that AH can't really help to protect
> something in transit, i.e. intermediate routers have not the key and
> can't verify the AH MAC.

Well, there must be many things I don't understand, but about this I have no
confusion. I didn't think it necessary to point out that IPsec AH integrity
check will be performed by the IP interface identified by the destination
address only.

	Jarno
--------------------------------------------------------------------
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: Thu, 20 Dec 2001 13:35:18 +0100

[email-masked] wrote:
...
> change the value from zero to non-zero). I know that you disagree with this.
Seems that we need to ask for WG opinions on this. I prefer not to endorse
this kind of kludge, but as long as we don't change AH, it has little practical
importance what we write in the document.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Dec 2001 19:44:03 +0700

Date:        Thu, 20 Dec 2001 14:13:26 +0200
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | However, if the change from zero value to non-zero value is banned, then the
  | end-to-end value would always be immutable,

Really?   When I read the draft I saw three modifications permitted.
The (pretty silly) modify and unmodify case, which is immutable, so that's OK.
The "start at zero" case - which apparently now might be deleted (I wasn't
in SLC to hear the discussion, but I have no opinion on this either way).
And the "by prior arrangement" case.

Even if the zero case is deleted, isn't there still the other one?

I am just trying to understand what this draft may become in its next
revision.

  | - what if your default router goes down, and you start using another? How
  | would you make sure that the flow label would be marked the same way by the
  | new router?

In that type of scenario, one typically has only one router.  Or if one
has 2, they're both configured the same way.   Which isn't to say that
doing this is a good idea - but it also isn't impossible.

  | - Or assume that the host distributes different flows to different default
  | routers. How will you guarantee that the routers will not pick the same flow
  | label values (which would be a problem if the flows go to the same
  | destination)?
  | 
  | - Or what if the host is "dumb" only with some flows, but will assign flow
  | label values for some other flows. How will you synchronize the flow label
  | setup in the host and the router?

Any of these can be handled by administrative control if necessary (the
first few bits in the flow label identify the source - 0 -> original host,
1, 2, .. N identify a router).

Smart routers are possible, not necessarily smart though.

kre

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 17:55:01 +0100

=> as we don't really know how to use flow label IMHO to remove
a well-known scenario from the space of possibilities.

=> I didn't say that dumb host/smart router is good, I did say this is
a common scenario. But I am tired of flow label discussions, usually
they go nowhere. Please count me as a "keep current (non) specs" supporter.

Regards

[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Dec 2001 10:22:50 -0800 (PST)

> they go nowhere. Please count me as a "keep current (non) specs" supporter.

   So here's the end-game for the flow label
   allowing for dumb hosts/smart routers: MIDCOM.

   Can we just say no?

	  Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 15:06:31 +0100

Can we just say no?
   
=> right fight, wrong forum...