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 PROTECTED]
--------------------------------------------------------------------
